My First 3 Headcount Requests Were Rejected: the 7-Step Business Case That Got 5 Approved

I lost three headcount requests in a row, and for a long time I thought the problem was the budget climate. It was not. Reading the three submissions side by side afterwards, they had the same defect: each one described how the team felt and asked for a person, and none of them told the approver what would break if they said no or what it would cost to solve the problem another way. The committee was not being obstructive. It was being asked to do analysis that I should have done. The next five requests used the method below and all five were approved, including one that was approved as a contractor instead, which I count as a success because it was the right answer.

Step 1: Find out who decides and what they optimise for

Before writing anything, establish two facts: who holds the authority to approve, and what that person or committee is actually measured on. These are different questions and the second one is the one managers skip. A finance lead optimising for cash conservation, a managing director optimising for margin percentage, a group function optimising for total headcount count, and a board optimising for risk will each accept a completely different argument for the same hire.

The practical consequence is concrete. If the constraint is cash, a contractor starting next month is easier to approve than a permanent hire, and phasing matters more than total cost. If the constraint is headcount count, which is common in groups with a regional parent, then the number of bodies is the binding limit and a more expensive senior hire may pass where two junior hires will not. If the constraint is margin percentage, you need to connect the role to revenue or to cost avoidance rather than to delivery speed. Ask directly. In my experience the question is answered honestly, and asking it signals that you understand the decision is a trade-off rather than an entitlement.

Step 2: State the constraint in delivery terms before mentioning a person

The first paragraph of the case should contain no job titles. It should describe the work that is not happening, in the language of commitments and dates. Compare two openings. The first: the platform team is overloaded and morale is suffering. The second: three of the eight commitments on the quarter roadmap have moved twice, code review now takes a median of eleven days against a target of two, and the two integrations promised to the sales team for January cannot start until the review queue clears.

The second version is harder to write and impossible to dismiss. It also survives the most dangerous question in the room, which is whether this is a prioritisation problem rather than a capacity problem. That question is often fair, and if you cannot answer it with specifics you deserve to lose. Doing the capacity arithmetic first is the groundwork here, and our method for engineering capacity planning is where I would start if those numbers do not exist yet. Avoid utilisation as your headline metric: to anyone outside engineering, ninety percent utilisation sounds like good management and invites the suggestion that it could be higher.

Step 3: Price the alternatives you are not asking for

This is the step that changed my results, and it feels counterproductive until you watch it work. Present four options honestly costed, including the one you want and the ones you do not. For the senior backend role we eventually filled, the table looked like this.

Notice that the recommended option loses on both cost and speed. Conceding that is the point. The permanent case is not a price argument, it is a horizon and retention argument: the work continues well past six months, the knowledge needs to stay in the company, and the role includes reviewing and mentoring, which a short engagement delivers poorly. Writing that out, with the contractor option costed fairly rather than strawmanned, is what persuaded a committee that had declined me three times. It also means that when I do argue for a contractor, which has happened since, that recommendation is believed immediately.

Step 4: Build the cost of the seat, not the salary

Bring the fully loaded year-one number, not the base salary, because the base salary is the figure that gets you a follow-up question you cannot answer well in the room. For the role above, base was SGD 132,000 and the cost of the seat was about SGD 175,000. The additions are unglamorous and each one is a question somebody would otherwise ask.

• Employer CPF contributions, where the hire is a citizen or permanent resident: 17 percent for employees aged 55 and below, but only on wages up to the prevailing ordinary wage ceiling, so the contribution does not scale linearly on a senior salary. For this role it added about SGD 15,000.
• Bonus or variable provision at the rate you actually pay rather than the target rate, which for us was one month, about SGD 11,000.
• Equipment, licences and per-seat tooling, around SGD 4,500 in year one. Small, routinely forgotten, and the omission that makes a committee wonder what else is missing.
• Amortised recruitment cost, whether an agency fee or loaded internal hours, which we carried at about SGD 12,000.
• For a foreign hire, the Employment Pass process, which under the COMPASS points framework carries a planning cost as well as a fee, because eligibility is assessed rather than guaranteed. Flag it as a schedule risk even when you expect to pass.

Volunteering this total feels like arguing against yourself and does the opposite. It tells the approver that you are not going to return in three months with costs you had not mentioned, which is the specific fear that makes committees defer rather than decide. If you want to sanity-check the compensation half of the figure before you present it, our salary calculator and the method in structuring developer compensation packages cover the market range, and the team cost calculator handles the multi-person version of the same arithmetic.

Step 5: Attach a measurable outcome and a kill condition

State what will be true if this works, by when, and what you will do if it is not. The outcome needs to be something already being measured, because a metric invented for the business case will not be trusted and often cannot be produced later. Ours was the review queue: median time to first review falling below ten days by the end of month four. If you do not have delivery measurements in place, engineering productivity metrics are the shortest route to numbers a committee will accept.

The kill condition is the part almost nobody volunteers, and it is the highest-leverage sentence in the document. Ours read: if the median has not fallen below ten days by the end of month four, we convert the role to a six-month contract and stop recruiting for the permanent position. The reason this works is that committees are less worried about a hire being unproductive than about permanence, because headcount is the hardest decision to reverse and each approval reduces their future flexibility. A kill condition hands some of that flexibility back, and it reframes your request as a testable proposal rather than advocacy. It also protects you: the condition you wrote is far gentler than the one that gets imposed if the hire underdelivers and nobody agreed in advance what would happen.

Step 6: Pre-brief whoever can veto it

A business case should never be seen for the first time in the meeting where it is decided. Walk it past finance, and past any peer whose budget or headcount allocation is affected, before submission. This is not politics so much as debugging: in both of the pre-briefs I have done, the figure that came back challenged was one I had not expected, and fixing it quietly beforehand is far cheaper than being corrected in front of the decision maker.

Pre-briefing also surfaces the competing request you did not know existed. Twice I have discovered that another function was asking for overlapping capacity in the same cycle, and in one of those cases we combined the requests and both got approved. Arriving in a meeting unaware that you are competing with a colleague is how two reasonable requests become two rejections.

Step 7: Write the one-page version and bring the appendix

Compress everything above onto a single page: the constraint in delivery terms, the four options with year-one costs and lead times, the recommendation with its concession, the outcome metric with its date, and the kill condition. Then keep the workings in an appendix you do not present unless challenged. The one-page discipline is not about brevity for its own sake. It forces you to decide which number carries the argument, and a case that cannot be compressed to a page usually has not identified that number yet.

Bring the appendix to the meeting regardless. The most common challenge is arithmetic, and being able to turn to the CPF treatment or the contractor rate assumption and answer in ten seconds does more for your credibility than the rest of the document combined. The worst outcome in a budget meeting is not rejection, it is being asked to come back with numbers, because the cycle will have moved on by then and you will be competing against fresher requests.

One final note on reading the result correctly. Of my five approvals, one was approved as a contractor rather than the permanent hire I recommended, and at the time it felt like a partial loss. It was not. The committee had read the alternatives table, agreed with the constraint and chosen a different option from the same analysis, which is exactly what a good business case makes possible. If your case is only a success when the committee picks your preferred option, you have written advocacy rather than analysis. The quality of the hire that followed was a separate exercise, and the screening side of that is covered in our guide to building a dedicated engineering team.

Frequently asked questions

Why do most engineering headcount requests get rejected?

Because they argue from the team’s experience rather than from the committee’s decision. The team is overloaded describes a feeling the approver cannot verify. Our utilisation is at ninety percent sounds like efficiency to anyone outside engineering. We need a senior backend engineer opens with the solution and never establishes the problem. None is false, and all three fail because they do not say what breaks if the answer is no, nor acknowledge that approving one request means declining another. A request that has not costed its alternatives is asking the committee to do that work, and committees reject rather than do it.

What belongs in the true cost of an engineering seat in Singapore?

Base salary is usually around three quarters. Add employer CPF where the hire is a citizen or permanent resident, at 17 percent for employees aged 55 and below on wages up to the prevailing ordinary wage ceiling, so it does not scale linearly on a senior salary. Add bonus provision at the rate you actually pay. Add equipment, licences and per-seat tooling, routinely several thousand dollars and routinely forgotten. Add amortised recruitment cost. For a foreign hire, add the Employment Pass process, which under COMPASS carries a planning cost because eligibility is assessed rather than guaranteed. Present the year-one total rather than the base.

What is a kill condition and why does it help the request?

A commitment stating what you will do if the hire does not produce the promised outcome, written before approval rather than negotiated afterwards. For example: if the review queue has not fallen below ten days by the end of month four, we convert the role to a six-month contract and stop recruiting permanently. It works because committees worry less about productivity than about permanence, headcount being the hardest decision to reverse. A kill condition returns some of that flexibility and reframes the request as a testable claim rather than lobbying.

Should I ask for the permanent hire or the contractor?

Whichever fits the work, and show that you tested both. A permanent hire is rarely cheapest in year one: in our comparison the contractor was materially cheaper over twelve months and available in about three weeks against ten to fourteen for a permanent hire. The permanent case is a horizon and retention argument, winning when the work outlasts the contract, the knowledge must stay in-house, and the role includes reviewing and mentoring. It loses on bounded projects with a definable end, and conceding that openly is what makes your recommendation credible when you do argue for permanence.

All figures in this article come from our own records across eight headcount requests over an eighteen-month period in Singapore, and are illustrative of one senior backend role rather than a market benchmark. Employer CPF rates and wage ceilings, and Employment Pass eligibility under the COMPASS framework, change over time and should be verified against current official guidance before you present a case.