A Call to Action for Web Managers: Blow the Whistle

This is a story for all of you out there who manage your organization’s Web presence and are too fearful to take the steps required to effect real change.

I remember a vocation-defining moment more than a decade back when I was still working at Cisco Systems. It was the 11th hour of a Web content management product selection and we were trying to figure out whether or not to buy the software we had just tested. The software in question was Interwoven Teamsite (I think version 1.13). This was the first Web content management system product selection I had ever done. This was the first Web content management system product selection any one at Cisco Systems had ever done.  It was the late 1990s when the Web in the enterprise was still relatively new and everyone who worked on Web sites were experts at making up stuff and implementing it quickly just to see if it worked. People still do that now but they call it Web 2.0.

Anyway, when I joined Cisco Systems in 1996 I was coming in on the heels of the real Cisco Web site pioneers. The site had taken off, Cisco was already doing multi-channel publishing.  And there was a mountain of marketing materials, technical documentation, and various e-commerce applications and software images for product support on the site. 

Many, many smart people were working on the site but most were early adopter types. Lots of vision and execution power—but not a lot of planning or process orientation. So things were getting out of alignment and the power struggle between IT and Marketing was beginning to form. I wish we had thought more about Web Governance as a concept then. It would have saved a lot of grief. But to be honest, all those Wild West Web types would have laughed that right off the table.

We Tried Every WYSIWYG Tool on the Market

In an attempt to wrestle down a huge, unruly Web site, Cisco’s Web publishing and development community had used just about every text editor and WYSIWYG tool on the market as well as made a few of our own. We’d also done some best practices stuff like establishing file naming conventions and directory structure rules. And, some organizational stuff like moving the Web team around from group to group and giving it a better name, adding more people to IT, adding more people to Marketing, decentralizing content authoring to alleviate the “webmaster bottleneck,” and, redesigned the homepage a few times.

And none of it worked.

We still had a huge, unruly Web site. It just had different graphics, a better-named Web team and more people shoveling on content and applications. Finally, out of desperation, we decided to try a new-fangled thing called a Web content management system.

We Wrote a Great Web CMS Requirements Document

You wouldn’t know it from looking at the top of my desk, but I’m a process girl (except for the process of cleaning up my desktop). So the idea of a tool that was going to add some process and control to  Web content publishing got me excited. So, I volunteered to drive the product selection process. And, I must say, given that this was around 1997 or 1998, we did a pretty good job with the product selection. We got a number of things right:

1. We wrote a requirements document which included use cases focused on content contributors' needs.
2. The product selection team was organizationally diverse which resulted in a set of requirements which reflected the needs of all the Web site stakeholders – both the Marketing and IT sides of the house and a few of the lines of business (we could have been better about this).
3. We piloted the software to determine if it would actually work with our use cases. (And, after some twisting and stuffing, it did).
   

But this blog post is not about Web CMS product selection.

It’s about a Eureka that I had at the 11th hour of the product selection – a Eureka which led to my current vocation as a consultant who helps organizations figure out how to manage big, messed up Web sites. (Who knew product selections could be so inspiring?)

So, here we are sitting around the table, Web CMS pilot complete. We had quite a crew around that table including Chris Sinton who was a pioneer in the B-to-B e-commerce movement of the mid-late 1990s. I have to mention Ellora Sengupta on the IT side at Cisco who wrote an amazing requirements document and helped drive the piloting of the software. Ellora could slap the last stretching-of-the-truth-about-functionality out of any software vendor. Clint Stark was a great project manager—you know the kind that knows how to stay out of the way of the subject matter experts but also pushes things along.

On the vendor side was Peng Ong, an amazing human being and one of the Founders of Interwoven and, I think that Russell Nakano, the other Interwoven co-founder, might have been there as well.  I remember fondly a white-boarding session with Peng and Russell where we ruminated about what a Web CMS really ought to do. None of that has ever come to fruition in any system I’ve seen—yet. 

Also at the table was the man who was nice enough to put me in the job at Cisco that has lead to more than a decade's worth of fun invention around Web Operations Management, David Grabel.  David didn’t always know what I was talking about when it came to Web management (I didn't always know what I was talking about) but he respected me, trusted me, and made sure that my projects were funded. There were several others there as well on both sides.

And then there was me: Program Manager Lisa with a degree in Philosophy. Thank goodness I can be delusional from time to time. It honestly never occurred to me that I might not know what I was doing.

So, here was the situation (see if it sounds familiar):

Web production at Cisco was pretty out of control. Not chaos, but not great. We did not have separate development, staging and production environments which meant that way too many people had access to the production server and were messing around with mission-critical live content all the time, real-time. There was no audit trail for what happened to content. The site was full of redundant, outdated and trivial content. On the apps side there was a lot redundancy (the Web CMS wouldn’t help with this but the apps were still there).

AND...

The Web CMS pilot had shown that the software could manage the hundreds of thousands of content pages that was Cisco.com, integrate with some key, internal publishing systems, and help us gain some control over the site. The solution was imperfect but better than what we had. We needed this.

BUT...

The senior people around the table were reluctant to make the commitment to buy the software. They were concerned about the risk of going with an untried product. To everyone’s defense, Cisco deploying a Web CMS was jumping into the big software unknown with a very prominent poster-child-for e-commerce Web site. 

But, having lived in the production trenches of the site for awhile and understanding exactly how much was wrong with the site and its management, I couldn't really stomach management's reluctance to take hold of this obvious opportunity. All of Cisco.com was nothing more than a completely unplanned, unproven, fly-by-the-seat-of-your-pants software experiment. And here we had this tested software application and they were saying "no"?

So, I said to a table of people who were more experienced and much more highly paid than I, “What about the risk of continuing to work the way we are working now?” Chris Sinton turned, looked at me, paused for a moment and said, “Good point.” And, that started a real conversation about the benefits and risks associated with continuing with the "as-is" model of operating the site-- and in that same meeting we made the decision to move forward with the software.

Less than a year later, I realized there was a lot more to fixing a broken Web site than a CMS and I left Cisco Systems and started the business which would become WelchmanPierpoint.

In 2009, Web Operations is Just as Bad as in 1999

So, over 10 years later, what about the risk of continuing to manage your organization’s Web presence the way you are managing it now? How complicit are you in the crime of your organization's poor Web operations? Are you just going with the status quo because you're too afraid to make noise?

Here's my little lecture for you:

Status quo does not equal correct, or optimal, or high-value. Status quo just happens to be the way your organization fell into managing the Web. Status quo is lazy. You know that the way you are managing your site is inefficient and does not produce a Web presence which, if examined, supports the values and mission of your organization.

If you are an experienced Web manager, you know better than this. What you maybe don’t know is that the other faster, smarter people around the table don’t know better. It’s not that they are passive-aggressive or spiteful or out to make your life miserable (all things that I've heard from the Web trenches). They really don’t “get it.” They haven’t been working heads down on Web sites for the last ten years. You need to help them “get it” by explaining both the opportunities that proper Web management provides and also expose the real risks associated with poor Web management.

You are a Web Expert, not the CEO, not CIO, not VP of Sales. Exposing this risk and benefits of improper Web management is your job and you probably know what to do to maximize the benefits and mitigate the risks. The fix most likely isn’t easy. The fix might require changes beyond your current vocational range. So, stretch a little and then a little more. You can start by opening your mouth and stating the obvious, which might be that your Web site as it is managed now might be creating some real risk for you organization. Start the conversation.

The transformation to mature web operational practices will not happen overnight. It will take years. But, it will not start if those of us who have the knowledge to make the change happen sit back, tight-lipped and do nothing.

Blow the whistle.