Growth without chaos: what to systematise first
Broken processes get worse under load, and more people doing it wrong is not capacity. Which four systems to fix first, and how to tell you are ready.
· 5 min read
You cannot scale chaos, and load makes it worse
A process that works at ten customers a month and depends on someone remembering does not degrade gracefully at fifty. It fails, and it fails in a specific pattern: the person holding it together starts missing things, the misses are caught late by whoever notices, and the business spends increasing effort on rework rather than on the new volume.
The reason is that informal processes run on spare attention, and spare attention is the first thing volume consumes. At low volume there is time to notice the order that looks wrong, to remember that this customer needs a call, to catch the invoice that never went out. Double the volume and that slack is gone, while the number of things needing to be noticed has doubled.
This is why growth often feels like a decline in quality that nobody can locate. Nothing broke. The thing that was doing the work — human attention on a manageable number of items — simply ran out, and because it was never written down as part of the process, there is nothing obvious to point at. The business concludes it needs more people, which is sometimes true and rarely the first problem.
The four that need to hold first
Not everything needs systematising before growth, and trying produces a project that never ends. Four areas carry the load, and they are the four where failure is both invisible for a while and expensive when it surfaces.
Customer onboarding. Everything downstream inherits whatever happens here. Inconsistent onboarding produces customers with different expectations, different information and different setups, and every one of those differences becomes support work later.
Delivery of the actual product or service. The core promise. If this depends on one person's judgement at every step, volume is capped at that person's attention regardless of how many others you hire.
Invoicing and collection. The failure mode is silent and directly financial. Invoices that go out late or not at all, and payments nobody chases, do not announce themselves — the work all happened, so it feels fine.
Support, meaning what happens when something goes wrong. Under load, an unsystematised support path swallows the whole team's day, because incoming problems are the only work with a person actively waiting.
Marketing, hiring and reporting all matter and none of them break the business in the first month of doubled volume.
Why hiring first makes it worse
The instinctive response to strain is more people, and applied to a broken process it reliably makes things worse rather than better — which is counterintuitive enough to be worth spelling out.
An undocumented process is transmitted by demonstration, so each new person learns a slightly different version, and the variation compounds with each hire trained by someone who was themselves trained informally. Three people now do the job three ways, and no version is the reference. Diagnosing anything requires first establishing which variant was used.
More people also means more coordination, and coordination in an informal process happens through conversation. Ten customers handled by one person needs no handover; fifty handled by four needs constant handover, and handover without a defined shape is where things get dropped.
And the new people consume the attention that was holding the old process together. Training is expensive precisely when you are already short — so the first month or two after hiring into a strained process is usually worse than before, which is often misread as the new hire underperforming rather than as the predictable cost of adding people to an undefined process.
What systematised actually means here
It does not mean automated, and conflating the two is how businesses buy software to solve a definition problem. Automating an undefined process encodes the confusion and makes it harder to change.
Four properties, and a process either has them or does not.
Defined: the steps exist somewhere outside one person's head, in enough detail that someone competent could follow them without asking.
Owned: a named person is responsible for it running and for updating it when it changes. Not a team.
Observable: you can tell whether it happened, from outside, without asking the person who does it. A process whose completion is invisible is a process that will silently stop.
Repeatable: the same input produces the same output regardless of who is on shift or how busy the week is.
Observability is the one most often missing and it is the one that matters most under load, because it is the difference between finding out about a failure from your own process and finding out from a customer. Automation is a reasonable later step once these four hold, and it is an accelerant rather than a fix.
A readiness checklist
Questions that can be answered honestly in an afternoon, in rough order of how much they predict.
Can you name who owns each of the four core processes, and would they agree with your answer?
Could a competent new person perform each one from written material, without shadowing someone for a week?
If a step were missed today, how would you find out — and would it be from your own process or from a customer?
Does the same customer situation produce the same handling regardless of who deals with it?
Do you know your gross margin per product or service line, well enough to know that more volume is more profit rather than more work?
Is there slack in the current setup, or is the present volume already consuming all available attention?
A no to any of the first four is a specific thing to fix and none of them takes a quarter. A no to the last two is more serious: scaling a line whose margin you cannot state risks growing the unprofitable part, and adding volume to a system with zero slack means the failures start on day one rather than in month three.
What systems cannot do
They cannot create demand. A business with excellent processes and no growth in customers has removed the constraint that was not binding, which is a common and expensive way to spend six months feeling productive. The honest question before a systematisation project is whether process is actually what is limiting you.
They cannot fix a broken unit economic. Volume multiplies whatever the per-unit reality is, and if that is negative, a well-run process delivers the loss more reliably and at greater scale. This is why margin sits on the readiness checklist rather than in a finance conversation happening separately.
They cannot substitute for judgement in the parts of the work that are judgement, and pushing that boundary is a real cost. Over-systematising work that genuinely requires discretion produces staff who follow steps that do not fit the situation, or who route around the process entirely and stop reporting that they did.
And they do not stay true on their own. Every one of the four processes will drift as the business changes, and a system nobody updates becomes the thing people work around while it continues to look authoritative. Ownership is not an administrative detail in that list; it is the property that keeps the other three alive.
Common questions
How do I systematise anything when there is no time to stop and do it?
Write it while doing it rather than setting aside a project. Keep a document open for one process and add the step you just performed, including the exceptions, over a couple of weeks of ordinary work. That produces a usable first version at close to zero marginal cost and avoids the situation where the improvement work is scheduled after the busy period that never ends. Pick the process where a failure would be most expensive, not the easiest one to describe.
Should I buy software to handle this?
Only after the process is defined, and for a specific reason: software encodes whatever you give it, so automating an unclear process makes the confusion durable and harder to change. Once a process is defined, owned, observable and repeatable, tooling genuinely helps with the observable part in particular. Choosing a tool as a way of deciding how the process should work is the sequence that goes wrong.
How much growth justifies doing this first?
The threshold is less about a growth rate than about slack. If the current volume already consumes all available attention, any increase will produce failures immediately, so the process work has to come first. If there is genuine slack, you can absorb some growth and fix things as strain appears — that is a legitimate strategy as long as somebody is watching for the strain rather than assuming it will announce itself.
What is the first signal that a process is failing under load rather than just being busy?
Rework, and customers telling you about problems before you know. Busy looks like a full day and completed work; failing under load looks like a full day where a growing share of it is fixing things that were already done once. The second signal is more diagnostic: if you consistently learn about failures from outside, the process is not observable, and that gap widens with every increase in volume.
Related pages