What is the ideal software development team size?
What is the ideal software development team size?
The answer is obvious: 42
I’ve advised a few heads of engineering over the years and the number one question I hear is on team sizing. Something along those lines:
“I have a team of 24 engineers and I am trying to figure out the optimum team size, can you help me?”
There’s obviously not a good answer, other than “it depends”, because it truly does.
The underlying motivation for asking this question isn’t really on trying to find if the answer is 3, 7 or 18. It ultimately comes down to trying to maximize the team’s throughput, I term dislike in this context but bare with me, by not over allocating resources to teams. Said otherwise, the VPE with 24 engineers might believe that having 12 teams of 2 would double her throughput over 6 teams of 4. That is obviously wrong, or at best highly dependent on the individuals and work they are tasked to do. Again, “it depends”
My approach to team sizing is highly contextual. I tend to differentiate between two distinct situations:risk and growth. Each situation tries to optimize for different outcomes and therefore each offers a different staffing model. Before diving into the staffing model for both of these situations, I want to share a few first principles that I default to.
First principles
Teams must be vertical. This implies that teams are responsible for developing a feature end to end. The team is not organized by the layers of the stack they operate on. They will operate on any layers of the technical stack that they need to in order to complete their work. Consequently, vertical teams will have all resources - backend engineers, frontend engineers, data engineers and so on - and skills needed to successfully complete their work. This in turn, eliminates any external dependencies.
Minimum team size is a pair. There are always exceptional situations where you might staff a project with only 1 engineer. Otherwise, the absolute minimum is a pair. There are two reasons for this: redundancy and pair programming.
Staffing to reduce risk
Staffing for a team about to undertake a new feature is always fraught with risk. I use the term new here to truly mean new, not incremental to an existing one, but new, novel with lots of unknowns. Therefore, what I try to optimize for here is to reduce the risk and uncertainty. Therefore, the maximum staff I will allocate to a team in this situation is the minimum resources needed to de-risk the project. My experience is that anywhere from 2-4 engineers are sufficient to staff a project that is fraught with unknowns. I default to a pair of pairs and no more.
It’s important to understand what minimizing risk actually means. It’s the point at which most unknowns have been discovered - you’ll never know all. The team you allocate to de-risking the project will tell you when they have uncovered enough unknowns to progress to active software development. More importantly, it’s the point at which more resources could be added to the team to accelerate development. The addition of more resources is obviously conditional on the nature of the work. If it’s highly parallelizable then more resources will accelerate development and the converse is true.
Therefore, the model I apply here is to start with the smallest number of pairs and then add more resources, dependent on parallelism and availability of resources, once the project has been sufficiently de-risked.
Staffing for growth and development
This is a scenario where you are optimizing for the growth and development of some, or all, individuals within the team. It usually arises when you are onboarding new hires, or moving individuals around from one team to another. The goal of a team operating under this scenario is not just to deliver software, but to invest in the growth and development of those new team members. This will come at the expense of “max throughput”, but is a necessary investment. The time that some of the more tenured team members invest with the newer ones will allow them to become productive, not to mention happier, quickly. This short term drop in productivity is offset by the long term benefits of taking care of your new team members.
The model I apply to staffing a team in this growth phase is to pair a new team member with a more tenured one. Most teams tend to be 2-3 pairs, hence the team size is usually between 4-6 developers. I’ve seen larger teams, but 6 tends to be the max, at least in my experience.
I mentioned earlier that the answer is “it depends” and it truly is. However, there’s probably going to be a normal distribution of software engineering team sizes. My experience shows that the mean is around 4 and standard deviation 2. Most of the my teams have been 4, some were 6 or 2, very few were 8 or less than 2.
Recent topics of interest
The collapse of SVB has obviously been all the rage recently.
offers a very well written note on how that happened and its implications. Must read IMHOIf you’re a Founder, CFO or just scrambling to create bank accounts now at your company, you might want to read this post by
first.My word of caution is that when something is rushed there are opportunities for mistakes to happen or for fraudsters to take advantage. Companies need to make sure:
Bank account structure follows best practices
Proper fraud controls are implemented
Cash management and planning is performed
