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:
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
[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
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,
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
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
...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
Promoting internal communication is good; don't forget to pull in
people from the outside, though. I work for a big, growing, company.
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.
Labels: book, business, research