The most productive factory in America increased its output by stopping the line more often.
That reads like a paradox. It is not. It is a constraint architecture principle that most technology organisations have never internalised -- and the consequences show up in every breach report and every outage postmortem.
We have spent two decades building faster pipelines, faster deployments, faster feedback loops. And yet 81% of organisations knowingly ship code with known vulnerabilities, with 38% doing so explicitly to meet deadlines. The pipeline is fast. The decisions flowing through it are not good. These two facts are not unrelated.
The real question is not how to make your pipeline faster. It is where to place the gates.
Constraint Architecture: The Discipline We Skipped
There is a discipline that gets this right, and it is not one most technologists would think to study. Skydiving's flightline check -- descended from the military Jumpmaster Personnel Inspection codified at Fort Benning from 1940 -- is a peer-performed, every-jump gear inspection following a protocol called the Check of Threes: three rings (the release system), three points (the harness), three handles (main deployment, cutaway, reserve). It occurs at three stages: self-check, buddy check, and a pre-exit pin check at the aircraft door.
The flightline check is designed friction. It is a gate that exists not despite the need for speed but because of it. Every skydiver wants to exit the aircraft quickly and cleanly. The check does not prevent that. It prevents the one thing that would make speed catastrophic: an undetected configuration error in a system where the consequences of misconfiguration are irreversible.
This is not a safety net. Safety nets catch you after you fall. This is a constraint placed before the point of no return -- a gate that reduces rework to zero by ensuring the system is correctly configured before it enters an environment where reconfiguration is impossible.
The Paradox of Designed Friction
One could argue that gates slow you down. The evidence says otherwise.
When Toyota and General Motors opened the NUMMI plant in Fremont, California, they gave every worker on the line the ability to stop it using an andon cord. The conventional wisdom was that stopping the line was the most expensive thing a factory could do. Toyota's insight was the opposite -- because defects that passed one station compounded at every subsequent station. Defects dropped from 135 to 45 per 100 vehicles. Labor hours dropped from 31 to 19.
85% of andon pulls resolved within 60 seconds without a full line stop. The gate did not slow throughput. It increased throughput by eliminating the rework that had been consuming it.
Atul Gawande demonstrated the same principle in surgery. The WHO surgical safety checklist -- a two-minute pause before incision -- reduced surgical deaths by 47%. Two minutes of designed friction eliminated nearly half the fatal errors in a process performed by highly trained professionals who believed they did not need a checklist.
IBM documented the economics decades ago: a defect caught in production costs 100 times more to fix than one caught in design. The gate is not a cost. It is a 100x cost avoidance.
Where Gates Fail
Not exactly. The counterargument against gates is real, but it targets the wrong thing. It targets gate existence when it should target gate design.
Gates degrade. This is documented and measurable. LOSA data shows that 49% of airline flights involved intentional procedural noncompliance -- pilots skipping checklist items they considered unnecessary. In one study, Bedford G-IV pilots skipped flight control checks on 98% of 175 takeoffs.
Diane Vaughan named this pattern after analysing the Challenger disaster: normalisation of deviance, the process by which repeated success without consequence makes rule-breaking invisible.
The skydiving community knows this failure mode. An experienced team of five with 40,000 combined jumps once collectively missed a misrouted chest strap during their buddy checks. Two military fatalities in the last decade -- including Spc Perez in 2024, whose jumpmaster falsified the inspection -- traced directly to gates that had degraded from inspection to ritual.
The conclusion is not that gates do not work. The conclusion is that gates are architectural components, and like all architectural components, they require design and maintenance. A gate that is never maintained becomes a rubber stamp -- and a rubber stamp is worse than no gate at all, because it creates false confidence.
Three Properties of Effective Gates
If we model the gate as an architectural component rather than a process step, three design properties emerge:
- Enforcement at the constraint boundary. The gate must sit at the point where the cost of a defect changes discontinuously. In skydiving, that boundary is the aircraft door -- the last moment when a configuration error can be corrected without deploying a reserve or dying. In software, the equivalent boundary is the deployment (or better yet, the runtime) point. Google's Binary Authorization enforces attestation at deployment, not at commit. The gate sits where it matters, not where it is convenient.
- Independence from the flow it inspects. The buddy check works because the person checking your rig is not you. The surgical checklist works because the nurse reads the checklist, not the surgeon. The moment the person performing the check is the same person who benefits from skipping it, the gate has a structural conflict of interest. In software terms, this is why the team that writes the code should not be the only team that approves the deployment.
- Resistance to normalisation. The gate must be designed to resist the very degradation that Vaughan described. Skydiving addresses this through annual Safety Day, mandatory requalification, and a culture that treats peer accountability as a social norm. Netflix addresses it through paved roads -- making the safe path the easy path, so that circumventing the gate requires more effort than following it.
The Decision Architecture of Placement
The real design problem is not whether to have gates. It is where to place them and what to enforce at each one. This is a decision architecture problem, and it has trade-offs that most organisations have never made explicit.
A gate placed too early catches defects cheaply but cannot see integration failures. A gate placed too late catches everything but at a cost that makes remediation painful. The Verizon DBIR's finding that 68% of breaches involve human error is not an argument for more training. It is an argument for better gate placement -- for architectural interventions that catch human error before it reaches a point where the consequences are irreversible.
CrowdStrike's July 2024 incident is the canonical example. A single configuration change crashed 8.5 million devices simultaneously and cost Fortune 500 companies $5.4 billion. The root cause was the absence of a gate at the deployment boundary -- no staged rollout, no canary, no attestation that the change had been validated against the target environment.
Three absent checks. $5.4 billion.
The Check That Slows You Down Is the Check That Speeds You Up
Skydiving's fatality rate has improved 48-fold since 1961. The sport did not achieve this by making parachutes faster to deploy. It achieved it by placing constraints at the right points in the process -- constraints that feel like friction in the moment but eliminate the catastrophic rework of a fatality investigation, a grounded fleet, or a destroyed reputation.
The gate is a constraint. And constraints, as any architect knows, are not obstacles. They are design drivers. The flightline check does not slow the skydiver down. It is the reason the skydiver can jump with confidence, at speed, knowing the system has been verified at the boundary where verification matters.
If your deployment pipeline has no gate at the point of irreversibility, you have not optimized for speed. You have optimised for the appearance of speed -- and the difference, when it matters, is measured in billions.
(Views in this article are my own.)