McDonald's is not in the food business. It is in the systems business. Ray Kroc did not invent the hamburger. He did not invent the french fry, the milkshake, or the drive-through window. What he invented — or more precisely, what he extracted from the McDonald brothers' original San Bernardino operation and scaled to 40,000 locations across 100 countries — was a system so precisely documented, so relentlessly standardised, and so thoroughly repeatable that a sixteen-year-old working their first job could execute it to the same standard as a thirty-year veteran. The food was the output. The system was the product.
The principle is structural: any process that depends on individual talent, judgment, or memory to produce consistent results will fail at scale. A process that is encoded into a repeatable system — documented steps, defined sequences, explicit standards, built-in quality checks — can be executed by anyone trained on the system, at any location, at any time, with predictable output. The constraint on growth shifts from "can we find enough talented people?" to "can we deploy the system to more locations?" The first constraint is linear and fragile. The second is exponential and robust.
Atul Gawande's The Checklist Manifesto (2009) demonstrated the principle in the highest-stakes environment imaginable: surgery. The World Health Organization developed a nineteen-item surgical safety checklist — confirm patient identity, mark the surgical site, verify allergies, count instruments before closing — and tested it across eight hospitals in eight countries, from wealthy institutions in Seattle and Toronto to under-resourced facilities in Tanzania and India. Major complications fell by 36 percent. Surgical mortality dropped by 47 percent. The intervention was not new technology, not additional training, not better surgeons. It was a checklist. A system that made the critical steps explicit, sequential, and non-skippable — removing the assumption that skilled professionals will remember everything under pressure, because they will not. They are human.
Amazon runs on Standard Operating Procedures. Every warehouse process, every customer service interaction, every software deployment follows a documented playbook. Jeff Bezos did not build Amazon by hiring people who could improvise brilliantly. He built it by creating systems that made improvisation unnecessary for routine operations — freeing human judgment for the genuinely novel problems where it is irreplaceable. The SOPs are not bureaucracy. They are infrastructure. They are the reason a fulfilment centre in Poland operates at the same efficiency as one in Kentucky — because the system, not the individual, carries the knowledge.
The deeper principle is that repeatable systems are a form of encoded knowledge. When an expert performs a task, the knowledge lives in their head. When that expert leaves, the knowledge leaves with them. A repeatable system extracts the knowledge from the individual and embeds it in the process — in the documentation, the sequence, the checklist, the template, the standard. The knowledge becomes organisational rather than personal. It persists regardless of who executes it. It improves through iteration rather than degrading through turnover. Every company that has scaled past a hundred people has done so by converting individual expertise into repeatable systems, whether they called it that or not.
Section 2
How to See It
Repeatable systems reveal themselves through a specific signature: consistent output quality across different operators, locations, and time periods — without requiring exceptional talent at the point of execution. When a franchise produces the same customer experience in Tokyo and Toronto, a repeatable system is operating. When output quality fluctuates wildly depending on who is working that day, the system is missing.
The inverse signal is equally diagnostic: when an organisation cannot function without specific individuals, it has expertise trapped in people rather than encoded in systems. The "hero culture" where everything depends on a few stars who work eighty-hour weeks is a system failure, not a talent advantage. The heroes are compensating for the absence of repeatable processes.
Operations & Fulfilment
You're seeing Repeatable Systems when a company opens a new facility and reaches full operational efficiency within weeks rather than months. Amazon's fulfilment centres achieve target throughput rates rapidly because every process — receiving, stowing, picking, packing, shipping — is documented to the level of individual hand movements and tool placements. New hires follow the system. The system produces the output. When a company's new locations take six months to "figure things out," the systems have not been codified.
Software Development
You're seeing Repeatable Systems when a development team ships reliably on cadence regardless of which engineers are assigned to the sprint. Continuous integration pipelines, automated testing suites, deployment checklists, and incident response runbooks are all repeatable systems that decouple delivery quality from individual heroics. The team that can only ship when the senior architect is in the room has a people dependency. The team that ships consistently through documented processes has a system.
Healthcare
You're seeing Repeatable Systems when a hospital standardises its protocols and error rates drop without any change in staff quality. Virginia Mason Medical Center in Seattle adopted the Toyota Production System for healthcare in 2002, creating standardised workflows for patient care processes. Professional liability claims dropped by 74 percent over the following decade. The staff did not become better clinicians. The system eliminated the conditions under which good clinicians made preventable errors.
Section 3
How to Use It
Decision filter
"Before hiring another person to solve an operational problem, ask: is this a people problem or a systems problem? If the same failure would occur regardless of who fills the role, the system is broken — and adding headcount to a broken system scales the dysfunction, not the output."
As a founder
Your job is to build yourself out of every operational role by converting what you do into a system that someone else can execute. The first version of every system will be crude — a Google Doc with numbered steps, a Loom video walking through the process, a checklist in Notion. That is enough. The system does not need to be elegant. It needs to be explicit. Write down the steps. Define what "good" looks like at each step. Specify what to do when something goes wrong. Then hand it to someone, watch them execute it, fix the gaps they reveal, and iterate. Every founder who remains the bottleneck for routine operations at fifty employees has failed at system-building, regardless of how good they are at the work itself.
The compounding value is in the iteration. Version one of the system captures the basics. Version ten captures the edge cases, the failure modes, the optimisations that only emerge through repetition. McDonald's Speedee Service System did not arrive fully formed — it evolved through thousands of iterations across thousands of locations, each iteration encoding a lesson learned into the process. Your systems should work the same way: deploy, observe, improve, redeploy.
As an investor
The presence or absence of repeatable systems is the single most reliable predictor of whether a company can scale operations without proportionally scaling costs and management complexity. Ask the founder: if your top three operators left tomorrow, what would break? If the answer is "everything," the company has expertise locked in individuals and will hit a scaling wall. If the answer is "we would feel it, but the systems would carry us through the transition," the company has encoded its operational knowledge into infrastructure that persists independent of any individual. The second company is investable at a fundamentally different risk profile.
As a decision-maker
The decision-maker's leverage with repeatable systems is in choosing what to systematise. Not everything should be a system. Creative work, strategic judgment, novel problem-solving — these benefit from human flexibility and should not be forced into rigid processes. The discipline is distinguishing between activities that should be standardised (routine, high-frequency, quality-critical) and activities that should remain flexible (novel, low-frequency, judgment-intensive). Systematise the routine to free human capacity for the exceptional. The organisation that systematises everything becomes brittle. The organisation that systematises nothing becomes chaotic. The sweet spot is systematic execution of the predictable, combined with flexible response to the unprecedented.
Common misapplication: Treating system-building as a one-time project rather than a continuous practice. A process documented once and never updated decays into irrelevance as the business evolves. The system must include a mechanism for its own improvement — a feedback loop where operators flag gaps, propose changes, and update the documentation. Without this, the system becomes shelfware within months.
A second misapplication is over-systematising to the point of rigidity. The goal is not to eliminate all human judgment — it is to eliminate unnecessary reliance on human judgment for routine execution. A surgical checklist does not tell surgeons how to operate. It ensures they do not skip the steps that prevent catastrophic errors. The system handles the predictable. The professional handles the unpredictable. Confusing the two — applying rigid systems to novel situations, or relying on individual judgment for routine tasks — produces failure in both directions.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The founders who scale most efficiently share a structural obsession: they treat system-building as a core product, not as an administrative afterthought. They invest in process documentation, standardisation, and iteration with the same rigour they apply to product development — because the operational system is the product at scale. The company's output is only as reliable as the system that produces it.
Bezos built Amazon into an operational machine by systematising everything that could be systematised. The fulfilment centre network is the most visible expression: every process from receiving inventory to shipping packages follows a documented, measured, and continuously optimised standard operating procedure. But the deeper systematisation was cultural. The six-page memo replaced PowerPoint — a system for how decisions are proposed and evaluated. The "working backwards" process — start with the press release, then build the product — systematised innovation itself. The Leadership Principles were a system for hiring, promotion, and conflict resolution. Each system encoded institutional knowledge into a repeatable process that functioned independent of any individual, including Bezos. When he stepped down as CEO in 2021, the systems continued operating because they were never dependent on his personal involvement in execution.
Musk's approach to repeatable systems inverts the conventional sequence: where most operators systematise existing processes, Musk systematises by first questioning whether the process should exist at all. At SpaceX, the manufacturing process for rocket engines was rebuilt from first principles — eliminating steps that existed only because "that is how it has always been done." The remaining steps were then systematised with extreme precision. The Raptor engine production line at Starbase produces engines at a cadence that would have been considered impossible a decade ago, because each step has been stripped to its essential function and then made repeatable. At Tesla, the "machine that builds the machine" philosophy treats the factory itself as a product to be designed, iterated, and optimised. The production system is version-controlled like software — each iteration encoded, measured, and deployed across facilities.
Lütke built Shopify's scaling capacity by systematising the merchant onboarding and support infrastructure to handle millions of stores without proportionally scaling headcount. The platform itself is a repeatable system — the templated store setup, the standardised payment integration, the automated shipping configuration — that allows a first-time entrepreneur to launch an e-commerce operation in hours without any human intervention from Shopify. Behind the platform, internal operations follow the same logic: engineering deployment pipelines, incident response protocols, and merchant support playbooks are documented and continuously iterated. Lütke's programming background shows in the design philosophy: treat operational processes like code — version them, test them, deploy them, and improve them through pull requests.
Section 6
Visual Explanation
Section 7
Connected Models
Repeatable systems sit at the intersection of operations, knowledge management, and scaling strategy. The model's power comes from making organisational knowledge durable and transferable — and its connections to adjacent frameworks explain the mechanisms through which systems are designed, the quality standards they enforce, and the compounding dynamics they enable.
Reinforces
Checklists
Checklists are the simplest and most immediately deployable form of repeatable system. A checklist encodes the minimum critical steps of a process into a sequential, verifiable format — ensuring that every essential action is completed regardless of the operator's experience or cognitive load. Repeatable systems thinking reinforces checklists by providing the broader framework: checklists are one tool within a system that also includes documentation, training protocols, quality standards, and feedback mechanisms. A checklist without a system for updating it becomes obsolete. A system without checklists for its critical steps leaves too much to memory.
Reinforces
Kaizen
Kaizen — the Japanese philosophy of continuous incremental improvement — provides the operating rhythm for repeatable systems. A system documented once and never improved is a snapshot that decays into irrelevance. Kaizen embeds improvement into the system itself: every operator is expected to identify inefficiencies, propose changes, and update the process. Toyota's production workers submit millions of improvement suggestions annually, and over 90 percent are implemented. The repeatable system provides the structure that Kaizen improves. Kaizen provides the mechanism through which the system evolves. Without Kaizen, systems ossify. Without repeatable systems, Kaizen has nothing structured to improve.
Tension
Process Engineering
Process engineering seeks to optimise every step of a system for maximum efficiency. Repeatable systems thinking creates tension by arguing that some steps should be standardised for consistency rather than optimised for speed — and that premature optimisation of individual steps can undermine the reliability of the whole. A process engineer might eliminate a quality check that "slows things down." The systems thinker recognises that the check prevents downstream failures whose cost exceeds the time saved. The tension is productive: process engineering pushes toward efficiency, repeatable systems thinking pushes toward reliability, and the best operational designs balance both.
Section 8
One Key Quote
"If you can't describe what you are doing as a process, you don't know what you're doing."
— W. Edwards Deming
Deming spent four decades demonstrating that process clarity — the ability to articulate exactly what happens at each step, in what sequence, to what standard — is the prerequisite for quality, consistency, and improvement. You cannot improve what you have not described. You cannot scale what you have not documented. You cannot delegate what exists only as intuition in someone's head. The statement is not an insult to skilled practitioners. It is a structural observation: until the process is explicit, it cannot be examined, measured, or improved. It can only be performed — and its quality depends entirely on the performer rather than the process.
The implication for founders is direct. Every operational task in your company is either a described process or an undescribed one. The described processes can be taught, delegated, measured, and improved. The undescribed ones are locked inside individuals and will leave when they do. The act of description — writing the steps down, making the implicit explicit — is the foundational act of system-building. Everything else follows from it.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Repeatable systems is the model that separates companies that scale from companies that stall. It is not glamorous. It does not make for compelling keynote presentations. Nobody raises a Series B on the strength of their standard operating procedures. But the companies that reach a thousand employees without descending into operational chaos are, without exception, the ones that invested in encoding their knowledge into systems before they needed to.
The core insight is about where knowledge lives. In a ten-person startup, knowledge lives in people's heads and that works. The founder knows the sales process because they do every deal. The engineer knows the deployment process because they built it. Everybody knows everything because everybody talks to everybody. At fifty people, this breaks. At two hundred, it is catastrophic. The knowledge that was distributed across ten brains is now distributed across two hundred — and the coordination cost of keeping everyone aligned through conversation rather than documentation exceeds the productive capacity of the organisation. The company stalls not because it lacks talent but because its talent cannot access the knowledge they need to execute.
The McDonald's lesson is not about fast food. It is about the economics of system design. Ray Kroc's franchise model worked because the system — the Speedee Service System, the operations manual, the training programme — contained enough encoded knowledge that the franchisee's individual capabilities became a secondary variable. The system did the heavy lifting. The franchisee provided the capital and the local management. This is the structure that enables exponential scaling: the knowledge is in the system, the system can be replicated, and replication does not require finding another genius operator for each new location.
The Checklist Manifesto result — 47 percent reduction in surgical mortality — is the most powerful data point in the entire systems literature. Surgery is performed by highly trained specialists operating under intense time pressure with life-or-death consequences. If a checklist can improve outcomes in that environment by nearly half, the argument that "our work is too complex for checklists" holds no water. The complexity is precisely why the system is needed. Complex work has more steps to miss, more interactions to coordinate, more failure modes to catch. The checklist does not replace expertise. It ensures that expertise is reliably deployed rather than randomly omitted under pressure.
The most common failure mode is building systems that nobody updates. A process document created in 2022 and never revised is not a system — it is an artefact. The business has evolved, the tools have changed, the team has turned over, and the document describes a process that no longer exists. The system must include a mechanism for its own evolution: a review cadence, an owner responsible for accuracy, a feedback channel through which operators report gaps. The document is the output. The improvement loop is the system.
Section 10
Test Yourself
Repeatable systems thinking sounds intuitive but is misapplied in predictable ways. The most common error is treating every problem as a systems problem when some problems are genuinely about individual capability. The second most common error is building systems too early — before the process is understood well enough to systematise. The scenarios below test whether you can identify when a repeatable system is the right intervention and when it is not.
Is a Repeatable System the right intervention here?
Scenario 1
A restaurant chain with 200 locations finds that food quality varies dramatically between locations. The top-performing locations are run by experienced managers who have been with the company for years. The worst-performing locations have new managers. Corporate's proposed solution: hire better managers for underperforming locations.
Scenario 2
A design agency finds that its most innovative campaigns come from a small group of senior designers who work in unstructured, intuitive ways. The CEO proposes creating a 'creativity system' — a documented process for how campaigns should be ideated, developed, and refined — to replicate this output across the broader team.
Scenario 3
A SaaS company's customer onboarding takes an average of 14 days, but ranges from 5 to 40 days depending on which customer success manager handles the account. The company has no documented onboarding process — each CSM follows their own approach.
The most compelling case for repeatable systems in high-stakes environments. Gawande traces the checklist from aviation (where pre-flight checklists reduced crash rates to near zero) through construction (where complex building projects coordinate hundreds of subcontractors through standardised protocols) to surgery (where the WHO checklist reduced mortality by 47 percent). The book demonstrates that the simplest form of a repeatable system — a list of steps on a piece of paper — produces transformational results in domains where the cost of error is measured in lives. Essential reading for anyone who believes their work is "too complex" for systematisation.
Gerber's central argument — that most small business owners are technicians who started a business, not entrepreneurs who built a system — is the most direct application of repeatable systems thinking to company building. The "franchise prototype" concept proposes that every business should be built as though it were going to be franchised: every process documented, every role defined by its system rather than its occupant, every outcome produced by the process rather than by individual heroics. The book is the operational playbook for founders who want to build a company that works without them.
The definitive account of the Toyota Production System — the most influential repeatable system in manufacturing history. Liker documents the fourteen management principles that enable Toyota to produce vehicles at higher quality and lower cost than competitors, with the central theme being standardised work as the foundation for continuous improvement. The key insight: standardisation is not the enemy of improvement. It is the prerequisite. You cannot improve a process that is not standardised, because there is no baseline against which to measure the improvement.
Carpenter's account of transforming his chaotic telephone answering service into a systematised operation provides the most practical, step-by-step guide to building repeatable systems in a small business. The methodology — identify the process, document it, assign an owner, improve it through iteration — is applicable to any operational function. The book is especially valuable for founders at the ten-to-fifty-employee stage where the transition from informal knowledge to documented systems is most urgently needed.
The original text on process systematisation. Taylor's methods are dated and his labour philosophy is rightly criticised, but the foundational insight — that work processes can be studied, decomposed, optimised, and standardised to produce consistent output independent of individual variation — launched the discipline. Reading Taylor in the context of modern systems thinking reveals how much of contemporary operations management, from lean manufacturing to DevOps, is a refinement of his original structural observation. The text is freely available and short enough to read in an afternoon.
Repeatable Systems — Encoding expertise into process transforms scaling from a talent-dependent linear function into a system-dependent exponential one. The cycle of document, execute, measure, and improve creates processes that get better through use.
Tension
[Six Sigma](/mental-models/six-sigma)
Six Sigma targets the elimination of process variation to achieve near-zero defect rates (3.4 defects per million opportunities). Repeatable systems share the goal of consistency but create tension around the level of investment justified. Six Sigma requires extensive statistical analysis, dedicated Black Belt practitioners, and significant organisational overhead. For many processes, a well-documented checklist achieves 90 percent of the quality improvement at 10 percent of the cost. The tension clarifies when each framework is appropriate: Six Sigma for high-volume, high-stakes processes where marginal defect reduction justifies the investment; simpler repeatable systems for everything else.
Leads-to
[Leverage](/mental-models/leverage) (Systems)
Repeatable systems create leverage by decoupling output from individual effort. Once a process is systematised, the founder's time shifts from executing the process to improving the system that executes it — working on the business rather than in the business. This is structural leverage: a single improvement to the system multiplies across every instance of its execution. Fix a step in a checklist used by 500 operators and you have improved 500 processes with one change. Repeatable systems lead naturally to systems leverage because each iteration of improvement compounds across the entire footprint of the system's deployment.
Leads-to
Standardisation
The natural endpoint of repeatable systems is standardisation — the establishment of uniform specifications across an organisation, industry, or domain. Repeatable systems begin as internal process documentation. As they mature, they become the standards against which performance is measured, new hires are trained, and quality is audited. The ISO quality management standards, the FDA's Good Manufacturing Practices, and the aviation industry's Standard Operating Procedures all evolved from individual organisations' repeatable systems that proved effective enough to become industry-wide standards. The progression from "how we do things" to "how things should be done" is the path from repeatable systems to standardisation.
For founders, the practical question is sequencing: what do you systematise first? The answer is whatever you do most frequently and whatever is most painful to get wrong. Start with the processes that are executed daily and that produce visible damage when they fail — customer onboarding, deployment procedures, financial close processes, hiring pipelines. These are the highest-leverage candidates because the system will be used often enough to justify the investment and tested often enough to reveal its gaps quickly. Low-frequency processes can wait. High-frequency, high-consequence processes cannot.
The AI-era implication is that repeatable systems become even more valuable — not less. AI agents can execute documented processes. They cannot execute processes that exist only as tacit knowledge in someone's head. Every system you build today becomes an asset that AI can augment, accelerate, or eventually execute. The company with well-documented, well-structured repeatable systems is the company that will deploy AI most effectively — because it has already done the hard work of making its processes explicit, measurable, and improvable. The company whose operations are a tangle of undocumented tribal knowledge will struggle to deploy AI for anything beyond superficial chat interfaces. The system is the interface between human knowledge and machine execution.
Scenario 4
A three-person startup is building its MVP. The technical co-founder proposes spending two weeks creating detailed engineering process documentation, deployment runbooks, and coding standards before writing any product code.
