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 bottlenecks 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:
- Accept that either one or both of your team outcomes are going to be delayed
- Hire additional resource
- 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 the 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.
If you missed it, you can read Part 1, Part 2 and Part 3 here.
