Scalability Audit
A load-and-flow read of whether your operating model carries the growth you're planning - the one constraint that caps throughput today, and where the flow jams first as you double.
Our scalability audit tells you whether your operating model carries the growth you're planning, or buckles under it. We look at six things: how work flows through the core delivery model, the one constraint that caps throughput today, the people the model can't run without, whether your systems and data are wired to grow, whether decision rights keep pace as layers are added, and how much headroom you have to the ceiling. Then we name the load-bearing constraint - the bottleneck that jams first as volume climbs - and what to shore up before the growth makes it expensive.
Scale doesn't break an organisation evenly. It finds the single weakest handoff and pushes until that gives. So we pressure-test the model against a specific volume scenario rather than scoring generic maturity: at double the caseload, where does the flow jam first, and does the cost-to-serve improve or worsen as you add load.
Around 50% of growing organisations restructure within two years (Bain). Growth reliably outruns the operating model that got you here - a scalability audit finds where yours will strain before a reactive restructure becomes the only option.
When a scalability audit helps
A scalability audit earns its place when you're about to add load - headcount, volume, sites, funding - and you need to know what carries and what buckles before you commit:
The situation | How it helps |
|---|---|
You're planning to grow, fast | Stress-tests the operating model against the growth you're planning, so you scale on foundations that hold rather than ones you'll have to rebuild mid-flight. |
Delivery already strains at today's volume | Names the load-bearing constraint capping throughput now, so you lift the real ceiling instead of adding effort everywhere. |
Everything routes through one or two people | Maps the key-person dependencies the model can't run without, so growth doesn't stall the moment the founder or lead steps back. |
New funding or a new contract is about to land | Reads whether you can absorb the step-up in load without the flow jamming, before the commitment is signed. |
You're held together by spreadsheets and re-keying | Shows where manual workarounds will break at volume, so you fix the wiring before it becomes the bottleneck. |
Growth is making you more expensive, not less | Reads how cost-to-serve moves as you add load, so growth improves your unit economics rather than eroding them. |
What we look at
We read your operating model the way load will actually test it - through six angles that decide whether it carries tomorrow's volume or jams under it:
- Process architecture and handoffs - how work flows through the core delivery model, and which handoff jams first as volume climbs.
- Breakpoints and bottlenecks - the load-bearing constraint that caps throughput today, before anything else does.
- Key-person dependencies - the single points of failure the model can't run without when the founder or lead steps back.
- Systems and data fit for load - whether the tooling and data are wired to grow, or held together by spreadsheets and re-keying.
- Decision rights and governance - whether authority and sign-off keep pace as layers and volume are added, or become the queue.
- Capacity headroom and unit economics - how much slack you have to the ceiling, and whether cost-to-serve improves or worsens as you scale.
The six angles stay constant; how we read them, we shape around you - your delivery model, growth plan, systems, roles and funding - so the picture fits your organisation, not a template.
Why these six angles
These six are where an operating model tends to give way under load, in the order load finds them. Process architecture is where volume first shows: a flow that runs fine at today's caseload can jam at a single handoff the moment throughput doubles. Breakpoints is the master signal - every model has one constraint that caps throughput before the others, and naming it is worth more than tidying the rest, because lifting anything but the real bottleneck buys you nothing.
Key-person dependencies decide whether growth survives the people who carried it here - the work that only runs because one person holds it in their head is the failure point that scale exposes fastest. Systems and data fit for load is whether the wiring grows or snaps: spreadsheets and re-keying hold at small volume and become the bottleneck at large. Decision rights and governance is the quiet one - as layers are added, the sign-off that was fast in a small team turns into the queue everything waits behind.
And capacity headroom with unit economics is the reading that reframes the rest: how much slack you have to the ceiling, and whether adding load makes each unit cheaper to serve or more expensive. These six are our lens, anchored to load and growth rather than steady-state tidiness - the question is never whether a process is good, but whether it survives doubling.
How it works
We read the model under load rather than at rest - making the operating model visible, then stress-testing it against a modelled growth scenario so the findings hold up:
- We map it - a process and value-stream map of the core delivery flow, from request to done, with every handoff made visible - so we can see where work moves cleanly and where it queues.
- We measure it - we model a specific growth scenario - what happens at double the volume - and run a bottleneck and breakpoint analysis against it, naming the constraint that caps throughput and the point where the flow jams first. We surface a survey too, showing where friction and firefighting concentrate, and we show you the spread across teams, not just the average.
- We listen - cross-section interviews from the front line to leadership, tracing real work through the model - what actually happened when volume last spiked, and where the load landed. We map the key-person dependencies and single points of failure the org runs on but rarely names.
- We notice - time spent watching the actual flow run, so we read how work moves in practice, not how the process diagram says it should.
The thinking behind the method
No single method shows how a model behaves under load, so we use several and cross-check them. A map shows the flow but not where it strains; a growth scenario shows where it strains but not why; interviews reach the why, but only from the people in the room; watching the flow run shows what people actually do rather than what the diagram claims. A finding has to show up in more than one before we treat it as real.
The stress test is the heart of it. Scoring a model at rest tells you it looks tidy today; it says nothing about whether it carries tomorrow's volume. So we model a concrete scenario - at double the caseload, this handoff is where it jams - because a specific number turns an abstract worry into a precise constraint you can act on. Premature scaling is what breaks growing organisations, and it breaks them at the point no one was watching.
We interview across a cross-section, front line to leadership, on purpose. The people who feel the breakpoint first are rarely the ones who set the growth plan, and the gap between those two views is often the most useful thing we find. And we map key-person dependencies explicitly, because the work that only runs because one person holds it is invisible on any org chart and is exactly what scale exposes.
We show you the spread, not the average, because a model doesn't strain evenly - the team already at its ceiling is the one that jams first, and it disappears the moment you average it against the teams with slack.
What you get
A working session, not a report filed and forgotten. We walk you through:
- The load-bearing constraint - the one bottleneck that caps your throughput, named plainly.
- Where the flow jams first at 2x - the handoff and the key-person dependencies that don't survive the growth.
- What's already fit for load - the parts of the model worth building on, not just what buckles.
- The handful of moves that add the most headroom - what to shore up before growth makes it expensive.
Where two things are both true and pulling against each other - "we need to grow fast" and "the model that got us here only runs because two people never stop" - we show you both. That tension is usually where the useful conversation about scaling starts.
How we hand it back - and what happens next
The audit ends in a working session, not a document dropped in your inbox. We take you through the flow map, the stress-test scenario and the load-bearing constraint in person, so it lands as something you can act on rather than a report read once and filed.
Some of the most useful findings come as pairs - the pull between the growth you're planning and the model that can carry it. We name those tensions rather than smoothing them into one tidy message, because the tension is where the real scaling decision sits.
From there it's your call. Sometimes the picture is enough and you build the headroom yourselves. Sometimes you want us alongside for the work that follows - shoring up the constraint, or a fuller scaling-operations programme. And if what you need turns out to be lighter than you feared, we'll say so.
Focused now, or continuous over time
This is a focused, one-off deep read of whether your operating model carries the growth ahead of you. If what you want is the whole organisation tracked continuously - operational load as one thread among eight - that's States of Vitality, our organisational-health platform. Different job: depth on the growth question now, versus the wider picture over time.
Common questions
How is this different from a process improvement review?
A process review asks whether today's flow is efficient. A scalability audit asks whether it survives doubling. We don't optimise the steady state - we stress-test the model against a specific growth scenario, name the constraint that caps throughput, and show you where it jams first as load climbs. It's a read of tomorrow's capacity, not today's tidiness.
Who do you involve?
A cross-section, front line to leadership. The survey goes wide; we interview across levels and teams, and we spend time watching the actual flow run. The people who feel the breakpoint are rarely the ones who set the growth plan, so the gap between those two views - and the spread between teams - is where the value is.
How long does it take?
Usually weeks rather than months, but it depends on the size of your organisation and how complex the delivery model is. We build each audit around you, and agree the timeline when we scope it.
How much does it cost?
There's no standard price - we build each audit around you, so the cost reflects the size of your organisation, the scope, and the depth you need. We scope it with you and give you a clear figure before you commit.
Is it confidential?
Yes. Survey responses are anonymous, interviews are confidential, and we report in groups and patterns - the constraint and the flow, never in a way that identifies an individual.
We're not a start-up - is this still relevant?
Yes. Any organisation adding load - headcount, volume, sites, a new contract - hits breakpoints, whatever its age. The premature-scaling risk is a start-up headline, but the constraint that caps throughput and the key-person dependencies that don't survive growth sit in established organisations too. The audit finds where yours are before the growth makes them expensive.
Thinking about a scalability audit?
Tell us what's prompting it and what you want to understand, and we'll say whether it's the right move.