It was six months when I started looking for work and it was just this last week that I got my first phone screen. There aren't many technical writing jobs in San Francisco, thus phone screens are rare. So I was pretty excited: finally, a chance to eliminate my commute!
Partway through the phone screen, I was trying to convince this company's CTO that he didn't want a technical writer. I don't think I convinced him. I probably wasn't very coherent--I was pretty surprised when I realized "Hey what the heck I am trying to talk this guy out of hiring me!?!" But I couldn't help it; when I talked with him about the project, it sounded like he could get a lot more use out of a short-term contractor writer and a junior programmer. And I said that before I really thought I was disqualifying myself.
And thus I will continue with my long commute.
My job title is "Technical Writer." But that's not my mission. My mission is:
Spread knowledge
Writing technical documents is one way to spread knowledge; sometimes it's the most appropriate way; often, it's not. Sometimes I get so wrapped up in some document that I forget to stick my head up, remember the big picture.
The Social Life of Information is a book about the big picture of spreading knowledge. It was written back in 2000--back when the internet's firehose of information was about to wash away all conventional governments, businesses, economies, societies, and we were all going to live happily ever after. The book points out: new communications technology eases the flow of information around the world, but there's still a "last 5mm" problem--getting that information through a learner's skull.
Lately, I've been working on company-internal documentation. I work for a large multi-national corporation with clusters of software engineers hacking away across the globe. Some group in Dublin figures out a clever way to do something useful. Can we spread that knowledge to other groups? Maybe. Sometimes.
The Social Life of Information touches on many topics. But my current focus caused me to latch onto certain parts. The second half of this book could have been called How Organizations Learn. I kept hitting passages which made me nod my head and say "Right on." Please indulge me as a quote long passages from this book.
...The instability that rapidly-changing technology brings, however, often lies less in the technology itself than in enthusiastic expectations that everything being "just a click away" or "at your fingertips" will make life easy. Battered by such hype, it's easy to believe that everyone except you knows how to use this stuff without a problem.
We saw this pressure at work on a new employee at Xerox PARC. She was intelligent and hard-working, but got mired in difficulties with the office computer system. That system came with the usual promises of "usability" and self-explanatoriness, but she found it impossible to use or understand. Being a newcomer, she was reluctant to keep asking for help. ...
Then chance moved her desk from an isolated office into the center of a group of offices. There she immediately benefitted from... incidental learning... She saw that these "stable" machines crashed for everyone. She saw that there was no more "ease" for experienced assistants, long-time employees, or PARC's hallowed computer scientists than for her. And she also saw that when a machine did crash, its user would without shame look around for help from someone else who, whatever their status, had successfully steered around that particular problem. No one person knew how to handle these temperamental machines. But spread around the office was enough collective knowledge to keep them up and running.
This story makes me cringe. She didn't report these crashes to the people who could fix them? Surely, there should be a way to report the crashes--along with documentation of "known problems"-- a-and with workarounds for those problems! Surely we should solve this problem with tons and tons of documentation. Then I calm down a bit. It takes effort to document things, to maintain that documentation. How much time should she have put into trying to track down where each crash was coming from, coming up with a good report? Who would be in charge of tracking the known problems? That takes effort, too. When you hire someone for some random job, you don't tack "...and must write excellent bug reports" onto their job requirements. It would be nice if these people carefully tracked down every defect, but it's not a realistic hope.
[When Alexander Graham Bell was promoting use of the then-new telephone]... The company needed, Bell argued, to abandon specialists and specialist training and put the phones in people's hands. In the right circumstances, the practicality of the device would do the rest. So he crafted the circumstances. ... [The company] put phones near lunch counters. That way, it reasoned, people who didn't know how to use them would be likely to see people who did know how and in this way learn about the phone system.
Later, they mention that one thing that helps people learn how to drive motor vehicles: before they learn how to drive, they've probably been a passenger many times, watching someone else drive. It's almost an apprenticeship system.
Another interesting section...
An anthropologist, Orr, studied the Xerox technical representatives (reps) who service and repair the company's copiers at customers' sites. ...
The company tried to provide the reps with the targeted information they would need. [It provided training and documentation.] ...
Everyone knew what reps did. But Orr argues forcefully that work is rarely well understood. Neither management nor management theorists, he points out, are adequately "concerned with work practice," by which he means they "do not focus on what is done in accomplishing a given job." He was not surprised, then, to find out that what looked quite clear and simple from above was much more opaque and confusing on the ground. Tasks were no longer so straightforward, and machines, despite their elegant circuit diagrams and diagnostic procedures, exhibited quite incoherent behaviors. Consequently, the information and training provided to the reps was inadequate for all but the most routine tasks they faced. ...
The reps' real difficulties arose, however, not simply because the documentation had lapses. They arose more problematically because it told them what to do, but not why. ... So when machines did something unpredicted, reps found themselves not just off the map, but there without a compass or tools for bushwhacking. ...
Orr begins his account of the reps' day not where the company process begins--9 o'clock at the first call--but at breakfast beforehand. From a conventional perspective, the reps' job was highly individual. Routine work was carried out alone... Yet Orr found that the reps were remarkably social, getting together on their own time for breakfast, lunch, coffee, or at the end of the day--and sometimes for all of the above.
...At these meetings, while eating, playing cribbage, and engaging in what might seem like idle gossip, the reps talked work, and talked it continuously. They posed questions, raised problems, offered solutions, constructed answers, and discussed changes in their work, the machines, or customer relations. In this way... they kept one another up to date with what they knew, what they learned, and what they did.
If I really want to spread knowledge around my company, should I write another document? Or should I offer to take care of an engineer's pet budgie for a week, freeing that engineer to travel to a remote site and sit down to lunch with a different group of people?
Reps tell stories about unsolved problems in an attempt to generate a coherent account of what the problem is and how to solve it. They may do this individually, putting their own story together. Or they can do it collectively, as they draw on the collective wisdom and experience of the group. ...
While it may appear at first that the reps used stories to circulate information, they were actually doing much more. For it is not shared stories or shared information so much as shared interpretation that binds people together. In their storytelling, the resps developed a common framework that allowed them to interpret the information that they received in a common light. To collaborate around shared information you first have to develop a shared framework for interepretation. ...
Before you can describe your day to someone, you need to understand your day and that someone needs to understand your vocabulary of description.
As a result of Orr's work, rather than trying to support the reps with yet more information from outside the reps' community, Xerox instead turned to reinforcing internal ties. The first step was simple. Reps were given two-way radios, which allowed them to continue to talk to one another even when working apart. This intervention both supported and acknowledged the reps' ways of collaboration, narration, and improvisation.
The second step was more ambitious, but it too reflected the resources the reps provided for themselves and tried to amplify this resourcefulness. Though passed on in war stories, the insight reps developed in the course of their work tended to have a short reach, traveling primarily in local groups, and a short life, fading from memory even locally. Consequently, reps near and far ended up reinventing fixes that might have been known elsewhere. The Eureka project set out to create a database of this useful knowledge, preserving over time and delivering over space resourceful ideas.
I.e., rather than giving them the effort of a writer, it was more useful to give them a tool that made it easy to record knowledge themselves. Maybe your organization needs a scruffy wiki more than it needs another polished document.
...To maintain a competitive edge, firms first search for the best practices either within their own or in their competitors' units. Once identified, they then transfer these to areas where practices are less good. The search part has led to a a great deal of useful benchmarking. The transfer part, however, has proved much more awkward. ... the now-famous lament of HP's chairman Lew Platt, as he considered how much better the firm would be "if only we knew what we know at HP."
Spreading knowledge ain't easy. Some moves, but a lot of it slips between the cracks.
Another colleague, Jack Whalen, showed the power of practice in his study of learning in a service center taking the calls from customers and scheduling technicians. ...the people who take the calls can save the company money by diagnosing simple problems and telling the customer how to fix these for themselves. ...
The phone operators are not, of course, trained as technicians. In the past, however, they learned from the reps when the latter called in to pick up their next job. The reps would then explain how trivial the last one had been, and in the process the phone operators could learn a lot from these mentors. When they next took such a call, they could offer such a solution. ...technicians no longer pick up calls this way. Consequently, operators no longer pick up insights. ...
The company has tried to replace this kind of learning with the more explicit support of a "case-based expert system." ... This alternative has not worked well. As the reps found with "directive documentation," it can be surprisingly difficult to get a clear diagnosis and solution this way. Moreover, such a system doesn't help the operators understand what they're doing. ... the company contemplated new training courses...
Whalen and his fellow researchers took a slightly different route, however. They studied one service center and the quality of diagnosis its staff provided. There they found two operators who gave especially reliable answers. One, unsurprisingly, was an eight-year veteran of the service center with some college experience and a survivor from the days when reps served as mentors. The other, however, was someone with only a high-school diploma. She had been on the job barely four months.
The researchers noticed however, that the newcomer had a desk opposite he veteran. There she could hear the veteran talking calls, asking questions, and giving advice. And she began to do the same. She had also noticed that he had acquired a variety of pamphlets and manuals, so she began to build up her own stock. Moreover, when she didn't understand the answers the veteran gave, she asked him to show her what he meant, using the service center's own copier.
...Ultimately, Whalen concluded, given the amount and level of knowledge already available in the room, what the operators needed were not so much expert systems or new training courses but "longer phone cords." (These allow an operator taking a call to slide over to the desk and the screen of a resourceful colleague who could provide the necessary help.)
Documentation wasn't useless in that story. The veteran had pamphlets and manuals. But the documentation wasn't enough, couldn't stand on its own.
We see two types of work-related networks that, with the boundaries they inevitably create, are critical for understanding learning, work, and the movement of knowledge. First, there are the networks that link people to others whom they may never get to know but who work on similar practices. We call these "networks of practice." Second, there are more tight-knit groups formed, again through practice, by people working together on the same or similar tasks. These are what, following Lave and Wenger, we call "communities of practice." ...
Great, new buzzwords with which I can bewilder my colleagues. Maybe if I say "network of practice" enough times, I'll irritate my co-workers enough such that I can trick them into reading the book just to find out what I'm talking about.
...In a similar vein, Saxenian draws attention to the importance of social forces to the development of Silicon Valley that both encourages and is encouraged by the networks of practice that run between companies. By contrast, the companies of Route 128 discouraged fraternization between firms. This insularity not only cut firms off from their ecology but also prevented the ecology as a whole from developing. ...
Promoting internal communication is good; don't forget to pull in people from the outside, though. I work for a big, growing, company. I could talk to a different brillant co-worker every day and never run out. If I did that, it would be tempting to forget the many brilliant people outside the company that I wasn't talking to. It's easy to fall into the trap of provincialism.
Gee, I'm tempted to just type the whole book into this blog entry, but my fingers are getting tired and that would probably violate copyright, so I'll stop here. I'll just recommend that you read this book. But not on this blog post. Oh, poor tired fingers.