Why you should always cook by the recipe

Most of the time, when I cook I improvise. I have a general idea what I want to eat, but mostly I decide spontaneously what ingredients I throw into the pan. A bit of roasted dates here and a hint of vanilla there. Wonderful. I see recipes as a source of inspiration, rather than an exact guide to follow.

Usually my food is eatable.

Write standardized guidebooks for all parts of your business

In business however, I do follow recipes. I do want to replicate what worked for me or others in the past. It saves my time and money.

You found a way to increase your conversion rate on your landing page? Great, tell me exactly how!
You developed a framework that helped your teams to communicate better? Please, show me!
You managed to convince an upset customer to stay with you? How did you do it?

You see where I am going. There is so much knowledge surrounding you on a daily basis that you are not tapping in, simply because you don’t ask for it. So, if you don’t already have one, it is time to write your own cookbook.

It helps you to replicate your results, leverage the learnings of others and helps you to avoid the mistakes your peers did before.

But you shouldn’t stop there. Every business should have a general cookbook lying around. Every time someone discovers a new smart way of solving an existing problem, take a pen and write it down.

I personally spend a great deal of my time to develop and improve workflows. I am making things faster, cheaper or more reliable. Whenever I found something that works, I write it down and create a new recipe. Now, when I want others to do the same I simply hand them the recipe and watch them succeed (or even better, improve my recipe).

You will be surprised how much time this will save you in on boarding and training processes. Treat your cookbook as a living document and encourage your team members to actively contribute.

So how does such a process cookbook look like?

There are two different types of cookbooks:

  1. The final one, that should not be altered but only executed. Those should be saved as a PDF in some kind of knowledge center.
  2. The living one, that gets extended and altered as needed. For this kind,  I normally use a collaboration tool such as Google Docs. Like this, everyone involved in the project can contribute to the workflow.

Let’s have a closer look at a living playbook I created for a B2B sales company, I advised some time ago. I recommend to create individual cookbooks for different departments or workflows. Like this, you can keep the books small and modular. This is important in order to assign ownership to a single persons that makes sure the handbook stays up to date.

There is nothing more annoying than out of date handbooks. Keeping a playbook updated is just as important as writing it in the first place.

 

Playbook and guidelines for standardized processes
Advise: Use tools like Google Docs to create documents that can be edited by all members of the team.

 

Prior to creating the document itself, you might want to inspect the current workflow and improve as needed.

Just like a real recipe, the cookbook should be easy to follow, aim to define/solve/improve a certain workflow and include all information necessary to replicate results. In fact, a guidebook is only then good enough when you can give it to a new member and he is able start working without any further instruction.

The key is to be as specific as possible in regards to:

  • expected output (e.g. “The bounce rate of any mail campaign send must be under 3%”)
  • step-by-step instructions (e.g. “Remove local and global duplicates and filter for unwanted or invalid top level domains”)
  • established naming conventions
  • link to related documents and tools
Example of a process recipe
A simple example of a process recipe

 

Before putting the workflow into production run it by your team and make sure everybody understands all steps described.

One of the reasons I started creating cookbooks was that I had to explain the same things over and over again. The other one was the annoying hand-over process whenever someone leaves the team. Most of the the parting worker had own workflows in place that allowed him to fulfill his work. Having these small, continuously improving handbooks in place solve both problems. It literally saved me dozens of hours in training and hand-over.

Now, I can use my time for other things and rest asure that all new learning or changes to workflows get documented. No know-how gets lost (in fact, it promotes knowledge sharing within your team), knowledge bottlenecks are avoided and fast on boarding and training processes can be created (which, again are defined in a separate recipe).