I recently wrote a piece directed at marketers reminding them that it is important to keep their IT folks in the loop all the time. This is important so they can get the best advice, counsel and work the IT folks can offer. It’s a topic I talk and write about quite often.

As is usually the case, there is another side to the coin. The IT folks have to be willing to communicate as well.

As in any relationship, the one between Marketing and IT is a two-way street. Each side has to be willing to work with the other and offer the best they have to the relationship. Each side has abilities and strengths the other lacks. By combining skills, knowledge and efforts, the entire organization benefits.

It goes without saying that Marketing and IT have different missions within an organization. But, where those missions overlap, it is in each groups’ best interest to cooperate for the good of everyone. Sometimes this involves compromise and sacrifice. Isn’t that true in any relationship?

Here’s my challenge to my IT counterparts in 2012: Reach out to your Marketing colleagues and try to find meaningful ways you can help them succeed. Look at their business objectives and see if you can find ways to help meet them. Not only will you learn more and expand your horizons, you will help the whole business do better. And that, my friends, is what it’s all about.

What say you? Are you in a corporate IT group and have a good relationship with your Marketing counterparts? What kinds of things help the relationship? Please feel free to share any tips in the comments.

photo credit: mikecogh

I hereby claim I coined the term “Tech Support Custom Code Cop Out.” This is described as a lame excuse used by some tech support people to avoid dealing with a difficult issue a customer has with software or a service they purchased.

This has happened to me a few times – and it’s really annoying. I’m certainly not saying that tech support people should be expected to support someone else’s totally custom application. But, when just a couple of things are changed in a product which is customizable and the person calling for help has clearly documented the changes in their tech support request, this excuse becomes unacceptable.

Here are a couple of examples of what I mean.

Once I was helping a friend who ran an online art gallery. He decided to go full on with an e-commerce site, adding a shopping cart while keeping some list pages organized in categories as he had on his straight HTML site. I recommended a new host for him which had a built-in shopping cart application he could rent. I figured there would be no problem recreating the look of his “old” site (which was working very well for him).  I’d merely put all the products into the shopping cart database with a category flag and then query up the data to put into his list pages.

No problem, that is, until I tried to find information on creating a connection string to the database on the host’s web site. I found nothing. No examples, not even a mention of it. Now keep in mind this is a major shopping cart host, not some rinky dink outfit.

So I went through the support forums. I saw lots of people asking the same question, but no answers. I found that strange, but I carried on with my task.

I eventually ended up emailing their support. My request went something like, “Please tell me how to do a connection string to my client’s data on your service. I have the database name, user name and password, I just need the server name  to connect to.”

A couple days later I got a reply, which went something like this: “We’re sorry, that’s custom code. We don’t support custom code.”

That made me go, ‘Hmm.” I replied to that message pointing out there was no custom code yet, because without a connection string I really couldn’t even get started writing the custom code. I didn’t need any help with the data queries or anything like that, I just needed to know how to connect to the database. A database which they, no doubt, already had connection strings for or my customer’s shopping cart wouldn’t work.

The answer back was exactly the same, “Sorry, that’s custom code. We don’t support custom code.”

I went back and forth three or four more times, always with the same answer. No help, no how. Needless to say, I do not recommend that host any more.

More recently, a work colleague and I were troubleshooting the administration piece of another shopping cart. (Coincidence?) My colleague did some major work on the CSS files for this product but just a couple small custom user controls were added to the code in order to display a little extra data on our products display pages.

We tested, and everything worked properly in our test environment. Once we moved the files to our production server, however, the admin piece started failing. We went through troubleshooting ourselves. When we couldn’t find a problem, she went into their help forums and found a couple of possible fixes, but nothing would get us past the error. Finally, when we could do no more ourselves, she opened a support ticket.

The first answer: “You did custom code on your site. We can’t support your installation because of this.”

My colleague replied that the customized parts were not in the admin section, but their reply was the same. She finally documented the changes she made, showing that they had nothing to do with the administrative portion of the software. Still, the reply was the same.

Good news: My colleague found a solution on her own. Still, it’s kind of sad she had to slog through their code for a couple of days before she found the problem. They, likely, could have found it much quicker. And it had nothing to do with any customization she did.

We Have To Do Better
Again, I’m not expecting  a software vendor to support a complete customization unless they wrote it all themselves. But in these two examples I don’t think the requests for support were unreasonable. It looked to me like the support folks were trying to close the tickets as quickly as possible, regardless of whether or not the customer was satisfied. Service after the sale is important – and this ain’t it.

Here’s another thought: If you’re a vendor, what if you had a couple of tech support people on staff who could help customers regardless of their customizations? Now that would be rock start support. Would you have to ask higher prices or perhaps a premium on your maintenance fees? Yes, but I’ll bet a lot of customers would find it worth the extra cost. That could be the one thing to differentiate you from your competitors.

What say you? Have you been a victim of the Tech Support Custom Code Cop Out? What do you think about it? Have you ever been on the other side? I’d love to hear from folks on the support of the issue. Please feel free to share in the comments.

photo credit: Lazurite

Last week I read two excellent articles on IT and Marketing working together (or not) which got me thinking quite a bit. The first was “IT + Marketing: Innovation Through Collaboration in B2B Software Companies” by Julie Hunt, the other was “I own the technology, you own the content” by Eric D. Brown.  Go check them out because each writer makes some excellent points.

Let Me Put On My IT Hat
Those of us who read Scott Adams’ “Dilbert” comics are familiar with the character “Mordac, The Preventer of Information Services.” While we can laugh at the silliness of those comic situations, there is a bit of tongue in cheek truth to what is portrayed.

Often, we IT folks are looked at as spoilers and inhibitors. What I often hear and read from those frustrated people is like a line from the old Five Man Electrical Band song: “All we hear is ‘Do this, don’t do that, can’t you read the signs?’” In this case the signs come in the form of a policy document or a banner across the monitor screen of someone trying to accomplish their mission. Their frustration goes up and out come the comparisons to Mordac.

Unfortunately, what these people don’t realize is that we’re just doing the job delegated to us. We’re tasked with making sure the enterprise’s network and data remain secure. No one wants to go through the nightmare of a T.J. Maxx or Epsilon security breach. Many IT Departments are understaffed, overworked and looked at as merely a cost center and not a business multiplier. In this type of environment, the easiest way to head off security issues is to raise the shields and plug up any holes found in the perimeter.

Switch To The Marketing Hat
What marketers really need are flexible systems which allow them to reach out to customers wherever they are.  They need to be able to reach out via email, web sites and social media spaces. While IT development shops dabble in Agile Development, marketing shops need and want to get into what Scott Binker calls Agile Marketing. When we run into what looks like an IT roadblock, we get frustrated and don’t feel protected or secure. We just want to get our mission accomplished.

Can’t We All Just Get Along?
So, how do we get going in the right direction? Is there any skipping along arm in arm down the yellow brick road? I think there can be. It’ll take some work and a whole lot of communication, but it is possible for all sides to accomplish their individual missions while still working together to bring about success for the overall organization.

Department Ambassadors
I once worked in an organization where work was divided into different “shops.” Each shop had its own mission, leadership and way of doing things. Work was supposed to flow from front to middle to back. The front and back offices were supposed to react to priorities based on guidance from the home office while the middle shop had a supporting role in helping the work flow between all three shops. In reality, though, this rarely worked out. What usually ended up happening was the front and back shops argued over what the home office meant by priorities while the middle shop sat back out of the fray and waited for the dust to settle.

The leadership of the front and back shops decided to smooth things out. Instead of two committees of people interpreting home office directives each shop appointed a liaison to work with the other office. All communication was funneled between these two. They made the decisions how home office directives were to be interpreted and those decisions could only be overridden by the managers of their respective shops.

To be sure, it took a little time to work out the kinks in this system. After a few weeks of working things out, though, work flowed much more smoothly. Production went up and arguments went way down. Everyone benefited from this arrangement – even the home office took notice.

There is a lesson to be learned. I propose those IT and Marketing departments who find themselves in disagreement consider having an in-house technology summit. At this meeting, sit down and discuss the challenges each side faces in an open and honest way. At the end, with guidance and direction in hand, appoint a person from each side to be the liaison who will be empowered to communicate and help make decisions on behalf of their department. Let those two work out the priorities and permissions and bring the results to their respective departments.

Oh, and don’t pick the new person to do this. The one tasked with this job needs to be taken seriously. Appoint your best and brightest so the job will get done right.

And don’t forget: You’re all on the same team. In the end, overall success of the organization benefits everyone.

What about you? How do you smooth out communication between departments. Do you think a “Department Ambassador” program will work at your shop? Please feel free to share in the comments.

Back in the day, when I first started building web sites, controlling file sizes and download times were a critical part of the process. This was in the days of dialup. For those of you who grew up in a broadband world you have no idea how unimaginably slow some sites would render. Back then, it was important that image tags specified height and width of images so they could act as placeholders. This allowed the text of the page to download on the visitor’s screen in the right place so they could at least read the text while the images downloaded. And those images had better be small, or else. I remember chiding many clients for trying to put 1MB PDFs or 100K images on their sites.

Today, we take broadband for granted. Download speeds are so fast, that the occasional multi-megabyte PDF doesn’t faze most people. Some of us (yes, including me) have gotten a little lazy when it comes to optimizing images and other files for size. Some of our code is bloated and filled with redundancies. Still, for many of our customers, these things don’t really matter. Or do they?

Ah, But It Does Matter
There are two main reasons why download time really does matter: Consider mobile and SEO.

Mobile Browsing
It’s a given that mobile browsing is becoming a larger and larger share of overall internet usage, and that share will continue to grow as time goes on. Think about your customers using their mobile device to visit your site. If they are running on a 3G connection, depending on their provider they can download at speeds from 350 kilobits to 1.7 megabits per second. Those speeds are under optimal conditions and can be/are often slowed by such factors as weather, network congestion, distance from the tower, tall buildings or trees and a host of other things.

While on average your mobile visitors can expect speeds faster than dialup, are they going to wait patiently while the beautiful 150 kilobyte image on your home page downloads? Chances are they won’t, especially if they are stopped at a red light trying to find your address or phone number.

SEO Considerations
I remember during Search Engine Strategies, San Jose in 2006, Google was already warning that Adsense relevancy scores were going to be tied to download times of the landing pages the ads led to. Since then, they have started using download speed as a signal for organic search results as well. I haven’t heard anyone specifically mention Bing using download speed as a relevancy signal, but I can well imagine if they are not using it now they eventually will.

To illustrate this point, Aaron Shear reported in his presentation at last week’s PubCon South during the Advanced SEO Tactics session, that performance gains alone accounted for a 5% increase in traffic to web sites he monitors because of better placement in SERPs on Google. How fast are your pages downloading? Could a performance gain help your placement in SERPs? It’s certainly something worth considering.

Speedometers
There are a couple tools you can use to check your download speeds. My employer uses Webmetrics as an outside monitor to alert if the web sites go down. Part of their weekly report shows download times for monitored websites from their multitude of monitoring sites along with  a comparison to the average of all web sites they measure. This is a paid service, but it might be worth the cost for keeping tabs on downtime and download speeds.

A great free tool is the download speed indicator found inside Google Webmaster Tools. This shows you how long it takes to download your pages, “straight from the horses mouth,” so to speak. Google Webmaster Tools has so many other great features, I highly recommend signing up and using it to help you manage your sites better.

Speeding Things Up
If you find your pages are taking more than 4 seconds to download, there are some things you can consider doing to speed them up:

• Check your image sizes. If you have images on your pages larger than, say, 50 kilobytes, consider putting in some smaller images with options to click for a larger version. Making sure text is text and not embedded in images will not only make the images smaller, it will help search engines index your content better.
• Consider ditching large Flash movies if you have them. If you have one of those “Please wait while the content loads” things on your home page, your Flash movie is too large. Consider moving the “cool” content to other pages with links to it from the home page.
• Use CSS to control the look of your site. This helps eliminate redundant code by taking many style-related tags off each page and refers back to the CSS file, which can be downloaded once and used from the visitor’s local cache.
• Watch for code bloat. If you have CSS files and you’re no longer using some parts of it, delete those parts out. Copy and paste unneeded lines into a text file somewhere off the site if you think you might need them again.
• Consider moving your images and CSS files into a cloud service with distributed data centers. This can help speed up your downloads because bandwidth for these services is usually higher and multiple locations offer better speeds for visitors because files download closer to them. This isn’t usually a cheap solution, but if you have a large web site it could pay off quite well.

What about you? Have you wrestled with download speeds to improve visitor experience and/or SERP placement? Feel free to share in the comments.

Last week I did a quick poll in preparation for my presentation at PubCon South next month. I asked IT folks what they wished their marketing colleagues better understood so they (the IT people) could better help them.

I only had a few responses with some additional email discussion so I can’t claim definitive results. But, the general sentiment among those who responded was that the marketers they work with don’t understand the technology used by the IT folks.

Now, that’s not to say that the IT people are mad at their marketing counterparts. I believe they really want to help, but sometimes are hampered by the lack of knowledge of the people they work with.

Enter the Marketing Technologist
Marketers: here is a chance for you to get into a growth area of your field. Rather than looking at this as just another “challenge” to deal with or proof of the “struggle” with the IT Department, look at this as an opportunity. Join the ranks of the Marketing Technologists.

There is a huge need and a growing demand for marketers who understand technology to the point where they can do some of the tasks traditionally done by IT people. Look at how much marketing is going online. It only stands to reason that IT cannot support everything Marketing needs to do. Someone has to come in and fill the gap. That could be you.

Develop a skill set which includes traditional marketing as well as IT skills. You don’t need to be a class-A coder (but that certainly wouldn’t hurt). To begin with, start learning to use and understand the technology already around you. Dig into it a little bit and pick up some of Marketing’s technology tasks your IT Department doesn’t have the resources to support. As you learn, you’ll be far better equipped to work as a partner with your IT folks when you do need their assistance.

For more information on this, I highly recommend you follow Scott Brinker’s Chief Marketing Technologist blog. He has some great ideas about what a Marketing Technologist should be as well as interviews with people who have already crossed the line and stepped into the Marketing Technologist role.

In preparation for my presentation at PubCon South next month, I thought it would be an interesting learning experience to ask IT workers what they wish the marketers they work with understood to help them work together better. I first posed the question on LinkedIn and got quite a discussion going via email with those who answered.

From those answers and the subsequent email discussions, it would appear that for those who answered the biggest pain point is the lack of understanding of the technology the IT folks use.

In the interest of continuing the discussion and helping everyone learn to work together better, I pose the question here:

Poll for IT folks who work with marketers: What’s one thing you wish your marketing colleagues would understand which would help you work better with them?

I’d very much like to hear your opinion. Please feel free to answer in the comments below, on LinkedIn or on Quora.

This is a “Lesson Learned” for me as well as a reminder for you who are admins for web sites running on IIS.

For years it’s been best practice that when you move web site content from one place to another, to set a permanent server-level redirect so search engines will know to remove the old addresses from their index and add the new addresses in their place. No problem, we all do this.

Over the past several years, my colleagues and I have been coding background processes of our web sites in ASP.NET. Over that time, we’ve converted many applications from Classic ASP. Some applications were outright moved as they were converted based on guidance from our Marketing Department.

In one case, we had an old press release application, written in Classic ASP, which we redid in ASP.NET and moved. Being the student of SEO, I set up a permanent server-level redirect in IIS to the application’s new address. “Done and done,” or so I thought.

Fast forward a few years and we find ourselves troubleshooting a vexing problem with one of our servers. Through the course of the investigation, we found something very interesting. Those Classic ASP pages in the folder of which the server-level redirect was set were still firing; this despite the fact that the IIS server was set to automatically and permanently redirect visitors to the new page.

We did a number tests on those pages and confirmed our findings: the underlying Classic ASP code was, indeed, running before the visitor was redirected to the new page. The redirect happened so quickly that the end user was completely unaware it was happening.

From a security standpoint, I should have known better than to leave old code on a web server. That is a classic “no no” and a possible opportunity for hackers to come and exploit your system. Thankfully, that didn’t happen.

From me to you, here is a reminder (or a tip if you’ve never heard this before): If you move web pages from one address to another set up a server-level permanent redirect on the old folder, then archive and delete the old pages from the server. This keeps your server cleaned up and gets rid of any old code which might be exploited later down the line.

photo credit: Andrew Mason

Screen shot of the main Google Wave page

Last week Google announced it was pulling the plug on Google Wave. When introduced, it was touted by some to be a revolutionary new way to communicate online. Some opined it would replace email, instant messaging and a host of other communication methods. I didn’t think it was “all that and a bag of chips” and certainly not a replacement for email, but I found it quite useful for collaborative projects and described why in my November 2009 article entitled, “Google Wave – Great Potential For Collaboration.”

Many have pointed out Wave’s flaws, and there certainly were some as there is in any new tool. Here are good examples, some which have points I agree with:

• “Let’s Celebrate Google’s Biggest Failures” by Danny Sullivan
• “Why Google Wave Sucks, and Why You Will Use It Anyway” by Martin Seibert on TechCrunch
• “Google Wave’s Unproductive Email Metaphors” by Robert Scoble

Most of the people I talked to about Wave either didn’t get how it could be useful (an argument I hear against using Twitter all the time, too) or that it was too slow (which it was at times).

Despite its shortcomings, I found Wave to be rather handy and used it in a number of collaborative projects. There were others who saw the potential it had and used it with some success, notably Chris Brogan, who wrote a number of times he used it on a project with his Trust Agents coauthor, Julien Smith.

• “How I Came To Love Google Wave” by Chris Brogan
• “How Google Wave Could Transform Journalism” in the L.A. Time Blog
• “Google Wave In Real Life” by Mitch Wagner on Computer World

So, in the end, was Wave a colossal failure? Was it a good idea gone bad or an innovation looking to fill a need that wasn’t there? Call it like you see it. No matter what anyone else may believe about Wave, I applaud them for at least trying.

Sometimes you just can’t tell if an idea is good or bad until you try it out. In cases like with Wave, what looks great in the laboratory just doesn’t quite make it out there in real life.

I will miss Wave on occasion, but not too much. I’ll go back to doing what I was doing before Wave came out. I”m sure another tool is in the offing. Perhaps one a bit easier to “get” and use.

What about you? Did you like Google Wave? Why or why not?

I’ve referred to Scott Brinker’s blog “The Chief Marketing Technologist” a couple times now. Scott has some great ideas on how marketing folks should harness technology and take command of it.

Over the weekend, he came out with a brilliant article stemming from his “Rise of the Marketing Technologist” post which I wrote about back in April. Go check it out here: The Marketing Technology Manifesto.

I recently read an article by Scott Brinker on his Chief Marketing Technologist blog entitled “Rise of the Marketing Technologist” which really caught my attention. In this article, he advocates Marketing Departments have someone on staff who Scott calls the “Chief Marketing Technologist” (CMT). Rather an adding another layer of management, this person would report to the Chief Marketing Officer and be the subject matter expert on the technical aspects of marketing. The CMT would be a technically-minded marketer who would coordinate with IT on matters where collaboration is needed, but mostly be responsible for helping Marketing harness online and other technical resources to further their aims.

Scott rightly points out that IT and Marketing have very distinct missions and goals and thus have differing priorities. By having a technical person on staff, Marketing can move much faster with online initiatives where direct IT support is not needed.

The CMT …

• … is in on Marketing’s plans from the outset and throughout any campaigns.
• … helps the marketing team make strategic and tactical decisions on which technologies would be appropriate for a given project/campaign.
• … evaluates what in-house resources are available and needed.
• … moves forward with implementation of plans when they are made.

The CMT would only call on IT for those things which they need to directly support, and coordinate for outside technical resources as needed. Because the CMT goes through this screening process at the outset of projects Marketing gets their stuff done quickly and efficiently, and IT has more time to devote to their missions because they don’t get involved until they are truly needed.

My Thoughts On This
Last October, I posted an article, “Communication is Key – The Funnel Effect” where I recommended that when Marketing and IT Departments work on a collaborative project, each department should appoint a point of contact person who would take all communication from their counterpart and distribute as needed. All communication between the departments would funnel through these people in order to better track the messages going back and forth. Rather than this becoming a new bureaucracy, I looked at this system as a way to avoid lost and duplicate communication. (Note: since then I’ve used Google Wave as a tool for communication on collaborative projects. It’s worked quite well and may eliminate the need for this communications “funnel.”)

Expanding on Scott’s idea, the person on the Marketing end of this type of collaboration could very well be the CMT. This would be the person who would speak IT’s language, as it were, and know best what they need to be given in order to successfully complete the project.

Also, right around that time, I posted an article entitled “Agile Teams” where I described how small teams could be pieced together using personnel from the Marketing and IT Departments to work on short-term projects. I suggested it might even be a good idea to temporarily move these people into an office space together to facilitate faster completion times. A person who could very likely lead such a team would be the CMT.

Scott has some brilliant ideas on his Chief Marketing Technologist blog. If you are a technically-minded marketing person or a marketing-minded technology person I think you will get a lot out of his writing.