Chefs, Not Recipes: The Tyranny of Tools and Best Practices

Cooking

One of my favorite sayings is, “Chefs, not recipes.” It’s a phrase that I stole from Dave Snowden, and it perfectly encapsulates the approach I think we need to take (and aren’t) in the collaboration, networks, and organizational development space. I believe in this so strongly that I had it engraved on the back of my phone.

What exactly does this mean, and why do I find it so important?

One of the reasons I got into this field was that, over a dozen years ago, I experienced exceptional collaboration in open source software development communities, and I wondered whether similar things were happening in other places. If they were, I wanted to learn about them. If they weren’t, I wanted to share what I knew. I thought that developing shared language around common patterns could help groups achieve high-performance.

I still believe that a good pattern language would be useful, and there’s been some interesting movement in this direction — particularly Group Works and Liberating Structures. (Hat tip to Nancy White for pushing me to explore the latter.) However, I think that there’s a much bigger problem that needs to be addressed before a pattern language can become truly useful.

Collaborating effectively is craft, not science. There are common patterns underlying any successful collaboration, but there is no one way to do it well. It is too context-dependent, and there are too many variables. Even if best practices might be applicable in other contexts, most of us do not have the literacy to implement or adapt them effectively. We think we lack knowledge or tools, but what we actually lack is practice.

I’m a pretty good cook, but I still remember what it was like to be bad at it. I first tried my hand at cooking in college, and I was so intimidated, even simple recipes like “boil pasta, add jarred sauce” flummoxed me. I was so incompetent, a friend mailed me a box of Rice-A-Roni all the way from the other side of the country because she was afraid I would starve.

Back then, I followed recipes to the letter. I had no way of evaluating whether a recipe was good or bad, and if it turned out badly, I didn’t know how to make adjustments. I ended up defaulting to the same few dishes over and over again, which meant that I got better quickly, but I also plateaued quickly.

A few things got me over the hump. I had lots of friends who cooked well. I relied on them for guidance, and I especially enjoyed cooking with them, which allowed me to see them in action and also get feedback. But the turning point for me was challenging two of my less experienced friends to an omelette competition. (I suppose that speaks to another thing that helped, which was that I was brash even in the face of my incompetence.)

I cooked omelettes the way my parents cooked them and the way I assumed everyone else cooked them. But both of my friends cooked them differently, and I liked all three versions. The differences in approaches were more subtle than what was usually captured in a recipe, but the differences in results were clear.

That experience made me curious about my assumptions. Most importantly, it got me asking “why.” Why do things a certain way? What would happen if I did it differently? I also stopped using recipes, choosing instead to watch lots of cooking shows, cook with others (including people who worked in kitchens or were professionally trained), and experiment on my own. Recipes were a helpful starting point, but they were not helpful beyond that. While better knives and pans improved my ability to execute, they did not make me a better cook.

Recipes and tools have their place, but they are relatively meaningless without the literacy to wield and interpret them. Practice, experimentation, mentorship, constantly asking “why” — these are the keys to mastering any craft. This was my experience learning how to cook, and it’s also been my experience learning how to design and facilitate collaborative engagements.

What does approaching collaborative work as a chef as opposed to a set of recipes look like? It starts with asking “why” about everything. For example, if you’re designing and facilitating a face-to-face meeting:

  • What are your goals, and why?
  • How are you framing them to participants, and why?
  • How are you arranging your space, and why?
  • When are you breaking up your group, and why (or why not)?
  • What kind of markers are you using, and why?
  • Why are you having a face-to-face meeting at all?

I meet a remarkable number of practitioners — even ones with lots of experience — who can’t answer these questions. They’re simply following recipes.

Even if you have answers to all of these questions, don’t assume that your answers are the best ones. Experiment and explore constantly. Shadow other practitioners, especially those who approach their work differently. Intentionally do the opposite of what you might normally do as a way of testing your assumptions.

Finally, if you are a more experienced practitioner, remember that in professional kitchens, chefs have a supporting cast — sous chefs, line cooks, prep cooks, and so forth. If you yourself are not regularly working with a team, you’re not optimizing your impact. Most importantly, find a way to mentor others. Not only is it a gratifying experience, you’ll find that the learning goes both ways.

Photo by yassan-yukky. CC BY-NC.

Actually, Documenting Is Learning!

Boardthing Screenshot: Learning Via Artifacts

Last week, I published the second of my three-part series of “gentle rants” on facilitating learning in groups. The title was, “Documenting Is Not Learning.”

That piece was widely shared on various social media channels, and it also stirred up some controversy. A few of my close colleagues raised their eyebrows when they saw my title. One of those colleagues was Dave Gray.

On my personal blog, I described how I know Dave, why I respect him so much, and what I’ve learned from him over the years. His credentials — founder of XPLANE, author of Gamestorming and The Connected Company, creator of Boardthing — are impressive, but they don’t do him justice. Dave is a great thinker, practitioner, learner, and teacher. He has a deep understanding of collaboration and innovation, and he is a brilliant visual thinker. These are what his notes look like:

Dave Gray: What Ignites Creative Energy?

He might claim that this is a polished version, but I have seen his “rough” notes, and they look essentially the same.

Dave read my post, and he understood and agreed with my overall message. But he rightfully had a beef with my title, and he called me out on it. I felt like I needed to write a followup post to clarify what I meant, but I thought it would be much more fun to have a conversation with Dave on this and related topics, and to let the content of that conversation essentially become the post.

Yesterday, we spent about an hour talking on a public Google Hangout. (The video of our conversation is below.) To my delight, we had about six people listening in (including my wonderful and wise colleagues Nancy White, Seb Paquet, Beth Kanter, and Natalie Dejarlais), and we all took collective notes using Boardthing. I want to highlight a few points here.

Documenting Is Learning!

In my quest to make my title punchy and provocative, it lost importance nuance. The process of documenting is absolutely a great way to learn for the person doing the documenting. I tried to make that point in my post:

Externalizing our knowledge can be a valuable way for individuals to reflect and internalize, but it’s only valuable for peers and colleagues if they take the time to absorb it.

It’s even more powerful when the act of documenting becomes a collective process, which is what was happening during our conversation on Boardthing.

My rant was essentially about people’s assumptions about why or how artifacts that result from documentation can be valuable for learning. In my conversation with Dave, I shared the three dimensions in which I think about artifacts:

  • Transcriptive. A detailed, chronological capture of a discussion or thought process. The video below is an example of a transcriptive artifact.
  • Interpretive. A synthesis of a discussion or thought process. This blog post is more interpretive than transcriptive, but it’s still somewhat transcriptive. The same goes for the resulting Boardthing from our conversation. (That also gets special status, because it was collectively as opposed to individually created.) Dave’s image, on the other hand, is highly interpretive and not very transcriptive.
  • Evocative. Something emotional that triggers a memory. I told a story about how my photographs from various projects often serve a more useful role in triggering learning than my writing, because they elicit an emotional response. I probably pay more attention to Dave’s idea stream than to other colleague’s because his notes are so evocative.

Focusing too much on the transcriptive and interpretive dimensions of documentation prevents you from designing effective learning processes.

(As an aside, understanding and experimenting with the role that artifacts play in high-performance collaboration is a foundational question for me. I’ll write more about it in future posts.)

Getting Real

Dave and I talked a lot about the nature of learning and knowledge. The truth is that learning is wonderfully messy and contextual, and it’s often done best with others. Attempting to abstract learning into a series of information transactions is not only wrong, it’s harmful.

Dave described how Visual Thinking School (one of the inspirations for Changemaker Bootcamp) came about at his previous company, XPLANE. As an experiment in encouraging more cross-organizational and enjoyable learning, they had decided to designate two-hours a week for people to learn from each other. They wanted to make it optional, but they also wanted to demonstrate a real, organizational commitment to the experiment.

They decided to schedule it on Thursdays from 4pm to 6pm, which meant half of it was during work hours, but the other half was on people’s personal time. They also told managers not to schedule meetings during this time, so that people’s calendars would be clear to attend if they so choose.

Listening to Dave describe the thinking behind Visual Thinking School felt like a case study in how to design effective learning processes. It wasn’t about trying to get people to write down what was in their heads. It was all about creating a delightful space in which learning could happen, facilitating stronger relationships within the company, and focusing on the true nature of craft.

We ended our conversation the way we started — exploring the realities of how we learn. I told Dave about how my parents would always say to me when I was growing up, “We don’t want you to make the mistakes that we did.” Later in my adult life, I decided that I disagreed with this. Sometimes, you absolutely do want people to make the same mistakes, because that can be the best way to learn. You just want to minimize the negative effects of making them.

In response, Dave shared a story about the four kinds of horses that he used to tell to his students who were failing his class:

  • The first kind learns to run effortlessly.
  • The second kind learns when it sees the shadow of the whip.
  • The third kind learns when it first feels the sting of the whip.
  • The fourth kind only learns when the sting of the whip sinks into the very marrow of its bones.

Everyone envies the first kind of horse, but only the fourth kind truly understands what it means to run in the very marrow of its bones. There is something deep and wonderful about that kind of learning, painful though it may be.

Many thanks to Dave for provoking this wonderful conversation and to all of my friends and colleagues who engaged with us on our call and on social media!