My Playbook for Scalability

How to stop growth from requiring more of everything — and why making work faster is not the same as needing less of it.

This is for anyone who wants or needs their business and products to be scalable — to break the linear dependency between growth and the need for more headcount, processing power, vendor spend, or whatever the constraining resource is. The principles here apply to all businesses, from two-month-old startups to well-established enterprises.

What is scalability?

The word gets used loosely, so let's define "scalability" here. A business is scalable when its cost curve grows slower than its revenue curve — ideally, flat. Not "we hired smart people" or "we are using AI" or "we have good software." A specific, testable claim: the last time revenue grew 2x, what did your constraining resources do — headcount, compute, per-use vendor fees, sales capacity, whatever your business actually consumes to serve a unit of demand? If they grew close to 2x or more, cost is tracking revenue and the curve isn't bending.

Most improvement work attacks the wrong variable. It makes existing work faster or cheaper: first with automation, now with agents. I don't want to dismiss it — freeing human time and making any improvement that leads to better outcomes for the customer is worth doing on its own terms. But it moves the line down; it doesn't bend it.

There are other expensive versions of the same mistake, such as adding software before defining the process it's supposed to run on, or stacking tools without a smart architecture connecting them, and without defining the single source of truth. It brings local improvements but adds work that didn't exist before. Integrations to maintain, data to reconcile between systems, someone whose job becomes keeping tool A talking to tool B. Looks like transformation, but the entropy increases.

Real scalability comes from reducing how much work the system generates in the first place. AI has made that dramatically easier to pursue — and much easier to mistake.

The trees analogy

If you have trees to cut:

Rung	Tree-cutting	In a business system	What it does to the cost curve
1	Humans with a hand saw	People doing repetitive, low-value work	Cost scales 1:1 with volume
2	Humans with a motorised saw	Partial automation, human still in the loop on every unit	Cost per unit drops. Still scales 1:1
3	Robots with a motorised saw	An agent runs the process end-to-end, humans handle exceptions	Cost per unit drops sharply — but still scales with volume, now in tokens and exception hours
4	Fewer trees to cut — or none	Redesigning the system so the work no longer needs to exist	Volume grows, work doesn't. The curve finally bends

The Diagnostic

A way to test where you actually have this problem.

For each function: if volume multiplies by 10x tomorrow, what breaks first — headcount, compute, per-use vendor fees, manual hours, or whatever that function actually consumes per unit?

Product
Engineering
Operations
Customer Support
Data / Analytics
Sales
Finance / Admin
Others

Force the answer to be evidence, not instinct. For each function, look at:

The last time volume jumped. What actually got added? Headcount, contractors, overtime, infra spend?
The ratio over the last 4–8 quarters. Output per FTE, per euro of compute, per euro of vendor spend. If the ratio improved while volume grew, something in the system is decoupling. If it stayed flat while volume grew, cost tracked demand — that's the signal.
Where the queue forms when the function is under load. The queue points at the constraint more reliably than anyone's opinion does.

Defining "output" — and what a flagged function looks like

Tech companies rarely have units of production. They have units of demand that each function consumes — so the question per function is: what arrives here that, if it doubled, would force us to add resources? Tickets or active accounts for Support. Accounts taken live for Implementation. Opportunities worked for Sales — not revenue, which mixes price with volume, and price doesn't consume capacity. Invoices and reconciliations for Finance. Requests, jobs or GB processed for Infra.

Engineering is the hard one. Lines of code, story points and PR counts measure none of the things you care about, and all of them get gamed the moment they become a target. The honest move is to stop trying to measure engineering output and measure what the function absorbs instead. The most revealing one for scalability: the share of engineering time going to new work versus maintaining what already exists. If that share drifts toward maintenance as the product grows, you have a scalability problem even with flat headcount.

What a flagged function looks like

In each of these, the resource that should have stopped scaling linearly didn't. They're grouped by the lever that would fix them — the cascade the next section covers.

Demand (the product itself creates the work)

Fully bespoke customer onboarding instead of a configurable self-serve flow — every rollout is a new project.
"Unlimited customization" for enterprise accounts, with no shared configuration layer — every request becomes dedicated code.
A product whose defaults are wrong for most users, generating a support ticket per account to correct them.

Flow (each unit needs its own pass through the system)

100% manual review of all content before publishing, with no risk-based sampling.
Sales where every lead — any deal size — goes through a 1:1 human demo.
A pricing exception process where every discount above 5% goes to the same two people.

Execution (the multiplier applied to work that shouldn't exist)

An AI agent that answers tickets, but the root cause generating the ticket volume is never addressed.
A bot that auto-generates reports an analyst still doesn't trust, because the source data is inconsistent — the AI didn't fix the data architecture.

The Three Levers

Two things get called scalability. The business model sets the ceiling — what you sell, to whom, and what it structurally costs to serve one more customer. Operations determine how close you get to that ceiling. No amount of operational excellence makes an hours-for-money business scale; no model survives operations that grow 1:1 with revenue.

The cascade works from the outside in. Demand asks what the product and the commercial promise are generating. Flow and Execution are the machine that delivers on it. Work top-down: each lever only makes sense once the one above it has been answered, otherwise you're optimizing work that shouldn't exist.

1. Demand — how much work does the product create?

What in the system generates work volumes — and does whoever decides it ever see the cost it creates downstream?

The decision that creates the work and the team that absorbs it typically are in different places. Product decides; Support absorbs. Sales commits; Implementation delivers. Nobody is being careless — the cost simply isn't visible from where the decision is made, or each team's goals are just disconnected.

2. Flow — does each unit need its own pass?

The question: does one documented process — one set of instructions, one agent spec — cover the large majority of cases without a custom variation per team, customer, or edge case?

A process that needs a different playbook or template per customer, per market, per edge case isn't a process; it's a category of projects. And the test applies regardless of who executes: an agent that needs a bespoke prompt per account has exactly the same problem as a human who needs a bespoke briefing per account.

Four mechanisms decouple a step from volume:

Elimination — the step stops existing.
Shifting — the requester does it themselves; it costs the organisation nothing per unit.
Exception routing — most volume flows straight through; only what fails a check gets individual handling.
Batching — many units handled in one pass, so executions track cadence rather than volume.

3. Execution — what runs the work that's left?

The question: is the workflow redesigned so the agentic architecture runs the process end-to-end and a human steps in only for exceptions and orchestration — or is the agent layered onto the existing human-centric workflow as a tool that makes each step faster without changing who runs the process?

The Five-Step Loop

A summary of everything above, in the order you'd actually run it.

Step	What you do	What you end up with
Diagnose	Run the diagnostic: what breaks first at 10x, per function, backed by evidence rather than instinct.	One constraining resource per function, with the evidence behind it.
Prioritize	Work down the cascade — Demand, Flow, Execution — and stop at the first lever with real headroom. Pick one function to fix this quarter, not all of them.	A ranked shortlist: function → highest lever with headroom → this quarter's pick.
Redesign	Make the work shrink, not just run faster.	A flow that answers its lever's question: less work created, fewer units needing their own pass, or an architecture that runs what's left.
De-risk	Check the redesign didn't trade cost for quality, or move the bottleneck somewhere less visible.	Named exception owner, escalation rule, downstream absorption check, and a plan to sample what passes through untouched.
Measure	Prove the curve bent, not just that the ratio improved once.	The ratio at two volume levels, the exception rate, and the per-unit cost of the new architecture.

Worked example — Product detail page abuse at one of the largest e-commerce platforms

Anonymized. Absolute figures — headcount, savings, cost per unit — can't be shared; the proportions are accurate.

The problem. A product optimized for one thing was generating work for a function measured on the opposite. Reducing friction in listing creation made the catalogue easier to exploit, and every exploited listing became support volume: fake reviews, badges and search rankings, transferred to products that hadn't earned them. The cost surfaced two places away from the decision that caused it, so it was managed as a staffing problem. At its peak this single failure mode consumed ~50% of the headcount of the Seller & Buyer support function, alongside escalations up to SVP level and press coverage.

What was tried first — and why it wasn't enough. The process itself got better. SOPs were rewritten, cases resolved with fewer contacts each. Real improvement, and it moved the line down. But headcount kept growing with the business, because nothing had changed about how many cases the catalogue was generating. The listing experience was designed without visibility of what it produced downstream.

Step	What happened
Diagnose	The constraining resource was manual case-handling hours, and it tracked listing volume rather than anything the team controlled. The evidence was in the growth pattern: volume up, headcount up, contacts-per-case down. An efficiency gain sitting on top of a demand problem.
Prioritize	Demand, not Flow or Execution. The work existed because the catalogue permitted the abuse. Routing it better or automating the handling would have industrialized a problem that didn't need to exist.
Redesign	A cross-functional Kaizen event across five teams, with an audit of 200 real cases to map how sellers were actually circumventing the rules. The listing experience itself was mapped alongside them — not just the abuse cases, but the flow that made the abuse possible. That surfaced 18 distinct gaps; work focused on the top five: suppressing reviews from long-dormant listings pulled into active variation families, blocking risky product-type changes, penalizing sellers who recreated removed families, monitoring listings with multiple parents, and validation at creation. The change that mattered most wasn't on that list. The upstream catalogue product was optimizing for less listing friction, fewer seller contacts to create and maintain a listing, and a smoother path to purchase. The downstream orgs — seller support, trustworthy shopping — were optimizing for fewer violations, fewer abuse reports, fewer contacts to resolve one. Both were doing their jobs well; the goals pulled against each other, and nothing made that visible from either side. So the downstream impact was embedded into the upstream product's own goals, and both product orgs were put on a single source of truth for the data. Without that, the five fixes would have been patches on a system that kept regenerating the problem.
De-risk	Enforcement changes carry a false-positive cost: legitimate sellers caught by rules aimed at abusers. One concept was worked through with legal precisely because it was penalizing non-abusive behaviour.
Measure	Contacts and escalations fell by roughly half, and headcount came out permanently from that business unit. It also held as the business kept growing: a rule doesn't care whether it governs a million listings or ten million. It later improved further, once proactive detection with AI was added on top — applied to the residual problem, after the root cause was closed, not instead of closing it.

When Not to Scale

Not every business should focus on decoupling cost from volume, and treating scalability as an unconditional good is how good operators end up destroying the thing that made the business work.

Deliberate exceptions worth naming:

When the human contact is the product. High-touch enterprise relationships, private banking, executive search. Cost per customer is meant to scale with revenue — that's the model, not a defect.
Craft and scarcity. Some products are worth more precisely because they don't scale. Automating the constraint destroys the pricing power.
Regulated work where accountability is per-unit. Where a named human must be answerable for each decision, exception routing isn't an efficiency question.
Early-stage, pre-product-market-fit. Doing things manually is how you learn what to build. Automating before you understand the work locks in the wrong design at speed — the most expensive mistake on this list.

The test still applies. You should still know exactly which resource scales with volume and why.