How Big Should Your Engineering Team Be?

Have you ever been on a team where it seemed like it took forever to get anything done? You had constant status meetings and could never seem to get a handle on what was being done. It's not an unusual situation, and it can have a variety of causes. How big was the team? Was it six or seven people? Maybe more? That could have been your problem. I was recently asked to propose a solution to reimagine an existing system. The system should use all the same data and database tables, but the rest of the application could be reimagined. The goal was to be able to deliver an MVP as soon as possible. I had to include the technical aspects and what the team of engineers should look like. The stakeholder wanted the MVP delivered in a month, maybe six weeks, and assured me that there were plenty of engineers available, so whatever it took to get the MVP delivered was fine. He told me he had 10 to 15 engineers he could assign to this easily if we could deliver the MVP in under 6 weeks. I proposed a team of five engineers, and he was surprised at how few I wanted. The Mythical Man-Month The Mythical Man-Month: Essays on Software Engineering by Fred Brooks was published in 1975 and contains many ideas and lessons that still apply today. The idea that I reference most, and which was at play in my recommendation for a small team, was the mythical man-month. There is an analogy or idiom I've heard that illustrates the mythical man-month concept well, even if it doesn't go into the reasoning from the book: "Nine women can't make a baby in a month." A pregnancy is about 9 months long, and the baby is growing and developing, which is not something you can divide among multiple people. The pregnancy will take roughly the same length of time, no matter what. Unlike a pregnancy, developing software can be divided between multiple people, but can't be perfectly divided into discrete, self-contained tasks without dependencies. There will be dependencies between tasks and the people doing the work. People will have to communicate and coordinate their work. Communication and task coordination are major limiting factors for development teams. When you have two people, there is only one line of communication between them. If you have a team of three, there are three lines of communication. If you have a team of 10 people, there are 45 lines of communication. The formula for the lines of communication between people in a group is n(n-1)/2, where n is the number of people. If you really want to get into the math, this creates a polynomial growth curve. The Work Matters Regardless of the number of lines of communication, the kind of work you're doing matters when it comes to team size and scaling, and what can get done. When you can eliminate dependencies between people and tasks, you find opportunities to be more efficient. If your large team owns multiple microservices, for example, dividing the team between the microservices for the current sprint helps reduce the number of lines of communication. The same idea applies if you have 100 engineers migrating 20 microservices from Java to Go, for example. If you assign five people to each microservice, you have drastically reduced the number of lines of communication by removing dependencies outside those groups of five. In both these examples, you effectively created smaller teams. Suppose your team needs to create a lot of data models in your codebase, for example. In that case, you can often effectively split that across a large team if you properly plan for dependencies and relationships. The fewer dependencies and relationships, the easier the work will be with a large number of engineers. That's the key: Reducing the dependencies between work can enable you to leverage a larger team effectively. It's not always a great idea, but it's an option if you have no choice. Can I Speed Up My Project with More People? Probably not. One of the key points in The Mythical Man-Month about the mythical man-month is what has been coined as Brooks' law: "Adding manpower to a late software project makes it later." Getting new people up to speed on the work will require coordination and communication, which will be affected by that growth curve from earlier. If the work is well enough defined, there are few enough dependencies, and the new people need very little context, you might be able to add people and speed up the project. But that is a lot of "maybes" and "ifs." Small Teams Are Fast Several years ago, I led a team that fluctuated in size from four to seven engineers. When the team had seven engineers, it took a lot of mental effort to keep everything coordinated and moving forward; I felt like I was losing my mind. When we were down to four or five people, we had a few sprints where it was just me and one or two other engineers due to vacations and holidays. During a two-week sprint with four or five engineers, we completed 25 - 30 stor

Apr 17, 2025 - 14:26

How Big Should Your Engineering Team Be?

Have you ever been on a team where it seemed like it took forever to get anything done? You had constant status meetings and could never seem to get a handle on what was being done. It's not an unusual situation, and it can have a variety of causes. How big was the team? Was it six or seven people? Maybe more? That could have been your problem.

I was recently asked to propose a solution to reimagine an existing system. The system should use all the same data and database tables, but the rest of the application could be reimagined. The goal was to be able to deliver an MVP as soon as possible. I had to include the technical aspects and what the team of engineers should look like. The stakeholder wanted the MVP delivered in a month, maybe six weeks, and assured me that there were plenty of engineers available, so whatever it took to get the MVP delivered was fine. He told me he had 10 to 15 engineers he could assign to this easily if we could deliver the MVP in under 6 weeks.

I proposed a team of five engineers, and he was surprised at how few I wanted.

The Mythical Man-Month

The Mythical Man-Month: Essays on Software Engineering by Fred Brooks was published in 1975 and contains many ideas and lessons that still apply today. The idea that I reference most, and which was at play in my recommendation for a small team, was the mythical man-month.

There is an analogy or idiom I've heard that illustrates the mythical man-month concept well, even if it doesn't go into the reasoning from the book: "Nine women can't make a baby in a month." A pregnancy is about 9 months long, and the baby is growing and developing, which is not something you can divide among multiple people. The pregnancy will take roughly the same length of time, no matter what.

Unlike a pregnancy, developing software can be divided between multiple people, but can't be perfectly divided into discrete, self-contained tasks without dependencies. There will be dependencies between tasks and the people doing the work. People will have to communicate and coordinate their work.
Communication and task coordination are major limiting factors for development teams. When you have two people, there is only one line of communication between them. If you have a team of three, there are three lines of communication. If you have a team of 10 people, there are 45 lines of communication.

The formula for the lines of communication between people in a group is n(n-1)/2, where n is the number of people. If you really want to get into the math, this creates a polynomial growth curve.

The Work Matters

Regardless of the number of lines of communication, the kind of work you're doing matters when it comes to team size and scaling, and what can get done. When you can eliminate dependencies between people and tasks, you find opportunities to be more efficient.
If your large team owns multiple microservices, for example, dividing the team between the microservices for the current sprint helps reduce the number of lines of communication. The same idea applies if you have 100 engineers migrating 20 microservices from Java to Go, for example. If you assign five people to each microservice, you have drastically reduced the number of lines of communication by removing dependencies outside those groups of five. In both these examples, you effectively created smaller teams.

Suppose your team needs to create a lot of data models in your codebase, for example. In that case, you can often effectively split that across a large team if you properly plan for dependencies and relationships. The fewer dependencies and relationships, the easier the work will be with a large number of engineers.

That's the key: Reducing the dependencies between work can enable you to leverage a larger team effectively. It's not always a great idea, but it's an option if you have no choice.

Can I Speed Up My Project with More People?

Probably not. One of the key points in The Mythical Man-Month about the mythical man-month is what has been coined as Brooks' law: "Adding manpower to a late software project makes it later." Getting new people up to speed on the work will require coordination and communication, which will be affected by that growth curve from earlier.

If the work is well enough defined, there are few enough dependencies, and the new people need very little context, you might be able to add people and speed up the project. But that is a lot of "maybes" and "ifs."

Small Teams Are Fast

Several years ago, I led a team that fluctuated in size from four to seven engineers. When the team had seven engineers, it took a lot of mental effort to keep everything coordinated and moving forward; I felt like I was losing my mind. When we were down to four or five people, we had a few sprints where it was just me and one or two other engineers due to vacations and holidays. During a two-week sprint with four or five engineers, we completed 25 - 30 story points. When it was just me and two other engineers, we completed over 30 story points. Our last sprint that year was just me and one other engineer, and we completed just under 50 story points! This was the same kind of work we had been doing, but we reduced the necessary communication and coordination and produced amazing results! Sometimes, shrinking your teams is the answer.

Amazon and other companies are well known for using the "two pizza team" concept, the idea being that you should be able to feed the entire team with two large pizzas. According to this concept, Amazon says teams should be less than 10 people. I think teams need to be eight people or fewer, including leads, BAs, POs, or whatever. If someone is allocated 50% or more to the team, they count. For me, the sweet spot is around 4 to 5 engineers per team, including the lead.

Scaling Software Engineering is Different

There are so many industries and disciplines where adding resources enables scaling. That's even the case with most systems we deploy, but not with our engineering teams. Many people think of software development as solitary work, like being a machine on an assembly line, but that's not the case. Software development is knowledge work, and there may be similar concepts and approaches across different projects and products. Still, they aren't the same, and there needs to be a lot of coordination.

Keep your teams small, and communication and coordination are easier. Look for places to divide work and eliminate dependencies. Don't try to speed up a project by adding a bunch of developers to it; it won't work.