Hire People or Optimize Processes: A cost-benefit analysis for engineering leaders

Your engineering team is a lean, mean, feature-shipping machine. You have a happy and growing customer base. You’re taking customer requests but have a clear product direction. Things are hectic, but good hectic.

Then, the execs decide it’s time to scale. They’re asking your team to increase output by 20%, 50%, 2x, or 10x. And they give a budget of $x to do so.

Most engineering managers put that cash straight into recruiting and hiring. Their team has worked so hard to get this far, so instead of trying to push them to do more in less time, they’re going to double their output by doubling their headcount.

Managers who have experienced scale, however, are wary that growing a team can have diminishing marginal returns. They also know that the processes of their 7-person team aren’t going to work for a 20-person team or a 200-person team. The legwork to prepare for scale is significant so the decisions should be made carefully.

To help you make a well-calculated decision, we put together a cost-benefit analysis of scaling an engineering team, equipped with a spreadsheet Hire Or Optimize Calculator.

The hidden costs of hiring

When you’re working on an agile team, it always feels like you’re just one person short from getting everything done. It’s tempting to take advantage of the opportunity to bring on just one or two more folks to hit a 20% increase in output.

But just like every line of code adds technical debt, every butt-in-seat adds logistical complexity to your team. At the heart of the inefficiencies of scale is the non-linear growth of communication lines:

The complexity of the relationships between individuals grows exponentially with each added team member, which makes it harder for managers to:

• Communicate decisions to team members
• Give team members a voice or input into said decisions
• Execute on a process change (more on this later!)
• Gauge the effectiveness of said process change

Two-way communication between leaders and direct reports is integral to maintain alignment on the team and ensure people feel invested in the work. Without it, you’ll run into expensive problems like burnout, high turnover rate, and slow/inefficient incident recovery.

The measures typically introduced to adjust for scale usually take time away from actual engineering:

• More team meetings that ensure employees understand how their work fits into the larger picture (+30 min/week)
• More 1:1s that ensure employees get face time and opportunity for input with decision makers (+30 min/week)
• More documentation that ensures that information doesn’t get siloed with one person or team members (+15 min/week)
• More reporting that ensures that new changes are being implemented without direct supervision (+15 min/week)

If you added these processes overnight at an inflection point of hiring your 31st engineer, that’s 45 engineering hours lost a week– a loss that’s greater than the return you’re getting from a fully-onboarded engineer. This effect is often described by Brook’s Law: that adding manpower to a late software project will delay it.

Calculate your own cost of hiring

We built a model for you to estimate the costs and benefits associated with engineering hiring over time. Note that we made some simplifications, but as the saying goes, “all models are wrong, but some models are useful.”

The information you’ll need is:

• The # of engineers you’re looking to hire
• The # of engineering managers you’re looking to hire
• The average engineer salary at your organization
• The average manager salary

Inputting our own data, the monthly costs look something like this:

Our “Hire” Results from the Hire or Optimize Calculator. See Yours

While the benefit does, in fact, outweigh the cost, we’re looking at a 36% cost increase for a 26% productivity increase. Over time, here are the cumulative results we’d be looking at:

Our Cumulative “Hire” Results from the Hire or Optimize Calculator. See Yours

Before committing to such a hefty, upfront cost, consider making your existing processes as lean as possible first. For most managers, this opportunity is much greater than they realize.

Hidden cost of process optimization

There are two common misconceptions about process optimizations:

• That there are few associated costs, and
• Benefits are minimal, often to the point of being trivial

Neither is necessarily true.

Let’s say a manager joins an engineering team and is horrified to find barely any processes in place ensuring continuous delivery. The team calls itself agile, but in reality, everyone is working on an undefined number of projects, and almost no one sticks to the deadlines discussed during planning meetings. The manager might try to force a new structure, equipped with retros, burndown charts, and a more-structured code review process.

All of those changes are good in theory, but making them all at once will drastically affect performance, as team members adjust to the new constraints. If productivity stalls for too long, a manager might pull the plug on the whole overhaul, and get back to their disorganized, but frequent shipping schedule.

Big process changes require a re-onboarding of every existing team member, each of whom has already found and developed a working process that they believe to be efficient. You can expect your team to dip below its previous productivity level for anywhere from 3-12 months before seeing the effects of those changes.

To mitigate the risk associated with the process change, you can minimize the scope of each change. This “agile” approach to change management ensures that the workflow changes for your team members remain minimal and gives you the ability to roll back anything that isn’t effective without incurring too much loss.

This kind of process optimization can also lead to much more than marginal returns. Just like adding a couple of meetings a week can subtract the equivalence of the productivity of a full-time engineer, the reverse is also true.

If you make small optimizations for each team member, it can boost output significantly. A change that improves the individual output of each developer by just 1%, means a team of 10 will be working 185% faster by the end of just one year.

Calculate your own cost of optimization

Use the same model as above to see the relative costs and benefits from an optimization.

When our engineering department restructured our teams into smaller squads earlier this year, we were aiming for a 20% productivity increase. Here are the kind of costs and benefits we were projecting per month from this optimization:

Our “Optimize” Results from the Hire or Optimize Calculator. See Yours

Cumulatively, the gains quickly and drastically outpace the costs:

Our Cumulative “Optimize” Results from the Hire or Optimize Calculator. See Yours

While hiring means our monthly costs increased 36% for a 25% ongoing increase, here, our monthly costs increase 3% for a 20% ongoing productivity increase. These relative costs illustrate that it is always better to look for opportunities for optimization before hiring.

Engineering processes are invisible, so uncovering opportunities for improvement is rather difficult. This requires quantifying how fast your team is moving and learning the patterns of where work gets stuck along the pipeline.

An engineering analytics tool like Velocity can help you understand speed and work habits at a glance, or you can track simple metrics, such as Pull Requests Merged or Commit Volume yourself.

Optimize or hire?

Whether it’s better to (a)optimize or (b)optimize and then hire, depends on your desired outcome. You probably can’t 10x your output by optimizing alone, but before hiring, make sure you’ve taken every advantage of optimization that you can. As your team grows, any process improvement will become more lengthy and expensive.

Use the calculator to determine whether you can optimize for your desired output.