Adding Senior Capacity Without Adding Payroll

What a Senior Hire Actually Costs

Salary is the smallest visible part of the number. Add employment costs, which vary by country but always exist: taxes, insurance, leave, equipment, software seats. Add recruitment, whether that is a fee or weeks of your own time reading applications. Then add the ramp: the period before a competent senior is genuinely productive inside your codebase, your process and your client context.

Then there is the cost nobody puts in the model. Management. A senior needs work queued, decisions unblocked, output reviewed and direction reset when a client changes their mind. That time comes out of whoever currently sells, which means a hire intended to create capacity can consume some of it from the one person the agency cannot afford to slow down.

Sanity-check it against your own figures rather than a published benchmark. Take a fully loaded monthly cost for the role and compare it against the fee on a typical project in that discipline. If the role costs the equivalent of several such projects a year, that is the volume you must sustain every year before the hire contributes profit rather than consuming it. Then ask whether your pipeline in that discipline has ever delivered it.

Utilisation Is the Number That Decides

Utilisation is the share of someone's paid available hours that ends up billed to a client. In a service business carrying fixed salary costs, it is the hinge the whole model turns on, and it is the number most agency owners can feel but have never actually calculated.

Nobody is billable all of the time. Internal meetings, admin, sales support, holidays, training, and the gap between one project ending and the next starting all take from it. A realistic target sits well below full, and it differs by role: a delivery engineer runs closer to full than an account lead who spends part of every week in pre-sales. If your model assumes a new hire will be fully billable, the model is wrong before anyone starts.

The common failure is hiring for the peak. When demand is lumpy the peak is not the average, and you pay for the trough at precisely the moment revenue is lowest. Utilisation pressure also distorts judgement: an underused senior gets assigned work below their level, which is demoralising, or a project gets sold because someone is idle rather than because it is the right project.

What a Bench Actually Changes

A partner bench converts a fixed cost into a variable one. That is the entire mechanism, and everything else follows from it. You pay when work exists and stop when it does not, which makes a slow quarter uncomfortable rather than dangerous.

The second-order effects are often worth more than the first. You can say yes to categories you do not staff, which changes what you are allowed to pitch for. You can test whether a service line sells before committing a salary to it. You can quote to a deadline your in-house queue would never clear. And you stop declining briefs where the gap is a single skill rather than a whole team.

The costs are real and should be stated plainly. You pay more per hour than your marginal in-house hour. Coordination overhead is genuine work. And you depend on someone else's availability, which means booking earlier than you would with your own team and building the relationship before the week you urgently need it. A bench you first contact during a crisis is not a bench.

What to Keep In-House

Keep everything the client experiences as you. Strategy, the relationship, creative direction, project communication and final quality judgement are the agency. If those are delegated, you are not an agency with a partner, you are a reseller with a margin problem waiting to arrive.

Keep the work that repeats and defines your positioning. If most briefs need the same discipline and you can keep someone busy in it, that is a hire rather than a delegation, and doing it in-house compounds: your team gets faster at your specific kind of work in a way an external team never will.

Keep enough technical literacy in-house to evaluate work you did not do. Someone on your side has to be able to open a pull request, read a handover document and judge whether it is adequate. An agency that cannot review a delivery is buying blind, and will learn the quality of a partner only when it goes wrong in front of a client.

What to Delegate

Delegate against a simple test: is this skill deep, occasional, and outside what defines you. If the answer is yes on all three, a bench is almost always cheaper and faster than the alternative, and it does not commit you to a category you may not want in two years.

The pattern that works best is delegating whole vertical slices rather than tasks. Handing a partner a defined outcome with a working staging link at the end produces better results than distributing tickets, because responsibility for the result stays in one place and your time goes into reviewing rather than coordinating.

• Deep but occasional specialisms: WebGL and motion engineering, data pipelines, AI orchestration, native mobile.
• Overflow of work you can already do, when volume rather than capability is the constraint.
• Categories you are testing before committing headcount to them.
• Fixed-deadline work that would otherwise force you to reschedule an existing client.
• Anything where the honest alternative is declining the brief entirely.

Protecting the Client Relationship

Four rules cover almost every situation. Maintain a single point of contact in each direction. Put your brand on the artefacts, from repository to documentation. Have an NDA and a non-circumvention clause in the partner agreement before any client material moves. And build in a review step where someone from your team reads the work before the client sees it.

Do not hide anything that would embarrass you if it surfaced. Clients accept that agencies use specialist teams, because that is how the industry has always worked. What damages trust is a client discovering one for the first time during a dispute, which reframes a normal arrangement as a concealment.

Insist on documented handover on every engagement, including the small ones. Handover is what stops the client relationship depending on a partner's continued availability. If a partner becomes unavailable and your client's system is maintainable by anyone competent, that is an inconvenience. If it is not, it is your problem and your reputation.

Making the Switch Without a Big Bang

Start with one project on a narrow paid slice while your in-house queue continues untouched. Judge the result on communication and handover quality at least as much as on the code, because those decide whether the second project is easy. Clean code from an unresponsive partner is a worse outcome than good code from a partner who answers by lunchtime.

This is why we work pilot-first at Kronx: a scoping call, one narrow scoped slice, and a working staging link before any full contract exists. The structure is there so a first engagement is a small test rather than a bet, which is the only sensible way to begin a relationship where your client's opinion of you is at stake.

Build a second relationship before you need it, so a partner's busy month is not your crisis. And revisit the hire question when the evidence changes: three or four similar projects in a row with a real pipeline behind them is a different decision from one large win, and part of the point of a bench is to generate exactly that evidence.