There’s a common misconception from a management/executive standpoint that throwing more staff at a project or problem may increase the progress or throughput. Of course, most developers and other knowledge workers know this is definitely not the case, but it’s pretty hard to describe why – it just doesn’t work that way. I’m going to take a stab at explaining it in terms that everyone can relate to.
When a developer writes code, there’s a lot going on. There needs to be a pretty solid knowledge of the codebase they’re working in, how everything relates to one another, and how a small change in one file might have cascading effects on other parts of the program. In addition to that, we need to understand the problem we’re trying to solve, which usually requires a bit of domain knowledge in addition to all the software development skills we use. It’s a complicated and involved process.
Sitting down to write some code, you need to spend some time getting familiar with the codebase you’re about to change. If you’re the only person who’s ever written the code in the codebase, this is going to be relatively easy – even if you need to spend a few minutes to refresh your memory, it’s going to come back pretty quickly. Probably a negligible amount of time before you can be productive in your own codebase.
More People = More Complexity
Note: These are completely arbitrary numbers for example purposes, but the general idea holds true. I’d love to see some actual research & data on this.
Now imagine if you work with someone else, and they write roughly the same amount of code as you. Odds are it’s going to be pretty similar to how you write code, and you both are probably familiar with the same problem domain. So there won’t be a lot of figuring out to do, but there will be some additional work. Let’s say, for every hour of code you write, you have to spend 10 minutes getting familiar with your surroundings first.
Alright, there’s a new team member now, bringing your team up to three people. Assume everyone writes a pretty equal amount of code – that means 2/3 of the codebase is stuff that you haven’t written yourself. Every time you add a few feature or fix a bug, you now need to figure out what two other developers have wrote. Now you need to invest 20 minutes of time to research and investigation for every hour of code you write.
Team Size as a Tipping Point
You can see where I’m going with this. Eventually you’re going to be on a team of 8 people, and for sake of argument let’s say it all scales linearly. It now takes every one of your team members up to 70 minutes before they’re at a point where they can be completely productive. Those 7 people don’t all have to be developers either – every PM, QA, and staff member on your team adds complexity that you need to be aware of to be productive.
So no, you don’t get an immediate benefit from adding new people to a project. In fact, at a certain point you’re probably going to get a net loss – every team member you add to a project will increase the complexity of the project, and reduce the overall productivity of the team. This is one of the reasons that smaller teams can be just as (if not more) effective than larger teams. There’s some groups that say a team size of 5 is the “ideal” productivity point, and this example lines up with that.
How do you actually fix productivity issues? Small, clear, and measurable goals with small self-managed teams is a great start. Focus on goals & due dates, and let teams take ownership of features instead of assigning them work (more on this on a future blog post).