Managing Chaos. Lisa Welchman
Чтение книги онлайн.
Читать онлайн книгу Managing Chaos - Lisa Welchman страница 5
CHAPTER 1
The Basics of Digital Governance
Your Digital Governance: How Bad Is It?
In 1995, when my son was eight months old (Figure 1.1), I packed up my family and moved to Silicon Valley to work with 500 Startups’ Dave McClure’s very first start-up, Aslan Computing. Dave had sent me a 14.4 modem and an HTML book as a baby shower gift, and coding Web pages was a good stay-at-home-mom job. At Aslan, we coded pages for the Netscape website. We invented out-of-the-box website building tools with names like “Ready, Intranet, Go!” We figured out how to manage an ISO 9001 certification process online and built lots of websites for dotcoms, most of which rose and fell quickly in the stew pot of 1990s Silicon Valley.
FIGURE 1.1 Baby Welchman circa 1995.
Late in 1996, I took a job at Cisco Systems, managing the product pages for its website (see Figure 1.2). The site was huge for its time (200K+ HTML pages), and the Web team was relatively small. There was the main site, “Cisco Connection Online,” as well as various “country pages.” Cisco was getting recognition for being a leader in ecommerce, and folks like Jan Johnston Tyler and Chris Sinton were doing pioneering work in multichannel content delivery. The whole Cisco ship was being steered by John Chambers.
Back then, corporate websites were so new, resources to manage them so few, and Web skills so ill-defined and shallow that people like me who knew only enough HTML and UNIX to be dangerous were let loose on the live production servers of major corporate websites to do whatever we wanted. At Cisco, we invented a lot. We laughed a lot. We accidently erased content a lot. (I remember accidently replacing the Cisco.com homepage with the Japanese Cisco.com homepage once.) The Web team tried almost any idea because there were no rules. The norm was to make it up as you went along. And we did. It was fun, and it couldn’t have happened any other way.
FIGURE 1.2 The original Cisco site in 1996.
But, in the years I was at Cisco, I noticed something. Cisco Systems was the epitome of all things Internet and Web. It wasn’t just that it sold routers, hubs, and switches. It wasn’t just that Cisco installed a high-speed Internet connection in its employees’ homes. Cisco as a company was serious about using the Web as a business tool. In 1996, Cisco had all its technical documentation online, downloadable software images, a robust intranet, and a rapidly growing B-to-B ecommerce model. But, despite all of this cutting-edge use of the World Wide Web, Cisco still had a lot of problems managing its own website.
There were internal debates over homepage real estate by various business units. There was an ever-present debate about who (the marketing team or the technology team) ought to be selecting and implementing key website technologies like search engine software and other, then newer, technologies such as Web content management systems and portal software. At almost every meeting about the website, more than half the time was spent not actually determining what type of functionality needed to be implemented, but on who got to decide what functionality would be implemented.
Competing factions would show up at meetings with different website designs, information architectures, and technologies, and the debate would go on and on. People would get angry. Managers would fight. Office politics raged. But after all the drama, the solution usually ended up being that no decisions were made. We left the room only to come back for rounds two, three, and four once tempers had cooled off. What that meant in practical terms was that often multiple competing technologies were deployed and multiple website designs implemented—each area implementing its own vision over the part of the site that it “owned.” The result was a graphically diverse, incongruent website with a confused information architecture.
And I was part of the problem. I was part of the marketing team that felt that we owned the whole site—because websites are communications vehicles first and foremost, right? The evil nemesis on the other side of our debates was usually the IT team, who was constantly pointing out that the website was first and foremost a technology. I wasn’t thinking about governance per se back then. But, being tasked with leading the team to select the first content management system for Cisco Connection Online, I was frequently caught straddling the line between marketing and technology. I was beginning to see that both teams had valuable contributions to make, not only in the selection process but also in the overall running of the site. Still the battles raged on.
Eventually, the cross-departmental content-management product-selection team we had assembled narrowed our candidates down to a single vendor. All the stakeholders (marketing, IT, hands-on Web folks, managers, and senior managers) assembled in a conference room. We’d written a requirements document, installed and tested the software for months over a number of use cases, negotiated pricing, and pretty much driven the vendor crazy. It was time to make the decision. Both the vendor’s implementation team and the software had passed all of our tests and the price was right, but still the people around the table were reluctant to make the commitment to buy the software.
There we were: the right people around the table, the right solution in front of us, and we still couldn’t make a decision. That’s when I began to understand what was really going on. It wasn’t that we couldn’t make a decision because we weren’t sure about what the right solution was; we couldn’t make a decision because no one really knew whose job it was to say “yes” or “no.” I also began to realize that the uncertainty didn’t stop at CMS software selection, because no one knew whose job it was to decide anything about the website: content, design, information