The Enterprise 2.0 Recovery Plan

Recent events in the news have inspired a thought experiment: I asked myself what I would do if I were put in charge of IT as part of the turnaround effort at a big US automaker. To be a bit more specific, I imagined that one of the big 3 American auto companies was taken over tomorrow by enlightened and aggressive new leadership whose only goals are to restore the company to operational and financial excellence. This leadership is enlightened (in my book) because it believes firmly in the power of IT to help businesses achieve their goals and differentiate themselves in the marketplace, and will fund and fully support whatever initiatives I propose (this is a complete fantasy for several reasons, but thought experiments aren't supposed to be constrained by reality.).

So what would I propose?

I'd be guided by a couple facts and a few principles. The first fact is that on day one I would know virtually nothing about the company's IT environment. I wouldn't know, for example, what major enterprise systems needed to be deployed, integrated, consolidated, upgraded, etc. I also wouldn't know about the health, status, and importance of the large projects currently underway. I'd set about trying to learn answers to these questions, of course, but this would be a long, slow process.

My colleagues on the new management team would be similarly in the dark on day one about other critical questions:

• Which of our current vehicle platforms under development will be hits in the market? Which will be duds?
• Are our current platform projects largely on schedule, or are they falling badly behind?
• Where are our biggest opportunities to cut costs without losing valuable capabilities?

The second fact (actually more of a very safe bet) is that the company would have a static and fragmented Intranet, and that employees would communicate with each other primarily via email. In other words, Enterprise 2.0 would not be advanced within the company, nor would it be universal.

As I got to work and tried to deliver results and benefits as quickly as possible, I'd be guided by a set of principles, many of which I've discussed in this blog:

1. The company 'knows' the answers to our questions. The knowledge required to answer them exists within the workforce. This knowledge is widely diffused, constantly changing, and not contained in the mind of any single person (As Friedrich Hayek pointed out many years ago), but it is out there. Most executives, I'm pretty sure, believe this to be true. What's frustrating them is that they don't have great ways to collect and access this knowledge.
   
2. Most people want to be helpful to each other, and to the company. I think it's self-evident that people are largely good; if we weren't, we would have wiped each other long before now. And we are to some extent wired for altruism and reciprocity. Finally, American carmaker employees have ample reason to fear for their industry, their company, and their jobs, so they have extra incentive to pitch in and help out, and to experiment with new ways to do so.
   
3. Expertise is emergent. It's logical and natural to think that all the good new product ideas come out of the design department and R&D labs, that the folk in the IT department are the best ones to help you with your computer problem, and that the engineers are the only ones who can figure out why the doors start rattling after 5,000 miles on the road. But this is not always going to be the case. The more we look, the more we see that a very effective way to solve a problem is to expose it to a highly diverse set of potential problem solvers, then let them have at it.
4. People are busy. Most knowledge workers have more than enough to do with their normal jobs, and aren't going to go too far out of their way too often, even though they do want to be helpful. This implies that any new tools need to be perceived as 'in the flow' of work, rather than 'above the flow.' There are a few ways to achieve this. One is to make the new tools extremely simple, easy, and intuitive to use, and to ensure that they're never more than a couple clicks away. Another is to 'widen the flow' so that job descriptions include 'enterprise-level helpfulness / collaboration.' A series of three posts advocating this is here, here, and here.
   
5. Weak ties are strong. Weak-tie networks are great places to look for novel information and introductions to valuable people. And social networking software (SNS) is a great tool for building, maintaining, and exploiting networks of weak ties. Instead of being a time-waster, enterprise SNS would be a powerful resource.
   
6. The ability to convert potential ties into actual ones is valuable. At present we rely primarily on human brokers and connectors to introduce us to valuable colleagues. These organizational matchmakers are extremely valuable and influential, and there aren't nearly enough of them.
7. Platforms are better than channels , for a lot of reasons. Channels like email hide information; platforms like blogs, wikis, Facebook, and Twitter make it visible, persistent, and widely consultable.
   
8. Search is the dominant navigation paradigm. People navigate online content by typing words into search boxes rather than navigating through menus. This implies that we should do everything we can to make sure search works well.
9. The mechanisms of emergence should be encouraged. For search to work well, online content needs to be heavily interlinked. So people should be given the ability to link to content they find valuable and encouraged to do so. They should also be encouraged to tag, vote, rate, and to all the other things that help identify what a particular piece of content is about, and how good it is. In addition to this explicit work people also vote on and rate content implicitly as they browse through it.
10. Anyone can learn the new tools, but they need to be educated, trained, and encouraged. I do think that digital natives use technology differently than us older digital immigrants, but we can learn. The new tools of collaboration don't require any skills beyond point, click, drag, drop, and type. They do require users to adopt a particular philosophy about sharing information and interacting with each other, and this philosophy can seem strange at first. When I first heard about Twitter, for example, I said something like "What on Earth would that be useful for, and who on Earth would ever want to use it?" Now, however, I'm a fairly frequent user, find it a really novel and valuable resource, and think that it has strong potential within the enterprise (here are my blog posts on Twitter, and here's a research report on Enterprise 'microblogging' from Pistachio consulting ).
    

So what would adherence to these principles lead me to do? I'd roll out as quickly as possible a single integrated suite of emergent social software platforms (ESSPs) to all employees of the company. This suite would include blogs, wikis (including collaborative document production tools like Google Docs), discussion boards, SNS, a microblogging tool like Twitter or Yammer, a tagging utility, prediction markets, ways to vote on good content (a la Digg) and ways to give praise or good karma to particularly helpful colleagues. Lots of vendors both big and small are working to develop such suites; for now, I'm going to assume that a complete one exists.

As I wrote earlier, SNS helps with principle #5 above, and a blogosphere (broadly defined here to include a Twitterverse) helps with #6. And the whole idea of ESSPs supports #7. To put the other principles into practice, I'd insist that:

• The tools be trivially easy to use, primarily by copying the look, feel, and user interface of the most popular Web 2.0 resources. Too many ESSPs intended for the enterprise try to reinvent the wheel, and they do so poorly. (helps with principles #4 and #10)
• All content is cross-linkable, taggable, and Diggable. (#9 and #3 and #8)
• The ESSPs contain some initial content and suggested structure, but that these are modifiable over time. (#4)
• There be few initial rules or policy statements beyond 'use your judgment' and 'highlight any behavior you find inappropriate.' (#2)
• Most platforms be available company-wide. I'd probably allow only group collaborative document production tools to have limited membership. (#3)
• Training on the tools be made mandatory for all employees (#4 and #10)

Of course, I'd also make them as device-independent as possible, and give people the ability to access them from home, the road, etc. Somewhat more controversially, I'd also make E2.0 part of every knowledge worker's job. A series of three blog posts on this topic is here, here, and here, and generated a raft of great comments. I'd introduce this change by announcing on the 'go live' date of the new E2.0 suite that participation will become part (10-20%?) of everyone's performance evaluation, starting in six months.

But what about principle #1 above, that the company knows the answers to the critical questions it's facing? This is perhaps the most important one, yet is not directly addressed above. To start to get answers, I'd set up prediction markets for the biggest projects, both IT and otherwise, within the company, letting people trade on whether they'll be finished on time, nearly on time, or nowhere near on time. These markets would very quickly provide accurate and valuable information. I'd also set up markets to predict sales volumes and competitors' moves.
I'd also start asking questions via my own blog, and listen to the comments and responses I got back. I'd work to create an environment in which people feel safe and free to speak the truth.

How would I know if Enterprise 2.0 was working well over time? The accuracy of prediction markets is easy to assess. It's also easy to conduct surveys and find out if employees like the new tools, and prefer them to previous ways of collaborating. I'd also partner with academics to design and execute research investigating whether various attributes of performance improved after the new tools went in.
But the point of having the trust and commitment of my management colleagues is that I wouldn't need to justify this kind of expenditure. If they're on board with the principles then they're on board with the investment required to put them into practice. And this investment is not huge. I'm pretty sure E2.0 wouldn't cost as much as the typical ERP project at a car company.

I used Twitter to float this idea before writing this post, and a number of people responded that "IT isn't the problem at the car companies!" I totally agree. But technology can be a large part of the cure for what ails them. And I'm confident that the biggest and fastest bang for the IT buck at a US automaker today comes from ESSPs and Enterprise 2.0.

Do you agree? Or do you think there would be better uses for investment dollars and managerial bandwidth after the hypothetical leadership change of my thought experiment? I don't, but I'd love to hear your thoughts and reasoning if you disagree. Leave a comment, please, and let us know.

by Andrew McAfee Associate Professor, Harvard Business School