Transparent Office

Transparency, not Anarchy

In a recent post, ZDNet blogger Dennis Howlett asserts that Enterprise 2.0 is a "crock." It's a smart and thought-provoking post, which has elicited equally smart and thought-provoking replies from Andrew McAfee, Thomas Vander Wal, Larry Hawes, Gil Yehuda, and others.

I think Dennis's argument is wrong. But it's interestingly wrong, which is a very good thing. (There's a special place in heaven for interestingly wrong arguments.) Rather than tackle the' entire argument, I'll focus on my favorite part. Dennis writes:

Like it or not, large enterprises - the big name brands - have to work in structures and hierarchies that most E2.0 mavens ridicule but can’t come up with alternatives that make any sort of corporate sense. Therein lies the Big Lie. Enterprise 2.0 pre-supposes that you can upend hierarchies for the benefit of all.

The problem with this provocative sentiment is that Dennis doesn't understand the difference between transparency and anarchy.

He's not alone. Dennis has picked up on the unfortunate fact that a lot of Enterprise 2.0 rhetoric has a man-the-barricades, throw-the-bums out flavor. That's particular true on Twitter, the blogosphere, and industry conferences, where the most outspoken advocates--Dennis's E2.0 mavens--dominate the conversation. If you listen closely, you can hear La Marseillaise (or is it just Les Miserables?) playing on the hotel muzak.

But when you look at real Enterprise 2.0 implementations in real companies, a different story emerges.

Companies are not using blogs, wikis, social networking, or micromessaging to upend hierarchies. They're not trying to introduce anarchy to corporate America. They're not fighting a moral crusade to free the downtrodden knowledge worker from the tyranny of the org chart. But they are using these tools, and using them to good effect.

Successful Enterprise 2.0 practitioners have learned that it's a mistake to radically realign accountability within their organizations. They respect, preserve, and even reinforce the roles and responsibilities already prevalent within the organization. If your job used to be to manage Tech Support in your company, then guess what your job is after your company adopts Enterprise 2.0? You guessed it: managing Tech Support. That responsibility is still on your shoulders, just as it was in the old days.

The difference is that Enterprise 2.0 gives you and your team information and relationships that help you accomplish the things for which you are and remain responsible. You can see who is working on what, even when you're on different continents. You can access relevant information from other departments. You can quickly put your fingers on documents otherwise lost in the bowels of your email in-box. You can see and discuss in public the issues that your colleagues are already grumbling about in the company washroom. These are good things, and companies are adopting them because they're good business.

When Dennis says that "Enterprise 2.0 pre-supposes that you can upend hierarchies for the benefit of all", he is confusing transparency with anarchy. Put differently, he's confusing information access with decision rights. (For more on the difference, see McAfee's The Great Decoupling and Ross Mayfield's Decoupling Decision Rights and Decentralization. Andy and I also talked about it a couple years ago in a memorable panel discussion at Razorfish.)

Enterprise 2.0 pools information, so that workers can benefit from enhanced access to their colleagues and their colleagues' work. That's transparency. But Enterprise 2.0 does not pool decision rights. Embracing Enterprise 2.0 does not mean that workers can assume decision rights that formerly belonged to others. That would be anarchy.

But fear not, oh champions of freedom and enlightenment, all is not lost! Enterprise 2.0 can still free you from the chains that oppress you!

"Hierarchy" is a pejorative term, often used to suggest that senior decision-makers are ignorant, out-of-touch, or otherwise unqualified for the responsibilities the organization accords them. The more transparent an organization is, the less likely that problem is to occur. Open, ongoing conversations with staff, customers, and channel partners make management better-informed, less isolated, and more engaged with what's really happening in the organization and the marketplace. It's easier to focus on what really matters, and harder for managers to succumb to yes-men and wishful thinking. And it's easier for staff to understand management decisions, even when those decisions are controversial or unpopular.

When decisions get made in a transparent organization, we don't call it Hierarchy. We call it Leadership.

Launch E2.0 Broad, Then Go Deep

In my previous post, I argued that companies should Skip the Pilot for Enterprise 2.0 applications. The argument, which came out of my own experience with hundreds of implementations, is that small-scale pilots are not representative of the way companies use collaborative tools at scale. As I put it there, "Scale is the oxygen that feeds collaboration."

The post was controversial. You can see the comments on both my personal blog and on the Socialtext blog. Many people agreed with me. Others trashed my advice to skip the pilot. But even those who trashed it agreed that small-scale collaborative dynamics and large-scale collaborative dynamics are different. They defended pilots on purely pragmatic grounds of risk mitigation. It's just too risky, too scary to launch on enterprise scale until you've proven adoption and value with a small group.

Chris McGrath and I have been going back and forth on this point, and his last comment summarizes his position nicely:

"How is E20 ever going to go mainstream if it requires massive deployments? I'd hate to be the person that convinces their company to make a million-dollar leap of faith, only to have a full-scale rollout languish."

Well shucks, I wouldn't want to be that person either. And you don't have to be. Skipping the pilot does not mean you have to be reckless or risk your career on an all-or-nothing Enterprise 2.0 deployment. The best launch approach ratchets down risk without artificially narrowing the scale of your launch.

Enterprise social software isn't one application. It's a range of collaborative modes that includes blogs, wikis, micromessaging, personal dashboards, collaborative spreadsheeting, and social bookmarking. As Ross Mayfield shows in his post The Power Law of Participation, these different modes have different adoption profiles. Some modes of collaboration have a really low threshold of participation: It's very easy to get started on them because individuals don't need a ton of engagement to find them useful. Other modes of collaboration have a really high threshold: Users don't see the point unless they invest a lot of time learning and using the tools.

Historically, Enterprise 2.0 implementations have focused on collaborative tools fairly high participation thresholds: blogs and wikis. That's not by design, it's by default. Until recently, those were the only Enterprise 2.0 tools that showed potential for high-value business use. Since these activities required a lot of engagement, we smothered our pilot participants with training and encouragement--which forced us to keep the pilots small.

Today, Enterprise 2.0 participation is a whole different game. At the "low threshold" end of the curve, we have low-engagement tools like social messaging (internal "Twitter"), social bookmarking. By leading your implementation with these low-threshold tools, you lower the risk of implementation while still launching at the scale required for success.

The results can be exciting. My company, Socialtext, recently held a webinar on micromessaging for a major financial services company in the Midwest. We didn't position it as a comprehensive Socialtext training. We just focused on Signals, our social messaging component. We were blown away by the response. So many people dialed into the webinar that we--no joke now--brought down the company's phone system.

The webinar itself was energizing (at least until the phones went dead). The group was super-engaged. People were actively creating profiles. They uploaded pictures. They sent signals razzing each other about their pictures. They tagged each other's profiles. And best of all...they signaled about what they were doing at work.

Signals was not just a useful tool, it was also a stepping stone that helped participants move to the right on the Participation curve (see image above). As participants started to get the hang of Signals, many started to ask about Socialtext's other collaborative features: What are workspaces? How do I use the Dashboard? How do I look up an individual?

After the webinar was over, a number of users wanted to go deeper by creating wiki workspaces to collaborate on tasks, projects, documentation, etc. We scheduled follow-up time with them to understand their collaborative needs and build tailored solutions.

This story describes a launch approach that simultaneously achieves seemingly conflicting objectives:

• Launch quickly and cheaply, without investing a ton of time or money in training and content creation.
• Achieve scale by inviting lots of people.
• Minimize risk by making participation opt-in rather than mandatory
• Generate active participation through interactive launch events that don't require a lot of training or engagement from the new user.
• Deliver deep value by following up with local champions who want to invest time and effort in more robust, group-specific forms of collaboration.

So let me ask the question one more time: Why do you need a small-scale pilot?