The problem with collaboration

One of the problems with collaboration is that it often only works if many people do it. There is no good way to get to it one person at a time. For example, everyone now thinks the telephone is a great idea, but picture yourself 100 years ago, trying to sell someone the very first telephone. Why would anyone want it? You couldn't call anyone else, and no one could call you.

It's relatively easy to learn how to use a hammer or spreadsheet by yourself, because it only takes one person (you!) to make it work. It's harder to learn how to use e-mail effectively as a business tool, because there are two learning curves - each person has to learn what keys make something happen, and then everyone has to learn simultaneously what the new powers and pitfalls are of this approach. After a period of getting no e-mail and failing to check it regularly, you get going and run into "flame wars" and "spam" and come back from vacation to 250 emails and people angry that you didn't respond in 4 hours.

Then there's damage caused by the terrible "lost message" problem, where someone responds to you, but he message goes astray somehow, so they think they sent it and you think they didn't. They get silently upset that you aren't thankful, and you get silently upset that they refuse to respond to you, and it can chill or destroy relationships without anyone realizing what happened. This is actually a fairly common problem caused by the use of e-mail.

E-mail is an example of a "socio-technical system". It appears on the surface to be just a new technology, like a spreadsheet or word processor. That is, it appears to be in "technology" space. In reality, however, it operates primarily in social space, changing the way people interact. And, when it breaks down these days, it can break in either the technical space or the social space. The technical bugs and breakdowns are obvious. The social bugs and breakdowns are often not at all obvious.

So, it is actually quite hard to develop and test socio-technical systems. A good design will deal with all aspects of use, not just the technical ones. Many times, software people who grew up with single-user systems mistakenly think that all they need to worry about is the software and the "human interface", and forget the "social interface" part. When the system breaks down socially, they treat this as a big surprise, or something outside their control or responsibility. It should be part of the design. Not including it is like designing a bridge that only works if no cars actually drive over it.

If it's hard to get many people's expectations adjusted and synchronized for e-mail, imagine the issues involved if the software requires everyone, not just some people, to use it, and use it well for it to work out. Again, like the telephone, it can be a great idea, but is hard to start.

This is where hospitals are right now with computerized physician order-entry systems (CPOE). It doesn't do any good to send an order via this new technology if the person you are sending it to can't receive it, or doesn't check, or gets upset that you sent it. The stakes are quite high for "lost messages" when the message might be "Urgent! Don't give that drug to this person!" So, the expected place such systems will breakdown is in social space, which tends to be overlooked by IT people, or treated as some sort of single-user training issue that learning what keystrokes do what will solve. As with the e-mail, the keystrokes are just the beginning of the battle. "Implementation" then is far more than scheduling which people or units will "go live" on what dates, and being sure the "software works." That's just the leading edge of the actual social implementation and adjustments required that will make or break the system.

It's not too surprising that many such implementations fail, leaving the IT people just baffled since they had tested "the software" and it worked just fine. Odds are, no one had budgeted, staffed, and done an equal amount of testing and validation on the "social-ware" part of the system, mistaking single-user human-interface for all that needed to work, and blaming any larger social system failures on "bad users" versus "bad design." ( The bridge works fine so long as no one drives on it -- the design is perfect, and perfectly useless. )

Well, those are problems where at least some of the system is visible to the IT people. Then there are even harder problems, where most of the system is invisible and in social space. These are the areas where "systems thinking" is required, but again much of this work fails unless everyone understands it.

So, tomorrow I'll discuss how life-like simulators, like cockpit simulators, are used to train pilots in both which buttons to push, and what happens when 2 or three of them try to push buttons at the same time. These are two entirely different training problems, as the airlines took decades to learn, but have finally grasped.

Still, studies show that three-quarters of commercial airline accidents occur on the very first day a new set of people, all fully trained in which button does what, have to try to cooperate as a crew and fly the same plane at the same time. The social part, collaboration, is fully as important as the technical part, button pushing. Both are required of today's pilots.

This kind of training is something I'd like to explore for the executive suite -- as a way to take managers, trained in Theory X organizations, and teach them how to fly a Theory Y organization, in the privacy of their own office, anonymously, so one one has to see their clumsy and awkward period figuring out which way is up, and discovering that all their old instincts and reactions and intuitions are now wrong or worse than wrong.