Nobody was careless. Everyone worked hard. The customer still had a bad week, and someone will spend Thursday fixing it.
That is a process failure. It has nothing to do with the size of the company. It happens at four people and it happens at four hundred. What changes with size is what it costs to fix, and that cost only moves in one direction.
What a business actually is
Strip a business down and three things are left. People, or machines. Data. And processes.
People process data by following processes, and what comes out is value for a customer. Everything else serves that sentence. The software is where the data sits. The org chart is who does which part. The meetings are what happens when the process does not cover the situation.
When the process is undefined, the sentence breaks in one specific place. People improvise. Improvisation is not laziness, it is what a capable person does when the path is not marked, and most of the time it works. But two capable people improvise differently. The data they leave behind carries the shape of their improvisation, so it degrades. And the value the customer receives becomes a function of who happened to handle the work that day.
Then you grow. Growth multiplies what you already have. If the work is consistent, growth multiplies consistency. If it is not, growth multiplies the variation, faster than you can hire people to absorb it.
That is the whole argument. The rest is evidence and timing.
Where "that is for big companies" came from
The belief has an honest origin. The research that built this field was done on large organisations.
An influential management practice survey in economics covered 732 manufacturing firms the authors called medium-sized. The median had 700 employees (Bloom and Van Reenen, Quarterly Journal of Economics, 2007). Work on the Capability Maturity Model approach began at Carnegie Mellon in 1986, after the US government asked for a way to evaluate software practices. The Software CMM was published in 1991. If you learned process improvement from any of that, you learned it from big companies, because that is who was studied.
The same data shows the pattern that makes the belief feel true. The US Census Bureau's Management and Organizational Practices Survey finds a firm with 10 employees scores about 0.5 on structured management practice and a firm with 1,000 scores about 0.7, rising continuously across that range (Bloom, Brynjolfsson, Foster, Jarmin, Patnaik, Saporta-Eksten and Van Reenen, using 2010 MOPS data on 32,000 US manufacturing plants).
So small firms really do run with less structure. That is a description of what is, not a law about what works.
For what works at small scale, the useful study is McKenzie and Woodruff in Management Science (2017). They measured 26 basic business practices across more than 20,000 firms in seven countries. The median firm had zero employees and nearly 97 per cent had nine or fewer. Variation in those practices explained as much of the variation in sales, profits and productivity among microenterprises as among larger firms, with a one standard deviation improvement associated with 35 per cent higher labour productivity and 22 per cent higher total factor productivity.
There is causal evidence at small scale too. Bruhn, Karlan and Schoar ran a randomised trial with 432 Mexican firms averaging 14 employees, most under ten (Journal of Political Economy, 2018). Firms given a year of consulting showed higher productivity and return on assets, and Mexican social security records, administrative data rather than self-report, showed roughly 50 per cent more employees five years later.
Then there is the history, which should end the argument. The Toyota Production System is the reference case for process improvement, and most people file it under enormous company. In 1947, when Taiichi Ohno began rearranging machines in one Toyota machine shop, Toyota built 3,922 vehicles that year. Ford Motor Company built 1,091,229. Three years later Toyota had posted heavy losses, shed 1,600 employees through voluntary retirement, cut wages by 10 per cent, and was being kept alive by a syndicate of 24 banks. Its managing director toured River Rouge that summer and made the comparison himself: "their daily output was 8,000 units; ours was a piddling 40."
The method was not a product of scale. It was a product of not having any.
The retrofit cost, and why you cannot see it
Here is the uncomfortable part. The cost of not defining a process does not appear anywhere in your accounts.
Two separate research literatures found this by accident. In construction, Love, Teo and Morrison examined 218 projects and 7,082 recorded non-conformances and found formally logged non-conformance costs averaged 0.18 per cent of original contract value in the 68 projects with contract-value data (Journal of Construction Engineering and Management, 2018). Thirteen years earlier the same lead researcher surveyed 161 construction professionals and arrived at roughly 12 per cent. Same broad subject, different samples and cost definitions, and a gap of more than sixty times. That is not a like-for-like estimate of hidden costs. In quality accounting, a three-year study of one manufacturing firm found its books captured quality costs equal to 8.89 per cent of sales, while measurement including hidden costs put the same year at 34.02 per cent (Sailaja, Basak and Viswanadhan, IJMVSC, 2015). One firm, so read it as illustration, not benchmark.
Neither pair of numbers gives you the true cost of poor process. They show how much the answer can change with the definition and measurement of cost. Your accounts may miss time spent chasing, clarifying and repairing work, but these studies do not tell you what that costs in your business. That is why the financial case for fixing a process often has to start with measurement, not an expense line that already exists.
What is measurable is the escalation. The best data I have found is NASA's, published by Stecklein and colleagues in 2004, drawing on cost records from five spacecraft projects and a two-decade aircraft programme. Call the cost of fixing a requirements error at the requirements stage one unit. At design it becomes three to eight units. At build, seven to sixteen. At integration and test, twenty-one to seventy-eight. In operations, twenty-nine units to more than fifteen hundred, depending which of their three methods you use.
That spread is more useful than a confident single multiplier. You will have seen the claim that a defect costs a hundred times more to fix in production than in requirements. Shull, Basili, Boehm and co-authors examined it in 2002 and found it held for severe defects, but came out closer to two to one for everything else. The two to one never survives the retelling.
Strip it back to what you can defend and it still says something worth acting on. Fixing the definition of work is cheap while the work is still being defined. It gets steadily more expensive once people, customers, contracts and software have been built on top of the undefined version.
The same failure at 3, at 15, and at 50
At three people, the process lives in three heads and it works. Everybody can see everybody. Coordination is a sentence across a desk. Writing anything down feels like bureaucracy, and mostly it is.
The exposure is not efficiency, it is residency. US Bureau of Labor Statistics data put median employee tenure at 3.9 years as of January 2024, 3.5 years in the private sector, and 2.7 years for workers aged 25 to 34. Those figures measure tenure so far, not how long someone will stay. The operational risk is still clear: at three people, one departure can take critical knowledge with it.
The cost of fixing this now is an afternoon. You write down how the thing you do repeatedly actually gets done, once, in plain language.
At fifteen, the failure changes shape. You can no longer see everyone, so you hear about problems instead of noticing them. This is the stage where owners describe themselves as spending all day answering questions.
That is not a feeling, it is structural. Research covering roughly 90 per cent of French manufacturing value added found that firms which grow substantially do not just add people, they add a management layer, and the wage and hours structure of every existing layer changes with it (Caliendo, Monte and Rossi-Hansberg, Journal of Political Economy, 2015). Growth is not smooth. It is a series of reorganisations.
Fixing it at fifteen costs weeks, mostly in other people's attention, because the process now has to be agreed rather than simply written.
At fifty, undefined process has become structure. There are roles that exist to compensate for handoffs nobody designed. There is software configured around a workflow nobody wrote down, which means the software now defines the workflow by default. There are three ways of doing the same thing, each with a defender.
Consider what happens when firms can actually see the cost of getting bigger. French labour law triggers a set of obligations at fifty employees. Garicano, Lelarge and Van Reenen found firms were more likely to stay at 49 employees: 12 per cent remained at that size for two years running, compared with 2 per cent at 52 (American Economic Review, 2016). That is a legal threshold, not a management one, and fifty is not a natural wall. The point is the reverse. When the cost of crossing a line is visible, firms stop and choose. When the cost is coordination overhead, which shows up nowhere, they do not choose. They absorb it and call it growing pains.
Fixing it at fifty is a project with a budget, a sponsor and a change management problem. Same failure as the Tuesday phone call. Orders of magnitude more expensive to undo.
Why the document is not the deliverable
Now the part most process work gets wrong, including plenty of mine early on.
A process defined once and never revisited becomes another out of date artefact. You have probably lived through one. Somebody produced a folder of procedures, everyone nodded, and within eighteen months it described a company that no longer existed. That experience is the main reason owners are sceptical of this work, and the scepticism is earned.
The best evidence on what actually happens comes from a follow-up nobody expected to be so useful. Bloom, Eifert, Mahajan, McKenzie and Roberts ran a randomised trial on Indian textile firms, introducing 38 specific management practices, and measured a 17 per cent productivity improvement in the first year (Quarterly Journal of Economics, 2013). Nine years later they went back (Do Management Interventions Last?, 2018). About half the practices adopted in the original experimental plants had been dropped, although a significant performance gap between treatment and control plants remained.
Which ones survived is the interesting part. What stuck: recording quality defects systematically, preventative maintenance, monitoring machine downtime daily, managing old stock. What was dropped: visual displays, written practices nobody had used before, and anything needing daily attention from a manager. Some practices were dropped because firms decided they were not worth adopting. But in the treated experimental plants, managerial turnover accounted for well over half of the drops. Many practices disappeared when the people holding them left.
That is what separates a process habit from a process document, and it is why documentation alone does not create consistency. The thing that compounds is not the folder. It is the habit of looking at how work runs, changing it on purpose, and writing the change down so the next person inherits the current version rather than the original one.
The same study holds the best line in the literature about why this matters. Before the intervention, 93 per cent of those plants already recorded quality defects. Only 29 per cent looked at the records daily or by defect type. And none had any standard way to analyse the data and act on it.
That is the operating problem in one sentence, and I see it constantly. The data exists. The system around the data does not. One client had bought a CRM and barely anyone used it, because there was no workflow behind it. We designed the workflow first, then built the automations behind it, covering assignments, status triggers, escalations and reporting views. Then we documented it and trained the team so it held after handover. The software had never been the problem. It was the document without the system, in reverse.
Two honest caveats. The evidence for process maturity frameworks is thinner than their popularity suggests: a review of 148 software process improvement studies published between 1991 and 2008 found half used uncontrolled before-and-after comparison with confounders largely unaddressed (Unterkalmsteiner and colleagues, IEEE Transactions on Software Engineering, 2012). And none of the randomised trials here studied a Western professional services business. India was textile manufacturing, Mexico micro-enterprises in Puebla, the census data manufacturing. The pattern holds across very different settings, which is why I find it persuasive, but nobody has run the experiment on a fifteen-person agency in Manchester.
When it is genuinely too early
An article arguing start early that will not say when early is too early is a sales document. So here it is.
It is too early when the work is not repeatable yet. If you have delivered something twice and both times were structurally different, you do not have a process. You have two projects. Defining one now freezes a guess, and a frozen guess is worse than no document, because people follow it.
It is too early when you do not know who the customer is. Process work makes the delivery of value more consistent. It cannot tell you whether the value is wanted.
It is too early if you do not want to grow. Hurst and Pugsley found nearly three quarters of people starting a business said they wanted to keep it small, with a median expectation of three or four employees at five years, and that 60 per cent of new firms added no employees at all (NBER working paper, 2011). Most small firms stay small by choice, not by failure. If you are two people who intend to stay two people doing bespoke work, formal process is overhead and you should skip it.
And it is too early to start with notation. BPMN is a precise language and I am certified in it, which is why I will say that starting there is usually a mistake for a small company. The common obstacles with BPMN documentation are mostly obstacles of premature formality. Write the steps in sentences first. Notation earns its place when sentences stop being unambiguous.
The idea
Process improvement is not a stage of corporate development you graduate into once you are large enough to need it. It is a habit, and habits are cheapest to form when there is almost nothing to change.
The company at three that writes down how it does the thing it does repeatedly is not being precious. It is buying the ability to hire a fourth person without losing a quarter of its memory. The company at fifty that never did it is not careless. It is paying interest on a decision made when it was three, by people who could see each other across a desk and reasonably concluded none of this applied to them yet.
The Tuesday phone call is the same event in both companies. Only the invoice is different.