← All articles

GTM Operations

The Systems That Got You to $10M Sabotage You at $30M

Your ops model does not scale linearly. It snaps at revenue breakpoints, and the failure signatures arrive on a schedule you can name a year ahead.

· 12 min read

The spreadsheet forecast that carried you from $2M to $10M does not gently degrade at $30M. It snaps. One quarter it is fine and the next the forecast is off by 20% and nobody can say why, because the model that worked was a model that fit in one person’s head, and at $30M the business no longer fits in one person’s head. Here is the assumption almost every operator makes and almost every operator is wrong about: that the ops model scales linearly, that what works at $10M works at $30M with more of it. It does not. Each order of magnitude of revenue is a different business wearing the same logo, and the systems keyed to the old magnitude do not stretch. They break.

The systems that got you here were correct for here. A manual forecast is right when you have 12 deals a quarter and one person knows all of them. It is catastrophically wrong when you have 200 deals and six reps, and the failure is not that the person got worse. It is that the approach hit its ceiling. Growth breakpoints are the ARR levels where a given approach stops fitting the business, and they arrive with specific signatures on a schedule you can predict.

Before the map, feel the scaling. Zoom through the revenue magnitudes and watch the ops load around a single constant reference: one ops person. The dot stays the same size; the field of deals, leads, and reps they answer for explodes around them. That explosion is why linear thinking betrays you.

Zoom the magnitudesOne ops person, an exploding field
seed$1M to $3M$2MA dozen deals a quarter, one queue, 30 CRM fields. Everything fits in one head and doing nothing is correct.

One ops resource stays constant. The field around it grows each level.

~$15M
Where the manual forecast starts drifting
1 : 50
Ops resources to reps before ops becomes the bottleneck
20%
Forecast miss when a breakpoint hits unmapped

The framework: four breakpoints, mapped to thresholds

The zoom shows why the strain is nonlinear. The framework tells you exactly where it lands. Each of these four systems fails at a predictable size, and they map one-to-one onto the magnitudes above. Watch for the signature, not the calendar.

L1, routing lag, around $10M to $20M. The symptom is leads taking hours to reach a rep and reps complaining about cold handoffs. The root cause is routing that was a manager eyeballing a queue and assigning by hand, which works at 30 leads a week and collapses at 300. The fix is rules-based automated routing with SLAs, treated as a latency problem. The tell is a Slack channel where someone asks “who’s got this lead,” because that question is a manual routing step that does not scale.

L2, forecast drift, around $15M to $25M. The symptom is a forecast that is directionally right for a year and then starts missing in ways nobody can explain. The root cause is that the manual, in-someone’s-head forecast has exceeded the number of deals a human can hold. The fix is a systematic forecast built on stage-weighted conversion and a daily pipeline snapshot, not a better guesser. If your forecast lives in a spreadsheet one person updates, this breakpoint is coming for you and you can name the quarter within a year.

L3, field bloat, around $20M to $40M. The symptom is reps filling out 6 of 47 required fields and a CRM full of nulls. The root cause is that every team that hit a wall added a required field to solve its reporting problem and nobody ever removed one. The CRM accretes fields the way a hull accretes barnacles. The fix is a required-field audit that ties every mandatory field to a decision someone makes, and deletes the rest. If you cannot name the decision a required field feeds, it is bloat.

L4, ops capacity, arriving continuously. The benchmark is roughly one ops resource per 50 reps. The symptom is your one ops person becoming a bottleneck on every report, every routing change, every deployment, and quietly becoming the single point of failure for the whole revenue engine. The root cause is headcount that scaled while ops did not. The fix is hiring ahead of the ratio, because ops is the system that lets everyone else scale, and starving it caps the whole business at the throughput of one overloaded person.

Here is the map on one page. Print it and mark where you are.

BreakpointFires aroundSymptomRoot causeThe fix
L1 Routing lag$10M to $20MLeads take hours, cold handoffsManager eyeballs a queueRules-based routing with SLAs
L2 Forecast drift$15M to $25MMisses nobody can explainForecast fits in one headStage-weighted, daily snapshot
L3 Field bloat$20M to $40M6 of 47 fields filled, nulls everywhereEvery team added a field, none removedRequired-field audit tied to decisions
L4 Ops capacityContinuousOne ops person is the bottleneckHeadcount scaled, ops did notHire ahead of 1:50

The breakpoints do not queue politely. They cluster, and the diagram shows how three of them land inside the same two-quarter window on a fast-growth trajectory.

The breakpoint map Failure signatures land on schedule, and they cluster
ARR$8M$15M$25M$40MRouting lagForecast driftField bloatops capacity pressure runs the whole way
Plotted against ARR. Routing lag arrives first, then forecast drift, then field bloat, with ops capacity pressure running underneath the whole line.

Why the cluster is arithmetic, not bad luck

The breakpoints cluster because they are all driven by the same underlying variables: deal count, lead volume, and headcount. Those variables move together because they are all functions of ARR. When revenue doubles, deals roughly double, leads roughly double, and headcount roughly doubles, so the systems keyed to each of those variables hit their ceilings inside the same window. That is why a company can feel fine for six quarters and then feel like the wheels came off in one. The wheels came off together, because the thing driving all of them crossed a threshold at once. This is the same nonlinearity the zoom above makes physical: the constant dot is your ops capacity, and the field exploding around it is deals times leads times reps, all compounding on the single variable of revenue.

Line the load up against the magnitudes and the schedule stops being mysterious.

MagnitudeDeals / qtrLeads / weekRepsOps ratioBreakpoints live
$2M~12~1581:8none
$10M~60~120401:40L1 approaching
$15M~90~180551:55L1, L2, L4 fire together
$30M~200~300651:65L3 arrives, L4 acute

A worked timeline

Take a company at $8M planning to hit $25M in two years. Map the breakpoints against the plan instead of discovering them in production.

At $8M the manual forecast is fine, routing is a manager’s queue, the CRM has 30 required fields, and one ops person covers 40 reps. Everything works. That is the trap: at $8M, doing nothing looks correct.

By $15M, on the current trajectory, three things fire at once. The forecast starts drifting because deal count crossed what one person can hold. Routing lags because lead volume tripled. And the ops person now covers 65 reps and is underwater. None of these announce themselves early. They all arrive in the same two-quarter window and the company feels like it hit a wall, when in truth it hit three walls it could have seen on the map.

The chart shows the divergence: two companies at the same $8M, one that builds one stage ahead and one that builds one stage behind.

Forecast accuracy when breakpoints hit unmapped
A company climbing from $8M that discovered breakpoints in production instead of building systems one stage early. The dip at $15M is the board-meeting miss.
View as table
PointValue
$8M92%
$12M88%
$15M72%
$20M80%
$25M86%

The company that mapped this built the systematic forecast at $13M before the drift started and automated routing at $11M before the lag, and it crossed $15M without a wall. The company that did not spent the $15M-to-$18M window in permanent firefight, and the cost was the quarter the forecast missed by 20% in front of the board. Understanding that the fires share one cause lets you stop treating each as a separate emergency and start treating them as one predictable event you can schedule around.

The other failure mode: building too early

There is a failure mode on the other side too, and it is worth naming so nobody overcorrects. The company that reads this and builds all four systems at $6M has not avoided the trap. It has walked into a different one. Enterprise routing infrastructure at 30 leads a week is a maintenance burden with no payoff. A systematic forecast at 12 deals a quarter is more overhead than the manual version it replaced. Premature systems do not only waste the build cost. They add operational drag that slows the small team down at exactly the stage when speed is the advantage. The discipline is to build one stage early, which means the manual approach is still running and still correct while the replacement is being staged behind it.

Built one stage late Built one stage early
Forecast at $15M Misses by 20% in front of the board Holds; systematic model already live
Routing at $12M "Who has this lead" in Slack Rules-based with SLAs since $11M
Second ops hire Reactive, after burnout At $12M, before 1:50 broke
The $15M-$18M window Permanent firefight Crossed without a wall
Cost of the choice A missed quarter and the scramble One stage of build a quarter early
Same growth curve, opposite outcomes. The only variable is whether the system was half-built when the breakpoint arrived.

Here is how I would build it: the breakpoint map

The lesson is not “build enterprise systems at $5M.” Premature systems are their own tax. The lesson is that each breakpoint is predictable, so you build the next system one stage before you need it. Here is the mapping exercise I run to place a company and sequence the builds.

The breakpoint map
  1. 1

    Step 1, write down the five numbers

    ARR, deals per quarter, leads per week, required-field count, and rep-to-ops ratio. Each one is approaching a specific breakpoint. You cannot map what you have not measured.

  2. 2

    Step 2, find the number closest to its threshold

    Routing lag around $10M to $20M, forecast drift $15M to $25M, field bloat $20M to $40M, ops capacity at 1:50. Whichever number is nearest its line is the system you build next.

  3. 3

    Step 3, build that system one stage early

    Half-build the replacement before the current approach breaks. The systematic forecast should exist before the drift, not during the miss. Early enough to be ready, not so early it is premature.

  4. 4

    Step 4, do not replace what still fits

    The manual forecast is correct until $15M. Replacing it at $6M is over-engineering and a tax. Know the ceiling is coming, keep the simple system until the ceiling is close.

  5. 5

    Step 5, re-map every two quarters

    Growth moves the numbers. Re-run the five measurements each half so the next breakpoint is always on the calendar, never a surprise in production.

Place yourself on the map. The number closest to its threshold is the system you build next, and you have until it hits to get ahead of it. When routing is the number closest to its line, lead routing is a latency problem is the build; when forecast drift is closest, start with pipeline coverage. The whole discipline compresses to one habit: measure the five numbers, watch the field explode around your constant, and build the next system one magnitude before the old one snaps.

scaling revops-strategy

Keep reading

One email. Every week.

One email a week: an operating problem I solved or botched, with the model, the numbers, and what I would change. No roundups, no theory, unsubscribe whenever it stops being useful.

The newsletter opens soon.

Connect a provider in src/config.ts