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.

Organizational Development as Product Design

Startup Habits Workshop at Code for America

I got my start in the tech industry. Even though that was a lifetime ago, I’ve carried over many lessons from that experience, and I like to keep one foot in that door. One lens I still carry with me is that of product design.

I’m currently embarking on an experiment with Dharmishta Rood, who runs the incubator at Code for America. The gist of the experiment is this: Changing organizational habits is hard. Starting new habits is easy. If you want to build a high-performance, collaborative organization, the best thing you can do is instill good habits right from the start. Incubators are in a great position to do just that.

Code for America is trying to help local government truly live up to its promise of for the people, by the people. Its central activity is a fellowship program that connects designers and developers with local governments for a year. Think Teach for America for geeks. On the surface, these fellows design innovative applications for local government. On a deeper level, these fellows help change the culture of local government. It’s an amazing organization, and I’ve been a proud supporter for many years now.

Sometimes, fellows want to continue working on their apps beyond the fellowship. Last year, Code for America started an incubator program to help their fellows do just that. One of the many things that Dharmishta does is find mentors and trainings to improve her startups’ chances at success. One of the services she wanted to provide for her current class — a great new startup called PostCode — was help with getting better at collaboration.

I’m looking for ways to scale collaborative literacy. Helping an incubator instill great collaborative habits with civic startups seemed like a wonderful opportunity to do exactly that. The twist was that I didn’t want to do the work. I know how to do that already, and I know that I’m not scalable. Instead, I wanted to see if I could create a toolkit that Dharmishta could implement on her own with some behind-the-scenes coaching on my part. Dharmishta and PostCode both graciously agreed to try this experiment with me.

This is essentially a product design challenge, and it’s been incredibly humbling. We whipped together a prototype in just a few weeks, but I based it on years of experience, and I thought it would be great. It’s been solid so far, but not great. Watching Dharmishta and PostCode work through the toolkit behind-the-scenes has been an exercise in frustration — not with them, but with my own work. It’s uncovered all sorts of flaws and faulty assumptions, and because I’m not the one implementing it, I can’t make adjustments on the fly, which I do regularly in my own practice. It’s providing value, but it’s not living up to my expectations.

Which is exactly the point. Unless you’re incredibly lucky, you’re not going to get it right on the first try. Good product design is about getting your best first guess out there as quickly as possible and learning as quickly as possible based on real world usage. You take your lumps early so that you have a better chance of getting to the right answer quickly (and cheaply).

I wrote in an earlier post:

In order to design an effective tool, [product designers] use powerful methods for understanding how their customers think and feel and for measuring the impact of their interventions. Most process designers would do well to learn the tools of product design.

Most process designers I know have a very limited toolkit. They are typically over-dependent on meetings to accomplish their goals. (The exception to this are folks I know in tech startups, who tend to have more of a — you guessed it — product mindset when developing their own organizations.)

The bigger problem is that most process designers do not spend enough time up-front thinking about how to measure success. This ends up being fine, because most don’t bother to assess their work afterward anyway, outside of a casual, gut-feel conversation with a very narrow set of people.

I can say all of these things without judgement, because I have been guilty of all of these things. Doing these things well requires a tremendous amount of discipline, practice, and boldness. Frankly, I don’t know many product designers who do all these things well either. But on average, I find that product designers have a very different mindset than process designers.

What exactly is this mindset? That you don’t know all the answers. That underneath your considerable experience lies a foundation of faulty assumptions. That the way to learn is to move forward constantly, but thoughtfully, to iterate rapidly, to assess obsessively, and to assume that you will fail many times before you succeed.

This is the approach that I’ve been taking with the “product” that Code for America and PostCode has been using. They are both tremendously busy, but they have been great about playing with the toolkit. PostCode is a company full of product designers, and that mindset is strongly engrained in Code for America’s culture as well. (Code for America is an ardent evangelist and practitioner of the Lean approach, whose chief evangelist, Eric Ries, serves on its board.) They understand the spirit of what I’m trying to do, which has helped me a lot in doing this experiment.

This shared understanding has also helped me explain some principles of organizational development with them. PostCode is grappling with the typical startup challenges — lots of opportunities, but also lots of uncertainty, the need to focus in light of this uncertainty, and the challenges of norming as a team in the midst of the thousands of other things they need to be doing. They need to go fast, but they also recognize the importance of slowing down.

We were discussing the challenges of deciding on decision-making processes, and I latched onto something very wise that one of them said: Sometimes, things will actually work themselves out if you just let them play out. You want to be thoughtful and reflective, but you can’t let that paralyze you. The value of actually trying something, then stopping to reflect, is that now you’re basing your decisions on real data rather than on a bunch of competing, subjective, abstract notions. That’s a product designer’s mindset, and organizational development practitioners would do well to adopt it.

The trick is finding the balance between doing the work and taking a step back, doing the work and taking a step back. That’s what I’m trying to help them do. It’s an incredibly hard balance to learn how to strike. Clients have been hiring me to help them with this for years, yet I found it extremely difficult to do myself when starting up my own company a few years ago. I continue to improve, but I’m still in that cycle of trying and learning.