Teams

Anticipate reorganisation by constantly evolving a meaningful structure.

Scaling up organisations is often driven by pain. We move fast, hire a lot, and at some point we realise that the way we operate isn't working anymore. Unfortunately, there is no quick fix because we scale up by splitting teams or by restructuring them, and these processes take time. If you're feeling the pain now, you failed to anticipate your needs six, maybe twelve months ago.

Often, we aren't only reorganising too late, we're also executing changes poorly. The weeks following the changes are chaotic. No one knows who is responsible for what anymore. The new teams don't have a clear mission. It's not clear who is supposed to maintain that legacy system that keeps breaking.

I may be negatively biased on the topic of radical reorganisation because I've seen a lot of badly executed reorganisations. I've been part of newly created teams named after desks, colours, floor numbers, programming languages used; the most nonsensical splits and structures you can imagine. It's depressing to see how little some leaders care about organisational design. And yet structuring teams in a coherent and efficient way has a major impact on the overall success of the organisation.

The starting point of designing a good structure is accepting that no structure is durable. Nothing works forever when you are trying to organise human beings. Once you accept that static structures can't make the cut, you can shift your attention from designing the right structure for today to constantly evolving the existing structure into a better one.

To facilitate this process, I suggest you build teams with the following properties:

• A formal definition: a name and a mission statement

  The fact that each team needs a name is obvious. So obvious that we don't give enough attention to it. The purpose of a mission statement is to ensure everyone inside and outside of the team knows what the team does and what they're responsible for. I suggest you come up with a short name and a one--two sentences mission statement. Writing clearly is hard, but the challenge here is that you really need brevity, too. If team names are too long, people will shorten them. Then you have two sets of names and a non-written mapping between the two. If the mission statement is more than one or two sentences, it won't stick.

• A backlog and a roadmap

  These fulfil different and correlated functions. A backlog tells a team what to do right now: the tactical goals to achieve in a short period of time. A roadmap tells them where they're going: the strategic goals to achieve to fulfill their mission.

• No dependencies

  Dependencies between teams can be disruptive to morale and efficiency. For example, failing to release a feature because another team wasn't ready with their part on time is a recipe for disaster. The resulting tension has a strong negative impact on the morale of both teams. People can leave a company if this happens often. People feel bad when they're stuck waiting for something they can't solve on their own. The more they are committed to the job, the worse they feel. It's vital to design structures that give people enough autonomy so they don't get stuck waiting on somebody else.

Evolving structures mostly means splitting teams into smaller teams. There are rare exceptions when it makes sense to absorb a team into another one, but these situations are too special to have a conversation around them. Splitting is what you usually do when you reorganise your teams so that's what we're going to discuss next.