Hiring plans and budget, in the CFO's language

"We need six more engineers" is the weakest sentence available to you.

It's also the one most engineering leaders open with.

It's weak because it's a request for a resource with no attached claim about what the company gets in return, which means the only way to evaluate it is by trusting you and the only way to negotiate it is to cut the number.

Which is exactly what happens. You ask for six, you get three, and nobody learned anything about the actual trade.

The alternative is building it from outcomes, bottom up.

Now the conversation is about what the company buys rather than about how many people you'd like to have.

Build it backwards from outcomes

Start from what the business intends to do next year, in its own terms, and work backwards.

For each outcome: what has to be built or operated. Then what capability that requires, and what capacity.

Then, and only then, how many people that means, and how many of them you already have.

The output is a set of statements that read like this: "the enterprise push requires SSO, audit logging, and a compliance programme. That's roughly two engineers for three quarters plus a security-focused hire. Without it, the deals in that segment don't close."

Different conversation entirely. It's arguable, which is the whole point.

Somebody can respond that the enterprise push is being deprioritised, and now you're having a real discussion about the plan rather than about your appetite for headcount.

It also gives you a natural way to present options.

Here's the plan at full funding. Here's what happens at seventy percent. Here's what we'd drop.

A leader arriving with three funded scenarios is taken a great deal more seriously than one arriving with a single number and a defence of it.

The numbers people forget

Four of them.

Leaving them out is how a plan that looked reasonable in January produces a shortfall in September.

Ramp time. A senior engineer is not productive on the day they start. Assume roughly three months to meaningful contribution, and longer in a complex domain. A hire made in November contributes almost nothing to that fiscal year, which changes when you'd want to make it.

Attrition. Somewhere between 10 and 15 percent annually is normal for a healthy engineering org, and pretending it's zero means your growth plan is quietly a replacement plan. Plan the backfills explicitly, including the time to notice and hire.

Recruiting capacity. Every hire consumes engineering time: interviews, debriefs, onboarding. At a rough estimate, hiring one person costs somewhere around 40 hours of engineering time across the loop. Planning twenty hires means planning to spend a meaningful fraction of a team's year on hiring, and if you don't budget it, it comes out of delivery and everyone is confused about why the quarter slipped.

Manager capacity. Hiring twelve people into a structure with three managers means someone is going to have eleven reports, and the quality of everything downstream of that manager will fall. Growth in people requires growth in the layer that supports them, and that layer is slower to build.

Speak in unit costs

Finance thinks in cost per unit of something, and engineering rarely offers a unit, which is why the conversation defaults to headcount as the only visible number.

Some units that work: fully-loaded cost per engineer (salary plus everything else, which is usually 25 to 40 percent more than salary and is the number the CFO already has). Infrastructure cost per customer or per transaction, and its trend. Cost of the engineering organisation as a percentage of revenue, benchmarked against comparable companies at your stage.

That last one is worth knowing even when you don't use it, because your board almost certainly does.

The reason to bring these numbers yourself is that it changes what kind of person you are in the room. An engineering leader who arrives with the unit economics of their own function, unprompted, gets treated as a peer of the CFO rather than as a supplicant. It's the single most effective thing I know for raising the standing of an engineering leader with the exec team, and it costs an afternoon a quarter.

Contractors, agencies, and offshore, evaluated honestly

All three are legitimate and all three are consistently mis-sold, so evaluate them on the same terms as anything else.

Contractors are right for genuinely bounded work with a clear specification and a defined end: a migration, an integration, a spike in capacity for something well understood. They're wrong for core product work, because the knowledge leaves when they do, and core product work is largely accumulated knowledge.

Agencies are right when you need a whole capability you don't have and won't build, on a timeline where hiring won't get there. They cost two to three times a salaried engineer for a reason, and the reason isn't margin alone: you're buying the ability to start now and stop later.

Distributed teams in other regions are right when you're building a real team there, with real ownership, real seniority, and a real career path. They're wrong as an arbitrage play on hourly cost, where you own the specification and they own the typing. That arrangement fails predictably: the coordination overhead eats the savings, the specification is never complete enough, and the best people leave because the work has no judgment in it.

The honest cost comparison includes the coordination. A distributed team eight hours out of phase, on work requiring frequent judgment, has a real productivity cost that doesn't appear on the invoice. It's manageable with genuine ownership and asynchronous working. It's not manageable by pretending it's zero.

Defending the plan when the market turns

It will turn, and the plan will be cut, and how you handle it determines whether you're consulted next time.

Bring the cuts yourself, before you're asked. If the number needs to come down 30%, arrive with the version at 70% funding and what it costs the company. That's a very different position from having it done to you.

Cut whole things rather than trimming everything. An organisation with six initiatives at 70% funding delivers approximately nothing and everyone is stressed. Four initiatives fully funded and two stopped is worse politically and much better operationally, and you should say so plainly.

Protect the things that compound. Hiring can pause. Platform and developer experience investment cutting is a decision to be slower next year, and if that's the choice, make it explicit rather than letting it happen by attrition.

And be honest about what's being lost. A leader who accepts a 30% cut and promises the same output has told everyone, including themselves, something untrue. It always surfaces two quarters later, and it surfaces as your credibility rather than as the budget.