There’s a popular saying among software engineers stating that 9 women can't make a baby in a month. In other words, there’s not a linear relation between the output of a tech team and the number of people coding.
This is often a debate that non-technical stakeholders (NT) will have with tech leaders (T).
NT: This is the most important thing for the company now. Every day we delay it we are losing money. Why there’s only 3 people working on it?
T: Well, adding more people to it won’t deliver it faster. In fact it might even delay the project. It’s going to take 4 weeks even if I double the team.
NT: I don’t get it. Is it a management problem? If you organize the team you can double the number of people working on it and deliver this faster, no?
T: (He has no good answer to give and capitulates, adding more people to the team and delivering in 6 weeks crunching the team)
This is a trap that every tech team must avoid. It may lead to a spiral of negative feedback that will decrease the energy of the team.
Here I try to break down this problem so technical leaders and product managers have the tools to discuss this issue with non-technical stakeholders. To properly discuss it we will also need to cover the topic of estimates, which will need another post. Therefore I will hint some aspects of estimation that are needed for this discussion without getting deep into it.
A proper discussion on the topic should break it into three main parts:
What are the assumptions contained in a deadline?
What’s the stage of the code base regarding the project?
Is it possible to add people down the road?
Before we start
This is an old discussion in software engineering. The seminal book on the topic was published in 1975 by Fred Brooks and is called The Mythical Man-Month: Essays on Software Engineering. This book is the origin of what is known as the Brooks’ law:
Adding manpower to a late software project makes it later
Therefore, if you want to get deeper into the topic go read the book. It is actually a series of essays that cover many topics on the management of complex systems, so I won’t reduce it to a single sentence.
The deadline
When you start something new, the first question you will be asked by stakeholders is “how long it is going to take?”. This is the start of every discussion regarding how many people will be allocated to a project1.
For a typical stakeholder, the thought goes like this: “this is a company’s priority and we can put everyone available in tech to accomplish it as fast as we can”. The tension begins with this assumption that it’s just a matter of adding more people.
But for software engineering, at every step of the project there is a limit of people that can work simultaneously on it. Adding more or less people will in fact delay the project. This is mind boggling for some people, but it is one of the hard truths of software engineering: for each step of the project there’s an optimal number of people that will deliver the output that the best velocity.
Here we get to the two main drivers of a deadline: how many people can work in parallel in a project and the pace at which they deliver. It is quite hard to determine the “optimal” number of people to be allocated to a project (I will get to this later), but you can observe what is happening once the work starts:
If you have less people than optimal, everyone will be working at full pace2 but there will be tasks in queue that could be done in parallel and are waiting
If you have more people than optimal, discussions on how to split the work will take long, merge conflicts will often emerge - people working on the same piece of code - and the average velocity of each developer will decrease, often this decrease is way bigger than the gain of having an extra person in the project, leading to Brooks’ law
So when communicating a deadline to a stakeholder, show that you have thought about maximizing the output and the number of people you allocated to the project is in fact what gives the fastest outcome. This shows that you are aligned to the interests of the company.
Moreover, show that, although you are doing your best effort to give a deadline, software projects have a statistical nature, there are uncertainties and risks that only shows up when you start - some new framework or library you have never used before, a collateral effect on another system that you haven’t predicted, etc. There’s a post from Erik Bernhardsson that does a great job at showing this:
I suspect devs are actually decent at estimating the median time to complete a task. Planning is hard because they suck at the average.
Summarizing, when communicating the deadline you need to be clear about the statistical nature of it - a good way of doing it is giving a best case scenario and a worst case scenario - and you need to be clear that you are allocating to the project the maximum number of people you can3.
The follow-up question here will probably be: “how do you know this is the best you can do?”.
The orthogonality of the code base
Here we arrive at the concept of orthogonality:
In software engineering, a system is considered orthogonal if changing one of its components changes the state of that component only.
This is probably the trickiest point to communicate to non-technical stakeholders. Because it comes down to the practice of writing code that most of them have never experienced before.
But this is something similar to what everyone has experienced in their managerial lives. Programming is about decision making, every line of code you write is a decision you are making on the steps the computer will follow to solve a problem. Orthogonality is about making those decisions as autonomous as possible, so the developer can move faster. Bringing more people to a project means breaking the problem into smaller parts and people will to agree on decisions more often - and every manager knows that this kind of agreement, although necessary, slows down the decision making. The more people you bring the worse the communication between them gets.
Of course, the number of people you can bring to the project depends on the stage of the code base and the kind of project. There are two extremes of it, most projects sit in between:
A project that is a collection of new features built on top of a mature, well designed system
A project that builds a new “core” to the code base, something that is completely new and will add to the inner layers of the infrastructure (a new table in database, a new domain)
In extreme 1 often the deadline has lower variability and orthogonality is better, so you can bring more people to the project. Building new things that do not change the concepts of the software (ex. changing the layout of a screen, adding a new field to a form, collecting data from several systems to an endpoint) on top of a mature code base4.
In extreme 2 there’s essentially no orthogonality and you can bring less people to the project (often 2). Since it’s a new piece of code, no contracts are established and every decision made affects everything the other people involved in the project do.
The problem is that, more often than not we are closer to extreme 2. And it is frustrating to justify that you are allocating 2 in a team of 15 to the most important project of the company. What to do then?
Adding more people as the project advances
This is where the agile concepts come to help. We need to break the delivery into smaller stages and at each stage we need to have clear progress. Sometimes the progress is indeed a working prototype version of a feature, but sometimes it doesn’t need to be so. It can simply be a milestone in the project that will allow you to add more people to it.
For instance, if you have a project that needs to add a new table to a database and build a whole new subsystem, a first stage would be to build the core system - basic contracts, table migration, first endpoints - after which more people can work on the project, for example, each one building an endpoint in parallel.
Notice that software architecture is crucial here. You need to build the software at the core with the mindset that more people will be brought to write it with you. Sometimes this is an overhead at the start and it is fair not to use it in test prototypes. But for systems that take longer to build - and should live longer to worth it - it is important to use this approach.
The transparency that more people will get into the project as it matures also illustrated the exponential nature of complex systems like software. Slow at the beginning, exponentially faster as it matures. This is what stakeholders are looking after, isn’t it?
Conclusion
So, whenever you are asked to move a project faster, here is how you should approach the discussion:
Make it clear that you are allocating the most people you can to a project
Explain why you cannot allocate more people to the project now because of communication issues
Split the project in stages and commit that, at it stage, it will be possible to add more people to it so we can deliver faster
In this post I use the term “project” and not “product” ou “feature” because it exemplifies better what I am talking about. A project is a clear deliverable that takes a certain amount of time to build. It can be a feature requested by stakeholders in a feature-driven team or an epic or the launch of a prototype in a product-driven team. I make no distinction here since the problems are quite similar.
I will abstract the pace of a developer here, there are a number of factors that affect it. So whenever I say “pace” or “velocity” I mean an average, abstract, way of thinking about it. The variability of it in fact makes it deadlines super hard to define but for the external communication standpoint it does not add much since it is contained in the statistical approach I mention later.
A side note: as I discussed before, you need to also take into account the diversity of the team and try to allocate the best team for a specific project. There are people that do best at high pressure, fast prototyping and others that do best in long-term scalable projects.
I assume that the software is relatively well designed so that side-effects are isolated