“You can't replicate the end point of an evolutionary process, which by its success has changed the context anyway. However we can seek to copy the starting conditions and enable the emergence of new contextually unique successes that learn from it.”
- Dave Snowden
“… the fact is, if you don't know what makes things work, you won't be able to improvise”
~ Heston Blumenthal
Recipes, scripts and musical scores are all examples of patterns, emergent outcomes of someone else’s evolutionary journey. Their form depends on largely on their context, the conditions that were present when they emerged. For example the available ingredients, equipment and technology eg heat sources as well as the chef’s style, the prevailing culture and food trends at the time would all influence a restaurant’s signature dish.
Replicating a chef’s recipe requires a similar context i.e. the exact ingredients, equipment etc as stated in the recipe. Anyone who watches a Masterchef pressure test knows the importance of precisely following a recipe, and even then results aren’t guaranteed. The fact is that recipes are fallible and finicky - consider mayonnaise: theoretically it should be possible to make the perfect mayonnaise every time if you follow the recipe precisely. But many factors influence the result e.g. the quality of the ingredients (free range organic eggs taste very different to those laid by battery eggs) - however even with the exact ingredients, the weather may be your undoing. Something I learned about only recently is that you mayonnaise doesn’t ‘bind’ during a stormy conditions.
Now I have to state up-front that I don’t think recipes are inherently bad; beginners need to copy recipes as they learn to cook, and even the best chefs know when to use a recipe (e.g. if there’s a best practice for making Choux pastry, why re-invent the wheel), but they aren’t constrained be it and when the context shifts they are able to improvise. Recipes are “scaffolds” that scaffolding move people progressively toward stronger understanding and, ultimately, greater independence and autonomy (for more on learning scaffolds have a look at Bruner and Vygotsky’s work (https://en.wikipedia.org/wiki/Instructional_scaffolding).
All of this means that without contextual intelligence and an understanding of the principles behind the recipe, a recipe is often not ‘a recipe for success’. And as true as this is in the kitchen, it’s even more pronounced in the business world (or any social system for that matter).
Just like in the kitchen, the contextual aspect like leadership style, culture (organisational and societal), resource availability etc all influence the practices and structures that emerge in organisations. And while one can create a controlled environment to perfectly replicate a chef’s kitchen, you cannot do the same with an organisation. Indiscriminately copying practices and structures from other contexts very seldom works (unless by accident), yet it seems to be as hard to resist as the siren’s songs were in seafarer myths.
This seemingly thoughtless recipe copying happens everywhere: in strategy, change, culture etc, but a particularly salient example currently is the Agile industry.
The majority of organisations I’ve worked with (or heard about) who has gone through an Agile implementation (or Agile transformation) has a similar storyline (it’s mostly just the sequence of events that differ).
1. Agile is sold as the new silver bullet.
2. Everyone (predominantly in IT at first) must become Agile - and to do so they get sent on an Agile bootcamp, swiftly followed by some sort of certification. (In most companies the first iteration is Scrum.)
3. Things go well for a while (the Hawthorne effect states that anything novel will make a difference at first) and then cracks start appearing.
4. So it's on to the next recipe, typically this is either SaFe (which seems safe (pun intended) and familiar as it looks a lot like Waterfall) and “everyone’s doing it” or Kanban. Again, lots of money is spent and it seems to work for a while ... until it’s not
5. Maybe a hybrid will work ... Scrumban seems to be a new thing (but be careful of anti-patterns) and finally ...
6. When all else fails, we copy what made X successful (currently in the Agile community, Spotify's success story is the one everyone seeks to copy)
Sometimes, in the end they abandon Agile and revert back to Waterfall.
All of this in the hope of a fix (preferably a quick one) that doesn’t require the hard (and risky) work of experimenting, muddling through and emerging our own practices.
Let’s consider this latest "recipe for success": the Spotify model of scaling agile (interestingly enough, while happy to share their practices, Spotify themselves discourage people from mindlessly copying them. The authors of this paper also rightly mention that this is a point-in-time snapshot of an ever-evolving context). The Spotify model mostly centres around an organisational structure with associated processes and practices. The structure is communicated using metaphoric language … they organise around Missions, Tribes and Squads, with chapters and guilds functioning across the tribal boundaries (see image below).
When Cultures Collide, Richard D. Lewis
Now consider the context where this model emerged i.e. a dynamic, tech start-up who prides themselves on disruption based in Sweden. The Swedish culture is interesting. Different cultures often have very different leadership styles, as charted by British linguist Richard D. Lewis in his book "When Cultures Collide," first published in 1996 and now in its third edition. He defines the Swedish leadership culture as primus inter pares - a first among equals.
“Swedish leadership is vague and imprecise [...] the typical Swedish order is ‘See what you can do about it!’ What does it mean? It obviously has to do with a far-reaching delegation of authority. Managers who say ‘See what you can do about it!’ demonstrate trust for their co-workers. It is also a matter of the execution of control by a common understanding of the problem, rather than direct orders. This must be regarded as a strength with the egalitarian Swedish society”. (Edström & Jönsson, 1998).
I’ve only visited Sweden once, so I certainly am not an authority on Swedish culture. But from what I observed and the stories people told, it seems that there is an inherent value for autonomy, and a natural tendency to self-organise in the Swedish culture. In fact, imposing Agile methods (which to South African companies seem way to “loose”) may be resisted in Sweden as they bring too much control. It is in this context, that the structures and metaphors of the “Spotify model” emerged and evolved. Having recently visited Spotify and seen their culture first hand, I believe it is that culture (along with the unique Swedish culture) that has made this model successful, in my opinion largely despite itself.
When Cultures Collide, Richard D. Lewis
In a country like South Africa, whose leadership culture is probably closer to the US model (after years of copying US manufacturing best practices taught on MBA processes) and a tribalist societal culture, simply copying these approaches can be problematic. The metaphors alone, if used as-is can have serious unintended consequences. Consider more broadly the notions of Tribes and Squads - are they typically closed or open structures? Let’s only look at Tribes:
According the dictionary, a tribe is a social division in a traditional society consisting of families or communities linked by social, economic, religious, or blood ties, with a common culture and dialect, typically having a recognised leader.
So, in the real world …
• What do tribes typically do when they encounter each other in the real world? Do they collaborate or do they compete and fight?
• How does one become part of a tribe (besides being born into it)? Is it simple and painless, or does it involve some sort of ritual either marriage or a potentially painful initiation.
Fact is, tribes, like squads are exclusive, not inclusive by nature. So it’s no surprise that problems like internal competition; failure to collaborate and difficulty with induction soon manifest when this model is implemented as a recipe - the metaphors work against what most organisations are attempting to achieve when they decide to “go Agile”.
While the guilds and chapters were designed to keep the tribes from becoming insular, if these boundary spanning communities don't emerge naturally, strong incentives are needed to encourage participation. More often than not the tribe and squad boundaries will probably dominate as incentives such as performance targets are lined to production, not participating in these communities. Organisations therefore seeking to scale Agile by adopting this framework as a recipe will probably end up with unintended consequences and the opposite of what they wanted.
So what is the alternative (and this does not only apply to Agile, but to may others like strategy, culture, customer experience and most OD/HR practices):
1. Start where you are. What is possible from here? What is the cultural disposition? If you don’t understand your own context, how would you know what would be fit for your context?
2. Study the starting conditions that enabled a particular practice or structure to emerge and evolve in a different context :
- if some of those are already present in your own organisation can you amplify them?
- if not, conduct safe-to-fail experiments to introduce some that aren’t currently present, but that seem compatible with your organisations cultural disposition.
3. Focus on changing the environment, processes and how people interact with them (and each other) vs immediately assuming training people to be different is the solution. Often the behaviour we want emerges when we change the environment people function in.
4. If you do implement a recipe, make sure you understand the principles behind it and that it seen as a scaffold from the start i.e. it is the starting point for evolving our own practices. Use the principles as enabling constraints that allow fit-for-context patterns to emerge.
5. Think carefully about copying metaphors from other contexts, language matters and metaphors are powerful. Always play devils advocate around potential unintended consequences.
When it comes to scaling:
6. Resist a one-size-fits-all approach and maintain a requisite diversity. As long as everyone is within the boundaries of purpose, values and organising principles, there is nothing wrong with different areas having different practices.
7. Chefs don't invent their own ingredients, instead they recombine existing ingredients into new configurations. So to scale, think like a chef ... breaking things down into smaller discrete units (or ingredients) and allow them to recombine in different ways in different areas (while maintaining coherence through purpose or intent and constraints or boundaries e.g. values)
If you want a thinking partner to help make sense of your own context and how to apply these principles, contact me to explore the available options.
Please subscribe to the blog and our quarterly newsletter to make sure you don’t miss out on future posts and events.