<!-- Content Here -->

Radio Silence

You might have noticed that I haven't been posting here much over the last year. More likely, you haven't noticed at all. Blogs are often like that. They come and go depending on the whims of the blogger.

The reason for my silence is that my focus has shifted from pure content management to lean product development, web application development, and cloud-base architecture. At Lionbridge, I have been helping to build a business called Lionbridge onDemand. It has been a little over a year since our first sale and I am in a constant state of amazement about how things are growing. Like most of my projects, we followed a lean product development model of launching a minimum viable product and continually improving it to support the needs of our growing customer base. In this case, we started with a tiny website to translate videos. Since then we have grown to the point where:

• We now have a wide array of services that support nearly 40 different content types. We even have services that do not involve translation at all such as proof reading and CRM data cleanup.

• There are enterprise sites for many name-brand clients. It turns out that large organizations are full of individuals who prefer a simple consumer style eCommerce experience. With onDemand Enterprise, we can quickly create a custom site for a corporate account. These enterprise sites have the same simple "consumer" feel but they also have the ability to offer custom services and can tap into corporate payment channels.

• We have a Public API with a developer program. We started with an API for eCommerce systems to translate product catalogs; but then we grew into a full featured translation API that can handle our full complement of content types. While there are other translation APIs out there, ours is unique because it exposes different translation services ranging from pure machine translation to professional translation by subject matter specialists.

• We are now a global team working around the clock to deliver projects with industry leading quality. We have operations specialists in North America, Europe, and Asia. Managing a service like this requires a special mix of problem solving skills. This is content management at a level of complexity that I have not seen before. The process requires the constant attention of highly skilled and conscientious individuals.

The last point is my favorite. I am currently en route from Warsaw, Poland where I have spent the last five weeks working with the operations core team. It was an incredible experience to meet the people that I had only known through email and conference calls. From the start, I was impressed by their dedication and can do spirit. Now they feel like family.

So, back to this blog. What has made Content Here a worthy endeavor so far was that it provided a useful place for me to explore observations and concepts that I encountered as a content management professional. If I learned something, I would flesh out my knowledge by writing it here. If I did a decent job of explaining something to someone, I would reproduce that explanation here. If that was all blogging did for me, it would have been enough. But blogging provided so many more benefits. In particular, it was a way to connect with other people. I made many business connections and friendships with this blog.

I am hoping that I can continue experiencing these benefits by shifting the focus of this blog to be more aligned with my day to day work. It won't be a total departure from my older posts. My involvement in web development and open source software has stayed the same. But I will probably write a lot less about content management software, product selection, taxonomy, workflow, and other pure content management concepts. To be honest, I feel like there is not much more for me to write on those topics. There will be more posts about my experiences from growing a web business. Topics will include things like working with distributed teams, lean product development, customer support, web application development, and web operations.

Hopefully, along the way, I will meet new people who are struggling with these same topics. The web is a pretty big place so I think that chances are good.

Internet Explorer, you did it again

I learned something new about IE9 today. Apparently, when visiting a site in the same domain as the computer, IE9 defaults to compatibility (quirks) mode. I am guessing that this is Microsoft trying to accommodate crappy intranet sites (cough cough SHAREPOINT cough cough).

So, if your site depends on standards mode, you might find that it looks fine in the real world but not in the office. I work remotely and this has burned me twice. Both times my launch celebration was cut short by complaints from colleagues in the office who saw broken pages.

Now I know.... And you do too.

Hat tip to Marjoe Bacus for letting me know about this "feature".

Chaining DNS Entries

Warning: geeky network admin post

I see a clear trend of marketing groups taking over full responsibility for their organization's digital presence. This includes maintaining various publishing systems such as the web content management system and running the website hosting infrastructure. Once you go down this path, you need to get with IT and start dividing up ownership of the different systems. Some of these decisions are easier than others. But the hardest one is often the DNS — which maps domains and subdomains to actual servers. Both groups have a legitimate claim over the name server. IT needs to make sure that email and other back office systems are properly mapped. Marketing needs to be able to route external audiences to the right applications. Both groups are afraid of the other group accidentally causing an outage by deleting or updating domain records that they shouldn't be touching.

To work around this problem, I recommend chaining DNS entries across two sets of name servers like this:

In this pattern marketing registers a domain for its private use. What the domain looks like doesn't matter because nobody will see it. Then marketing sets up DNS entries for public subdomains like www and points them to the IP addresses of the servers or other network infrastructure (like load balancers) that host the sites. Then the IT group create DNS (CNAME) entries in their name servers that point to the marketing entries. The end result is that a browser looking for the IP address behind www.example.com will be referred to get its answer from www.examplemktg.com, which will return the correct address.

Why is this useful? If marketing wants to temporarily or permanently move a site onto different hardware, no coordination is needed. Marketing has full control over what the domain is mapped to. This may not sound like a big deal but imagine it is 3AM and your primary hosting infrastructure goes down. Relief from your disaster recovery setup is just a DNS update away. But the IT help desk is offline or can't reach anyone from network operations to make the change. Your urgent request would just have to wait as audience associates your brand with 500 or Server Not Found errors.

CMS Adoption. Think Vertical, Not Horizontal.

"Adoption." For years that word has been on the top of the list of critical success criteria for any web content management initiative. "This project will fail if we don't achieve sufficient adoption." The goal of adoption instigated the CMS industry's usability crusade that brought us improvements like better rich text editors and in-context editing. Still, as I have written in "The Myth of the Occasional CMS User" (and Jeff Cram took one step further with "Step letting people use your CMS"), people don't clamor to use a CMS no matter how usable it is.

The truth is, most successful websites are managed by a proportionally small team of dedicated professionals. Gerry McGovern makes this point very eloquently in "Decentralized publishing equals amateur web management."

In most situations, the decentralized publishing model has been disastrous. The people trained tended to be relatively junior staff, for whom publishing to the website was just one more responsibility. The result was lots and lots of poor quality content that was never updated or reviewed.

Does this mean that we should give up on adoption? Hardly. But I do think our thinking about adoption has been all wrong. Most people measure adoption as the number of users who consent to using the platform. The more people using the system, the greater the adoption. I call this "horizontal adoption" and, like Gerry says, it is a recipe for failure.

Forget about horizontal adoption and focus instead on vertical adoption.

"Vertical adoption" is a measure of how much the CMS is used. High vertical adoption means using advanced features of the platform. Vertical adoption has always been pathetically low in web content management. Back in 2006, Lisa Welchman nailed it with her post "The Six Million Dollar WYSIWYG Editor." Nothing has changed. Most of those flashy features that you see in a software demo are hardly used and the problem is getting worse, not better. Most CMS customers are simply not ready to handle today's advanced Web Experience/Engagement Management functionality. I can't tell you how many customer references I have talked to that only use the most basic features. And the software vendors are as concerned as I am about this. At least they should be. If vertical adoption doesn't improve, customers will migrate to cheaper, simpler software.

Of course, vertical adoption isn't just about protecting license revenues for enterprise software companies. If we don't improve vertical adoption, we will never achieve meaningful digital marketing goals. The best that we can do with horizontal adoption is to have more people to fix spelling and grammar errors (and Gerry would argue that outcome is unlikely). If we want to truly engage an audience, we need power users that can get the most out of personalization functionality and uphold the company's side of the conversation.

How do we improve vertical adoption? That is the billion dollar question. There is certainly a usability component to vertical adoption but it is different from usability aimed at horizontal adoption, which focuses on reducing training by making things intuitive and point and click. Usability for a power user assumes expertise and focuses on power and efficiency. Look at an expert in any software. They use keyboard shortcuts. The user interface appears to dance in response to the slightest movements of the operator. But to the novice, these user interfaces can be inscrutable. Remember the Saabre terminals back when we went to travel agents to book our vacations? Is anyone else that old?

Achieving this level of expertise requires training and specialization. You need guidance from other experts and you need a lot of practice. This means that your marketing operations program has to have reached a critical mass where you are doing these initiatives more or less continually. Advanced functionality (like personalization or lead nurturing) is not something that you get right in the initial deployment and then put on auto-pilot. You only get results when you actively use them. Incidentally, most systems integrators are primarily focused on content modeling and template development. They are not very good at the using advanced functionality within the context of a real content strategy — like looking at the full lifecycle from planning to analyzing the results.

Most organizations are really far from this level of operational maturity. They probably know these truths to be self-evident at some level; but they are all too willing to suspend their disbelief when a software vendor tells them that, with their solution, advanced digital marketing is so easy that even the CEO could do it. On the other side, I can see the temptation of the software vendor. A lot of these customers are still justifying budget for software with an ROI based on cost savings. Better tools equals less effort equals smaller team. Would you risk being the only vendor in a selection saying that your solution will raise operational expenses by needing to hire more staff?

As an industry, I think we would all benefit if we focused on promoting vertical adoption by:

• changing the conversation from "look how easy it is to edit a web page with our CMS" to a more realistic view of web operations.

• setting realistic expectations for team size and composition.

• helping to focus attention on marketing performance goals.

• promoting professional services and mentorship programs to help keep customers on track.

• identifying and recognizing teams that are doing it right.

Until we improve vertical adoption, the CMS industry will continue to run around in circles and customers will never get the results that they hope for.

How to have success with technical freelancers

Over the past year, I have had the opportunity to work with some excellent technical freelancers. These relationships have been both professionally and personally rewarding. However, I also understand that for every one freelancer success story, there are many disasters. In fact, as a consultant, I have made a living out of cleaning up freelancer messes. Here are five tips to help you be more successful with your freelancers.

1. Don't use a freelancer to bring in a skill that you don't' already have in your organization

   If you hire a freelancer to do work that your team doesn't understand, you are setting yourself up for trouble. First, you will have no way to evaluate his/her level of skill and the quality of work he/she produces. Second, you will not be able to maintain the code or systems that the freelancer builds when the project is done and she moves onto other projects.

2. Use a publicly hosted distributed source control system (DVCS)

   Host your project on an externally hosted Git or Mercurial repository. This will allow you to try out freelancers with minimal risk. They can fork your repository and take on some development tasks and you can review their work before merging it into your own repository. If a new freelancer doesn't work out, just disable access.

3. Cast the net wide and filter

   The only way to really get a sense of skill and compatibility is to start working with someone. People who look great on paper and can talk a good game are not always as competent as they appear. It is also easy to dismiss diamonds in the rough. Some of my favorite freelancers were very shy when I started working with them and would have been easy to overlook. With a DVCS and the ability to review work, you can assign development tasks to several developers and see who rises to the top. Just be sure to assign meaningful work and pay freelancers for their time.

4. Connect

   Respect, trust, and communication are all critical to any relationship (personal and professional). Even though your working relationship with them may be shorter, treat freelancers with the same respect that you would give to a full time colleague. If the freelancer comes from another country, you have a great opportunity to learn a little about his/her culture and make a friend in a far away place. From my work with freelancers, I have seen a side of international current events that I would never see on CNN or the BBC. When you have these strong bonds, you get better commitment, better product, and a more enjoyable working environment.

5. Learn comfort zones

   Everyone has their strengths and weaknesses. In a new working relationship, it is natural for anyone to underplay their weaknesses. Who starts a job interview by listing all the things that they stink at? The only way to understand someone's strengths and weaknesses is to assign a variety of tasks and see what comes back. Usually, people will start with the work that they feel most comfortable doing. Once you have recognized a few strengths and built a level of mutual trust, you can have more candid conversations about comfort zones. Some people like to focus on work they have the greatest confidence in doing. Others like the challenge of learning new things. The greater understanding you have about personality and comfort zones, the better you will be able to assign work and also evaluate work product. For example, if one particular developer likes to stay inside his comfort zone, you should just assign tasks within that skill area and you can be confident that the work will be done well. If a developer likes to learn new things, you can assign him challenging problems but you better have more rigorous quality controls.

I honestly feel like this is the future way of working. Through strategic and effective use of freelancers, you can make your organization more nimble and responsive. Companies that are not able to use freelancers will be slow to start new initiatives or avoid doing them altogether. On a personal level, you can learn so much by working with a diverse set of freelancers with different experience and styles. It is also nice to build new friendships — it's even more fun than having a pen pal.

Never use cost savings to justify spending more on a CMS

Replatforming your website to a new web content management system is an expensive proposition. In fact, a CMS migration can be so expensive and risky, that I advised many of my CMS selection clients against doing it. That is not to say that there are not perfectly legitimate reasons to replace a CMS. The wrong CMS can hold you back and prevent you from seizing valuable opportunities. But one sure fire way to spot a foolish CMS replacement project is when it is justified by a return on investment (ROI) calculation that relies on future labor cost savings to offset the price of an expensive CMS.

The truth is, if you make a big CMS investment, you will probably spend more time managing your content and optimizing the experience for your visitors. Why? Because advanced (expensive) web content management systems allow you to do more sophisticated things like personalization, multivariate testing, and advanced analytics. If your CMS has these features, you better actively manage them because neglecting advanced engagement functionality is worse than not having it in the first place. Buying an expensive CMS to avoid the human effort of managing a website is about as silly as buying an expensive car because you want to spend less time driving.

If you must show an ROI projection to justify the cost of a new web content management system, focus on the top line. Talk about the value (or potential value) of your content. Talk about the opportunity to reach new markets or connect with potential customers in new ways. And make sure to set aside plenty of budget for people to operate and get the most out of that CMS. To learn about all that goes into effective an marketing operations program, see me present at the Now What Conference next month.

If you want to treat your website like a project where you "do the website" and then forget it about it for a few years, I would seriously consider ripping out your CMS entirely and build a nice static brochure website that you can cheaply host. If you just need to make occasional updates, there are lots of cheap and free web content management products available. Many of these products can take you pretty far as you increase the intensity of your digital marketing program. But if you want to go high end, your initiative will fail unless you build a competent marketing operations program that gets the most out of the technology.

Complex Systems

I have been loving the book Web Operations: Keeping the Data On Time

. It is indispensable reading for anyone responsible for hosting a web application or any important website. As the editors say, web operations is an emerging field with little in the way of training programs or officially sanctioned best practices. Nobody is classically trained. The best web ops people grew up in the field and learned from other greats and being faced with tough challenges.

One of the book's chapters is a reprint of an academic article called How Complex Systems Fail by Richard I. Cook. Interestingly, this article wasn't written about Web Ops at all. Richard Cook is an MD and he was writing about hospitals and healthcare. But the similarities with web ops are striking. It's a quick read and it's free. The points that were especially salient to me were:

• "Complex systems contain changing mixtures of failures latent within them."

  The more fault tolerance you add, the more unnoticeable little failures become. And even when you notice them, issues can be fleeting and too difficult and/or not important enough to fix. You just live with them. Even if you have a very simple set up, the cloud hosting service that you are running it on is incredibly complex — so complex that it can suffer from living organism diseases like auto-immune vulnerabilities. When adding yet another layer of complexity to make your system more resilient, sometimes you introduce more potential for failure that may reduce the health of the overall system. Our hosting infrastructure has lots of redundancy built into it. But sometimes I yearn for simpler times when I had one physical server that I just rebooted when things got ugly.

• "All practitioner actions are gambles."

  There are a few points in the article that deal with post accident analysis. As frantic as it feels to have a site outage, the author is talking about much higher stake failures (he's a doctor, remember). But his analysis is right on. Whenever we do anything, we are making a gamble — no matter how much we test. Sometimes the risk of the gamble is much less than the risk or opportunity cost of doing nothing. But you can't always tell. It is easy to get down on yourself or your team when a mistake is made or a failure occurs. But as the article says: "That practitioner actions are gambles appears clear after accidents; in general, post hoc analysis regards these gambles as poor ones. But the converse: that successful outcomes are also the result of gambles; is not widely appreciated." In other words, system improvement depends on gambles.

• "People continuously create safety."

  The point here is that you can't make anything totally idiot-proof. In the world of web ops, you can script things but you always need experienced people thinking about what they are doing and keeping an eye on things.

• "Failure free operations require experience with failure."

  This point really extends the previous point. The only way people get experience is by facing failure. In the early days of my career (amazingly, nearly 20 years ago), I worked in a tiny I.T. department serving a large and rapidly growing company. Our team was brilliant but inexperienced and we were constantly faced with new problems that we had to solve under pressure (my favorite was our "total network crash" that was actually the folding card table that held all of our servers collapsing). We all learned so much and everyone on the team went on to a successful career. But we wouldn't have learned anything if everything went smoothly. As a side note, I experienced more appreciation from the user community during those years than since. People saw that we were creative, dedicated, humble, and fearless. We didn't have that dysfunctional I.T. v.s. business dynamic. We were all in it together.

I know that the message I have been sending is that marketing I.T. is complex and messy and you just need to deal with it. To an extent, this is true. But it also means that whenever there is an opportunity to simplify something, you need to take it. I see every piece of unjustified complexity as a risk with unknown cost. It is easy to relate to the added up-front cost of adding a little flourish that makes an application more interesting. It takes experience to understand the long term cost of maintaining something that is more complicated than it needs to be. Even if that clever code is lucky enough not to break when something else changes, it will perpetually need to be circumnavigated by others who barely understand how it works. Before long, you have a culture of people who are afraid to touch things and cruft is inevitable.

If there is a way to do something in a more direct way, take that approach. When thinking of development costs, budget for the cost of maintaining that code. Prioritize refactoring and refinement over adding new features. Make is suck less. Most of all, don't let your complexity outgrow your capacity to manage. it.

SiteChecker Plugin for ServerDensity

A couple of weeks ago I wrote a post describing how to make sure that your fail-over sites are running properly. At the time, I was sending the results via email. Since then, I improved the process by turning the logic into a ServerDensity plugin (I mentioned that we use ServerDensity here: Marketing I.T. in the Cloud). It was pretty easy to do. The only thing even remotely clever that I did was cache the results in a file so that I didn't have to check the sites every 5 minutes (which is the ServerDensity agent run frequency). Here is the code

Monitoring your hot standby

As I mentioned in "Marketing I.T. in the Cloud," we maintain a hot-standby infrastructure on another hosting service. We automatically refresh this standby setup at a regular interval so that, if something really bad happened to our primary infrastructure, we could just re-point our domains and relatively recent versions of our sites would be back up.

Because this backup infrastructure is so critical, we monitor it just like our production infrastructure. One thing we have not been able to automate, however, is the check to make sure the front page is loading properly. The problem is that Wordpress forces a redirect to a primary host name. That is, if you try to hit the IP address of the backup server, it will redirect to the primary domain of the site (like http://www.globalmarketingops.com) which is still running on the primary servers. The fact that the redirect even happened told you Apache is running and Wordpress is able to read from the database. But you wouldn't know if the pages were broken. This is a little like driving around with a flat spare tire. You know you have it but you don't know it is useless until you try to use it.

Our work-around has been to manually edit our hosts file (which overrides the DNS) and browse the site on a regular basis. But that is a drag. I couldn't find a ping service that allowed me to override the public DNS with temporary mappings. So I came up with something much simpler.

I edited the /etc/hosts file of the backup server to map the supported domains to itself (localhost). With that setting in place, we can run a script on the backup server that loads the home page of each of the sites and verifies that each homepage contains certain text. The script sends out a pass or fail notification. If the server was too broken to run the script we would not get the pass notifications and other alerts would sound. If we get a fail notification, we know that we need to fix the backup site.

This is a pretty common challenge so I hope others can benefit from this simple solution.

One Field Job Application: Epilogue

A few people have been asking me about how my One Field Job Application experiment turned out (preliminary results here). We ended up hiring two excellent technical web PMs. Gerry Tamakloe works out of our Dublin Office. Gerry is a powerhouse: helping teams get the most out of our systems. He is not afraid to get into the details of an application and optimize it for an internal or external customer. Katie Methe works with me here in Massachusetts. In addition to managing projects, Katie handles deployments, QA, troubleshooting of our websites and GMO applications. I bombarded her with new stuff on her first day and she didn't even flinch.

In addition to finding some great people, this little experiment has reassured me that I am not unreasonable in expecting a web project manager to be capable of both managing people and doing technical tasks. A web project manager should rise to, rather than shrink away from, a technical challenge. Rather than just distributing work, A good web pm adds value to everything he/she touches: whether it be verifying and diagnosing a defect, deploying a fix, doing technical research, or configuring software.