In the previous posts, I described how we moved to a model of cross-functional squads, and the broader framework in which these squads operated. In this post, I’ll discuss how we evolved the model. Having put it into operation, we were able to observe what had and hadn’t worked and identify improvements.
What wasn’t working?
By and large, the first iteration had worked really well, but there were a couple of problems we observed:
- Some squads were more about planning than execution
2. Some squads had more than one outcome to pursue
Both of these issues arose out of the gap between my knowledge about certain elements of the business, and the business leaders understanding of exactly what we were trying to achieve with the cross-functional model. We recognised them relatively early on and were able to make the necessary changes.
Despite your best efforts, it’s very unlikely you will get alignment right first time. There is only so much time you can spend planning, eventually you have to put a plan into action and see what works and what doesn’t. What’s important is that you react to what doesn’t work quickly — inspect and adapt.
It’s also important to manage expectations — before we rolled out the team changes I had been at pains to warn everyone that it was unlikely the new model would work perfectly, and that we would want feedback on what wasn’t working so we could respond to it. Preparing everyone for inevitable changes helps them to be accepted.
Beyond these relatively minor tweaks, there was a bigger challenge I needed to address. Some squads were too big to self-organise effectively and struggled to collaborate effectively. This led me to reconsider the structure we had and how we could maintain alignment without compromising agility.
Tribes, Pods & Squads: Evolving the Model
Defining tribes
Previously tribes had been a concept we’d used purely for planning purposes. Yet over the first few months of seeing the squads in action, I’d recognised the potential benefit in more clearly defined tribes. Spotify, who developed the concept of tribes, used them as a way to make the organisation feel small as it started to grow. Tribes were used to develop small communities built around a shared purpose.
Whilst Moonpig is a much smaller organisation, it is still big enough to benefit from the concept of tribes. We had groups of squads that shared a common broad purpose, and I could see value in formally grouping those squads and articulating that shared purpose.
I recognised the need for three tribes:
Product & Service — this tribe was focused on developing and evolving our core customer value, both physical and digital. It was focused on customer missions — solving customer problems.
Growth — this tribe was essentially about marketing our customer proposition — getting more people to experience that core customer value. It was focused on business missions, leveraging our products and services to drive acquisition, activation, retention and revenue.
Foundations — this tribe was focused on support missions. We had some big re-platforming initiatives, so while this had high long term business value, it was not delivering new customer value in the short term.
The Product & Service tribe consisted of squads focused on designing and developing our card and gift ranges. This included creating the physical products and evolving the digital products which support their personalisation. Product & Service would also be the home of any new innovation around either physical or digital product.
The Growth tribe consisted of squads organised around the funnel, focusing on areas like acquisition, retention and revenue.
The Foundations squads focused on defining and building core elements of the new platform.
Size matters — introducing pods
It’s a well known fact within the agile world that smaller teams are more effective — smaller size makes it easier to self-organise. Spotify advocates a team size of 7–9, Skyscanner believe 8 is the maximum effective size. My own experience confirms this, but it also left me with a problem. What happens when we need more than 8–10 people to deliver an outcome?
The solution to this was “pods”. Reflecting on the problem I reminded myself that the core purpose of squads was to align people. Having observed the squads in practice, it was clear that multiple workstreams might be needed to support an outcome, and they didn’t have to live in a single squad, so long as the outcomes were shared between relevant squads and alignment was preserved.
A pod was simply two squads which shared the same goal — one team with two workstreams. Crucially each pod had a single data analyst — this provided a single source of truth on which hypotheses and experiments could be based.
Squads worked towards a pod goal which in turn supported a tribe goal
Sharing an outcome ensured the two squads would still collaborate, but were able to execute in smaller, more efficient units. Different pods worked in different ways depending on their goals and initiatives, but I’ll describe how the Retention pod worked as an example.
Pods in action
The Retention pod was made up of two squads:
Retention Web — a product engineering squad consisting of a product manager, engineers and a UX designer
Retention CRM — a CRM squad consisting of CRM marketers, a creative designer and a copywriter.
The pod would meet each Monday for a weekly growth meeting. They’d review the tests they’d run previously and analyse the results. Based on the new learnings, they would then meet to brainstorm together and generate new ideas. If the ideas involved experiments around emails, they’d be picked up by the CRM squad. If the ideas involved experiments on the website, they’d be picked up by the product engineering squad. The teams used shared tooling to capture and rank ideas and document analysis and learnings. Experiments themselves were executed within the individual squads, but they were generated by people across the pod.
Where coordination was needed the two squads could self-organise. There was also the freedom to share resource and expertise across the pod. For example, UX designers could help improve the layout of emails. Creative designers and copywriters could develop assets for landing pages on the website.
Aside from speed, alignment and knowledge sharing, the other benefit of this way of working was learning how to work more effectively. Whilst product engineering teams are familiar with the lean approach and the test and learn cycle, it was relatively new to the CRM team. Working closely together enabled the CRM team to learn from their product engineering colleagues and hone their own skills around experimentation. Likewise, the product engineering team were able to improve their understanding of email marketing.
What’s next?
The last few posts have covered how we designed cross-functional squads aligned around strategic goals. In the next post I’ll discuss how we went about optimising those squads by introducing lean and agile working practices.
If you missed it, you can read Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6 here.
