In the previous post I described our squad principles and roles. In this post I’ll talk about the broader framework in which the squads operated — some of the ceremonies and practices we introduced to provide visibility and coordination between squads.
The Kick-Off
At Moonpig we used the OKR framework, and at the time we were reviewing OKRs every 6 months, so the year was divided in to “H1” and “H2”. To provide a broad overview of what the organisation was doing, we organised an “H kick-off”.
Whilst it was important for everyone to understand what their squad was doing, and how it supported the company strategy, we also wanted them to have visibility of what other squads were doing. The event itself was fairly short and straightforward. We began by reiterating the strategy and then each squad spent 3–4 minutes explaining:
- Who they were
- What their long-lived purpose was
- What their short term goal (OKR) was
- What they planned to do to achieve that goal
This helped give everyone a high-level overview of each squad’s plans and how they aligned with the company strategy. The intention was to repeat this exercise at the beginning of each H.
The Showcase
A kick-off was useful, but we also wanted to provide regular updates and knowledge sharing to build on this.
In the pre-squad world, we had a weekly tech demo in which the product engineering teams would give an update and demo what they had been working on. In the squad world, we repurposed this to become a company-wide showcase. This was held every two weeks, and alternated between squads. That meant we would have an update from each team every 4 weeks.
Everyone in the company would attend the showcase, and for teams presenting, the brief was to:
- Showcase anything new — new physical products, new features, new marketing content
- Share noteworthy learnings — for example, an experiment that delivered unexpected results, positive or negative, and what was learned from it
Fundamentally this was about providing visibility and knowledge sharing. Even if teams didn’t feel they had anything particularly exciting or visual to present they were still encouraged to talk about how they’d spent their time in the previous 4 weeks.
The Squad Leads Stand-up
This was a 10-minute weekly gathering of squad leads wherein each squad lead would provide a high-level update on what their squad would be focused on for the next 1–2 weeks. It provided visibility and identified opportunities for cross-squad collaboration or highlighted potential conflicts.
The Monthly Check-In
The monthly check-in was intended as a “reporting and supporting” session. Each squad had a check-in once every 4 weeks, attended by all squad members and the Moonpig leadership team. The first half of the check-in covered the “reporting” element and this consisted of:
- Providing an update on progress towards the team’s goal
- Highlights and lowlights of the past 4 weeks
- Celebrating successes, sharing learnings from failures
- Discussing forthcoming plans
The second half of the check-in was dedicated to “supporting”. This provided the squad with the opportunity to seek guidance, advice and direction. It also provided an opportunity to raise problems and blockers — to raise problems external to the teams which they needed help addressing.
The Function Meeting
As I mentioned in the previous post, it’s important to maintain strong functions within the cross-functional world and regular gatherings support this. The recommendation was that functions meet at least once every two weeks, if not more often. The purpose of these gatherings was to:
- Provide visibility of what individuals were working on across different squads
- Learn and knowledge share — this might be around driving business outcomes or around working practices and processes. Functional gatherings support the cross-pollination of good ideas and help breed consistency.
- Continuous improvement — this was about driving quality, reviewing how excellence is achieved within a particular function
Functional gatherings could take different forms depending on the function. The UX function, for example, would run a weekly critique session, in which they’d peer review one another’s work and offer constructive feedback. In the case of the engineering function, demos were key — showcasing new technology and implementation.
Introducing Confluence
One key difference I noticed between product engineering and the other functions was that the mindset around radiating information was very different. Moonpig uses Google Drive and whilst this works well as a way to store and share documents, it doesn’t support finding information easily. One of the most frequent complaints I’d hear was people not being able to find information.
To that end, I started to encourage all teams to use Confluence. Confluence is a wiki that forms part of the Atlassian suite. It was not necessarily the best choice of tool, but it was readily available and provided a quick solution.
The idea was to use Confluence as a gateway to accessing information. Google Docs were not banned — far from it — but the stipulation was that information stored in Google Docs that was of wider interest was linked to in Confluence.
To get started I created a section in Confluence for each squad. This followed a loose template, and by default included:
- An overview page listing the squads’ long-lived mission and OKRs
- A people page which listed the members of the team, their slack channel and email d-list
- A metrics page which was used to capture progress against OKRs for the monthly check-ins
- A tracking resources page which had links to the teams’ Jira boards and dashboards
The purpose of Confluence was to provide information about every team — who they were, what they were trying to achieve and how they were progressing. I wanted everyone in the organisation to be able to find out exactly what any other team was doing.
We also used Confluence to capture information around user testing, analytics and AB tests. Essentially, any information which might be relevant to a wide range of people could be found and accessed via Confluence.
What’s next?
Thus far I’ve described our cross-functional model and the broader framework in which it operated. In the next post I’ll describe how we iterated on our squad model based on our early learnings.
If you missed it, you can read Part 1, Part 2, Part 3, Part 4 and Part 5 here.
