Looking for a proven way to transfer knowledge? Write a “cookbook.”

mastering_french_cooking

Julia Child and Knowledge Management

I like to begin conversations about knowledge management by talking about Julia Child. Julia’s travels through France, her education at Le Courdon Blue cooking school, and time teaching at an informal cooking school for American women in Paris – her experiences acquired over time – all became part of her personal knowledge base.

Julia’s informal cooking school was in fact, a collaborative effort with two other women, Simone Beck and Louisette Bertholle. Simone and Luouisette had already been working on a French cookbook for Americans and invited Julia to join them in order to make the book appeal to Americans. According to our good friend Wikipedia, “over the next decade, the three researched and repeatedly tested recipes. Child translated the French in English, making the recipes detailed, interesting, and practical.”

Julia Child was able to transfer her tacit knowledge (experience she had acquired over time) of French cooking into explicit knowledge (knowledge that can be reduced to a set of instructions)  through writing cookbooks. Millions of American women (and men) have read Julia Child cookbooks and learned from her experiences in France in the 50s.  

The Swiss Chef and his Cookbooks

My first manager after graduating from college was a Swiss technologist named Hannes Rosskopf.  Hannes possessed the traits you would stereotypically associate with the Swiss. He was precise, detail-oriented, and demanding.  I appreciated Hannes’s rigor because I knew that he was helping to mold me into a stronger consultant.  (Well, I almost always appreciated it.)

However, I believe what made the most lasting impact on me was Hannes’s approach to teamwork and personal development.  The first e-mail I ever got from Hannes went something like this:

 

Chris,

Glad to have you as part of the team. You will be helping me to write cookbooks.

Hannes

 

It turned out Hannes had also recently joined the company. He had been tasked with developing a standard methodology for our practice group. It was the dot-com bubble and our company was growing.  Our previous team leader no longer had time to provide technical leadership to the group because he had moved into a marketing and sales role. Charged with arming a hungry but inexperienced group of recent college graduates with technical knowledge  – Hannes borrowed a page from Julia Child. He decided to start writing cookbooks.

Hannes’s objectives differed from Julia Child’s in one major aspect. Julia Child aimed to transfer her knowledge to a sea of home cooks, most of whom she would never meet. Hannes’s predicament was more analogous to an executive chef starting a restaurant. His aim was to transfer his experience to a team of sous, prep, and line cooks so that he could further leverage himself over multiple projects.  Julia Child aimed to help her audience build their personal knowledge.  Hannes’s goal was to help build organizational knowledge. 

And so, I found myself busily writing procedural documents for building new e-mail servers, checklists for installing backup and recovery systems, and documenting rollouts of new software applications. Hannes curated, edited, and published this massive  collection of Microsoft Word documents to the team. He called this collection of explicit knowledge his “cookbooks.”

Often times, Hannes would lay down the outline of a new cookbook and seed it with his own knowledge. However, Hannes was most interested in enlisting us to improve the cookbooks because he knew that the process of writing cookbooks would help us to learn our subject matter better than simply following his procedures. Knowledge management in our team meant the following:

Figure out a new way to shave 3 steps off of a checklist that he wrote? Update the cookbook. Learn the hard way that the way we had been installing a certain piece of software was introducing conflicts with another piece of software? Update the cookbook. Need to learn how to perform a process that you’ve never done before? Read the cookbook. The cookbook doesn’t  exist? Write a cookbook. Then tell the team about it.

Hannes was relentless and systematic in his approach to creating, capturing, and sharing knowledge. In doing so, he not only built a library of explicit knowledge (cookbooks) with clear monetary value, he also leveraged his experience to grow a  team of consultants with a shared methodology for doing quality work.     

Crafting the Knowledge Architecture Menu

I continue to be surprised at how many “cookbooks” it takes to run a consulting practice. Knowledge Architecture will be one year-old next month. One of the things I have repeatedly told people over the last year is that I have felt like we were constantly doing things for the first time. 

Proposals. Contracts. Invoicing. Bookkeeping. Filing incorporation papers.  Checklists for welcoming new customers. Checklists for hiring new employees. Templates for developing information system roadmaps. Templates for developing intranet roadmaps. Planning guides for employee databases. Planning guides for project databases.  Procedures for performing integrations. Procedures for installing SharePoint. The list goes on and on.

Each of these cookbooks not only required an initial version, but now require constant revision as we acquire new knowledge through our daily work. However, I can sense that we are turning the tide on the volume of initial knowledge capture as we enter our sophomore year. While there is theoretically an infinite amount of knowledge to capture in cookbooks, not all knowledge is created equal.

We are focused on writing cookbooks which help us to do at least one of the following three things: perform quality work, increase profitability, and/or enable us to leverage each other and grow as a team.

Bon Appétit

If you are an architect who specializes in residential design, you probably carry around a library of unit plans which you have built over time. If you are a job captain, you probably have a checklist (at least a mental one) for transferring BIM models between members of the design team. As an HR professional, you probably have a set of  guidelines for your technical staff which you tell them before they interview new staff.

You are all cooks. You have acquired a large body of tacit knowledge over time through your work experiences.

There are more tools than ever before to help you create, capture, and share knowledge. Intranets, blogs, wikis, podcasts, and cheap video cameras to name a few.

Harness your knowledge. Write your cookbook.  Share it with your team.

You’ll never cook alone again.

Posted: February 21st, 2010 | Filed under: General, Most Popular | 3 Comments »

3 Comments on “Looking for a proven way to transfer knowledge? Write a “cookbook.””

  1. 1 Knowledge Architecture Blog » Blog Archive » “Game films” - Our latest knowledge management tool said at 3:11 pm on March 7th, 2010:

    […] Interviewing. Cookbooks. Host a […]

  2. 2 Tim Parker said at 4:51 pm on February 3rd, 2011:

    Chris; great story. And as someone who worked in Switzerland for three years, Hannes was doing one of several things the Swiss do well.

    A question though. In the consulting I did at that time — management consulting, part strategy, part operations — cookbooks never really seemed to work. Every job was very different, and if you approached one with the idea you already had the recipe, you’d likely miss the point and lose the job. So our analogy was the toolbox. Really powerful templates, frameworks and so on would be sort of thrown into the general library (there was one) or more likely passed around trusted colleagues. But there was no enthusiasm — I think rightly — for a cookbook.

    This may be just semantics. Or it maybe that the less repeatable and predictable the work, the less the cookbook represents processes, and the more it must consist of point solutions that can be combined and adapted to suit the need.

  3. 3 Christopher Parsons said at 6:56 pm on May 24th, 2011:

    Tim,

    First, I apologize for missing this comment.

    Second, I totally agree with your point. In fact, I was discussing it less than an hour ago with one of the researchers from Gensler. We were discussing the best way to generalize methods and tools in a design firm, where the clients and designers are very different. Can you distill methods and tools down to a shared platform for practice while providing good situational and individual flexibility? We think yes.

    You?

    Chris