Team of Teams

I just finished Team of Teams and it is one of my favorite books now. I’ve written about the most effective dev team I’ve been in before, but it came with the caveat that I had not seen that kind of structure scale up. Team of Teams describes a similar structure… scaled up to the size of all US forces in Afghanistan.

While there are significant differences between technology companies and the military, the one important similarity is that both are composed of people. What motivates people, how people behave, what people feel: these are all similar regardless of the type of organization.

Strict hierarchies tend to be inefficient. The US military had more money, manpower, and technology. Yet it was losing the war in Afghanistan. The issue is that strict hierarchies create silos. People don’t talk to each other. They focus on the narrow responsibilities they are given rather than looking at what benefits the whole organization.

Ideally an organization has a set of goals that everyone works towards. But when people work in silos, each silo has its own subset of goals. An example in software development is that a company has a goal to provide value for users. Users need a reason to give a company money after all. Yet it is possible for that goal to be narrowed based on the team involved. A development team is incentivized to ship code. A QA team is incentivized to make sure no bugs go to production. These two goals need to be balanced to maximize value for the user. Silo-ed teams don’t try to reach that balance. They focus only on their narrow goals.

Another problem with silos is information sharing. McChrystal talks about different divisions having different types of intel. Not sharing this intel means various units weren’t informed about where their efforts would be the most useful. This affected their ability to do what the entire organization needed. Often times this is unintentional. If you’re in a silo, you don’t intentionally withhold information from other teams. You just don’t think about talking to them.

Sometimes it is intentional. We’ve all seen these acts. The developer who hides behind “the technical details are too hard to explain to you. The UX designer who hand waves “this is better for the user without explaining how. The product manager who pushes a pet project without explaining how it achieves a company’s goals. Whatever the motivations for these actions, some people benefit personally from enforcing silos.

There are other examples of withholding information. In Team of Teams, McChrystal examines the Battle of Trafalgar. In it, Napoleon’s navy outnumbered Nelson’s. But Napoleon’s navy was very hierarchical. Not every captain was made aware of the overall strategy. The actions of every ship was controlled using signals from a central ship.

Napoleon’s navy lost that battle. Nelson had made sure that every captain knew all the details to his plan. He made sure that every captain had the capability to act as Nelson. They didn’t need commands from a central ship to act. They were given the knowledge they needed to act on their own and to act quickly. This was crucial as unexpected events often occur and being able to respond to these events quickly made Nelson’s navy much more effective.

I once thought I could save time by designing a software system and have someone else write the code. Surely that would have been faster than training them to design the system themself!

Unfortunately, lots of unexpected things come up during software development. Because I was lazy, this developer was not given the necessary foundation to account for the unexpected. He ended up having to come to me to make every decision. If I wasn’t available, he was paralyzed. I ended up costing both of us more time than I would have spent training him to be better at designing software systems.

Leaders should only make decisions when there is no other choice. To do so for every decision is incredibly inefficient. Good leaders ensure that things can continue to function even when they aren’t around. That means giving everyone the capability to make decisions on their own.

This post was originally published on blog.professorbeekums.com