Nov 25, 2013
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.
Oct 15, 2013
"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:
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.
Sep 03, 2013
-
You sweated over SEO but forgot to set your robots.txt to allow. Fail.
-
Your content is brilliant but you can't drive traffic to it. Fail.
-
You bought all the right keywords but your content stinks. Fail.
-
You have the content that a visitor wants but you show him something else. Fail.
-
You target the right content to a visitor but the display gets in the way of his enjoyment of it. Fail.
-
Your content goes viral but your site crashes. Fail.
-
Your visitors are devouring your content but you wouldn't know because your analytics isn't tracking properly. Fail.
-
Your visitors are ready to engage but they can't find a call to action. Fail.
-
Your visitor fills out a form but the data goes nowhere. Fail.
-
You are capturing leads but nobody is doing anything with them. Fail.
-
You have valuable data but no actionable insight. Fail.
We have all been there. We focus on one aspect of digital marketing but neglecting another critical step eliminates our impact. To be successful, you have to be good at lots of things and pay attention to the details. It is better to be proficient in all of the dimensions of digital marketing than to be excellent in any one. So much for the hope that you are just "one viral video" away from achieving your most ambitious marketing goals. Welcome to the grind.
Aug 28, 2013
Over the years I have seen well over a hundred web content management system demos. I have even done a few myself. But it doesn't take watching many demos before you notice that they all follow the same general patterns. "Watch me change this page." "This is how I find the content I was looking for." "Doesn't this demo website look nicer than yours?" OK, the last one is more implied than said. In this era of Web Experience Management, there are some new elements to the story. "See how this page looks differently to different audiences with different intents on different platforms?"
Don't get me wrong. I still get excited by the possibilities of technology that can show a visitor the perfect content in the ideal format. The problem is that achieving this goal assumes that the user knows what the perfect content and ideal format are. But we don't — not by a long shot. The best we can do is preview a page pretending to be a visitor; and that takes a lot of guesswork.
The missing element in this story is the visitor. That is significant because the visitor is the heart of WEM. After all, the "E" in "WEM" stands for the visitor's experience, not the experience of the content editor previewing the page. How do we get the visitor into the center of the demo's narrative? It is hard to switch back and forth between the visitor and the editor without making the demo appear choppy and disjointed. Besides, as I said earlier, we usually don't know as much about the visitor as we would like to.
Perhaps a better way would be to use data to represent the visitor. Having done demos, I know that showing transactional data (like web traffic) is a real challenge. You need to have lots of recent data to make the demo look realistic. This is why the analytics segment of a WCM demo usually falls flat. The demo environment usually just has a few hits — not enough to see any real trends. That said, wouldn't it be great to go through a scenario that begins with realistic visitor traffic data?
I could imagine a story that started in an analytics area with the identification of an under performing section of the site. Perhaps, you are getting search traffic on the wrong key words. Maybe a lot of people get to the page but then you loose them. Maybe you dig a little deeper and you notice particularly low conversion rates within what you thought was a high potential audience segment. At this point you could show how you reconcile audience segments between the analytics package and the WCMS personalization engine. That is, the CMS might have a "big spender" visitor profile, but how do you see that same population on the analytics side?
From there, you might validate that these visitors are seeing what you configured them to see. Going deeper, you might notice that "big spenders" are predominantly coming from mobile devices. You preview the personalized page on a mobile emulator and, BAM, the answer hits you in the face. The graphic that you thought would be so compelling to this group doesn't scale very well on mobile and makes the page unusable. Only then do you start editing content.
There could be many variations of this story but the key point is that the platform is helping solve the biggest obstacle to engaging visitors: understanding them. I would argue that unless you understand your visitors to this level, you shouldn't even touch personalization functionality. You are not engaging visitors; you are stereotyping them and then ignoring them. You may even be making their experiences worse because you haven't really tested what they will see. You are flying blind. What kind of business value is there in tool that facilitates unproductive tasks? I would argue less than none.
Aug 21, 2013
Last week, when we released a new version of Lionbridge onDemand, I was reminded of a valuable lesson: keep your deployments small. Up to that point, we had been upgrading the production environment on a regular basis — nearly daily. When a new feature was ready, we deployed it. But this development iteration had some systemic improvements (new service types, enterprise features…) so we held off to release everything at once. That was a mistake. The problem was that lots of configuration changes had been building up (new settings, new libraries on the server, etc.) and that led to a lot more work at launch time. As you would expect, some steps were missed that compromised functionality. It wasn't a huge deal. Nothing was obviously broken. There were just some "Oh SNAP!" moments along the way.
Thanks to that reminder, we are back on schedule with regular code deployments. Some of the updates will be "under the waterline" — invisible changes to the underlying architecture to support visitor facing features that we are still working on. The trick is to keep the back-log of un-deployed code to a minimum. In addition to reducing the risk of the actual deployment, smaller upgrades make it easier to troubleshoot issues because there are fewer potential causes. For further reading on this topic read Eric Reis's chapter on Continuous Deployment in Web Operations: Keeping the Data On Time
. David Hobbs also has some great articles on this topic in relation to website launches. The one that springs to mind is Site Launches: do as little as possible. Also, to work in this way, it is also critical that you use a mature code management strategy. A couple of months ago my team adopted the Git Flow branching strategy and it has been a huge help.
People getting used to this model of product management will find it counter-intuitive. They see upgrades as risky, scary things and the natural tendency is to avoid them. But the more you delay an upgrade, the scarier and riskier it gets. And that creates a vicious circle. Even if you know and agree with the small deployment approach, it is easy to justify delaying an upgrade because you want to do one more thing. That is what happened to me.
Jul 23, 2013
Global businesses operate on a 24 hour workday. No matter what time it is, somebody is trying to get something done - whether it be a customer trying to interact with you or it could be an employee trying to do her job. This can make system maintenance (such as deploying new website functionality or upgrading some business application) a challenge. Of course, we do our best to minimize or eliminate the amount of downtime a deployment causes. In fact, my team regularly deploys new code across our applications several times day (yay, automation!). However, there are also deployments that you try to schedule outside of peak load. Perhaps, there will be brief periods when the system is unavailable or in an awkward transitional state. So the question is, when do you do these deployments? We look at three factors:
-
The first thing we look at is the business calendar to make sure we are aware of any events that might drive traffic. For us, this could be a marketing campaign or, for our business applications, it could a peak in workload (like a deadline). It's a good idea to have a mailing list of primary users and announce upgrade plans to them. They will tell you if there is an issue with your schedule.
-
The second thing we look at is daily load patterns. All of the systems that I manage are running on Amazon Web Services using Elastic Load Balancers so my favorite tool for this is a CloudWatch ELB Request Count report. That shows nice regular daily spikes of traffic to your sites.
-
The third, and possibly most important, thing we look at is our own work patterns. While the load patterns may tell you to do your deployments at 3AM, don't do it. You could be tired and careless at that time of night. Plus, you will probably want to go to bed right after and that would be the worst time to be sleeping. Configuration errors usually take a little while to surface. You don't want to wake up the next morning to find an inbox full of frustrated users who lost large chunks of productivity.
Using this logic, we typically find our best upgrade windows to be at unexpected times like 2PM Eastern on a Wednesday. During this time: most of Asia is sleeping; Europe is enjoying dinner; and most of the Americas is having lunch or in a post-meal coma. At this time, we have our full team on hand for testing and remediation if anything goes wrong. And we get to sleep well that night knowing if anything were to go wrong, it would have done so hours ago.
One caveat: this strategy probably won't work for you if you are delivering a high traffic service with a ridiculously stringent SLA. But if that is your business, you should probably have an around-the-clock, 3-shift dev-ops staff and lots of people planning and managing deployments.
Jun 25, 2013
In my many years of collecting requirements for content management systems, I can't think of a single project where the word "flexibility" wasn't on the initial list of requirements. This "requirement" seems harmless enough. What could be wrong with the system being flexible? Flexibility seems like the perfect thing to ask for when you don't really know what you want. But it's a trap. Here is why.
Everyone who hears the word "flexibility" takes it to mean "being able to do whatever I want with the platform." But what that means depends on who you are and what you are personally capable of. For example:
-
If you are a content creator, "flexibility" may conjure up an image of MS PowerPoint where you can make text boxes and pictures wherever you want on the page.
-
If you are a web designer, you might imagine being able to edit pages as if they were static HTML where you could write whatever markup, CSS, or Javascript that you wanted. And every page could be a unique creation.
-
If you are a print designer, you might picture editing one big image in Photoshop where you have precise control over every pixel and don't have to worry about annoyances like browser support or different displays.
-
If you are developer might think about structured data that is re-usable and can be controlled by display template logic.
The interesting thing is that these expectations are usually mutually exclusive. The content producer's unstructured PowerPoint document is garbage to a template developer who whats to make global changes or adapt the display of the content for different contexts and audiences. The structured content model and display templates are inflexible to the content producer who doesn't know HTML and doesn't have access to develop and test code. An image produced by a graphic designer is a black box to anyone who doesn't have the source file and the right software to edit it.
And this is why everyone consider's their current CMS inflexible and tries to prioritize flexibility the next time around. But the process just repeats itself again and again.
The first step to breaking out of this cycle is to strike the term "flexibility" from the conversation entirely. Every time someone says the word, he needs to put a dollar in a jar. You can't move forward together if your interpretations of a word are diverging. After that, start talking about "balance of control" as in who controls what on the page. Stake out your territories. This doesn't have to be a land grab. Have mature discussions about control vs. responsibility and the ongoing maintenance implications of these decisions. Educate each other about your different perspectives. Talk through scenarios of what might need to change and who should need to participate in that change.
Most importantly, you should avoid thinking in absolutes like "flexible" or "inflexible." When you talk about balance of control, you are more likely to have productive discussions about moving boundaries rather scraping the whole system because it is "inflexible."
Jun 13, 2013
We have all been there. We launch a new website and, interspersed with general praise and appreciation, there are some hysterical complaints about trivial things like a word-wrap or a punctuation mark. The tone on these emails is similar to someone who just received their huge wedding invitation order and saw that their name was misspelled. They are mad and want immediate resolution to avoid mortal embarrassment on their special day. Ironically, it doesn't seem to matter that the old website was a total disaster. This site is new. It should be perfect.
If you are on the receiving end of one of these complaints, you know how easy the issue is to fix. You know it is nothing like re-printing 500 wedding invitations with gold leaf on expensive paper. You just edit the content in your CMS and republish. In fact, you fixed the problem in the two minutes that elapsed between receiving the urgent-flagged email and the frantic follow-up call. You also know that the content that is the target of the complaint has a shelf life of only a couple of days. In fact, you consider the entire website to be dynamic and constantly evolving. What you launched was not a bunch of static pages but new layouts, branding, and infrastructure to support your dynamic digital marketing program.
In retrospect, it is easy to see where the disconnect started. The internal audience for the site had not seen anything since they fell in love with the mockups. And the mockups were perfect — artificially perfect. The designer put in just enough text to make the layout look full, but not crowded. The PDFs that were distributed didn't depend on a specific screen resolution or browser. The audience was expecting to see those polished PDFs sitting in their browser on launch day; but what they got wasn't exactly the same. Add that to the fact that the web team appeared to vanish after the last site was launched and their anxiety is understandable.
How do we correct this? The number one thing you need to do is keep up the pace. You can't take a break after the new site is launched because that leaves the impression that the site is "complete." You know that launch day marks the beginning of a new phase of your digital marketing program, but if you act like you think your are done, you are bound to get into discussions with people trying to prove to you that you are not. The conversation invariably focuses on the site being "defective" rather than what it really is: a work in progress. Keep the site changing and be transparent with your road map. Regularly communicate with people who have ideas and update them on your progress.
Also, justify your decisions with data. When you relaunch a site, people will often look for their old content to make sure it is still there. If you removed it or re-organized their content, be prepared to explain why. The traffic was low, the content was redundant, the page was competing with more important pages on search results… these are all good reasons to retire a page. The fact that you can respond in this way shows that you are still engaged and moving forward in a thoughtful way. This will further re-enforce the idea that this is a journey and you are a competent and attentive driver.
Depending on your organization's culture and history, breaking out of a "print-final website" mindset might be easy or hard. Generally, the more web savvy your internal audience is, the easier it will be to change people's minds. The older guard will be more difficult to convince. Your line of reasoning should go like this:
Remember how perfect the last website seemed at launch? Well, it only seemed perfect because it was rigid. The designers got it just right and then locked it down through QA. But it was also brittle and it started to crumble from the moment we started to change content. New browser versions and platforms only hastened its decay. This new website is part of a program that involves continuous improvement. It will improve, rather than degrade, over time.
The key is to sell internal stakeholders on the idea that your website is a constantly evolving asset that will never be perfect but will be always be good (or even great). The site will adapt to changing organizational goals and audience expectations. Like the original meaning of the term "launch," putting up a new website should be considered the beginning of a journey, not the end of a project.
Related: Your Website is not a Project.
Jun 10, 2013
Estimation has long been a point of embarrassment for the software development community. A big part of that is unrealistic expectations set by association with construction and manufacturing industries. Software is unlike building houses and widgets because every software application is unique and unprecedented, whereas construction and manufacturing most often involve assembling well-understood components in repeatable ways. Truly innovative construction projects, like the Big Dig, and the Sydney Opera House, regularly overrun their estimates (by 3 times and 15 times respectively in these cases). They shouldn't be compared with building out a subdivision either.
A more appropriate analogy is a moving truck. If you have ever hired movers to help you move between homes, you know that the process starts by someone walking through your house and looking over your stuff. This person may pull out a tape measure a few times but she is not measuring everything and she is certainly not doing things like seeing if your ottoman can be neatly wedged underneath your dinner table. The real purpose of the exercise is to know how big a truck (and team) to bring on moving day. It is up to the movers to make the most of the space and there is a real art to that. Sometimes the moving team can see right away that the job is going to be a real squeeze and they think through every piece like a game of Tetris. But sometimes the truck is just too small, you need to call in another truck. Either that or pulverize your furniture into very compact dust.
The main point of this analogy is that precise software estimation is impossible at the detail level. It takes people who have done lots of projects to give a decent "truck-size" estimate, and even then they can be wrong. In fact, each task estimate will likely be wrong. Accuracy is achieved only at the aggregate level when the underestimates cancel out the overestimates. Just as important, an experienced team will be quick to identify the need to adjust: either by increasing the scope (size of the truck), by leaving low value items on the curb (decreasing scope), or by changing how things are packed together. The earlier you are aware of your constraints the more options you will have. Only inexperienced teams wait until the truck is full to realize that some adjustments need to be made.
Related: Work Breakdown Structure vs. Deadlines
May 09, 2013
Finding excellent technical people is a constant challenge that I struggle with every day. The traditional recruiting process of searching résumés for keywords has been broken for a long time. You need to use clever techniques like my "One Field Job Application" and engage in various communities to find people who are passionate about their craft and want to do great work.
Interviewing candidates is even harder than sourcing them. You don't want to waste anyone's time (including your own) but you also want to get a real feel of how someone works. Developers who work on large teams are particularly hard to evaluate because responsibilities are often ambiguous. It takes a while to learn that a candidate had a really mundane role on that very interesting project on the résumé or that he/she didn't have the professional curiosity to learn about what other people were doing.
Some recent experiences are leading me to believe that the ideal technical interview question is "Tell me about your setup." While the tools that people use may at first seem mundane and subjective, I am starting to believe that tools are a reflection of the attitude a person brings to his/her work. This theory was originally inspired by the site UsesThis, which contains personal descriptions of the tools that people use. The people that submit their setups are clearly passionate about their work and pay attention to the details. Most importantly, they identify with their work — and that is critical to the type of commitment that leads to greatness.
I am not so interested in what the tools are (although I am starting to see some interesting patterns that I might share in a later post). I am more interested in the why. If an interview candidate starts to light up when explaining why she loves to use something, you know right then that she loves her work and she loves being good at her work. This is especially true for people who like tools that require some dialing in but have incredible power. Users of these tools have proactively invested their time to get better at something. Contrast that with someone who is indifferent about his tools: who just uses what he is offered; who likes a tool because it has buttons that you can click that does things that he doesn't understand. To me, that is a sign that I am talking to a drone that is satisfied with the bare minimum. His passion lies elsewhere or doesn't exist at all.
Passionate professionals who care about their craft don't just make a team more effective, they also make work more fun because passion is contagious. When you see a colleague doing cool things, you want to learn from them. You are also inspired to raise the level of your own work. When your peers are just going through the motions, it has the opposite effect. You de-personalize and get cynical and start identifying with Dilbert.