People over process

I’ve recently spoken with a few peers about how we organise and run our product and tech teams at Auto Trader, which seemed like a good reason to reflect on the topic 🙂. We don’t have ‘a process’ at Auto Trader, and we favour conversation over documentation, so this is my attempt to share what I’ve observed and learned in 3 1/2 years.

This partly builds on, partly plagiarises an article my colleague Chris Collingridge published 3 years ago and the same three caveats are important:

1. This is reflective of a part of our organisation, and my own perspective. It may not be true of every team at Auto Trader.
2. The way we organise, plan and deliver is constantly evolving. This is not “the” answer but true of a moment in time.
3. Every organisation is different, what works for us might not work for you.

Some context about Auto Trader

All of our product and tech people (with a few exceptions) are based in the same building in Manchester, which is quite unusual for a company of our size. We don’t have any international operations, we don’t have any offshore teams. All of product, design, engineering and data sit together over two floors.

Before the pandemic we didn’t have much of a work from home culture, and post pandemic we’ve moved to a more flexible approach but we think it’s important that teams are together in person every week (as I said, this might not be the right approach for everyone but it is for us, at this moment in time).

Because we operate this way, and have done for a decade, we have a big emphasis on people over process. We don’t have a documented approach to how we build product at Auto Trader, but the principles behind the agile manifesto are deeply embedded in how we work. If I was to pick three of these that I think are particularly evident across our teams they would be:

Business people and developers must work together daily throughout the project.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Another thing that is unusual at Auto Trader is that we don’t do business cases. There is no forum for product people to pitch ideas, nor do we measure their value using NPV or IRR. The most valuable resource we can commit to an idea is our people. Our leadership team regularly identify a small number of initiatives we want to make progress with, and commitments against these, and these priorities flow down through the rest of the organisation.

Tribes and swarms

I’ve already referenced Chris’ brilliant article on this topic but tl;dr;

Having a large number of autonomous squads eventually led to teams optimising their products to the point of marginal gains and made it harder for us to organise larger numbers of people around bigger strategic priorities.

We still have Tribes (organisational homes for people and where they get their direction and business context), but we now favour more fluid Swarms over more rigid Squads. In practice this means:

• Calling out a small number of prirotities that are wildly important.
• Being OK with saying we’re not working on things, even if it means missing commercial opportunities or experiences remaining static over time.
• Being prepared to slow things down to speed other things up.
• People being flexible to move between teams when necessary (although we try and do this as little as possible).

In addition to the wildly important priorities, there will always be work that needs to be done to maintain platforms, support ongoing BAU activities and fix bugs, so we organise teams around two philosophies:

1. Stream teams: Working towards a specific goal or outcome, and once that is achieved the team will likely disband and move onto something else (may exist for weeks, months, or longer). Example: ‘Online finance applications’.
2. Enabling teams: More permanent than a stream team. There will always be work in this domain and the team are likely to be more specialised. Example: ‘Billing team’.

As I caveated in this beginning, this works well for us at this moment in time, given our current size and when there are a small number of well defined strategic initiatives that we want to make progress towards. The pendulum may well swing back towards more autonomous squads with clearer ownership of a product or domain at some point in the future.

So how does prioritisation work?

Quite simply, we agree what the most important things are that we want to make progress with and we organise our teams around these.

The process is more top down than bottom up, unashamedly so. Leadership sets the strategic priorities (we call them ‘Blue Cards, because once upon a time they were written on blue post-its), although this is a collaborative process with lots of input from teams across the organisation.

Within product and tech we then organise ourselves around how best to deliver these ‘Blue Cards’. This doesn’t mean not doing anything else, there are always platforms to support, bugs to fix and ‘non Blue Card’ things that we just need to make happen, but we’re very clear on the priorities that the business are expecting us to deliver against. There is no process for this, just regular conversations and pragmatism.

Balancing outcomes and outputs

We’re a very delivery focused organisation (again, unapologetically so). We have a great track record of picking things that are strategically important and bringing people together to execute against these. We’re most successful when we build motivated teams from across the organisation with a clear purpose and goal, and build momentum towards it.

Some teams may be working towards goals that you can measure incremental progress towards, such as improving conversion through a funnel from x to y, and others team may be working towards more binary outcomes such as to migrate from supplier a to b, by a specific date.

We’re not purist in how we define goals or OKRs, and we don’t mandate a standard way for teams to track progress. Leads choose how to best explain to their teams the outcome they are working towards, and we prefer to find out about any issues or blockers through conversation rather than red status reports.

In summary, what’s in like to work in Product and Tech at Auto Trader?

• We don’t do business cases; we identify our ‘Blue card priorities’ and we organise our people around these.
• We favour more fluid ‘swarms’ over more rigid ‘squads’.
• We balance making progress with our ‘Blue Card priorities’ with platform and BAU work that we need to support.
• We let teams decide how to set goals and track progress, and we’re not to purist about this.
• Most of all, we favour people over process.