Sharing the magic: Distributed roles in the flexible tribe
Recently I wrote about how we were exploring new ways of working, from squads to swarms. If you haven’t read that one yet, it’s worth a quick review for context.
One of the questions I was asked off the back of that post was how this flexible approach worked where there are smaller numbers of people with a specific role in the tribe (product people and designers typically, but it also applies to tech leads, QA, and potentially others).
This post is about how we manage that, some of the challenges it brings, and how I believe it is leading us to a higher-performing tribe overall.
Not binary
In a squad-based model, individuals are in one squad. This is an important part of the benefits of that model — you have a dedicated team, working together to achieve a common goal. All pigs and no chickens.
In the flexible swarming model though, this is often not appropriate — people are no longer on the team or not: there are more shades of grey. As swarms are created, expanded or shrunk, and maintenance and small projects go on alongside them, different balances of roles are required at different times.
For example, taking a snapshot across a flexible tribe at a point in time might show something like this:
While the swarms will typically have people with a variety of roles fully allocated to them, small projects and maintenance usually won’t — relying instead on part-allocated or ad-hoc input from other roles.
The Tetris / Gannt Chart Dilemma
John Cutler uses the analogy of Tetris for some of the dysfunctions you can see when organisations try to maximise the utilisation of people and divide projects up. A player (manager) rotates and moves pieces around as fast as they can, looking for the perfect fit. But holes get left, errors build up, and eventually you lose.
Another easy trap to fall into is to try to manage the dependencies that are created by part-allocated or ad-hoc people by using traditional project management — getting ahead of the work and managing dependencies through serialisation of work.
Some key elements that we’ve found can help avoid these problems are:
- Have a plan, but be the master of the plan not its slave
- Have an assessment of what will be required (how much effort) and when so that everyone can understand what the next few weeks/months looks like and can talk about what is realistic. But do not stick to this plan. Instead, constantly revise and update the plan based on new information and reality.
2. Explicitly avoid attempting 100% utilisation
- First of all, not all work is project work — at Auto Trader it’s important that everyone develops personally and professionally and contributes to our community, and that requires time. Secondly, unexpected issues, extra tasks, and support for others will always come up. Thirdly, people need capacity to enable the team to work effectively — everything we know about flow tells us that you go slower when you try to over-utilise.
3. Control the number of projects/teams any one individual works on
- Projects & teams come with overheads — context switching (see below), standups/planning, showcasing, building and maintaining relationships, and so on. Working on two projects at the same time is difficult, beyond two it becomes very difficult indeed and most likely counter-productive.
4. Give people autonomy, but help with prioritisation
- The people who are working as part of more than one team are the best placed to understand how to divide their time, where to sit, how to work, and so on. We’ve found they’re best able to be effective when they can work with their teams to organise themselves. Sometimes it can be hard to make a prioritisation call though — so having clear goals for the wider group (the tribe) helps identify what to do when there is a dilemma.
The Context-Switching Problem
It’s well known that asking people to context switch is bad for their ability to focus and be productive. Having people split between more than one team introduces additional contexts and can affect both overall effectiveness and morale. For people who are being exposed to multi-team working for the first time, this is often the most challenging thing for them.
While the impact of context switching can’t be eradicated, it can be minimised. Allocating blocks of time to work on one team/project or another is especially useful. By working with the team, individuals are able to identify what’s most important to do now and what could wait for a day or two, or a week. By communicating well with their team, unnecessary interruptions can be reduced without impeding progress.
The Expertise Gap
A big advantage of a settled squad is that the team gains a deep expertise of their product area, customers and users who use that product area, and future possibilities. (The downside, as mentioned in from squads to swarms is that the thinking can become siloed).
If people are moved around and split between projects, how do you counter the lack of that depth?
In our model, our people are associated with a tribe — which has a set of related products, services, and customer/users — which helps to retain a level of expertise across a broader area.
But within that — rather than trying to have a “resource pool” of identikit pieces — individuals have a particular part of the product suite that they are more expert in that others. For example, within Trade design we have people who are the first port of call for data & analytics, advertising, account management, and retailer/consumer communications.
The Lack of Ownership Paradox
By breaking the model of stable squads with direct responsibility for a single area, there might be a risk that a feeling of ownership is lost. We have observed the opposite of this in two important ways:
- Dedicated teams that deliberately come together for a shorter time with clear outcomes can quickly demonstrate high levels of accountability for those outcomes
- By having a broader view across the whole tribe, an increasing number of people take ownership of things outside of their immediate purview because they understand and are involved with wider concerns
A high performing tribe
Taken together, what I’m describing might seem like a number of mitigations for an imperfect approach — planning, managing dependencies, time-boxing tasks, defining areas of expertise.
I consider these situations though as part of moving from high-performing autonomous cross-functional squads to a high-performing autonomous cross-functional tribe, where individuals flex their roles, how they’re working, and who they’re working with on a regular basis to ensure the most effective tribe possible.
