Helen is the Head of Engineering at Axcell, a 100-person Travel Tech startup. Axcell’s founders have recently come up with a new product opportunity, for which there’s a lot of excitement in the marketplace, and want to have an MVP ready in six months.
Since Helen’s 12-person team is already busy with the current product, she would need to add 6 to 8 team members over the next six months to meet the founders’ deadline. Meanwhile, the founders have already pulled in the launch date by a full month, while adding some requirements. Helen has now five months to ship an MVP with even more features than initially expected, without impacting the current product.
Helen believes that the only way this is possible is by adding more capacity to the existing team, and quickly. She wants to say yes to this (the change would be meaningful to the business), but every bone in her body is screaming no (they’re taking a somewhat risky project and loading it up with a ton more risk).
What should Helen do?
Helen is right in her analysis of this project. To quote Frederick P. Brooks Jr., the author of The Mythical Man-Month: “adding manpower to a late software project, makes it later.” Even if Axcell has the budget to hire 6 to 8 team members, their real cost is not in the salary, but in their integration. As Will Larson writes in An Elegant Puzzle, “productively integrating large numbers of engineers [...] depends on how quickly you can ramp them up to self-sufficient productivity.”
First of all, there’s the hiring process. With the current tension in the software engineering’s job market, finding a suitable candidate usually takes several weeks, to which you should add the hiring process (41 days on average) and the notice period (up to 3 months in countries like France).
So, realistically speaking, there will be 3 to 6 months between the moment a job offer is out, and the new engineers are in the office. And this is just the beginning.
Let’s assume that to fast track the hiring process, Helen has decided to hire freelance engineers. Like full-time employees, these engineers would also need a substantial onboarding before becoming fully productive. During this onboarding process, new engineers would learn about the product, discover the codebase and the technologies used, and get their development environment ready to ship code in production.
If Axcell has exceptional onboarding and tooling, with a simple and easy to jump into system and codebase, then engineers can genuinely ramp up and contribute in under a month. But if most of Axcell’s engineering knowledge is verbally maintained, with many technical specificities, it could take more than three months for new engineers to become productive. Also, existing engineers would be spending time sharing knowledge and mentor the newcomers. Every time you bring on a new engineer, it slows down the people around them while they help the new person get up to speed. And obviously, a 6 to 8-person team would need to be managed, either by one existing engineering manager (impacting their current team), or hiring a new manager (with the same hiring challenges as for engineers).
In both scenarios (full-time hires and freelancers), there is no way Helen can realistically ship the new product in five months. There’s an alternative though. Instead of creating a whole new team to work on the new product, Helen could focus on making her existing team as productive as possible, while adding no more than 15% of the current team size (so two new engineers) to manage entropy.
As explained above, hiring isn’t predictable and has a significant productivity impact on existing team members (not mentioning culture). On the other hand, tasks, features and deployments are predictable.
There are essentially two ways to improve an engineering team’s productivity: lower input or increase throughput:
1/ Lowering input is pretty straightforward: the Product team stops writing requirements for new features, and engineers only fix the most impactful bugs. If Axcell works in 2-week sprints, existing engineers could become fully productive on the new product in less than one month.
2/ Increasing throughput is trickier, as you have to work the following measures to improve “developer velocity”:
- Delivery lead time (time from the creation of code to its use in production)
- Deployment frequency (how often you deploy code)
- Change fail rate (how frequently changes fail)
- Time to restore service (the time spent recovering from defects)
In my experience, every single engineering team is under-productive and can increase their throughput by 20 to 50%. Here is a non-exhaustive list of common productivity blockers:
- Imperfect knowledge management (engineers spend too much time understanding the codebase and asking questions)
- A constraint in the system slowing down everyone (a single manager approving all pull requests, too few QAs…)
- Too many dependencies (teams have to wait for each other)
- No CI/CD in place
If Helen manages to slow down input by 25%, while increasing throughput by 25%, that’s a 50% productivity gain (so around six engineers) to focus on the new product, without impacting existing operations too much, while maintaining culture.
Helen will also have to closely monitor the team’s morale as they will inevitably be doing some overtime with this scenario, and she wouldn’t want them burning out.