When Managing Multiple Teams, Think Networks—Not Hierarchies
When it comes to program—multipe team—management, I keep hearing a lot about “chief” this and “chief” that. You know—chief product owner, chief architect, that kind of thing. I’m kind of puzzled. I thought agile was all about self-organization and no command-and-control. "Chief" anything reeks of command-and-control to me.
At the same time, I understand the need for coordination among many teams to produce a usable product. Let’s discuss what the need might be and how you might get there.
First, how big is your program? Programs come in small, medium, and large sizes. I say a small program is three teams or fewer. A medium program is four to nine teams. A large program is ten teams or more. I draw the lines with these numbers because of the program teams.
The core program team—the program team at the executive level—has to be able to communicate. So does the technical or software program team. The larger and more complex the program and the more technical teams you have, the harder it is to communicate.
The name “chief” implies a hierarchy. But the larger your program, the less you want a hierarchy. Hierarchies are difficult to navigate, especially when you need to solve a problem. The problem has to go up one side of the hierarchy and back down the other to get solved. And who knows if you’ve even found the correct hierarchy to solve the problem?
That’s why it's more helpful to imagine wheels of networks. The idea is that the core program team and the technical program team are each a network of people responsible for solving their problems. The technical project teams that report to the technical program team are networks of people, too.
The program manager is responsible for the business value of the program overall, shepherding the program, managing risks, and helping to release the program when it has value to the organization. The program product owner is responsible for the business value of the roadmap. The program architect is responsible for the business value of the architecture. (Note that I did not say how these people are supposed to carry out these responsibilities. As with all programs, your mileage will vary.)
If you think of networks and not hierarchies, you are much more likely to get business value from your program. In my never humble opinion, calling the program product owner and the program architect both “chief” reinforces the idea of a hierarchy.
Now, you might need a person to be the chief architect and make all the final decisions. You might even need a person to be the chief product owner and make the final decision about the roadmap and the backlog. Say so. But make it a transparent decision.
If you’re transparent about it, everyone should be fine. I only have a problem when people say, “Anyone can change anything”—but not everyone can. It’s shades of Animal Farm, where some people are "more equal than others." Let’s be honest. You can do anything as long as you are honest about it—well, almost anything.
