We all want to do better. However we define better for ourselves and the organizations we work for/with, we all want some idea of better. We have hypotheses for what will make us this magical better: speed, quality, efficiency, optimization, risk mitigation, etc. For most of us, it is a complex formula that combines all of these.
It is this complexity in the interconnectedness of the systems we work in that really is the issue. So, why is it, we think that some magic wand from outside the system is going to be able to bestow on us all the truths about our system that will make us suddenly better?
I’m sure you’re familiar with some version of the following:
We just instituted SAFe.
or is it.
We are moving to the “Spotify Model”
I just got back from the d.school and we are going to start using “Design Thinking” throughout all our work.
Silver Bullets come in all forms and types, but since there is no such thing as Weirwolves, the fact that a bullet is shinier or more rare is really irrelevant. All our systems are unique calibers with custom machine parts (to extend the metaphor), so no one else’s bullet is ever going to work for us.
There are two types to the above examples. First there are prepackaged systems that someone is licensing or selling consulting for. The other type is the experience of an organization that they happen to have shared with the world. In the case of something like Design Sprints it's become a combination of both.
So, why is it, we think that some magic wand from outside the system is going to be able to bestow on us all the truths about our system that will make us suddenly better?
What is often missing from this second example, which I call the “Be like Mike” example, is that seldom do organizations that are trying to adopt these methods, do so with a full understanding of what it took for that sample organization to become the iconoclast they are today.
Let’s take the example of “The Spotify Model”. Many organizations look at this model, not for what makes it work, but what it supports in how they already want to be working. Ninety percent of the time when I hear “Spotify Model” what I really am seeing is embedded product teams. Now I’m not against embedded product teams where design, product management, engineering, and other folks sit together as a single team. I’ve implemented it a few times myself as a manager. What I am against is people thinking the embedding/collocating is both the start and finish.
But that isn’t the “Spotify Model”. That’s the Spotify Model done poorly.
Yes, that is true, so lets help people do it better, right? Easy!
What they missed is that they have to use “squads, chapters, tribes, and guilds”.
That would definitely go a long way to helping, for sure. But my contention is that even doing that by itself is meaningless unless you also look at the values of Spotify and how those values are put into action in a host of other ways.
From what I have seen from most attempts to make the Spotify Model work and why they fail, is due to lack of real belief in Autonomy. Spotify has a high risk tolerance, and has set up an operational model built on recovery from more than an avoidance of failure. But if your organization hedges at all about autonomy, you need to think how else are you going to replicate the effects of autonomy within the organization you have. If you want to head towards autonomy, you can’t fake it. You have to adjust the total plan for how your version of the Spotify Model will be based on the goals of the business and product organization.
Take a look at the videos that Spotify made to share what are doing:
The first thing you should notice is the title of the video is not “Our Process”, but “Our Culture”. Don’t watch it looking at the process and structure elements they are providing. Rather watch it for how they describe their values. By using the rhetorical framework that the Agile Manifesto uses of X > Y, they set up a world with no absolutes, just preferences.
You can set up all the squads, tribes, guilds in the world, but without the culture supporting that structure and the values and rituals of that culture you would not have a Spotify Model. This is hard. This is really hard. imposing new value structures is one of the hardest forms of corporate change to do.
Doing the work of translating someone else’s methods to fit your culture is hard work. It needs to be designed. It needs to be assimilated, not just applied. There are issues around change management that need their own program management. The work requires solid analysis not just of your environment, but environments of where it has worked and where it has failed.
If you are working some place that just wants to use someone else’s frameworks but in your context, be ready. Do your work. Understand your world really well. Understand the assumptions of the frameworks you want to make use of. What would it take to make the outcomes desired from these frameworks happen for you?
There are a ton of great frameworks and other toolkits out there for us to use. We just need to be prepared to make them work in our unique, complex, living ecosystems.