There is much conversation about how work should be defined, scoped, and delivered, and how teams should be organised around that.
At Auto Trader, one of the things we often do is talk with other organisations about how we do things and how we could learn from them. And because people are often really interested in our journey and where we’re currently at, I’m sharing that more broadly.
Caveats caveats caveats
There are a couple of important caveats to start out with:
· Auto Trader is not a homogenous organisation that dictates process or ways of working to its teams. Our teams are not all facing the same challenges, and they contain different people, so it’s right that we have more than one way of doing things. What I describe here is not the “Auto Trader way” but is true of a part of our company.
· The way we organise, plan, and deliver is always evolving. Although this article is accurate today, it may well be out of date by tomorrow, and by this time next year I’m sure we’ll have moved on from this. I’m not proposing this as *the* answer, just where we’re at right now.
· If you don’t work for Auto Trader your situation will be different, so I’m not recommending what we do as the right solution for you.
Transforming from a publishing company to a digital product company
The Auto Trader story is a fascinating one — transforming itself from a publishing company with tens of offices and printing presses to a purely digital one, and disrupting itself by killing off its magazine business in 2013.
As a part of transitioning from a publishing company with a digital arm to a technology company, we adopted a version of the “Spotify model”, with multidisciplinary, loosely-coupled, semi-autonomous Squads aligned within Tribes that shared similar focuses (Consumer Experience, for example).
The success of squads and tribes for Auto Trader
Squads and tribes helped Auto Trader be highly successful for a number of years — including a highly successful IPO and entry to the FTSE100 — as we optimised and developed across many feature areas. Our squads identified key metrics to deliver against and worked with high levels of autonomy to produce solutions that drove significant improvements.
However, over time, this model became less ideal for us, and we needed to adapt. Some of the symptoms we saw were:
- Squads had created long backlogs in their individual feature areas, but the things at the top of their backlogs weren’t necessarily the most important things for Auto Trader to be working on
- Although squads were linked together in tribes, they were (naturally) optimising in their own area — even though much of the time the user experience involved encountering many different “products” through a single journey, or even on the same page. This could lead to disjointed experiences in places, with features competing with each other rather than complimenting.
- Our natural optimism and energy as a business led us to create new (small) squads reasonably regularly so that we could get started on something. These squads were often not well resourced enough to make a big difference.
So overall, although the squad & tribe approach served us well for several years, it was limiting our ability both to deliver the best overall experiences and make the big strategic leaps forward on our main priorities.
The flexible tribe and swarming squads
Around 18 months ago, we started to evolve the way we were working — specifically around how we planned and resourced our work.
Our goal was to enable us to focus more strongly on our strategic priorities while retaining ongoing team ownership and improvements across a portfolio of products (which manifests itself to users as a single thing).
If a simplification of our previous model looked something like this:
Then a simplification of our new model looks something like this:
In this model the tribe retain responsibility for an overall product area, but within it people swarm in larger numbers onto strategic priorities to enable them to move more quickly. In parallel — as the owners of an ongoing service — a much smaller group of people works on responding to feedback and making usability and platform improvements.
At most times there are usually also a few smaller projects going on. These are typically important — but small — pieces of work that can be successfully completed by a couple of people in a few weeks.
Importantly, people are not permanently associated with a swarm, or maintaining, or a small project. For maintenance, people from across the tribe roll on and off that responsibility every two weeks. For a small project, they will typically be on that project for 2–6 weeks, and then move onto something else. For swarms, people may be on it for several months — but others may join and leave that swarm during that period.
At other times, we might look more like this:
In these situations, we typically have a strategically important project that isn’t well-formed or understood enough to have a large number of people on it. So while these are a priority over other work we could be doing, they typically have a smaller cross-functional team working on it until we can successfully accelerate. During these periods, we’ll look to pick up additional small projects.
Successes and lessons learnt
As we’ve moved to this model over the past year and a half, we have successfully achieved a rate and quality of delivery that seemed almost impossible before. As well as improving the pace at which we can deliver, we’ve also dramatically improved both the coherence of our offering for end users and the underlying technical platform we’re building on.
But it is not without its challenges.
- The transition from squads to flexible tribes can be difficult for people. They may have been very comfortable in their squad — understanding their role clearly and having strong relationships. In the end, we feel we have much stronger relationships across the entire tribe now (thanks to people working in more areas, with more people) but the personal change to get there is important to understand
- Swarming onto priorities that aren’t yet well enough defined is inefficient and causes frustration. There is a temptation to immediately put large teams onto strategic priorities (the first diagram above). But we discovered this was counter-productive where there was insufficient product, user, and technical discovery in place — it just wasn’t possible to accelerate them efficiently. Identifying the right pace to increase the size of your swarm makes you more effective.
- You need a way to shape and define your small projects so that the outcome & scope of them is well understood. Small projects often need reshuffling around your main priorities, so there is some up-front overhead in identifying them in outline so that they can be roughly sized and compared.
- Having a balanced tribe leadership group — encompassing technical, product, and design perspectives helps with balancing the tribe’s overall focus. An excess of any one type of thinking undermines your ability to successfully execute against strategic priorities, impactful projects, and incremental improvement and maintenance simultaneously.
A blended model
At the start I talked about some of the different ways people are proposing as the best way for modern software development teams to work.
In the example I’ve described here, I believe there we have ended up with a blended approach containing elements of all the approaches. We have some top-down organisational priorities that focus our efforts, but with large amounts of autonomy to find solutions and achieve the outcomes. We have a persistent product team that actively collects feedback, analyses data, and makes iterative improvements. We shape small impactful projects that can be delivered in a timebox by a couple of people.
As we’re an agile organisation though, what is certain is that we’ll inspect and adapt over time and continue to learn both from our own experiences and the wider community.