Adopting Business Agility at Moonpig, Part 4: Alignment

About the Series

In 2017 I had the exciting opportunity to introduce business agility at Moonpig, one of the UK’s best known start-ups. This series of blog posts provides an in-depth case study of my experiences, and I hope will provide a useful set of steps for others looking to adopt and scale lean and agile. I have written this for the benefit of the wonderfully generous lean and agile community from whom I have learned so much. I hope that by sharing my learnings, others can benefit as I have.

Getting Started

In the previous posts I described why we wanted to change, what we hoped to achieve and how we planned to go about it. In this post I’ll talk about the first step which involved reorganising and aligning our teams.

Why align?

Peter Senge is a Systems Scientist, Lecturer and Author

Beyond the obvious reasons why alignment is sensible, for me alignment was critical in order to promote speed. I believed this would help achieve one of our key outcomes - to get faster.

Outside of the world of agile software development, cross-functional teams are less common. I had one advantage at Moonpig in that we had introduced a flavour of cross-functional working through our homegrown Honeycomb framework. This meant that the concept and benefits were familiar. However, it’s worth clarifying these benefits, and this is how I explained them to our teams.

Why cross-functional teams?

Functional teams

Historically businesses have tended to organise themselves by function and to group people by skillset. The main drawback from functional teams is that they are liable to slow you down. Very often a single function is unable to achieve a strategic goal without being dependent on one or more other functions. This begins to create a network of dependencies, and necessitates a reliance on project management to manage the dependencies and the flow of information between teams. This tends to be exacerbated by conflicting goals which means functions don’t share the same priorities — put simply they are not aligned. This leaves the different functions of your organisation pulling in different directions.

Functional teams often result in multiple cross team dependencies

The functional model focuses on resource efficiency — the ideal being that 100% of people are 100% busy 100% of the time. This is deemed cost efficient as it keeps staffing costs as low as possible. However, focusing on resource efficiency as your primary metric comes at the expense of flow efficiency. Flow efficiency can be simply understood as how long it takes to deliver value.

Cross-functional teams

The fundamental difference with cross-functional teams is that you organise people by what you want them to achieve rather than by what they do. In doing so you align people more effectively around your strategic goals and you reduce (and ideally eliminate) dependencies and conflicting priorities between teams. This liberates individual teams to move at speed.

Cross-functional teams ideally contain the necessary resource to enable them to operate independently

The cross-functional model focuses on flow efficiency — it prioritises time-to-value over resource efficiency. Indeed, in a healthy cross-functional system there will be some slack. People will not be 100% busy 100% of the time. This is a counter-intuitive concept but it is essential to making this model work successfully. As soon as you start to focus on resource efficiency you risk creating dependencies and introducing those bottle necks which increase the time it takes to deliver value.

Slack time might seem wasteful, but it can prove invaluable. As well as ensuring a sustainable pace of work and avoiding burnout, it gives individuals time for personal development — time to learn. Companies that champion learning will be rewarded with a more effective, more engaged and more flexible workforce. Indeed learning provides one solution to managing the resourcing challenges that a cross-functional model presents by enabling the development of cross-functional, or T-shaped skills.

Understanding the context

Before attempting to make any changes you need to understand the problems that currently exist. As I mentioned in a previous post, I spent the best part of 6 months working with functions outside of technology. This gave me insights in to the way they worked and the problems they experienced. This was invaluable in understanding what changes we needed.

It became clear to me quite quickly that we could certainly extend a lean approach to these teams, but that their current structure would make it very difficult. We were set up in by functions, some of which were unable to deliver effectively because they were dependent on other teams or functions.

Identifying value streams and core metrics

My approach to reorganising our teams was to understand our core growth metrics and the key value streams which supported them. With this in place it was easier to understand what our teams should look like.

I began by identifying what I believed were a set of long lived metrics that captured our business value. This was very much about the “why” not the “what”. Outcomes like retention or acquisition rarely disappear unless your business model fundamentally changes. What you do to influence an outcome may change relatively frequently, but the outcome itself remains constant.

This was a key consideration because I wanted to introduce a model with some stability and longevity. There is a cost to commissioning and decommissioning teams. It takes time for a team to mature and become high performing; if you are constantly changing your teams you are having to reinvest this time over and over again. Not to mention which you introduce the risk of change fatigue.

There is often a tendency to organise teams around architecture or product. Unfortunately customer problems and business outcomes rarely conform neatly to these. Organising teams around outcomes does present challenges in terms of product and code ownership, but these are not insurmountable. Once you have teams aligned around outcomes, you can then start to work out a model of code and product ownership that will support it.

Once I had a set of metrics in place, it was relatively straightforward to understand the mix of skills we’d need to deliver against each one. I shared this with our leadership team, and we then spent some time refining first those metrics, and then deciding which people we needed to support each metric.

Resource Bottlenecks

One of the key challenges of devising the new teams was resource bottlenecks. We were not attempting to do more with the new teams — if anything we were much more streamlined. However, as we started to identify the skills each team needed, resource bottlenecks were brutally exposed. Whilst creating cross-functional teams didn’t solve this problem, it made us aware of it — and once you are aware of a problem you can start to solve it. I’m often asked about this question of resource, so it’s worth explaining how we tackled it.

Copywriting was one area in particular where we lacked resource. In some cases it was feasible for a single copy writer to work across multiple teams. There is no problem doing this if neither team involved needs a full time copywriter. However, as soon as the copywriter starts to become a bottleneck they will slow one or both teams down. At this point you have three immediate solutions:

  1. Accept that either one or both of your team outcomes are going to be delayed
  2. Hire additional resource
  3. Do fewer things

A longer term solution is to invest in up-skilling your existing resource to develop more people with t-shaped skills. So in the case of copy, for example, a long term solution would be to invest in training some of our marketers and UX designers to write copy themselves. This wouldn’t necessarily remove the need for dedicated copywriting expertise, but some of the simpler copy tasks could be handled by others.

T-shaped skills involve developing a breadth of skills as well as a depth of expertise in one or more specific areas

In the short term, however, your choices are limited, and none of the options are necessarily easy. In our case we did hire more copywriters. However, more people won’t always be an option.

Product engineering has always been the biggest resource bottleneck at Moonpig. As an e-commerce company, the business is entirely driven by technology and engineering resource is therefore in high demand.

No matter how well resourced you are, the list of things you want to do will always be longer than the list of people to do them. The solution is always to focus and prioritise — the more things you try to do simultaneously, the slower you will move. Limiting your work in progress at the level of project or initiative is vital.

Resource your outcomes in the order of their priority; once you run out of resource, put the rest of your outcomes in a backlog. This will allow you to generate the most impact fast. The faster you deliver your prioritised outcomes, the faster you get to the next items on your backlog.

This is hard to do because it is counter-intuitive. The assumption is always that the sooner you start something, the sooner you will finish it. But in fact when you start too many things you spread yourself too thin and you simply slow down. It takes discipline, but the key to moving faster will always be to focus on fewer things.

What’s next?

In the next post I’ll talk about how we took inspiration from Spotify’s model of squads and tribes, and I’ll also describe our squad principles and leadership model.

Could I help your business to become better, faster and happier? I am a freelance coach and consultant that helps organisations adopt business agility. Find out more about what I do at



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Amanda Colpoys

Amanda Colpoys

Business Agility Coach & Consultant supporting organisations to grow, innovate and deliver value quickly at scale.