≡ Menu
Pawel Brodzinski on Software Project Management

Recipes Are (Almost) Useless

Recipes Are (Almost) Useless post image

One of the least useful pieces of advice you may ever get on management would go along the lines: “we’ve done such and such and it worked freaking miracles for us, thus you should do the same.” In fact, all the ‘shoulds’ and ‘musts’ are sort of a warning signal for me, whenever I learn about someone doing something right.

This is by the way something that is surprisingly prevalent in many management books. A story of someone wildly successful who shares how they believe they achieved it. While I do appreciate a story and all the insider’s insight that help to understand a little bit more it is only a story.

Was it backed up by credible research? Was it successfully adapted in a number of other organizations? What might be critical assumptions that we base on and how would the story be different in another context?

It’s not that I would call each of these stories bullshit. Pretty much the opposite. I often find that many of the ideas shared are aligned with my experience. The issue is that on occasions I can track down some of the underlying prerequisites that aren’t even mentioned in the source. Does it mean lack of good will? I don’t think so. I’d rather go with fairly shallow knowledge.

Unfortunately this has a lot to do with what we, as consumers of books, articles or conference presentations, expect. It is oh so common when the basic expectation is to get a recipe. Tell me how to build my startup. Tell me how to fix my effectiveness problem. Tell me how to grow an awesome team. Tell me how to change my organizational culture. Tell me how to scale up a method we are using.

Yes, recipes sell well. They are sometimes dubbed “actionable content” as an opposition to theories that are non-actionable. That is unless someone undertakes effort to understand them and adjust to their own context.

Over years I’ve been enthusiastic about some methods and practices I discovered. I’ve been skeptical about many more. I’ve changed my mind about quite a bunch of them too. An interesting realization is that the further from a plain recipe a method is the more I tend to consider it useful in the long run. I guess one of the reasons for me to stick with Kanban for all these years is that I quickly realized how adaptive the method is and how much liberty I could take using it.

This is also a reason why I never become a fanboy of Scrum. While obviously there’s much value in specific practices it offers in specific contexts I got discouraged by early “do it by the book or you aren’t doing Scrum” attitude promoted by the community.

I digress though. The point I want to make is pretty simple.

Recipes are useless.

OK, OK. Almost useless.

It doesn’t really matter whether we discuss a project management techniques, software development practices or general management methods.

It’s not without a reason that pretty much any approach, once it becomes popular, ends up being not nearly as useful as it was reported in early success stories. There are just too many possible contexts to have any universally sound solution.

What’s more, during its early days, a method is typically handled by people who invest much time to understanding how and why it works. After all, there are no success stories yet, or very few of them, so a sane person handles such a thing cautiously. Then, eventually it goes downhill. Some would treat a method as universal cure for all the pains of any organization, others would sense a good certification business opportunity and suddenly any understanding of ‘whys’ and ‘hows’ is gone.

One thing is what I believe in and how I approach the tools I adopt to my toolbox. Another one is that I frequently get asked about an advice. I guess this is inevitable when you do at least a bit of coaching and training. Anyway, in every such situation the challenge is to dodge a bullet and avoid giving a recipe as an answer. This by the way means that if I am answering your question with ‘shoulds’ and ‘musts’ you should kick me in the butt and ignore the answer altogether.

A much better answer would be sharing a handful of alternatives along with all the assumptions I know that made them work in the first place. Additional points are for supporting that with relevant research or models.

In either case the goal should be the ultimate understanding why this or that thing would work in a specific context.

Without that a success story is just that – a story.

Don’t get me wrong. I like stories. We are storytellers after all. It’s just that a story itself bears only that much value.

The next time you hear a story, treat it for what it is. The next time someone offers you a recipe, treat it for what it is.

in: software business

3 comments… add one

  • szescstopni June 10, 2014, 3:59 pm

    In the mid 80’s “New Scientist” had an engineer’s recipe for salmon with vegetables (Google doesn’t link to the hard copies in my basement). It didn’t matter if you had an oven, a grill, or a Bunsen burner and a frying pan. End even if you forgot to buy the salmon you’d still get great vegetables.

  • Paul Klipp June 10, 2014, 9:24 pm

    I used to be a professional chef. I rarely follow a recipe. If I want to make something I’ve never made before, I read a dozen different recipes for that dish, consider what they have in common and where they differ, and use my experience, intuition, and personal tastes to create the dish my way and if I like it, I experiment with variations based on the first experience.

    Process recipes and their associated success stories can be used in the same way.

  • Pawel Brodzinski June 11, 2014, 5:11 am

    @Paul, That’s the point I was trying to make and you did it in just few sentences. I guess I’m not strong on brevity.

    I don’t say we should forget the recipes and stories. Let’s just take for what they are.

Leave a Comment