Are Collaboration Killers Roaming Your Halls?

Back around 1996, I made what I thought was the brilliant contribution to a workshop we (at Delphi Group at the time) called "The Complete Intranet Institute."

Mind you, this was the very early days of the public Web, let alone private intranets, so it was all very Wild West. Almost any in-depth thinking about the differences between corporate Web collaboration environments and consumer environments was a big deal.

The contribution wasn't just about democratizing content access or publication, not about the Web as a means to free content from "document" containers, and certainly not about microblogging streams, iPad apps, and cloud computing.

No, the discussion turned to "killing" your co-workers through collaboration.

If you're like most of the people who sat in that workshop, your first instinct just a moment ago was to reach out and shake me. "What in the world does that discussion have to do with collaboration at work?"

The person who immediately understood what I was talking about was an ex-Marine turned successful software exec. Why?

In the middle of the one-day institute, just after lunch as the carb coma was about to set in, I turned on the video game Quake. In our dedicated workshop room, we had quite the high-powered stereo system, so believe me when I say the first explosions got people's attention.

My point was this, and this was well before Second Life, the PlayStation Network, and Xbox Live: This "collaboration thing" we do online--we've always done it, since the first caveman handed a club to the guy next to him and collaborated to solve problems.

We aren't all naturally good at collaboration. Plan for reality, not dreams, if you want to survive the collaboration killers in your own organization.

So why did I use Quake in an intranet workshop? To show a simulation--virtual bullets fired, no one actually dies. If you want to survive in a multiplayer scenario, as a team, you had better get your collaboration skills up to snuff, or you're virtually dead.

The ex-Marine got it because he had trained in virtual environments for the sort of real-life dangerous missions he was going to be a part of. Sometimes these simulations are directly connected to reality; sometimes they're a stretch.

Simulations are incredibly useful environments. Unfortunately, most enterprise systems assume you're going to log in to a new system for the first time and jump straight into working like an expert.

This is absolutely the wrong approach about 90% of the time.

The early adopters/innovators of any new technology make up only about 10% of the population. (I bow to Everett Rogers and Geoffrey Moore on their diffusions of innovation and chasm work pointing to those statistics.) The early adopters/innovators are the ones willing to jump in when things are unclear and not yet formed. They're also the most likely to go poking at "real" systems to see what breaks.

While that profile fits me and some of the clients and colleagues I've worked with over the years, your boss, your colleague, your customer, your CEO, etc., are more than likely not the "jump in and figure it out" type. They're the mainstream or (generally in management) the laggards. You may not need the "For Dummies" approach, but that's not far off, and I don't mean that as an insult. You need to meet people where they are and onboard them from there.

If you provide a simulation/sandbox (as many wikis have) or a staged onboarding process (DropBox and Box.net do this very well in the consumer world.) that clearly walks new users through how to get started with the collaboration environment safely, they can cross that psychological barrier.

This also helps combat the "You just made a mistake, you're fired" fears that permeate corporate America in a down economy, which in turn discourages people from championing a new system or, God forbid, deleting or editing something in the new system.

Everyone makes mistakes. Plan for them!

If you (as the owner of the environment, an internal developer, a manager, a solution provider) have done your homework, the introduction/simulation you provide won't just be a generic one, but it will step users into doing their real work--within the first five minutes.

If you provide "mini-wins" (or from psychology, ways for people to step thru "mini-confirmations") that show they're on the right path, then you won't have a change-management problem on your hands.

The change-management problem is when well intentioned people try to get others to make an Evel Knievel-like jump over a software chasm, rather than first show them how to ride a bike with training wheels and then bring them along until they're mentally equipped to succeed in a new environment or scenario.

As someone who has spent 16 years thinking about how to make intranets, collaboration environments, etc., much more useful than they often are, I offer these questions:

Are you a collaboration killer or a collaboration contributor?

Only one will win, and in most situations, I'll bet on the collaborating team over the rogue agent. Action over debate. Imperfection improved over perfection never attained.

For those interested in participating in my "gaming meets the enterprise" experiments on Xbox Live, fill out the gaming experiment form (https://spreadsheets.google.com/viewform?formkey=dGJadXEzd0lhOFNMY1NGMWczNlJTU2c6MA). We'll link up online.

Game on or game over?

Dan Keldsen is the chief innovation officer at Information Architected Inc. (IAI), providing analysis, consulting, and workshops on Enterprise 2.0/social business and distributed convergence based on nearly 20 years of work as an analyst and consultant.

Attend Enterprise 2.0 Santa Clara, Nov. 14-17, 2011, and learn how to drive business value with collaboration, with an emphasis on how real customers are using social software to enable more productive workforces and to be more responsive and engaged with customers and business partners. Register today and save 30% off conference passes, or get a free expo pass with priority code CPHCES02. Find out more and register.