Learn by watching - Then do

JP Rangaswami writes an excellent blog - Confused of Calcutta - where he shares his experience as an "accidental technologist" who moved from investment banking to the services arm of a telco. His post on Facebook and Knowledge Management tells a great story about what happened when he decided to open up his mailbox to his direct reports:

My intention was to let them see precisely what I did by showing them what I faced, the incoming mail. That they could somehow vicariously gain the experience of sitting where I sat, doing what I did, thinking what I thought, by seeing what I saw.

And then I observed what they did. Boy was I wrong. Most of them were far more interested in my ‘sent mail’. They felt they could learn more by watching my outgoing rather than my incoming, they felt they could get ‘into my head’ faster by focusing on my responses rather than on the stimuli. - JP Rangaswami

His conclusion? "People learn best by watching what you do." He builds a great case for the future of knowledge management: Reduce the cost and simplify the process of letting people watch what you do - and learn from watching.

This strikes a very deep chord for me. Many years ago, I worked as project engineer at the Naval Research Lab with a handful of peers and a very creative boss. My boss would shuffle project assignments every now and then: I'd take over Rick's project, he'd take over mine, Sue would swap assignments with Peter, etc.

It was a small office. We knew generally what everyone else was up to and how it was going, but we each were deep in development, consulting, contract management, meetings, sponsor briefings and lively discussions with other project stakeholders. We could see the forest, but managing a project meant dodging the trees while running as fast as you could. When YS pulled the rug out under from us, the only way to come up to speed quickly was to scan the project serial file he had us keep.

Each project's serial file was nothing fancy. Usually it was a few file drawers with incoming and outgoing correspondence, briefing slides, q&a memos, contract actions and meeting notes, all top bound in chronological order - full contracts, formal specs and other deliverables were filed separately. In pre-email days, the project serial file was a pretty accurate snapshot of our interactions with the outside world interleaved with internal notes and memos. We all kept our own date stamped lab notebooks for private jottings.

A day or so of close reading and the chance to ask a few pointed questions to the original project engineer ("You said WHAT to Captain K??") usually got us up to speed on the pulse of each project - not just the formal status and deliverables. We learned to use the project file to refresh our memory on details before and important meeting or decision - or just to reflect and review the bidding. We learned to use each other's project files to keep track of dependencies and learn how to handle problems. Thomas Stewart had a similar experience:

"A whale ship was my Yale College and my Harvard," said Herman Melville's Ishmael; when it came to learning my job, circulating correspondence was mine. Reading my superiors' letters opened a window into how they conducted business with the world outside; I aped things more experienced colleagues did, and saw how they handled tricky situations; I copied useful addresses into my Rolodex (another antique). I learned who knew what, and that made me better at asking for advice. - Thomas Steward - The Wealth of Knowledge

I know that an electronic form of serial file can replace the old paper trail, since that's what I use every day. The TeamPage blog + wiki tool lets everyone look over my shoulder - and vice versa - as we tear off in different directions and do our work as individuals or teams.

I rarely need to read any one project in real time, but I know that I can come up to speed quickly, search across all projects, and dive in if I need to. If someone asks for help or sees an opportunity, they can post it if it's not urgent; add a tag to anything that needs quick action; or IM a permalink if they need me to look at something now. What I can do, all of Traction's employees can do - only the "Board of Directors" project is private. Board pages or posts - including monthly financials - are cross-tagged to make them visible to all hands when the dust settles.

It works the same way for our customers, reseller partners, OEM partners, law firm, Board members, PR firm and contractors. They just see, subscribe to and search a smaller set of projects than Traction employees, based on permissions assigned for each project. For example, each partner, customer, and contractor we have a long term relationship with has a separate project (blog + wiki space) dedicated to private working communication between us and them. All Traction employees, partners and customers share access to other project spaces for common work and discussion. We cross-tag posts, comments or pages we want to make visible across larger number of projects - and involve a wider audience.

More and more, knowledge management is going to be about reducing the cost of, and simplifying the process for, letting someone watch what you do. Nonintrusively. Time-shifted. Place-shifted. Searchable. Archivable. Retrievable. - JP Rangaswami

Amen.

See also Blog50: Traction Roots - Doug Engelbart
Blog384: Enterprise 2.0 - Letting hypertext out of its box
Public390: 20 June 2005 | Supernova | Why Can't a Business Work More Like the Web?
Public1153: Blogs and Wikis: Building Customer Connections