The Bench Problem: Staffing Engineers Between Agency Projects Without Bleeding Cash

Every agency owner has felt it. A senior engineer rolls off a project on Friday, the next engagement doesn't kick off for three weeks, and suddenly you're staring at a spreadsheet doing mental gymnastics about whether to fill the gap with internal work, discount the next deal to start early, or — the option nobody says out loud — quietly let someone go.

Bench time is the single most expensive thing in a services business that nobody puts on the invoice. This is how we think about it.

What Bench Time Actually Costs

Start with the math, because founders love to hand-wave this one.

If a mid-to-senior engineer costs you, fully loaded, somewhere in the range of $8k–$14k per month (salary, taxes, benefits, tooling, their share of overhead), then two weeks on the bench is roughly $4k–$7k of pure burn. Multiply by a team of ten and one bad month can wipe out a quarter of profit.

The trap is thinking of utilisation as a single number. It isn't.

• Billable utilisation: hours invoiced to a client / available hours
• Productive utilisation: hours spent on something valuable (billable, internal product, sales support, R&D that shipped) / available hours
• Chair utilisation: hours the person was technically working / available hours

Agencies that only track the first number panic and take bad work. Agencies that only track the third one lie to themselves. You want to optimise the middle one, and be honest about the gap between it and the first.

In our experience, a healthy delivery org runs billable utilisation between 65% and 80%. Above 85% sustained means you're burning people out and have no capacity to sell. Below 60% means you're either between growth phases or you have a pipeline problem you're not addressing.

Why the Bench Is Structural, Not a Failure

Here's the uncomfortable truth: you cannot run a healthy agency at 100% billable utilisation. Not for long. The math of project-based work guarantees gaps:

• Clients delay kickoffs by 1–4 weeks. Always.
• Discovery ends before build begins.
• A three-person team rarely rolls onto the next three-person project on the same day.
• Skills don't line up perfectly — your React specialist finishes while the next deal needs Go.

Founders who treat every idle hour as a mistake end up doing three destructive things: they discount to start projects early, they take work outside their strike zone, and they hire too slowly which caps growth.

Treat the bench as a line item, not an emergency.

A simple capacity model

We keep a rolling twelve-week capacity sheet. Nothing fancy — a spreadsheet or a lightweight tool like Float or Runn works. For each engineer, each week gets one of five states:

B  = booked (billable, signed SOW)
S  = soft-booked (verbal, contract pending)
I  = internal (product, R&D, tooling)
L  = learning / certification
O  = open (bench)

The rule: any week showing more than 30% O across the team, three weeks out, triggers a sales conversation. Any week showing more than 15% O, one week out, triggers an internal-work decision. Not a panic. A decision.

Four Honest Options When Someone Hits the Bench

When an engineer has open time next week, you actually only have four moves. Pretending you have more is how founders end up doing all of them badly.

1. Sell into the gap

The first instinct, and often the wrong one if you rush it. Selling into a two-week gap usually means one of:

• Discounting an existing pipeline deal to start early
• Taking a small fixed-price piece from a past client
• Sub-contracting to another agency

Sub-contracting is underrated. If you have a peer network — genuinely peer, not competitors you distrust — a two-week fill at 70% of your usual rate is far better than 0%. It also builds reciprocity for when they have overflow.

Discounting for early start is almost always a mistake. You anchor the client on a lower rate, and you rarely recover it.

2. Invest in internal product or tooling

This is where most agencies wave their hands about "building IP" and then produce nothing. It works only if you treat internal time like a client project: a brief, a deadline, a definition of done, and someone accountable.

Good uses of two-week bench slots we've seen:

• A reusable auth + billing starter kit for the stack you use most
• An internal CLI that scaffolds new project repos with your standards
• A client-facing status dashboard that reduces PM overhead
• A genuinely productised discovery deliverable template

Bad uses: "explore AI", "look at Rust", "clean up the wiki". These have zero exit criteria and produce zero output.

3. Direct at pre-sales and solutioning

Senior engineers on the bench are the highest-leverage pre-sales resource you have. A good solution architect drafting a proposal — with real estimates, real risks, a real architecture sketch — closes deals that generic sales decks lose.

We budget roughly 5–10% of senior engineering time to pre-sales even when fully utilised. When someone hits the bench, that number can jump to 40% for a week without anyone flinching.

4. Accept the cost

Sometimes the right answer is: they read, they rest, they pair with juniors, they catch up on the security backlog. Two weeks of genuine slack after a hard project is cheaper than replacing a burned-out staff engineer.

Agencies that never allow this option quietly become bad places to work.

The Hiring Question the Bench Forces

Bench time is a leading indicator. Read it correctly.

• Persistent bench in one skill area (say, mobile) → you're selling more web than mobile. Either kill the mobile offering or invest in selling it. Don't keep two idle iOS engineers hoping.
• Bench across seniorities → pipeline problem, not staffing problem. Hiring won't fix it.
• Bench only at senior level, juniors slammed → your project shape is wrong. You're selling implementation work that doesn't need the seniors you have. Rebalance either the sales motion or the org.
• Zero bench for three straight months → you're about to lose someone. Hire now, even if it means a month of intentional bench for the new person.

The last one is the counterintuitive move most agency owners get wrong. If you wait until you're desperate to hire, you hire badly, and the person lands into chaos. Hiring one engineer ahead of demand, with a deliberate 4–6 week onboarding on internal projects, is one of the highest-ROI decisions we make.

The 80% rule for new hires

We try to sign new engineers to internal or low-risk work for their first two to four weeks. Not because they can't do client work — because we want them to learn our standards, our review process, and our tooling before a client is watching. That's structural bench, and it's a feature.

Talking About It Honestly With the Team

Engineers know when they're on the bench. Pretending otherwise destroys trust.

What works:

• Naming it. "You're on internal next week — here's the brief."
• Being clear it's not a performance signal.
• Giving real work with real outcomes, not busywork.
• Sharing the utilisation numbers at a company level, quarterly.

What doesn't:

• Vague "catch up on things" instructions.
• Rotating people onto Slack-answering duty.
• Pretending an internal project is billable when it isn't.

The cultural cost of dishonest bench management is higher than the financial cost of the bench itself. Senior engineers leave agencies that feel arbitrary long before they leave agencies that are transparent about the business.

Where We'd Start

If you're running an agency and bench time keeps ambushing you, do three things this month:

1. Build the twelve-week capacity sheet, even if it's ugly. Update it every Monday.
2. Pick one internal project with a real brief and a real owner. Fund it explicitly from bench hours.
3. Set a target billable utilisation band (we like 70–78%) and stop optimising for the ceiling.

Bench time isn't a leak to plug. It's a cost of running a real services business — and if you plan for it, it's also where your next product, your next hire's onboarding, and your next big proposal come from.

If you want to compare notes on how we structure delivery teams, take a look at our engineering services or the rest of the blog.