In the previous post I talked about the process of moving from a functional to cross-functional structure. In this post I’ll describe how we used Spotify’s model of squads and tribes as a guide. What we ended up with was quite different from Spotify, but it relied on the same principles. I’ll also outline the values and roles within our squad model.
The “Spotify Model”
Spotify became the unwilling role models of how to scale agility when they published videos describing their engineering culture back in 2014. Since then many have sought to copy their approach with varying degrees of success. I was certainly influenced by Spotify’s approach, but it’s worth clarifying the nature of that influence.
Joakim Sunden, formerly an Agile Coach at Spotify, runs training courses on how Spotify approach agility, and I was lucky enough to attend one of these. The key point Joakim makes is that attempting to copy and paste Spotify’s solution will likely result in failure. He urges people to take inspiration from Spotify, but to experiment and tailor their own solutions. And that’s ultimately what I sought to do.
What we ended up with was very different from Spotify, but it shared the same principles. It’s worth noting that Spotify are just one of a number of companies that influenced my thinking — I find learning from other companies invaluable, and I am constantly researching how other companies approach agility and looking for ideas that can be adapted for Moonpig’s particular context.
What’s in a name?
As any good software engineer will tell you, good naming is important. When we designed our new cross-functional teams we did choose to adopt Spotify’s tribes and squads terminology — and that proved to be a double edged sword. Both internally and externally there were certain perceptions of what a squad is — it’s an “engineering thing”, or a squad must contain engineers, or squads only work on creating new growth levers.
We did consider developing our own naming convention, but at the time I reasoned that, having come up with a new names, we’d simply end up by saying that “it was like a Spotify squad”. In other words, why reinvent the wheel? Given the confusion it caused, in hindsight I might have done that differently. As it was, I eventually came up with a clear definition of a Moonpig squad — something I should have done at the very start. Whilst it was clear to me, I hadn’t communicated it well enough to everyone else!
Definition of a Moonpig Squad
So in the interest of clarity, this is the definition of a Moonpig squad:
A Moonpig squad is organised around a value stream. It has a clear mission and is resourced to achieve that mission independently.
If a mission doesn’t require software engineers or product management, there won’t be any product engineering in the squad. And conversely, a mission which is product or tech lead may not need support from any business function. The mission and outcome determine the composition of the squad.
In addition to long lived mission and independent resource, there was third key principle of a squad. We wanted squads to the have autonomy to decide how to achieve their mission.
Whilst leadership are responsible for devising strategy and defining outcomes, the squads themselves should be trusted self-organise to achieve those outcomes. There are a number of reasons why this matters.
- Squads will be closer to the data and closer to the problems which makes them better placed to solve them.
- If there is a need to constantly refer back to management, management become a bottleneck which slow the squads down.
- Autonomy is a key tenet of motivation. To achieve high engagement levels amongst staff, you need a high trust system which supports autonomy.
Squads in name only
For the most part, the squads we formed aligned to these principles. However, we had an added complication. Moonpig is part of the Photobox Group, and within the group there are group functions which serve multiple brands. Functions such as Shipping and Supply Chain, for example, operate at group level.
This was a challenge because we weren’t able to incorporate those group functions in to our cross-functional model. That meant some squads were squads in name only. Some were heavily dependent on group functions so we were unable to give them the full independence of a true squad. However, the reasoning that drove the squad model did encourage those teams to have a conversation with those group functions about how to better align and streamline their workflow. Not necessarily a perfect solution, but certainly an improvement.
Inspired by Moonpig, other brands within the Photobox group also started to adopt cross-functional teams. Should that trend continue, group functions might well adapt to become better aligned with individual brands.
Tribes
In our first iteration of squads, there was very little emphasis on the concept of tribes. We had a loose idea of tribes which helped us in planning the various squads, but they didn’t play much of a role beyond that. In our second iteration tribes became a much more important concept. I’ll describe the second iteration in a later post.
Squad Roles
Squad Leads
At the inception of the squads we identified a need for a squad leader — someone that could harness the talent and coordinate the work of each squad. The leader was responsible for helping the squad to decide how they would achieve their goals, as well as sharing learnings and progress with the wider organisation. You can read the full squad lead description here.
Squad Sponsors
In addition to a leader, each squad had a sponsor — sponsors later became tribe leads, but the role remained the same. The squad sponsor was a member of the leadership team. Their role was to support the squad by providing advice and guidance, as well as being the first port of call for problems such as blockers or resource issues. You can read the full description of the role here.
Functions & Function Leads
When introducing cross-functional teams, one common fear I encountered was that splitting functions across multiple teams would result in inconsistency and chaos. That is a legitimate concern and a key challenge of working in this way.
It’s important to understand that in a cross-functional world, functions don’t disappear. They still have a critical role to play. Functions provide the guidelines, frameworks and principles within which members of the function can operate autonomously across multiple squads. The engineering function, for example, will be responsible for defining preferred technology and coding standards. A creative or brand function will define clear brand guidelines.
Functions provide the boundaries and constraints which enable consistent, high quality output — individuals within squads can then operate autonomously within these boundaries. To help embed this concept, we outlined the responsibility of a function lead which you can read here.
The vertical represents a squad aligned around a goal. The horizontal represents the various functions to which individual squad members belong.
What’s next?
In the next post I’ll describe the broader framework we created within which the squads would operate. One intention of squads was to break down silos, but we wanted to ensure that individual squads themselves did not become silos!
If you missed it, you can read Part 1, Part 2, Part 3and Part 4 here.
