Teams of teams

So far, I equated evolving teams to constantly changing the teams' composition. The same applies to your leadership style: you can't evolve teams if you are not evolving the way you lead at the same time.

You could say that scaling leadership is like driving. A go-kart responds to changes almost in real time, a car responds a little slower than a kart. At the top of this chain we have trucks: they can carry a lot, but they respond slowly to any change of direction or pace. The point is: the bigger the car, the slower it responds to change.

Leadership isn't so different. Taking a decision for a small team has immediate impact: you make a mistake, you notice right away. The bigger the team, the slower the feedback loop. The increasing amount of communication that bigger teams need to function slows down the loop.

The problem with this analogy is that it centers the decision-making process around the leaders. Leading stops being about making direct decisions as soon you are leading a team of teams. One level of indirection is enough to break the analogy: as soon as you have more than one team, you aren't really driving. A team of teams isn't like driving a truck, it's more like being in charge of the roads where many cars are driving. Leading a team of teams feels more like building transport infrastructure. Your job to is to free the roads so that teams can go wherever they have to.

Your focus shifts from people to people infrastructure. Using the transport infrastructure analogy, you look at your teams and ask yourself:

• Is team A always getting stuck at the same traffic light?
• Is there a shorter way for team B to get to X?
• Do we need a better engine for team C?

Building infrastructure is a game of anticipation and coordination. You observe your teams to anticipate their needs. Two teams trying to get to different places can bump into each other somewhere on that bumpy road. You need to fix the road or find a different route.

It's worth spelling out the strong underlying assumption of this approach: you know what it's going on within your teams. It sounds obvious in theory but, in practice, there isn't anything obvious about it.

For starters, your teams must be observable. You don't want to ask them for metrics every week or have them check in with you regularly. In the culture chapter, I discuss the principle "Share everything by default". The idea is to make public information as accessible as possible. It's fair to expect your teams to share public information by default; it's a better deal than going around asking or trying to come up with some metrics and processes. It's also crucial that teams make their public information readily available.

When teams share information about their decisions, their problems, their successes, you start seeing patterns. Different teams travel via different roads to get to different places. But they're all travelling, so they all have travelers' problems. "Sharing everything by default" is how you gather data. You can help your team leaders to spot patterns and come up with an action plan. Change is easier to sell if you can back it up with data.