Skip to content
← All writing

How to justify engineering headcount: show what was turned away

· 5 min read · by Tan Gravam

How do you justify engineering headcount?

The short answer

To justify engineering headcount, show the work the organisation asked for and did not get, not how busy the team is. For the team you want to grow, give four numbers over two quarters: its honest capacity in FTE-months after support and unplanned work; what was committed against that and how it ended; the requests that were parked or declined for lack of capacity, each with who asked and the size the team gave; and what those requests were worth to the people who wanted them. Make the case for a specific team, usually a shared one, not a department. Say what a hire would not fix, when it would start to help, and what could be stopped instead.

"We are stretched thin" has never got anyone a hire. Every team says it, it cannot be checked, and the person holding the budget has heard it from four other managers this month. A headcount request is approved when it shows something the budget holder did not know: what the organisation asked for and did not get.

That evidence is not utilisation and it is not velocity. It is the list of work that was turned away, with the reasons.

Why the usual arguments fail

  • "Everyone is at 100%." Busy is not the same as short. A team can be fully occupied with work nobody would miss.
  • Velocity and ticket counts. They measure the team against itself. They say nothing about what the business is not getting.
  • A ratio from another company. "Industry standard is one platform engineer per eight developers" invites the reply that this is not that company.
  • Burnout. True and important, and it argues for doing less at least as well as it argues for hiring.

Each of these describes the team. A budget holder funds outcomes, so the case has to be made in outcomes that did not happen.

The four numbers that make the case

For the team you want to grow, over the last two quarters:

  1. Honest capacity. Gross FTE-months, minus keep-the-lights-on work and leave, minus the reserve unplanned work actually took. This is the team's line.
  2. What was committed against it, and how those commitments ended. A team that delivered what it promised is a team whose next figure will be believed.
  3. What was parked or declined for lack of capacity, with who asked, the size the team gave, and the date it was turned away. Only requests that were understood well enough to size count. A wish list does not.
  4. What those requests were worth, in the requester's own words from the time: the customer waiting, the cost carried, the date missed.

Put together they read as one sentence: "This team could promise nine FTE-months a quarter. Fourteen were asked for by work we agreed was worth doing. Here are the five that did not fit, who wanted them, and what each has cost since."

Which team, not how many people

Headcount requests are usually made for a department and should be made for a team. Capacity is short in a specific place. An organisation with spare capacity overall can have one shared team, often platform, data or security, that every plan runs through and that is asked for twice what it has. Walking each product line's requests down that team's capacity shows where the queue is. One hire there releases more work than three spread evenly.

Say what the hire would not fix

A case that claims everything gets doubted. Three things make it credible:

  • The delay. A hire approved today delivers in two quarters, after recruiting and ramp-up. Say which of the turned-away work would still matter then.
  • The alternative. Show what stopping something would release instead. If the answer to "what would you drop to do this without hiring?" is ready, the request reads as a choice, not a complaint.
  • The part that is not a capacity problem. If half of the declined requests were declined because they were unclear, more people will not help. Separate those out before someone else does.

The request, in one page

Request: two engineers for the data platform team.

The team's honest capacity is nine FTE-months a quarter after support and incidents. In Q2 and Q3 it committed to eight demands and delivered seven as committed.

In the same period, five requests sized at eleven FTE-months in total were parked or declined for capacity. Three are still wanted: the finance close automation (Finance, parked since April), usage-based billing data (Sales, declined in June), the churn model refresh (Customer Success, parked twice).

Without hiring, we could take one of them by stopping the reporting rebuild. With two engineers, productive from Q2 next year, all three fit.

Nothing in it is about how hard the team works.

You can only make this case if the nos were written down

The whole argument rests on the third number, and most organisations do not have it. Requests that did not fit were answered in a hallway, left in a backlog, or never answered. Six months later there is no list, only a memory that "we said no to a lot". A no recorded as a decision, with its reason and its date, is the evidence a headcount case is made of. Start keeping it two quarters before you need it.

If you use DeliverySheet

The product keeps the two sides of this argument and does not make it for you. Capacity is committed per team, with the figure the delivering team gave, and the Committed effort report adds up the FTE-months currently committed, by craft. Parking and declining a demand each require a written reason, and both stay in the record as their own lists. A parked demand also carries its review date. There is no headcount report and no utilisation figure, and nothing in the product is a number about a person.

I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.

Not ready for that? Play eight rounds of Request or topic? It takes two minutes and needs no sign-up.

More on capacity and what to measure

Read the overview: Capacity and what to measure →