7
Going Mainstream
A Road Map for Enterprise 2.0 Success
This chapter presents guidelines and advice to help leaders deploy the new social software tools successfully. It builds on the bull’s-eye model and benefits described in chapter 4. Enterprise 2.0 success can’t be reduced to a single step-by-step recipe; there are too many variables, and appropriate actions depend critically on both the goals of the effort and the characteristics of the organization. So this chapter presents a road map rather than a recipe; it stresses simple actions that leaders can take to increase the depth and breadth of their organizations’ participation in the new digital environments.
Turning Off the Old
Gourville’s research on the 9X effect and consumer adoption of novel products and technologies, discussed in chapter 6, suggests several strategies for overcoming resistance to Enterprise 2.0 and increasing adoption rates of emerging social software platforms (ESSPs). 1 One of these is simply to eliminate the old product and so force adoption of the new. At first this approach appears to be impracticable for ESSPs, because it would entail shutting down e-mail and the other incumbent channel technologies. Most companies are unwilling to do this, for good reason. Private communication channels are highly valuable, and it would be unwise to eliminate them completely just to force faster adoption of ESSPs.
For group-level work, however, the group’s leader can come close to turning off e-mail by simply saying, “I’m not going to read e-mails about this project; put all updates on the wiki,” or, “We’re not going to write this report by e-mailing successive drafts of it around to each other; we’re going to write it by making all of our edits to the single online version.” At the innermost ring of the Enterprise 2.0 bull’s-eye, where colleagues are strongly tied, managers can exercise a great deal of influence over the tools used for collaboration. In many instances they can eliminate the old channels completely and force migration to the new platforms.
It’s also possible to eliminate existing methods at the second and third rings of the bull’s-eye, where ties are weak or potential. As discussed above, few tools are currently in use at these two rings, and none of them works particularly well. Many organizations distribute digital or paper newsletters in an attempt to keep people updated on one another’s activities, but it’s probably safe to say that these are not the most eagerly consumed pieces of information. I often ask my students and audiences to raise their hands if they receive at least one “official” company newsletter; most hands go up. When I ask how many people routinely read them, very few hands remain in the air. These newsletters are filtered and edited sources of news, and they are forced on readers regardless of interest or demand.
An active enterprise blogosphere, on the other hand, is the product of many contributors, is not edited or filtered by any central authority, and is consumed primarily via search or signals such as really simple syndication (RSS). In a blogosphere readers decide what’s relevant to them and then pull that content in, rather than relying on someone else to decide what information to push throughout the organization. Eliminating the old channels at the second and third rings of the bull’s-eye simply means shutting down the existing set of newsletters and other “official” updates. I doubt they would be greatly missed.
Using Believers
For managers hoping to overcome the 9X effect with long-haul products, Gourville identifies believers as an important category of user. Believers are early and spontaneous adopters, who for some reason quickly see the benefits of the new product and switch to it. Managers can leverage Enterprise 2.0 believers by turning them into internal champions and evangelists. This strategy is particularly powerful if the believers are respected within the organization because of their rank, seniority, expertise, informal authority, and so on. The U.S. intelligence community (IC) is an example of an organization that is successfully employing this strategy. By the middle of 2008, Don Burke and Sean Dennehy at the CIA and Chris Rasmussen at the National Geospatial-Intelligence Agency were spending much of their time training, coaching, and encouraging their colleagues, both in person and online, about Enterprise 2.0.
Within most organizations the number of believers is bound to grow over time even without active evangelizing. This is because many, if not most, new entrants to the workforce are reflexive users of ESSPs, preferring platforms to channels for communication, collaboration, and interaction. A great deal of attention is currently being paid to Generation Y, the children of the baby boomers. This generation is also called “Millennials,” because its members came of age—graduated from college and entered the workforce—after the year 2000. Many observers see significant differences between Millennials and previous generations, and it remains to be seen how many of these differences are significant and persistent.
It seems clear, however, that Generation Y uses technology almost intuitively, and uses different technologies than their elders do. In their book Connecting to the Net.Generation: What Higher Education Professionals Need to Know About Today’s Students, Reynol Junco and Jeanna Mastrodicasa report that 75 percent of college students in the United States have a Facebook account and 28 percent author a blog. 2 Most Millennials, it seems safe to say, are believers in ESSPs and have an endowment of collaboration technologies that includes both channels and platforms.
These believers don’t have rank, status, or authority within their organizations when they first enter the workforce, but they do have enthusiasm that can be harnessed. If enterprises choose not to recognize this and instead ignore Millennials’ preference for ESSPs, they may not only be missing an opportunity but also are creating an unattractive work environment.
Most knowledge workers sit in front of computers for large portions of the day. The applications they use probably have a large impact not only on their productivity but also on their mood, as well as their affinity for the organization that put the tools in front of them. By 2008 I was starting to hear stories from managers about young employees who had left their organizations specifically because they were frustrated by the poor collaboration and knowledge-sharing tools available. An October 2006 survey in The Economist described how the global war for talent was heating up. 3 I imagine that an increasingly important front in that war, at least for new entrants to the skilled workforce, is going to be the technology environments that companies build and within which they expect their employees to do their work. Environments that support the way smart young people want to work, and are used to working, are going to look comparatively attractive.
Designing Technologies That Will Be Used
Technologists can mitigate the status quo bias by building ESSPs that work with existing communications tools like e-mail and text messaging rather than being direct substitutes for them. Many popular blog and wiki packages, for example, now allow users to send updates from e-mail accounts or mobile phones. Similarly, Facebook engineers have developed customized versions of their SNS for popular mobile devices, including Blackberries and iPhones.
Developers can further short-circuit the endowment effect and status quo bias by building applications for which no direct incumbent exists. As discussed above, Facebook became so popular so quickly in large part because it wasn’t replacing anything—no widespread existing technology worked well for building, maintaining, and exploiting a network of weak ties. At the BBC, Euan Semple initiated Enterprise 2.0 with discussion forums because there was no online space where employees could pose a question to the entire organization in hopes that someone would have an answer for them.
Online forums have also become popular at many other companies—including Google, where Bo Cowgill used the corporate idea board to post his thoughts about a prediction market and find colleagues to help him build it. Of course, corporate prediction markets themselves are highly novel technologies. Before they existed, employees had no way to put their money where their mouths were regarding future events of interest to the company, or to convert their beliefs and hunches into a tradable portfolio.
Finally, technologists can reduce the amount of behavioral change required to use their products. Gourville divides successful products that aren’t long hauls into two categories: easy sells and smash hits. McDonald’s achieved an easy sell with an ESSP set up in advance of a 2007 franchisee conference. Attendees were asked in a preconference survey to describe any best practices they wanted to share with their peers. These were then collected and posted to the conference Web site, which was maintained by the ESSP vendor Awareness. Awareness built discussion forums around this set of practices so that franchise owners could interact with and learn from one another before, during, and after the conference. Rather than presenting the conference site to the franchisees as a potentially confusing wiki or blog, McDonald’s and Awareness simply positioned it as a standard Web site with initial user-generated content and additional features. This was an easy sell.
Smash hits are innovations that “offer great benefits but require minimal behavioral change.” The most recent Web 2.0 product to meet this definition is probably Twitter, the updating tool described in chapter 3. Twitter was started in late 2006, and by August 2008 it had approximately 2.4 million registered users and a volume of updates heavy enough to crash the entire service periodically and necessitate a redesign of its architecture. Twitter lets people do something they couldn’t do before—broadcast short updates on any topic of interest to the entire world and selectively consume others’ updates—but it lets them do so using familiar tools and interfaces such as e-mail, mobile phone text messaging, and Web pages. By allowing users to carry out novel and valuable activities in deeply familiar ways, Twitter became a smash hit. 4
Six Organizational Strategies
It will, I hope, be clear by this point that the main challenges around Enterprise 2.0—the challenges of getting ESSPs widely and productively adopted within enterprises—are not the ones indicated by the questions listed in chapter 6, but instead those concerning people’s choices, biases, and endowments. Enterprise 2.0 is ultimately the result of a large number of individual choices about which technologies to use for communication, collaboration, and interaction. If many people choose to use ESSPs, healthy and valuable online environments are likely to result. If, however, the great majority of people choose not to use ESSPs in their professional lives and instead to continue to communicate only via traditional channel technologies, their enterprises will not reap the benefits described in chapters 4 and 5.
Awareness of challenges leads to the development of effective strategies for meeting them. My road map for success using Enterprise 2.0 has been developed through a combination of research, consulting, discussions with academics and practitioners, observation, and awareness of existing relevant research in many fields. This road map has six main sections.
Determine Desired Results, Then Deploy Appropriate ESSPs
ESSPs all share some deep similarities, but they are emphatically not all identical. As case studies demonstrate, and as the examples in chapters 3 and 4 illustrate, ESSPs can produce many different outcomes for an organization. They can operate at different levels of tie strength, and they can deliver a range of benefits.
The first step in any Enterprise 2.0 effort should be the formation of a consensus about its goals. The conversation that yields this consensus should involve both business and IT leaders. The material presented in chapters 4 and 5 can, I hope, be of some value during this conversation, but the specific terminology and framework used during goal-setting discussions are not critical. What is critical is to arrive at a shared understanding of what the enterprise hopes to achieve. Is the main goal to enable strongly tied colleagues to do better group-level work? To let people broadcast their expertise, or their questions, throughout the organization? To build better weakly tied networks inside and outside the enterprise? To harness collective intelligence? As I hope this book has made clear, realizing each of these goals requires a different technology toolkit.
Each of the case studies in chapter 2 began with awareness of an open space—a need that was not being met or an opportunity that was not being seized. None of them began with a vague realization that something interesting was happening on the Internet with Web 2.0, or an equally hazy sense that it would be beneficial to do the same activities on the intranet. It’s also the case that none of them began with a desire to bring “user-generated content” or “social media” into the organization. Rather, these ESSP deployments all started by identifying a fairly specific need or opportunity.
Being specific about needs and opportunities allows enterprises to be clear about which ESSPs they’ll acquire. As these tools are being installed, the next step is for the organization to plan its adoption efforts.
Prepare for the Long Haul
As discussed earlier in this chapter, some ESSPs may be easy sells within organizations. If no incumbent technology is in place, and if no great behavioral changes are required, Enterprise 2.0 technologies can be quickly and widely adopted. Managers are often surprised to discover how many of their employees already have Facebook accounts, for example, and to learn that there is actually a formal Facebook network in place for their organization. Facebook spreads quickly in part because most people do not have a prior endowment of social networking software, and because it is easy and intuitive to use. And as previously noted, a technology like Twitter, which is highly innovative and delivers novel benefits without requiring individuals to make significant behavioral changes, may even be a smash hit within the enterprise.
Most of the tools of Enterprise 2.0, however, do require both behavioral and technological changes and are therefore long-haul products. Most of today’s knowledge workers are not familiar with authoring for a broad audience, linking to and tagging online content, trading in a prediction market, or many of the other activities conducted on ESSPs. Furthermore, e-mail, at present the universally deployed collaboration technology, is part of the endowment and status quo for every worker. Because Enterprise 2.0 requires at least a partial shift away from this endowment, its adoption proceeds slowly—often more slowly than its enthusiasts expect.
Individuals, routines, processes, and organizations do not typically adapt quickly without a crisis or other forcing mechanism. Consequently, Enterprise 2.0 enthusiasts must learn patience and adjust their expectations to reflect the realities of a long-haul adoption.
The well-known examples of Web 2.0 successes—Facebook, Wikipedia, Delicious, Flickr, Twitter, and others—can convince observers that ESSPs are so inherently compelling that they essentially deploy themselves, becoming both broadly and deeply used with great speed. This perception, however, is inaccurate. As noted in chapter 6, only a very small percentage of Web users have ever actually contributed content to a Web 2.0 platform; if this same percentage were applied to the population of an enterprise, even a very large one, it would yield very few participants in Enterprise 2.0. Increasing the percentage of people within an organization who regularly contribute to ESSPs and ensuring that these platforms are healthy, vibrant, and sustainable environments is probably the work of years rather than months.
Communicate, Educate, and Evangelize
A critical component of this work, one that’s probably at least as important as agreeing on the goals of the Enterprise 2.0 effort and selecting appropriate technologies, is communicating with the intended users of the new tools. This communication task can be divided into three phases: explaining to users the goals of the effort, training them on the tools themselves and related best practices, and continually encouraging them to contribute to ESSPs. The Serena and IC case studies are both examples of thorough communications programs. The IC’s Intellipedians conduct frequent sabbatical programs in which analysts are taught both how to use tools like MediaWiki software and why they are valuable. After executives at Serena introduced the company’s efforts to use Facebook extensively, they maintained their focus on these efforts over time through new initiatives such as using the SNS to plan and execute corporate social responsibility efforts.
Enterprise 2.0 enthusiasts are often surprised by how much effort is required to build and maintain momentum for their work, especially in the early phases of an adoption effort. But just as long-haul products typically require a great deal of marketing and advertising in the consumer world, so too do ESSPs require a sustained communications effort. In my experience many organizations underemphasize the first and last of the three phrases, instead focusing too heavily on training efforts. This attitude can leave a user community aware of how to contribute to the ESSPs but unsure why doing so would be a good thing.
Early adopters and Generation Y entrants into the workforce are typically the most enthusiastic trainers and evangelists for Enterprise 2.0, but the formal leaders of the organization must also participate actively in the communication effort. These leaders can send a credible signal that ESSPs are important, and that contributions to them will be valued. Senior executives at Serena were some of the earliest and most passionate advocates for using Facebook and other social software. Within the IC, top administrators have also been evangelists for Enterprise 2.0. As Michael Werthheimer, the assistant deputy director of national intelligence for analytic transformation and technology (who has been described as the “philosopher of transformation” for intelligence analysis), told the community of analysts in a major speech, “We are going to share more … We are going to take risks.” 5
Move ESSPs into the Flow
In a December 2007 post to his Transparent Office blog, Michael Idinopulos made an important distinction between using ESSPs “in the flow” of work—as part of the standard procedures for getting one’s job done—versus “above the flow” of work—in addition to the standard activities of the workday. Concentrating on wikis, he wrote:
Left to their own devices, people don’t collaborate very much in above-the-flow ways. That was one of the great (if depressing) learnings of the Knowledge Management movement.
Above-the-flow wikis are used lightly (when at all) by large groups of people. Many are encouraged to participate, but participating is rarely an urgent or critical-path activity. Lurking is extremely common, and the bulk of content comes from <5% of users who are either personally invested in the success of the project or just love to publish. Wikipedia works because of the law of large numbers: A small percentage of a huge number is still a large number.
Adoption of in-the-flow wikis looks very different. It’s not at all hard to get people to use in-the-flow wikis. They are used intensively by relatively small, well-defined groups of people: a project team, a business unit, etc. Once the group (or the group’s manager) decides to use wikis as the primary collaboration tool, adoption is quite easy: People use it because that’s the way to do their work. Lurkers are rare, since most people have a steady stream of things to contribute to the rest of the group. 6
Idinopulos stressed that both types of ESSP have value, but cautioned that “[champions] should not expect an above-the-flow wiki like an internal knowledge exchange to have the same level of usage as an in-the-flow wiki.”
From what I’ve seen, ESSPs that are perceived as being purely above the flow have difficulty sustaining momentum and often wither over time. For this reason champions of Enterprise 2.0 often work diligently to move ESSPs into the flow of their organization’s work. Within the IC, for example, Don Burke and Sean Dennehy stress “Replace Existing Processes” as one of their three core principles of Enterprise 2.0 for intelligence analysis. At VistaPrint, Dan Barrett continually encouraged his colleagues to use the company’s wiki instead of e-mail for sharing knowledge with one another. Over time, his persistence paid off, and the wiki moved into the flow of VistaPrint’s knowledge work.
As these examples show, the decision to move ESSPs into the flow is often a deliberate one. Leaders can mandate that their teams will use group editing tools when writing a report, for example, or require that all departments, business units, and labs maintain blogs about their work. Some ESSP uses appear likely to remain above the flow—it’s not obvious, for example, how trading in a prediction market can be moved into the flow—but in many, if not most, cases Enterprise 2.0 can become standard operating procedure.
Measure Progress, not ROI
It’s possible to quantify many things about an Enterprise 2.0 initiative: the number of blog posts and comments; the number of wiki edits, editors, and new pages; the population of tags created; the volume of trades and traders in a prediction market; the number of members in a technology-facilitated social network and the volume of updates they share with one another; the popularity of all of these ESSPs as measured by the number of times they’re viewed; and so on. Robust tools are available to collect and display all these types of data, and they serve as useful indicators of the progress and momentum of an adoption effort. Both Google and the IC have conducted extensive analyses of the activity on their ESSPs and use this information to both track and shape their initiatives.
It’s also both possible and smart to collect case studies, anecdotes, and examples over the course of the effort to demonstrate the value of ESSPs. These examples serve two purposes. First, they illustrate desired actions and outcomes and so help to communicate the effort’s goals to participants. Second, they help convince decision makers that the effort is yielding results and is thus worth continuing to fund and support.
I do not, however, advocate that decision makers should ask for quantitative ROI analyses, either before approving an Enterprise 2.0 effort or to assess its progress. This view may seem surprising, since most organizations have a long-standing tradition of using ROI figures to justify IT investments. So why should the new social software platforms be an exception to this tradition? Discussions about the ROI from Enterprise 2.0 always remind me of an experience I had during a seminar in 2006.
In this seminar I was presenting the concepts and structure of my MBA course to a diverse group of Harvard Business School colleagues. Pretty early on, one of the professors in the finance area asked me the question I was most dreading and least prepared for: “Andy, what do you teach students about conducting a financial analysis of a proposed IT investment? How do you build a business case for IT?” I was about to launch into a long-winded and poorly argued answer, but Bob Kaplan spoke up first. “You can’t,” he said.
Kaplan is responsible for both activity-based costing and the balanced scorecard, so he speaks with no small authority on matters of costs and benefits. After the seminar he gave me a copy of Strategy Maps, which he wrote with David Norton. The subtitle of the book is Converting Intangible Assets into Tangible Outcomes. Intangible assets consist of human, organizational, and information capital; they define the latter as “databases, information systems, networks, and technology infrastructure.”
The authors make their point forcefully and early in the book: “None of these intangible assets has value that can be measured separately or independently. The value of these intangible assets derives from their ability to help the organization implement its strategy…. Intangible assets such as knowledge and technology seldom have a direct impact on financial outcomes such as increased revenues, lowered costs, and higher profits. Improvements in intangible assets affect financial outcomes through chains of cause-and-effect relationships.” 7
This is a very crisp articulation of what I was going to try to say in the seminar. I’ve probably seen hundreds of business cases that identify the benefits of adopting one piece of IT or another, assign a dollar value to those benefits, and then ascribe that entire amount to the technology alone when calculating its ROI. The flaw in this reasoning is that the first two steps of this process are at best estimates, at worst pure speculation. The final step gives no credit and assigns no value to cotemporaneous individual- and organization-level changes. It’s a little like giving all the credit for the Boston Red Sox 2004 World Series victory to manager Terry Francona, or hitter David Ortiz, or general manager Theo Epstein. Although all three were critical and probably even necessary elements, it would be ludicrous to say that any one of them was wholly responsible for the win.
Usually, even the most rigorous and objective IT business cases are exercises in speculation and attribution. And most IT business cases are something less than rigorous and objective. At their worst, they are like Soviet five-year plans—devices used by competing groups to come up with ever-bigger numbers in order to secure funding and avoid hard scrutiny.
IT is vexing because its costs are so clear, and often so high. Indeed, on paper concrete expenses make IT look like a new machine tool, assembly line, or factory, none of which a responsible company would buy without first conducting financial analyses. The difference between IT and these other fixed assets is that machine tools and factories add value directly, not through “chains of cause-and-effect relationships.”
A company invests in a new assembly line because it needs greater widget capacity. If it had that increased capacity, it could make and sell more widgets. The relationship between costs and financial benefits in this case is complicated in some ways (depending on many factors, some of which must be estimated), but the cause-and-effect chain is a short one, and one that doesn’t depend on lots of cotemporaneous changes.
With IT, in contrast, cause-and-effect chains are often quite long and dependent on changes in human and organizational capital, as well as information capital. It wasn’t enough, for example, for IntraWest just to purchase and install an ESSP that included blogging capability. Employees had to become comfortable contributing to this new social platform, searching for and consuming its information, and using it as a tool for collaborating with their remote colleagues.
IT looks very much like a standard capital investment—a company pays cash and acquires an asset, whether that asset is a server or a CD full of software, the right to access a system over a network, or any other innovation. But this money-for-assets exchange represents only surface-level activity. The real phenomenon of interest is the attempt to acquire an IT-based benefit, just as advertising is an attempt to build a brand and R&D is an attempt to innovate. Each of these attempts requires sustained management attention, not just a periodic contest among business cases in which the highest ROI figure wins.
So does this mean that companies should just stop building business cases for Enterprise 2.0 initiatives and other IT efforts, and proceed instead solely by intuition or the persuasiveness of a sales pitch? Of course not. I counsel Enterprise 2.0 advocates to put together a business case that has three main elements:
• Costs and time lines: The cost portion of the cost-benefit analysis can and should be calculated with all due precision. The cost breakdowns of most types of IT effort are well understood by now and should be laid out in advance. So should the best initial guesses about how long the whole effort will take, how it will be segmented, and what milestones will be reached along the way. When doing this, it’s important and smart to acknowledge the great uncertainty inherent in both anticipating costs and timing, especially for large and complex projects.
• Benefits expected: The previous section categorizes the benefits that ESSPs can deliver. While these benefits are not as low-level as the feature sets of any particular piece of software, neither are they as high-level as some of the promised results from IT like “organizational transformation” and “customer intimacy.” They provide a foundation for a concrete discussion of outcomes from Enterprise 2.0 that doesn’t rely on knowledge of any specific vendor’s offerings. When describing benefits, it’s often useful to include short case studies or examples of the results of other ESSP deployments. One such case study could be, “At Intrawest blogging allowed a cost savings of $500,000 to be transmitted throughout the company, and management believes that the transmission would not have occurred without the blogging platform.” Examples like these show decision makers that Enterprise 2.0 does yield impressive results.
• Technology footprint: A technology’s footprint is its geographic, divisional, and/or functional reach. It’s a description of how much territory a piece of IT is intended to cover. Some information technologies such as e-mail have large footprints that are easy to expand. Others have fairly small ones; a computer-aided design system isn’t that useful outside the engineering department. For ESSPs, the footprint is closely related to the concept of tie strength. Social software platforms that are intended to span the outer rings of the bull’s-eye—where ties are weak, potential, or nonexistent—must have much larger footprints than those that span only strongly tied colleagues. As previously discussed, most of the benefits of Enterprise 2.0 increase as the technologies span more types of ties and so have larger footprints.
Cost, capability, and footprint in most cases constitute sufficient information to allow business leaders to make IT decisions. They also provide a basis for prioritizing IT initiatives, something many companies struggle with. Is it more important for customer interaction processes to be standardized across all business units, or for vendor interaction processes to be? Is it more important to change how engineers collaborate, or to give them better tools for experimentation? These are not easy questions, but they are important and appropriate for leadership to discuss.
The comparison of dollars spent in relation to benefits acquired isn’t one that yields an ROI number, but it’s one that business leaders are adept at making. Most of the executive teams I’ve worked with would have little trouble answering questions like, “Is it worth spending $1 million and tying up the following resources for the next six months in order to build a broadcast search system that will span weak and potential ties?” I don’t mean to imply that the answer to such questions is always yes. I simply mean that most business leaders can answer them quickly because they’re posed in familiar terms—as cost-versus-benefit trade-offs.
Across the hundreds of quantitative IT business cases I’ve seen, I’d estimate the average ROI figure at about 100 percent. This observation raises a couple of obvious questions, which I have asked every business case author I could find: “If this ROI figure is at all accurate, why are companies spending money on anything else except IT? If there really are all these 100 percent ROI projects out there, doesn’t Finance 101 say that companies should immediately start lots of them and not stop until the marginal return is less than the return from traditional investments such as advertising, R&D, capacity expansion, and so on?”
I never got a satisfactory answer to this question until I read Strategy Maps and saw Kaplan and Norton’s points about how nebulous the numerator—the financial returns—of this ROI figure is, and how the denominator actually comprises not only IT capital but also human and organizational capital.
Walking away from ROI-based business cases for Enterprise 2.0 efforts does not mean walking away from careful thinking or analytical rigor, nor does it mean abandoning any important management duties. Rather, it entails acknowledging that IT is a lot more like R&D than like a new machine tool, and that reliance on large ROI numbers is both a shortcut and a potentially dangerous habit.
In my experience, ROI calculations for IT efforts more often than not wind up being exercises in justifying what someone already knows he wants to do. I am convinced that decision makers are easily capable of comparing the costs of an Enterprise 2.0 effort against the benefits it will provide, even if the two elements of this comparison are not expressed in identical financial terms. Chapters 4 and 5 can help Enterprise 2.0 advocates articulate the benefits of ESSPs, and it’s straightforward to calculate the costs of a deployment. A discussion of whether it’s worthwhile to pursue Enterprise 2.0 should revolve around whether these benefits are worth the cost, not whether the ROI figure for the project clears some hurdle rate. I have never spoken with a leader or participant in a healthy Enterprise 2.0 initiative who wishes that she had calculated an ROI figure, whereas I have spoken with many people who have described their ROI exercises as unproductive uses of time and effort.
Show That Enterprise 2.0 Is Valued
Perhaps the most frequently asked question I’ve heard related to the adoption of ESSPs is, “What incentives should we put in place to best encourage participation and contribution?” This is clearly a critical question, since incentives strongly influence behavior. As they begin to investigate social software, enterprises often ask themselves what new incentives, if any, to offer, and how, if at all, to modify existing ones.
Across organizations that have experience with Enterprise 2.0 there is a rich mix of beliefs and viewpoints about proper incentives. Some believe in relatively concrete and obvious signs of recognition and appreciation for good contributors. Within the IC, for example, particularly active Intellipedia editors were sent a small plastic shovel with the words “I dig Intellipedia! It’s wiki wiki, Baby” on the handle and, more recently, a coffee mug with the words “Intellipedia: it’s what we know.” In addition to these small gifts, it was also customary to send the editor’s supervisor a letter describing the contributions and expressing gratitude. Google distributed both cash prizes and T-shirts to the company’s most active traders and other star performers in the internal prediction market (the T-shirts turned out to be more highly valued). These concrete symbols provide gratification and an ego boost to ESSP contributors, as well as serving to start subsequent conversations about Enterprise 2.0.
Other organizations advocate making contributions to ESSPs part of an employee’s formal objectives or job description. This approach reflects a belief that making Enterprise 2.0 “part of everyone’s job” is the best way to accelerate it. Organizations that adopt this attitude hope that the relatively hard incentive will encourage even older and less tech-friendly workers to investigate the new tools and eventually incorporate them into their work. This approach is particularly common among enterprises seeking the benefit of authoring; they want people to commit their expertise in digital form to an ESSP like a blog, wiki, or answer board.
Organizations put incentives in place to encourage behaviors that they desire or value. This reality points to a single broad and powerful guideline for fostering Enterprise 2.0 that goes beyond the specifics of any incentive plan: demonstrate that contributions to ESSPs are valued. Perhaps the most straightforward way in which the leaders of an organization can do this is to consult and use these contributions themselves. Commenting on blogs, asking the authors of wiki pages questions, and bringing up content from an ESSP during a meeting are examples of quick and simple, yet effective, ways of showing that the new platforms, their content, and their participants are all important. My experience, observations, and intuition indicate that activities like these by managers and executives may well be the most powerful ways of fostering Enterprise 2.0.