Think Like a Chef — Not a Cook

We all know people who become enamored of their favorite new way of looking at the world – whether its a low-carb diet, Libertarianism, or scrum – and suddenly they look at their new obsession as the solution for all problems.

This is what blogger Tim Urban calls, “thinking like a cook, not a chef,” in his enlightening piece The Cook and the Chef: Musk’s Secret Sauce.

Cooks choose a recipe and try to apply it faithfully making sure all ingredients are in place and in the right proportions. While this can create powerful, or delicious, outcomes it’s an approach that is brittle and difficult to adapt when faced with real-world volatility.

In the volatile, uncertain, complex, and ambiguous (VUCA) real world it’s far better to be the one creating the recipe, than the one cooking by rote.  This is what Urban calls a chef and, he asserts, what makes Elon Musk so effective.

This chef like posture means thinking from something called first principles. It’s an essential stance for anyone who wants to improve their organization.

First principles are the elements from which recipes are created. Instead of learning to create a recipe for an apple pie we learn that crunch, sweet, and fat go nicely together. With that foundation, we  seek to apply the learned insight in a variety of contexts. Shows like The Iron Chef are testing a person’s ability to abandon recipes altogether and think like a chef not a cook.

In my work, I find frameworks, tools and processes valuable but incomplete.

Where I deliver the most value is when I'm able to refocus attention on what's most important and clear next steps. Humans are a distractible species – myself included – so asking, “What's the real issue here?” is often invaluable (it’s also a great way to appear smart in a meeting – even if you aren’t).

There is great value in studying and learning the basics – a jazz musician will play scales so it is  possible to improvise later, and Salvador Dali was skilled in a variety of traditional painting styles. You need to know the rules you need in order to have insight into the reasons those rules work.

To break rules you need to know them in the first place and often the only way to learn them is to live them.

The trick is to remain in inquiry and experimentation rather than blindly applying Kotter's 8 Steps, training legions of Certified Scrum Masters, or hiring a bunch of 6 Sigma Black Belts. While these roles and skills may be useful, imposing a system on unwilling or unenthusiastic people will kill motivation and lead you away from the speed and quality improvements you are after.

As you try on new systems and frameworks I encourage you to be deliberately experimental. Try them for a defined period and then reflect how they are serving you and your team. But do this in the smallest, cheapest, and least disruptive chunks possible. And do your best to understand the first principles that sit behind these systems. For example instead of applying story points blindly start by making sure the people who are going to do the work are the ones estimating it and let them choose how they’ll estimate.

Your goal should be to see beyond any and all branded processes to the simple and elegant truths from which they draw their power. Your goal is to co-create with your team your own, unique, and ever-evolving way of working.

The question you want to ask is, what are the foundational assumptions and principles that govern making good stuff, while using resources in the most efficient and effective way possible?

Rather than teach to you to be a Scrum/Agile/Lean/Holocracy cook I want to give you the tools/guidance/framework etc -  to become a chef of organizations. You will be able to improvise new tools and processes or select the right one from your existing tool box.

An example of a first principle for moving faster is to focus on a few work items at a time, what lean practitioners call Limiting Work in Process (WIP). If we approach this like a religious commandment – applying it blindly in hopes we’ll get into heaven sometime in the future – we’ll miss the elegant power of this idea.

Instead we need to refocus our attention on the core principle of focusing on a few items at a time. It may be more useful to develop a protocol for communicating to stakeholders outside the team what items are being worked on and what’s next in the queue than creating an internal WIP limit.

In a future post I’ll break this idea down and help you understand some of the mathematical, social, and behavioral foundations that make it work.

 
Bob Gower