“Web 2.0” is a term that gets bandied about far too often with far too little associated meaning. Essentially, Web 2.0 refers to multi-directional interactivity between one or more humans and one or more Web applications (with their associated back-ends) — period. The term often pops up in descriptions of any of the following: social computing, blogs, wikis, folksonomies, Web services, RSS feeds, online applications, collaboration, mash-ups and the Web as a platform. Don’t let the diversity of topics given as examples of Web 2.0 distract you from the fact that the key operative term is multi-directional communication. What does this mean for WCM?

For the end user, it means that Web applications such as online banking, which now rely heavily on technologies like Flash and AJAX, provide better customer service by building-in higher levels of interactivity between the user and the data within a browser session and by encouraging more efficient communication between the browser and the host. Whereas before, every user request meant a round-trip to the server, now far more data is sent at once to the browser, often in the form of an object with which the browser can interact. The user then manipulates the data multiple times – transferring funds between accounts, paying a bill, and updating an address, for example – and upon logging out, transactions are sent to the server all at once for processing. Because technologies like Flash and AJAX provide for easier inclusion of rich media in the user interface, the combined effect of these Web 2.0 technologies is reduced development time for programmers, a more satisfying user experience for consumers, server processing efficiency for the host, and bandwidth savings for everyone. Another significant advantage of Web 2.0 technologies for WCM is the tendency to be so highly based on well-defined standards that functional components of Web applications are often interchangeable. When built on Web 2.0 technologies, the “address update” function in the Web banking example above would likely be usable by the bank’s credit card Web application as well. This component swapability is the underlying principle behind enterprise mash-ups, a developer-oriented topic for an upcoming blog entry.

What’s it gonna take to get organizations to take their web sites seriously? By seriously I mean staff them, fund them and manage them? I’m beginning to believe that some newsworthy misinformation-on-the-Web or ecommerce-related revenue losing incident may be the only way that some organizations, both public and private, are going pay attention to the fact that their Web products are an embarrassment and, sometimes, a liability. Is that what it’s going to take? Some unlucky organization’s got to get caught with their Web pants down?

In 1997 I was working on the web team at Cisco Systems. The public web site was serviced by several different groups within the organization and we were constantly battling about who was in charge (sound familiar?). I only mention Cisco by name not to name drop but because it’s significant to my gripe: Cisco Systems, the first big retailers of multiprotocol routers. Cisco gets the internet. Cisco gets the Web. Cisco has a vested business interest in having the Web work for every breathing human on the planet. Cisco would be the first to put the internet on Mars (if it’s not already there). But, Cisco still had a lot problems managing their web site. Why? Because managing a large Web presence is less about understanding the potential and possibility of technology and more about sound operations and management practices– creating an environment where people work together to create a quality product.

Web People (this is a special breed of people who were drawn to work with web technologies during the Web’s commercial proliferation in the 1990s) have many strengths. But establishing sound operating practices and sound management principles don’t seem to be among them. Web people are good at flying by the seat of their pants, doing the impossible overnight for demanding and technologically clueless managers, inventing new products out of new technologies, and complaining about being underappreciated and overworked… but not great about clearly explaining to managers why the organization is at risk because of the low quality of the organization’s web products. In short, Web People are not good managers. It hurts me to say this because I feel like I’m dissing my own people. But, I think it’s for the greater good.

The Web needs to be managed and it needs to be managed by people who understand not just the Web but also business operations and product quality. Unfortunately, this is not a description of many of the plain old vanilla business school manager types we see in organizations. A lot of managers we work with have an aversion to any knowledge that might be construed as specialized. I’m generalizing to make a point. There’s a general view that mangers don’t actually need to *do* anything (particularly anything technical)… that would be for subject experts and individual practitioners—not managers. But not doing something is a lot different than not understanding what you’re managing. Not understanding what you’re managing is bad management. And there is a lot of bad management happening around web sites.

So, on the one hand you have technically-literate but managerially-illiterate individual contributors who know that the organization’s web site is a ticking time bomb. And, on the other hand, you have technically-illiterate but managerially-literate managers who just want to be able to report up that everything is “just fine” with the site. The result is that organizations are stymied by big, unwieldy messed up web sites largely created by a lot of smart, technology-focused Web People who don’t know how to manage their way out of the mess they have unwittingly created. Above them is typically an administrative structure that might know how to manage but won’t take the time to understand the basic technical underpinnings of the Web (“I’m not technical”); so, they can’t manage effectively and make bad, mostly tactical, reactionary choices for their web products based upon the complaint of the moment from the Web People who report them.

These things combined lead to what I consider to be a “deer in the headlights” web syndrome: where lots of smart people in an organization are standing around stunned and up to their waists in bad Web product — and they just stand there knowing that something bad is going to happen but unable to move. It’s a sad sight.

What’s to be done, for all my complaining? Here’s a few suggestions:

1. Admit Defeat – Admit that you are powerless over your web site and that your web site has become unmanageable.
2. Figure Out Who is In Charge – Establish some basic organizational norms around the management of your web sites. Make sure the definition of these norms includes Web People and Good Managers.
3. Make an Operational Plan – Figure out how to get out of the mess that you’re in and how you will work in the future to create a higher quality, strategically-focused web product.
4. Get a Sponsor – I say this a lot but I also mean it a lot. Find the most senior person that you can in your organization and get them to support you with management mandates and human and financial resources.
5. Be a Copy Cat – Most organizations have at least one thing that they do really well. Figure out what that is and then figure out why it works. Then apply those principles to your Web Operations plan. While the Web may be new, sound management principles are not.

I’ll talk a lot more about sound Web Operations Management practices and how organizations should approach the staffing of Web teams in 2007 at the Gilbane Conference in San Francisco. Hope to see you either at the Web Operations Management pre-conference tutorial or my talk on Web Team 2.0.