I Approved 6 Engineering Hires We Did Not Need: the 7-Step Headcount Plan I Use in Dubai Now

Six requisitions, one financial year, all approved by me. Two of them were the best decisions I made that year. Four of them produced capacity we did not have work for, in roles we had to reshape within two quarters, and one of those people left inside a year because the job he was sold was not the job that existed. Nobody was incompetent. The problem was that we had a hiring budget and no headcount plan, and those are not the same object. This is the method I use now, seven steps, written for the Dubai market specifically because lead times and cost structure here behave differently from the places most planning advice is written for.

Step 1: Write Down the Decision, Not the Number

Most headcount plans are built backwards. Someone decides the team should be eighteen people, and the spreadsheet is then assembled to support eighteen. You can tell when this has happened because the plan has no failure mode: there is no input you could change that would produce a different answer.

Start instead with one written sentence: which decision does this plan exist to make, and who signs it? The useful versions are specific. “How many engineers do we add in H1 and in which order, approved by the CFO in the November budget review.” Or: “Whether the payments workstream needs its own team or can be served by the platform team through Q2, approved by the CTO.”

Write the sentence at the top of the document. Everything that does not help answer it comes out. I have never run this exercise without deleting at least a third of what was in the previous version of the plan, and the deleted third is almost always benchmark data about what other companies of our size do, which feels like evidence and answers no question we were asked.

Step 2: Build the Demand Model From Committed Scope

Now convert the roadmap into engineering weeks. Three rules make this honest.

Only committed scope counts. Committed means somebody who can fund it has said it is happening and accepted a date. Everything else goes in a separate column called “candidate scope” and is explicitly not staffed. In my experience about a third of what a team calls committed turns out to fail this test, and finding that out in October is considerably cheaper than finding it out in June after you have hired against it.

Use delivered throughput, not estimates, as the conversion rate. Take the last two quarters. How many engineering weeks did the team actually have available, and what shipped? That ratio is your conversion rate, and it already contains your real overheads: the meetings, the context switching, the rework. Estimates do not contain those, which is why plans built on estimates are optimistic by a consistent and predictable margin.

Subtract non-project load before you compare. Support, incidents, security patching, dependency upgrades and interview time are real consumption of engineering weeks. Teams routinely plan as if capacity equals headcount times working weeks, and then wonder where twenty to thirty percent of the year went. Measure it for one quarter if you have never measured it. It is the single highest-value number in this whole exercise.

Step 3: Separate the Four Reasons to Add a Person

Every requested hire is one of exactly four things, and conflating them is what produced four of my six bad approvals. Each has a different urgency, a different approval test, and a different alternative that should be considered first.

Backfill is where the most money is quietly wasted, because it is the one nobody questions. Somebody leaves, the requisition reopens automatically with the same job description, and you rehire a role that was shaped by a person rather than designed by you. Half of my bad approvals were backfills that should have been reshaped: two of them because the departing person had accumulated responsibilities that belonged in two different roles, and one because the system that justified the role had been decommissioned eight months earlier and nobody had revisited the job description.

Bus-factor cover is the one most often refused and most often correct. It never looks urgent until the single maintainer resigns or goes on extended leave, at which point it is an incident rather than a hiring decision. If you are using it as a justification, name the system and name the person in the plan. If you cannot, it is not a bus-factor hire, it is a growth hire wearing a safety argument.

Step 4: Price the Loaded Cost in UAE Terms

A salary band is not a cost. If you are comparing an in-house hire against a vendor, a dedicated team or an employer-of-record arrangement, comparing salary against day rate will give you the wrong answer every time, because the two sides of that comparison contain different things.

The components that belong in a Dubai loaded cost:

• Gross salary, which is also take-home, since there is no personal income tax on employment income in the UAE. This is a genuine structural advantage when you are competing for candidates against higher gross figures elsewhere, and it belongs in your offer conversation as well as your model.
• Employment visa and medical processing, in the region of AED 5,000 to 8,000 per person, repeating on renewal.
• Health insurance, roughly AED 5,000 to 12,000 per person per year depending on the plan and whether dependants are covered.
• End-of-service gratuity accrual, at 21 days of pay per year of service for the first five years and 30 days per year thereafter. This accrues from day one and it is the line most plans omit entirely. It is not a cost that appears when someone leaves; it is a liability that builds every month they stay.
• Hardware, licences and tooling, which for an engineer with a full AI-assisted toolchain is no longer a rounding error.
• Recruitment cost, amortised over expected tenure rather than charged entirely to year one.

Build that number once, per level, and reuse it. If you have no defensible salary band to start from, that is the prerequisite rather than part of this exercise, and our guide to building a developer salary benchmark in Dubai covers it. If your levels themselves are undefined, building an engineering career ladder comes before both.

Step 5: Put Lead Time in the Calendar, Not the Spreadsheet

This is the step that fixes the most expensive and most common error in headcount planning: treating an approved requisition as if it were capacity. It is not. It is the start of a queue, and in this market the queue is long enough to cross a quarter boundary.

Work backwards from the date you need the capacity. For a mid-level engineer in Dubai:

1. Sourcing and screening: two to three weeks. Longer for scarce specialisations, and longer again if the job description still needs writing when the requisition opens.
2. Interviews and offer: one to two weeks if the loop is already designed and the interviewers are booked. Four weeks if you are designing the loop while running it, which is the normal case.
3. Notice period: commonly 30 days, frequently 60 for senior people already employed in the UAE. This is the part that is entirely outside your control and the part most plans ignore.
4. Visa processing and relocation: two to four weeks for a candidate joining from abroad. Fast by international standards, and not zero.
5. Ramp to meaningful productivity: four to eight weeks on an unfamiliar codebase, longer for anything with regulatory or domain depth.

That totals eight to twelve weeks to a start date and twelve to twenty weeks to real contribution. A requisition approved in January delivers useful capacity in April or May. If your plan has the January hire contributing to the Q1 commitment, the plan is wrong by a quarter before anyone does anything wrong.

Put these on an actual calendar, with dates, per role. A spreadsheet row that says “Q1” hides the problem. A calendar that says “requisition opens 12 January, realistic start 23 March, productive late April” makes it impossible to hide.

Step 6: Set Trigger and Kill Conditions Before Approval

A plan that approves six roles for the year will hire six roles, regardless of what happens, because once a role is in the approved plan nobody has the standing to question it. The fix is to attach two conditions to every planned role at approval time, agreed with the budget holder.

The trigger is the measurable condition that opens the requisition. Not a date. “Open the second platform engineer when reserved capacity utilisation exceeds 80 percent for three consecutive weeks.” “Open the third mobile engineer when the iOS release train has slipped twice for capacity reasons.” If a role has a date rather than a trigger, it will open on that date whether or not the need materialised.

The kill condition is the condition under which the role comes out of the plan without a renegotiation. “If the payments integration is descoped, this role is cancelled.” Writing it down in November, when nobody is emotionally attached to the role, is straightforward. Writing it in May, when a hiring manager has been promised a team, is a political event.

This is also the step that answers the question people actually want answered in a budget review, which is not “how many” but “what happens if we are wrong.” A plan with triggers and kill conditions is a plan that has an answer. In my experience it is also the thing that gets plans approved faster, because it transfers the risk conversation from the finance team to a set of conditions everyone has already agreed to.

Step 7: Reconcile Quarterly Against Delivered Scope

The plan is not finished when it is approved. Every quarter, put three numbers side by side: planned headcount, actual headcount, and scope actually delivered. Then, for each hire made, record one line on whether it changed the outcome.

This is uncomfortable and it is the step that makes the next plan credible. My four bad approvals were only visible as bad in retrospect, and they were only visible because we eventually started doing this. The pattern that emerged was specific and would not have been guessable: our growth hires performed roughly as modelled, and our backfills were where the losses were concentrated, because we were rehiring role shapes rather than designing them. That finding changed our process permanently, and no amount of planning sophistication would have produced it. Only the reconciliation did.

Keep it short. Three numbers and a line per hire, once a quarter, in the same document as the plan. If the reconciliation becomes a deck, it will stop happening by the third quarter.

Three Mistakes That Cost Us the Most

Treating an approved requisition as capacity. It is the start of a twelve to twenty week queue. Every plan I have seen that assumed otherwise required mid-year replanning, and the replanning itself consumed senior engineering time that was already the scarce resource.

Reopening a backfill with the departing person’s job description. You are then hiring a role that was shaped by one individual’s accumulated history rather than designed for the work in front of you. Reshape before reposting. It costs an afternoon.

Comparing salary to day rate when deciding in-house versus a dedicated team. They contain different things. Compare loaded cost per delivered engineering week, over the period you actually need the capacity, and the answer frequently reverses. If the need has an end date in it, our guide to building an offshore development team from Dubai sets out when that is the cheaper structure, and hiring an engineering manager in Dubai covers the point at which coordination cost makes a manager the highest-return hire in the plan.

FAQ: Engineering Headcount Planning in Dubai

Notes on figures: gratuity accrual of 21 days of pay per year of service for the first five years and 30 days per year thereafter is the statutory position under the UAE Labour Law. Visa, medical and insurance ranges are indicative market figures for Dubai at the time of writing and vary by free zone, mainland jurisdiction, plan and dependants. Lead times, capacity deductions and the illustrative 64 percent availability figure reflect the roles we recruit for in this market and should be measured against your own data before being used in a budget. This article is general information about hiring and planning practice, not legal or financial advice.