The Enterprise 2.0 conference took place last week in Boston, and was by all accounts a large success (I am on its advisory board).  If you couldn’t make it, a good way to get an idea of what happened is to do twitter searches on #e2conf (the hashtag for the conference as a whole) and on #e2conf1 through #e2conf49 (I think), which correspond to individual sessions. Many attendees were tweeting diligently throughout the event using the above hashtags, and have also used them to point to their blog posts and other related writings. Also valuable are the conference posts by Oliver Marks, Jessica Lipnack, Bill Ives, Susan Scrupski, and Doug Cornelius.

My main contribution was to interview Shawn Dawlin and Chris Keohane, two of the leaders of Lockheed Martin’s highly successful E2.0 deployment. The Lockheeders came to the conference last year, and their presentation was so well received that they were invited back for two sessions this time: one on the details of their current work (#e2conf49) and one where they got to endure being questioned nonstop by me for 45 minutes at 8:30 on Wednesday morning (#e2conf13).

Shawn and Chris did an amazing job. They were articulate, clear, well-informed, and highly enthusiastic about their work, and about Enterprise 2.0 at LM in general. They gave the strong impression that emergent social software platforms are now part of the fabric of work across major parts of the company, and are poised to spread even farther.

I’m not sure they appreciate how rare this is, especially for a large company in a deeply conservative industry like aerospace and defense. I spent much of our interview asking them how they were able to achieve their successes, and what accounted for the broad and deep adoption of 2.0 tools and approaches to collaboration at LM.

As I listened to their thoughtful answers I realized that I was hearing a partiularly thorough set of key success factors –  things that really need to go right or be in place for E2.0 to succeed. And I also realized that I had been hearing the same ones over and over when I talked with people whose organizations had been able to profit from 2.0 tools and approaches.

It’s actually a pretty long list, which helps me understand why Enterprise 2.0 is, in every case I’m familiar with, a long and sometimes difficult effort rather than an overnight success. In addition, I think that the lack of any of the items in the list below will be damaging (not automatically fatal, but damaging) to the effort. Booz Allen’s Megan Murray, who has been an advocate and community manager for that company’s Enterprise 2.0 initiative, talks about the ‘perfect storm’ of factors allowing them to be as successful as they have been.

Here’s my (almost certainly incomplete) list, inspired by Shawn and Chris (S&C) and the other E2.0 evangelists I’ve met, of the elements of an E2.0 perfect storm:

  • The support / blessing of ‘guardian’ functions like legal, compliance, and security. S&C started working with LM’s legal and compliance departments very early on, making sure that they were aware of current and planned activities, and that their concerns were being addressed. For example, in response to concerns from the legal departent, the LM E2.0 team included flagging functionality in at least some of its tools, giving users the ability to highlight inappropriate content. The fact that no content has ever been flagged is interesting, but also somewhat irrelevant. Flagging functionality was included to address the concerns of an important constituency, and has served its purpose well. Co-opting your potential adversaries is always a smart strategy.
  • Steady and patient evangelizing. I’m not aware of any E2.0 deployments that have succeeded entirely because a bunch of people in the organization kind of thought that it would be a good idea. Instead, I keep finding evangelists –  people who are so convinced of the value of the new, technology-enabled modes of collaboration that they devote substantial time and energy to promote me. These people always hearten me and remind me of Margaret Mead’s great quote: “Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it’s the only thing that ever has.”
  • The right pitch for why E2.0 should be initiated / encouraged. S&C, Don Burke and Sean Dennehy at the CIA, and many of the other successful ESSP evangelists I know talk first to their audiences not about cool new technologies, but instead about the needs of the organization. They then show how some cool new technologies can directly address these needs, preferably using examples from within the organization itself. This sequencing is critical.
  • Useful and usable technologies. I know that E2.0 is not about the technology. But it’s also not not about the technologies deployed. They had better be appropriate to the goal(s) of the initiative, and they had better be freeform, frictionless, and emergent. If the tools offered are clunky or annoying, they will be tossed aside and people will just keep emailing each other.
  • Early successes and demonstrations of value. Successful pilot projects and early wins serve a few purposes. They generate positive momentum and buzz in current and affected constituencies. They also provide examples, case studies, and other fodder for evangelists. They provide opportunities to learn and course correct. And they also build up goodwill so that if and when something goes wrong down the road it’s more likely to be forgiven.
  • Context-appropriate tools, practices, and philosophies. Every presenter I heard at the conference said that E2.0 is not a one-size-fits-all phenomenon, and that tools, norms, communities, practices, and virtually every other aspect of an effort will be context specific and unique. At LM, for example, the community came to the view that it was not OK for a member to use any of the company’s ESSPs to try to sell his car (many others I’m aware of have come to a different conclusion). Gentry Underwood of IDEO (#e2conf18) said that his company’s deployment would probably not make much sense elsewhere, given that company’s unique requirements as an ‘idea factory.’ I think the principles at work across E2.0 deployments are strikingly consistent, but their specifics vary enormously.
  • Executive awareness and support. An organization’s leaders need to be both aware of today’s technology-enabled opportunities to improve collaborative work, and interested in exploring them. Many of us who have been working 2.0-style for a while now have arrived at a certain blindness: we can’t imagine how any enlightened managers in this day and age could be unenthusiastic about these opportunities. It’s easy to assume that only Luddites, paranoiacs, and hopelessly narrow-minded executives in backwater industries could be unimpressed at the growing body of evidence around E2.0, or so conservative as to be unwilling to experiment. I assure you that this is not the case. I’m meeting in a few weeks with the senior executives of a large, profitable, high tech company, one that’s universally considered to be progressive and well-managed. And yet these managers aren’t convinced that they should proceed with Enterprise 2.0. Before they commit, they want to have E2.0 explained to them in a way that makes sense to them as businesspeople; they want to understand what its benefits are, and whether these outweigh any accompanying risks. They’re not up to speed yet with the phenomenon, and want to get there. I hope I’m up to the task…
  • Executive involvement. Most of the success stories I’m familiar with include examples of executive blog posts, responses to comments, use of social networking software, and other hands-on signals from the top of the company. Such signals serve a few purposes. They demonstrate desired behaviors and actions. They directly communicate the voices and ideas of the company’s leaders. They show that one consistent set of rules and expectations exists about participation –  that 2.0 is for everyone, not just the rank-and-file. And they provide a short, straight line of interaction with executives, and one that runs in both directions. I’ve heard a lot of senior managers worry that E2.0 will take up precious additional hours in their workweek as they have to deal with a flood of comments, friend requests, tweets, etc. Luckily, almost every time this concern comes up there’s an executive in the room who’s adopted 2.0 tools and practices. She tells her colleagues that doing so actually puts hours back in her week. This news is received with a great deal of interest.
  • Alignment with the stated goals and values of the organization. In our interview, S&C stressed how E2.0 was right in line with LM’s stated goals of greater agility and tighter integration across business units. In the US intelligence community, E2.0 fit in perfectly with the explicitly stated need to move from a ‘need to know’ culture to a ‘responsibility to share’ one. When evangelists can show that the tools and approaches they’re advocating dovetail with what the organization is trying to achieve, they have a much easier time.
  • External pressure. S&C talked about the deep changes in LM’s business environment, including the need to respond to governmental requests for proposals in weeks instead of months, the growing popularity of open-source software at many customers, and the current administration’s drive to increase levels of transparency and collaboration in government. I’ve also heard how the demands and preferences of Millennial / Gen Y workers and the general quickening of the pace of business have encouraged E2.0. As the old saying goes, nothing focuses the mind like a hanging, and many companies these days feel that they’ll be left hanging if they just continue with business as usual.

The title of this post is the title of a wonderful book of essays by Daniel Mendelsohn (who in turn took it from Tennessee Williams’s stage directions for “The Glass Menagerie”). It’s a little bit highfalutin for a blog post about software adoption, but I don’t care. I think an advanced E2.0 deployment is a beautiful thing; it benefits both the organization and its people, and is the opposite of a zero-sum game. It’s also pretty delicate, though, especially in its early stages when many (all?) of the items in the list above need to be present.

As this list indicates, there are many ways for an E2.0 initiative to go off track, and it’s easy to look at successful deployments and conclude that they’re pretty easy, rather than quite difficult. Enterprise 2.0 successes look pretty similar because they tend to have the attributes listed above. E2.0 failures, in contrast, are all over the map because they can run aground for so many reasons. Tolstoy’s famous observation was that all happy families are alike, but each unhappy one is unhappy in its own way. I think much the same is true for Enterprise 2.0 deployments, and those of us who are interested in seeing them succeed would do well to identify what makes the good ones work, then try to replicate these factors whenever possible. I’d like to thank Shawn, Chris, and all the other advocates and evangelists who shared their insights during the conference. I learned a lot from you.

What do you think?  Is the list above accurate and complete, or are there other critical elements of a successful Enterprise 2.0 initiative that should be included?  Leave a comment, please, and let us know. And stay tuned for the next Enterprise 2.0 conference, which takes place on November 2-5 in San Francisco.

Harvard Business Press has made the first chapter of my book Enterprise 2.0: New Collaborative Tools for your Organization’s Toughest Challenges available for download (after you give them a name and email address).

I hope it whets your appetite and leads to massive volumes of preorders. More seriously, I hope it piques your interest in the book’s ideas and contents. If you have any questions or comments after reading the chapter, please leave a comment here.

Attendees at next week’s Enterprise 2.0 conference will also get a copy of this chapter. If you have any interest in learning how companies are using emergent social software platforms to advance their goals in today’s business environment, I strongly encourage you to attend. The conference schedule is a smorgasbord of interesting and relevant content, and I know I’ll learn a lot.

As an added enticement, the conference organizer’s have given me a discount code. If you use the code CNACEB21 when you register, you’ll get 30% off any conference pass or a free Expo Pavilion pass.

I hope to see you there!

A Pattern Language, published in 1979 by Christopher Alexander and his colleagues, was a landmark book in architecture that also became a landmark in other fields like computer science; one review called it “The decade’s best candidate for a permanently important book.”

It identifies architectural patterns at three levels – towns, buildings, and construction – that seem to work: to be both useful and livable, and to please and welcome people instead of alienating them. Alexander and his team came up with them inductively, by looking at architecture all around the world that worked and asking themselves why it did so. The authors interlink the patterns they identify, and A Pattern Language has been called “perhaps the first complete book ever written in hypertext fashion.”

It’s an amazing piece of work, and it popped into my head recently as I was trying to articulate for myself how Enterprise 2.0 work is different from Enterprise 1.0 work — from how knowledge workers used technology to get their jobs done before all these weird (and wonderful) Web 2.0 tools and communities appeared.

I’ve had for some time now the vague sense that the iPhone, Twitter, Gmail, Googling, Facebook, Wikipedia, Delicious, and other runaway successes are trying to tell us something about how we want to use technology in our lives and in our work, and if we enterprise technologists listen carefully we’ll hear what that something is.

I don’t believe that what they’re telling us is that we have to throw out all of our existing devices and applications and start enterprise IT from scratch. But we do need to throw out some tools, approaches, and philosophies, and incorporate other ones. The enterprise technologists that do the best job of this will be the ones that see their offerings succeed.

I started jotting down some comparisons based on what I’ve seen, read, and experienced for myself, then realized that I was identifying patterns (although far less rigorously and thoroughly than Alexander and his colleagues did). And I thought that in best 2.0 fashion I should open up this work early in the process by posting an initial set of patterns, seeing if they resonate with people, and asking for further contributions.

I’m dividing my 2.0 vs. 1.0 comparisons into two groups. First is a set of patterns where 2.0 is just better than 1.0 –  where the old should, I believe, just be replaced with the new. Second is a set in which 2.0 is an alternative or addition to 1.0, not a replacement for it. This second group of patterns, in other words, shows two alternatives, both of them valuable and viable, for how computers are used to get work done.

Some of these patterns use the broad term ‘technology,’ while others are more specific about devices or applications. They ignore, at least for now, whether it will be technically easy or difficult to accomplish the 2.0 vision. They’re just an initial set of patterns related to 2.0 work, which will hopefully be expanded and refined over time.


Patterns Where 2.0 Should Replace 1.0



Patterns Where 2.0 is an Alternative to 1.0

2.0 1.0
Technology appears to have been designed for the user Technology appears to have been designed for someone other than the user — the developer, the boss, a lawyer, etc.
Only small amounts of time and training are required to become familiar with a technology It takes significant time and training in order to become minimally competent with a technology
Few steps are required to accomplish basic tasks; technology-based work is ‘frictionless’ Many steps are required to execute basic tasks; technology-based work has a great deal of friction
Devices delight, pleasing the eye and the hand Devices exist to accomplish tasks and are designed only for function, not form
Delays and latency are low; technology responds instantly Delays (especially at startup) can be long and latency can be high
Crashes are no big deal and are easy to recover from Crashes are time-consuming and costly / catastrophic
Relevant data is in the cloud, so it doesn’t matter which device the user employs Relevant data is stored locally at many devices, so it matters which device(s) the user has access to
Users navigate via search Users navigate via menus and directories
Work is accomplished via the browser Work is accomplished via many discrete applications
Technology accurately guesses what users want, is forgiving, and makes users feel smart Users have to guess what the technology wants. The technology is unforgiving and makes users feel stupid
It takes virtually no time to author (to contribute online content) and few if any approval loops exist It’s laborious to author, and many approval loops exist
At its best, technology is welcoming and empowering At its worst, technology is alienating, isolating, and frustrating
2.0 1.0
Technology is used to execute spontaneous collaborative work Technology is used to execute planned / predefined business processes
Technology is used to share work and conclusions with others Technology is used to generate or analyze information individually
Technology is used to broadcast information publicly to people both known and unknown Technology is used to transmit information privately to known people
Technology is used to ask questions and solicit information and help from people both known and unknown Technology is used to ask questions and solicit information and help from a small group of already-identified people
Online content is the start of group-level work; it is work in progress Online content is the end point of group-level work; it is finished goods
Online content is generated by many people Online content is generated by a few approved sources
A person finds new colleagues by examining the online content they’ve generated and assessing its quality A person finds new colleagues by asking around an looking through official directories
Information sources give good answers to the questions users thought they were asking Information sources provide complete answers to perfectly phrased questions
Technology is used to create and diffuse new knowledge Technology is used to encode previously-generated knowledge

The ecosystem of the public Web –  its sites, applications, and gadgets — is a truly Darwinian place. It’s crowded, always full of new entrants, and characterized by low switching costs; in many if not most cases, the competition really is only a mouse click away. This makes it a tough environment, and one where only the strong survive. ‘Strong’ in this case, I believe, means something close to ‘delightful and valuable to users.’

Of course, the primary goal of enterprise IT is not to delight users, but rather to increase the value of the company. But do these two outcomes have to be in conflict? I don’t think so. It wouldn’t be prohibitively difficult or expensive for enterprises to adopt 2.0 patterns. The biggest challenge will probably be to get corporate technologists (a group that includes IT departments, vendors, and consultants) to stop thinking like monopolists that can dictate tools to users with great confidence that, because of the lack of alternatives, they’ll get used.

Today there are viable alternatives out there on the Web, and they’re revealing new patterns for getting work done. I can think of four negative consequences of ignoring these patterns and continuing to act like a 1.0 enterprise technology monopolist. In ascending order of severity, they are that enterprises will deploy technologies that are disliked and/or not used; that employees will use ’stealth IT’ and any knowledge / information captured therein will not be retained by the enterprise; that employees and customers will leave because of their frustration with poor enterprise technologies; and that the the enterprise will be handicapped or crippled  –  less productive, innovative, collaborative, agile, ‘wise,’ foresightful, insightful, transparent, clear than it could be otherwise, or than its competitor is.

What Enterprise 2.0 patterns are you noticing? How should the tables above be expanded? Leave a comment, please, and let us know.

Powered by Wordpress