Most agency owners have run both versions of the same problem inside a single year. In spring the team is over capacity: deadlines slip a few days at a time, quality quietly drops, and your project managers spend more time renegotiating dates than running work. By autumn it’s the opposite — two developers with nothing booked, a pipeline that went quiet in August, and every idle day landing straight on the margin.
Both come from the same mistake, and it’s the one agency capacity planning usually gets wrong: capacity gets measured as headcount rather than as deliverable work. A twelve-person agency doesn’t have twelve people’s worth of sellable time. Some of it goes to sales support, project management, internal meetings, recruitment and chasing client feedback. Some belongs to people whose skills don’t match the work in front of you. Some has to be left unused on purpose.
The number you can actually sell is materially lower than the number in your employment contracts. The useful part is that the gap is knowable, and once you can calculate it you can stop discovering your capacity problems after they’ve already cost you something.
A product team knows roughly what it’s building next quarter and who’s building it. An agency’s demand arrives from other people’s decisions, and that breaks four assumptions the ordinary planning model depends on.
Demand arrives in waves, not in a line. A client pauses for a fortnight while their legal team reviews something. Another decides in the same week that a launch needs to move forward by three weeks. You don’t control when work starts and you don’t control when it stops, and the deadline you’re now defending belongs to someone else. A plan built on steady throughput is wrong within a month of being written.
Skill availability matters more than headcount. Two hundred unallocated development hours next month sounds comfortable until the incoming project needs a senior Laravel developer and all two hundred belong to front-end specialists. The aggregate says you’re at 70%. The one person you actually need is at 100%, and spare capacity elsewhere doesn’t change that.
People aren’t interchangeable units, and this is where most spreadsheets quietly fail. Two junior developers don’t add up to one senior on work that turns on judgement — which architecture to choose, which edge case matters, when to tell a client that a requirement doesn’t make sense. Adding people to work that’s already behind frequently makes it slower, because the new person consumes explanation, review and coordination from exactly the people who were already the bottleneck.
Non-billable time is always larger than anyone estimates. Internal meetings, project management, discovery workshops, recruitment interviews, training, technical leadership, client reporting, chasing approvals. Individually each looks manageable. Collectively they remove a serious share of what you thought you could sell — and the pitch that consumed two developer-weeks and didn’t convert was capacity too, even though it never appeared in anyone’s plan.
Most estimates describe building the thing. Building is the cheap part.
The pattern that shows up in almost every project is that the first 80% of the work consumes something like 20% of the effort, and the final 20% consumes the rest. Software people have had a name for this since the 1980s: Tom Cargill’s ninety-ninety rule — the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90%. It’s a joke that has survived forty years because it keeps being true.
Development usually isn’t the hard bit. The hard bit is what comes after: testing, absorbing feedback, implementing it, and the long tail of small things standing between working software and software a client will actually sign off. If you estimated the build and staffed against that estimate, you’ve sized your team for the easy 80%.
The calendar stretches at the same point, for a different reason. A change that takes a developer two days becomes a two-week calendar event — the work is finished on Tuesday, the client reviews it the following Monday, revisions take half a day, the next approval takes another five. No individual step is unreasonable and nobody is being slow. The project is simply three weeks further from done than the estimate said.
That waiting time isn’t recoverable capacity either. You can’t cleanly reassign a developer for six days and get them back on the same problem — they’ll spend the first half-day reloading context they had complete the week before. Approval latency doesn’t just stretch the calendar, it fragments the hours you thought it had freed up.
Go back through your last three completed projects and separate the two numbers: time spent building and time spent waiting. Most agencies have never looked. The second figure is usually larger than anyone expects.
Utilisation is a blunt instrument, but it’s the most useful single number you have. The bands most agencies work to are 75% to 85% for billable production staff, 60% to 75% for account management, and 40% to 60% for leadership. Sustained utilisation above 85% for production staff is a warning rather than an achievement — it’s the range where people stop taking holiday, quietly work evenings and start looking.
Be careful comparing your agency-wide figure against those bands. A whole-agency average will always sit below the production number, because leadership, account management and support pull the mean down. Benchmarking the two against each other will flatter you every time. If you want an external reference point rather than a guess, The Wow Company’s BenchPress survey has been benchmarking UK agencies annually for fourteen years.
Track it per person and per skill, not as a team average. An agency sitting at 78% overall can comfortably contain one developer at 98%, and that developer is usually the one the whole schedule depends on.
The commoner mistake is treating the top of the band as a target. A developer at 100% utilisation has no room for an urgent fix, a scope change, technical debt, mentoring, or a client request that lands on Thursday afternoon. Those things still happen. They just happen after hours, and you’ve converted a planning problem into an attrition problem.
There’s a harder reason not to run hot, and it’s arithmetic rather than wellbeing. In any system where work arrives unpredictably and takes a variable time to finish — which describes every agency — waiting time doesn’t rise in a straight line as you get busier. It rises asymptotically. The relationship has been understood since Kingman’s work on queues in 1961: the utilisation term is ρ/(1−ρ), so as utilisation approaches 100%, waiting time grows without limit. Moving from 80% to 90% utilisation roughly doubles how long a piece of work waits before anyone picks it up. Moving from 90% to 95% doubles it again.
That’s why the difference between an agency that feels calm and one that feels like it’s drowning is often fifteen points of utilisation rather than fifty. The team at 95% isn’t working badly. The queue in front of them is simply an order of magnitude longer than the queue at 80%, and every new request joins the back of it.
The most useful number in agency capacity planning is the ratio between what you’ve committed to and what you can actually deliver. Divide committed demand hours by available capacity hours — available meaning after non-billable time and buffer, not the figure in the employment contracts.
| Coverage ratio | What it means |
|---|---|
| Below 0.75 | Spare capacity. The problem has moved to sales. |
| 0.75 to 0.90 | Healthy operating range. |
| Above 0.90 | At the ceiling. Every new commitment needs scrutiny. |
| Above 1.00 | Already overcommitted. The only questions left are what slips and who you tell. |
The thresholds aren’t arbitrary. 0.90 is roughly where the queue starts lengthening faster than you can absorb it, which is the same curve as the previous section.
What makes the ratio worth calculating is that it replaces a feeling with a number. “Does the team feel stretched?” gets answered differently by the person who’s stretched and the person who sold the work. “Are our commitments larger than our deliverable hours?” has one answer, and you can see it three weeks before anyone feels it.
This is where most articles on the subject stop. The arithmetic is the part worth doing.
Take a twelve-person agency: six developers, two designers, two project managers, two in leadership. We’ll model development capacity, because for most agencies that’s the constraint. Six developers — but not six of the same developer. Two seniors who own architecture and review everything, and four mid-level and junior developers who build to a specification.
Step one, gross hours. Twenty working days at eight hours is 160 hours a head, so 960 hours across the six. That’s the number in the employment contracts, and it’s the number most owners carry in their head.
Step two, non-billable time — and this is where treating developers as one pool starts to mislead. Seniors carry the review, the architecture calls, the mentoring and the pre-sales input, so their non-billable share is much higher than a junior’s. Fifteen per cent is realistic for the mid and junior developers. For the seniors, thirty-five is closer.
| Group | Gross hours | Non-billable | Available |
|---|---|---|---|
| 2 senior developers | 320 | -112 (35%) | 208 |
| 4 mid and junior developers | 640 | -96 (15%) | 544 |
| Total | 960 | -208 | 752 |
Step three, the buffer. Twenty per cent held back for scope changes, rush work and the client request that arrives on Thursday afternoon.
| Group | Available | Buffer (20%) | Sellable |
|---|---|---|---|
| 2 senior developers | 208 | -42 | 166 |
| 4 mid and junior developers | 544 | -109 | 435 |
| Total | 752 | -151 | 601 |
Six hundred and one sellable hours against 960 in the contracts. More than a third of the month was never available to sell — and none of it has been wasted. It went on review, planning, mentoring, and the slack that stops one disruption cascading into three.
Step four is the one that matters. Say next month’s committed work is 560 hours, of which 190 need a senior: the integration nobody else has done, the architecture decisions, and reviewing everything the other four produce.
| Measure | Committed | Sellable | Ratio |
|---|---|---|---|
| All development | 560 | 601 | 0.93 |
| Senior developers only | 190 | 166 | 1.14 |
The aggregate ratio says 0.93 — tight, manageable, worth watching. The senior line says 1.14, which means you’re already overcommitted on the only two people who can do that part of the work. Every spare junior hour in the building doesn’t change it.
Run this on your own team, and split it by whoever is genuinely scarce: the senior Laravel developer, the one person who knows the payments integration, the designer everyone queues for. The aggregate will almost always look healthier than the constraint underneath it. That’s precisely why agencies get surprised.
Owners resist holding capacity back deliberately, and the objection is always the same: we’re paying for those hours, so why aren’t we selling them?
The answer is the curve from earlier. A team planned to 100% has no absorption, so every disruption propagates — the urgent fix delays the feature, the feature delays the release, the release delays the next project’s start date. A buffer isn’t unsold capacity. It’s the thing that stops one bad week becoming a bad quarter.
Fifteen to twenty-five per cent is the usual range. Below that you’re relying on people absorbing the variance personally, which they will, right up until they leave. Agencies that look calm under pressure aren’t working harder than the ones that don’t. They’re running with margin, and the margin is why nothing cascades.
Annual capacity plans in an agency are wrong by February, because the inputs change weekly. An eight to twelve week rolling forecast, updated every Monday, is worth more than a detailed annual one nobody reopens.
Review the same inputs each time: confirmed projects, retainers, likely scope changes, upcoming renewals, and weighted pipeline — deals discounted by their real probability of closing rather than their optimistic one. The point isn’t prediction. It’s that hiring and partner conversations both have lead times, and you want the trigger to fire before the crunch instead of during it.
A forecast that’s slightly wrong and gets looked at every week beats one that was accurate in January and hasn’t been opened since.
Most capacity problems originate outside delivery. A prospect asks for a date, somebody in the room offers one, the work gets sold, and only afterwards does anyone check whether the specific people it needs are free that month. At that point capacity planning isn’t planning. It’s damage control.
The fix is unglamorous and structural: whoever commits the date has to be looking at the same coverage ratio as whoever has to hit it. That means sales, operations and delivery in one weekly conversation about capacity, working from real numbers rather than a general sense of how busy everyone seems.
It’s also the change most agencies resist longest, because it slows down saying yes. That’s rather the point.
If your coverage ratio sits above 0.90 for several weeks running — and especially if the constraint line is above 1.0 — you have three options, and they have very different lead times.
Declining work is instant. It costs revenue and sometimes a relationship, and it’s the only option that actually works when the problem is next week.
Hiring is right when the demand is structural rather than a spike, and it’s the slowest of the three. Search, notice period, onboarding and ramp-up routinely take three to six months before someone contributes at full rate, and you carry the cost throughout. Hiring for a three-month surge means carrying that person through the quiet quarter that follows it.
External capacity sits in between. A development partner can usually start within a week or two, which is quick enough for a defined block of work and far too slow for an emergency. It’s worth being straight about what it doesn’t solve: most partners, us included, aren’t set up to take a few hours of work at short notice from an agency they’ve never worked with. The sensible unit is around a month or more of defined work — a feature, a module, an integration — not a gap in next Thursday’s schedule.
Don’t reach for a partner when the capability is core to what you sell and you intend to sell it repeatedly; when nobody internally can review the work; when requirements are still undefined and you’re hoping someone else will define them; or when the overload has been constant for two quarters, which is a hiring problem wearing a capacity problem’s clothes.
If the shape is right — a defined block, a skill you don’t hold, a spike you can see the end of — that’s a conversation we’re glad to have.
For billable production staff, 75% to 85% is the healthy range. Account management usually sits at 60% to 75% and leadership at 40% to 60%. Sustained utilisation above 85% is a warning sign rather than an achievement. Track it per person and per skill — a team average of 78% can easily hide one developer at 98%.
Start from historical timesheets and calendars rather than an assumption. Include internal meetings, project management, sales support, discovery, training, reporting and chasing approvals. Deduct those hours before calculating what you can sell. Split the deduction by seniority — senior developers carry far more review, architecture and mentoring time than juniors, so a single flat percentage will mislead you.
An eight to twelve week rolling forecast, updated weekly, is more useful than annual planning. It gives enough visibility for hiring and partner decisions, both of which have lead times, while staying flexible enough to reflect changing schedules and client priorities. The value comes from reviewing it often, not from getting it exactly right.
Fifteen to twenty-five per cent, held back for scope changes, rush work and unplanned requests. Planning to 100% leaves nothing to absorb normal variability, so every disruption propagates into the projects behind it. Below fifteen per cent you’re relying on people absorbing the overflow personally, which works until it doesn’t.
It depends on whether the demand is a spike or structural. Hiring suits sustained growth but takes three to six months to pay off. External capacity starts in a week or two and suits a defined block of work of a month or more. Neither fixes an emergency next week — that one needs a date moved or work declined.
