Transparent Office

When the Dog Catches the Car

What do you do when a wiki pilot succeeds? This is a question I'm hearing more and more. Usually the conversation goes something like this: "We launched a wiki pilot. It went great. Everyone in our group uses  the wiki. We can't live without it. We'd love to see the rest of the company follow our lead. But...they're not."

In theory this shouldn't be happening. According to most theorists of social software, getting started is the only hard part. Once a pilot is successful, viral adoption and network effects are supposed to take over and ensure broader uptake, just like the old "and she told two friends" shampoo commercial. (BTW, if you have a URL for that commerical online, please post it!). Stewart Mader, for example, describes it this way on his blog:

Dwight is compiling his quarterly marketing report with his teammate, Jim. He and Jim use the wiki to add their respective statistics and compile the department's report. However, when the report is complete, it must be submitted to their manager, Michael, who will have comments. Rather than emailing the report to Michael and then manually incorporating Michael's changes, Jim realizes it will be far easier for him if he has Michael do it directly to the wiki document. Michael, in turn, has to submit the report to the regional director, Jan, who will have her own changes. So Jim signs Michael up for the wiki, and then Michael gets Jan to use the wiki. It can expand even more widely from there.

Stewart has a good example, but it misses the fact that adoption has a natural stop. If Dwight and Jim are working together on the wiki to create a departmental report, it's very easy for Michael to join them as long as Michael is working on that same report. But what about Mary, who isn't working on that report?

When wikis are used in-the-flow, they have natural boundaries beyond which adoption does not typically spread without help. If the Marketing group uses the wiki to research and write reports, then adoption of that wiki will probably end with the Marketing group (and maybe a few interested outsiders.) It's not a silo thing; it's just that when people use wikis to work together on an activity, that wiki is not usually interesting or accessible to people who aren't engaged in that activity.

This doesn't discredit the notion of viral adoption. But when we think at the level of the enterprise, rather than the pilot, we need to think about virality differently. Rather than viewing virality as the extension of existing wikis and use cases to new individuals, we need to see it as the extension of wikis to new use cases (and, by extension, individuals).

Just to put a name on it, let's call this "Use Case Virality" and contrast it with "User Virality". User Virality is when users pull new users into existing wikis and wiki-enabled collaborative activities. Use Case Virality is when users extend existing wikis or create new ones to support and enable new and different collaborative activities.

What I'm saying here, and what I think a lot of the standard talk about virality and network effects misses, is that User Virality all by itself does not generate enterprise-wide adoption. User Virality may result in some nice, contained pilot successes, but in order to go enterprise-wide you need Use Case Virality as well.

Let's Talk about Numbers

Just when you thought it was safe to go back in the water, SocialText has made another major product announcement: SocialCalc, the first truly wiki-integrated spreadsheet.

SocialCalc has one really big, really obvious benefit over traditional spreadsheets like Excel: it's distributed. In other words, more than one person can work on it at a time. But as ZDNet's David Greenfield and others have pointed out, we're not the first ones to have delivered distributed spreadsheeting.

What's different about SocialCalc--and I think it's really fundamental--is that SocialCalc is integrated into a wiki. You can drop a spreadsheet into a wiki page. You can drop wiki text into a spreadsheet. You can link from a spreadsheet to a wiki page that explains where the numbers came from. In short, you can talk about the numbers.

What a concept...talk about the numbers. If you've done a lot of modeling, you know that the hard part isn't the mechanics of the model; it's the reasonableness and consistency of the assumptions, the accuracy of the inputs, and the strength of the modeling logic. And for all of those things, you need to talk: to your teammates, your colleagues, your data providers, your analysts, etc. A spreadsheet is rarely a one-person affair. Even if one person builds the spreadsheet, the data and thinking that goes into it almost always comes from a broader team of contributors. If those contributors aren't talking about what they're doing, it's just garbage going in. And we all know what garbage in leads to. Talking is also the single best way to spot the spreadsheet errors that Dennis Howlett has so artfully documented.

Our traditional analytical tools--whether Visicalc, Lotus 1-2-3, Excel, or even Google spreadsheets--have done a great job enabling us to crunch the numbers. But they've made it really really hard to talk about the numbers we were crunching. There's no good way in Excel to explain where the figure in Cell I-57 came from. There's no good way to ask whether the growth projection in Y-163 feels reasonable to the rest of the team.

Those of us who have done a lot of modeling come up with our own workarounds. We flag assumptions in a special color. We make cryptic annotations on those little yellow stickies you can add to cells. But those workarounds don't really shed much light. They may serve as useful personal reminders to the model-builder, but they don't usually do much for the rest of the team. If you really want to understand my model, let's face it: I have to walk you through it. If I'm a good and careful modeler, the process is painful and time-consuming. If I'm a sloppy modeler, well...let's not think about that scenario.

SocialCalc enables teams to have conversations about the models they are building. If I want to explain where I got the number in I-57, I can write it in a wiki page. A teammate can question my logic on that same page. If the teammate owns that input, she can change the number, and she can explain her reasoning so I understand it.

Realizing these benefits will, of course, require some new spreadsheet hygene. Modelers will have to start explaining the assumptions behind their models (gasp!). Teammates will have to pay attention to those explanations (double-gasp!). In short, teams will have to start talking about the numbers. With SocialCalc, they finally have a good way to do it.