Based on my professional experience, I believe the best structure for building software is one engineering manager per team. One person in charge, who owns the outcomes of that team and only that team.
This view is influenced by my four years in the Marine Corps infantry, before starting my tech career. I’ve been wanting to write this for a while, and what better day to do it than Veterans Day.
How the Marine Corps is organized
The United States military is extremely well run. Yes, one reason is money, but it also has good policies, procedures and training. The Marine Corps is the least funded of the four traditional branches and one of the best.
A big part of its success is the leadership structure. In the infantry, four infantrymen make a fire team, three fire teams make a squad, three squads make a platoon, and it keeps going from there.
Every one of those units has two things.
The first is one person in charge: a fire team leader, a squad leader, a platoon commander. Every team has one clear owner, and that owner is responsible for only that one team, big or small. A platoon sergeant can always go to a squad leader and say: What is the team doing now? Why did this happen? Make sure it doesn’t happen again!
The second is a clear chain of command. If, God forbid, the team leader goes down, everyone knows who is second in command, so that person picks up right away and continues to lead the team.
One manager, one team
I’ve managed in both environments, and I think the military structure maps really well to software.
I consider myself a technical manager. I like to be hands-on and to know what my team is doing. With one team, the job is clear: the team has goals, and I lead the team to get them done. If anyone has a question about the team, there is only one person to ask. That person is me, and it’s my job to have the answers.
In this structure, the director’s job is clear too. A director manages four or more engineering managers, each with one team. Because each manager owns one team, the director can set clear goals for each manager and hold that manager accountable, the same way a platoon sergeant does with a squad leader. A VP does the same for the directors, and so on.
One manager, many teams
There’s a growing trend in software to put one manager in charge of two or three teams. It looks more cost effective on the surface, because the company pays for fewer managers. In practice it’s less effective, because the cost just moves somewhere else.
There is a limit to what one person can process, even a good technical manager. A manager with two or three teams can’t know precisely what everybody is doing, so the day-to-day leadership falls to tech leads. That is a hard position for a tech lead. They have to direct people who don’t report to them, without the carrots and sticks a manager has, and that creates a misaligned power structure. The manager, in turn, has to rely on the tech leads to digest what each team is doing.
So when a director asks what’s going on with a team, there is no longer one person who has all the answers. The manager points to the tech lead, because the tech lead is closer to the work. The tech lead points to the manager, because the manager owns the higher-level picture. Each of them has half of the answer.
It often happens to the best managers. A strong, organized manager gets promoted and picks up a second team, and then a third. The manager doesn’t get worse. The job changes, and it’s no longer possible to stay close to what each team is working on.
This setup does work, and teams ship with it, but I believe companies get better, more focused results when every team has a manager of its own.
The approach was likely popularized by companies like Google. Perhaps, if you have a team of very strong, seasoned A players, you can get away with it. You lean on your tech leads, and they have enough experience to get the job done.
A lot of companies are not Google. Their teams have a wider mix of experience. I understand why they aim to emulate Google, but this setup depends on a deep and consistent presence of senior talent. Without fully considering whether they have that talent, companies often end up with less than optimal outcomes.
My own experience
I’ve seen both structures from the inside. I became a manager at Evernote when my manager’s scope grew to several teams and he handed one of them to me. He did the right thing: he found a person he could trust and gave them full ownership of the team.
With one team to focus on, we delivered great outcomes. We built Evernote’s notifications system from the ground up: native and web clients, a backend microservice and third-party providers. In 2022 it delivered over 110 million messages across email, push and in-app, at 99.9% uptime.
I manage two teams today. Both teams are great, and the work gets done. It is a different job, though: more delegating and less hands-on time.
Does AI change this?
Historically, before AI, I would recommend six to eight engineers per team.
I do think teams will get smaller with AI. Each engineer produces a lot more with AI, so a team needs fewer people, and you want those people to be A players. So does it mean a manager can now manage two teams?
My intuition says no. One manager per team is still the way to go. A smaller team with AI is not less work to manage, because each engineer now produces far more, and somebody has to keep all of that output pointed in one direction. Even A players need coordination, a unified vision and one person who is responsible for the team.
If I were the director, I would still want one person I can talk to who owns the whole thing. Not somebody splitting their attention between two teams. One owner per team, and that owner is fully accountable.
Happy Veterans Day!