A machinist sets up a part before cutting anything. The aluminium billet is clamped in the vice, but the machine has no idea where it is. So the first thing the machinist does is find it: touch a probe to one face to set zero on the X axis, another face for Y, the top surface for Z. Only once the machine knows where the metal is -- in all three dimensions -- does it start removing any.
To someone watching the clock, this is wasted time. The cutter isn't cutting. The expensive spindle is spinning in fresh air. The obvious way to go faster is to skip the setup and run the program. And if you do that, you will, reliably, drive a carbide end mill into a steel clamp at fifteen thousand RPM and turn an expensive billet and a £300 cutter into scrap and shrapnel in about a second.
The slow-looking part is what makes the shop fast. A part that's been probed, cut as a first article, measured against the drawing, and locked into a proven program can then run unattended -- lights out, overnight, hundreds of identical parts, nobody in the building. The setup isn't the tax you pay to get to the work. The setup is the work. The cutting is just what happens afterwards.
An engineering organisation has the same three axes. Call them measurement, test, and process. They're the X, Y, and Z that tell you where you are before you start removing material. And they get cut for exactly the reason the machinist is tempted to skip the probe: from the outside, they look like the part where nothing is happening.
The bureaucracy that makes you fast
On a young team, and on plenty of old ones, all three read as overhead. Measurement is dashboards, and meetings about dashboards. Test is the thing that turns a two-hour change into a two-day one. Process is the red tape some adult imposed to make sure nobody has any fun. So they get cut, in the name of speed -- and for a few months the team genuinely is faster, in the way you're faster downhill with the brakes disconnected.
Then something breaks and nobody can say why, because nothing was measured. The fix reintroduces a bug that was solved and forgotten a year ago, because there was no test holding the lesson in place -- the way Knight Capital lost roughly $440 million in 45 minutes in 2012, when a botched deploy left years-dormant code alive on one server and a repurposed flag switched it back on. And the same mistake gets made by three different people in three different corners of the company, because there was no process to carry the lesson from the first one to the other two. The team is busy. It is not learning. It is also not productive. Those are three different things, and from the inside they feel identical right up until a competitor that is both goes past you.
These three axes are a large part of what people vaguely gesture at when they say "engineering culture" or "the team's DNA." Not the perks and the offsites -- the wiring. A team's real DNA is what it does automatically, without being told: what it measures before it decides, what it checks before it believes, and what it writes down so it never has to learn the same thing twice. Done badly, all three are bloat. Done well, they're the difference between a team that compounds and a team that just churns.
Measurement: deciding what's worth doing
Measurement is how you decide what's worth doing before you spend the effort doing it. Most of it isn't a dashboard at all -- it's a back-of-envelope calculation done in ninety seconds on the back of a meeting. How big is this problem, roughly? If I fixed it perfectly, what would I get back? Is that more or less than the thing I'd have to stop doing to make room?
But measurement isn't always arithmetic -- sometimes the cheapest way to size a piece of work is to build the throwaway version of it first. Before committing three weeks to a piece of C++, I'll spend one day on a Python spike that does the same job slowly, badly, and with no thought to ever shipping it -- but does it, and gets it right. One day to gate three weeks -- that asymmetry is the whole point, and it only holds because the spike is throwaway in quality and trustworthy in result: ugly and slow enough to delete without a second thought, correct enough to trust. Often that day settles it -- the cheap version already clears the bar, and the three weeks were never worth spending. When it doesn't, the day still wasn't wasted, because the spike was doing two jobs at once: measuring whether the expensive work was worth doing at all, and leaving behind an oracle to test that work against -- a reference answer the eventual C++ has to match before I'll believe it works. A throwaway that proves the expensive work isn't worth doing is the best-paid day on the calendar; one that hands you the yardstick for checking the real work is the next best.
The lesson underneath all of this is to optimise what actually matters, not whatever happens to be in front of you -- and Amdahl's law is just the canonical way engineers first run into it, usually the hard way. You can spend a week heroically optimising a function -- shaving a genuine thirty percent off it -- and find the program is now a fraction of a percent faster, because the function was under one percent of runtime to begin with, which is to say nobody can tell. Meanwhile a single query nobody profiled is sitting at 50% of wall-clock time, untouched, because it never occurred to anyone to look: penny wise and pound foolish, made literal. And it is often worse than a wash, because the clever rewrite that bought the invisible speedup is exactly the kind of change that slips in a bug the slow, obvious version never had -- so the trade comes out doubly bad, a gain nobody can measure bought with a fault nobody saw coming, pennies picked up in front of a steamroller. The instinct to optimise the thing in front of you is almost always wrong. The thing in front of you is rarely the thing that matters.
This is the same move a north-star metric makes one level up. A good metric lets you do arithmetic on a decision instead of arguing about it: improve this by 10%, that's roughly so much more of the number we all care about. It's profiling for the whole company. And it's the same maths that explains why a brilliant engineer stuck in operational mud ships like an average one -- the talent is real, but it's multiplying the wrong fraction. Optimising without measuring first isn't engineering. It's decorating.
Test: knowing you did it right -- and banking what you learned
If measurement decides what to do, test tells you whether you actually did it -- and, looking back, which of those measurements were worth making in the first place. Notice that, and the team gets better-calibrated over time about what to measure and what to build next. The shallow version of this is obvious: does the code meet the requirement, does the thing do what we said it would. Useful, necessary, and not the interesting part.
The interesting part is that a test is how a team remembers. Every non-trivial bug you fix has a piece of hard-won knowledge buried in it -- a domain rule nobody wrote down, an edge case the spec never imagined, a way the real world turned out to be messier than the model. Fix the bug without writing a test and you've paid for the lesson and thrown away the receipt. It will be relearned, at full price, by the next person who touches that code -- possibly you, in eight months, having become the next person.
And that relearning is so expensive for a particular reason: debugging doesn't keep. An interactive session -- a breakpoint here, a print statement there, a hunch chased for half an hour -- solves the problem exactly once and leaves nothing behind you can run again. A test is the opposite: automated, or even just written down as a few manual steps, it's a process rather than a one-off investigation, and a process is repeatable -- re-running even the manual version costs a fraction of re-deriving the whole thing from cold. Good engineers half-know this already; they keep private, unwritten routines for cornering a bug, and just rarely think to write them down where the rest of the team could use them.
A test suite is the only documentation that fails the build when it goes out of date.
This is what people miss when they call tests overhead. The accumulated body of checks a mature team carries around isn't a cost centre -- it's the moat, and it's bigger than the automated suite. Even a written-down manual test -- a checklist someone walks before a release -- is part of it, and it earns its place three ways: it confirms a requirement was actually met instead of merely believed to be, it keeps last year's defects and the regressions you've already paid for from quietly creeping back, and when something does recur it collapses the root-cause hunt, because a known procedure narrows the search to minutes instead of leaving the next person to re-derive it from cold. None of that lives in the source code, which is, frankly, the replaceable part -- a competent team could rewrite most of it. What they couldn't reproduce is the ten thousand specific mistakes those checks quietly refuse to let you make again, each one a scar from a real incident, most of them describing some unobvious truth about your particular customers and your particular domain. A rival can read your code. They can't read your bugs. The same logic is why a ticket is really a notebook -- institutional memory written by the people doing the work, while they're doing it, when the context is still warm.
Process: don't repeat mistakes, make wins repeatable
Measurement and test operate on the work. Process operates on the team. It's how a lesson learned by one person on a Tuesday becomes something the whole organisation knows by Friday -- so the mistake isn't repeated, and the thing that worked isn't a one-off.
You can see the absence of it in a specific kind of stuckness: a team that hits the same blocker every week and never fixes it, just builds a slightly better workaround each time. Everyone knows exactly what the problem is. Nobody fixes it, because the fix would mean introducing a rule -- a step someone has to take, a check someone has to run -- and a certain kind of engineer would sooner route around the same wall a hundred times than accept a single piece of process. That is the busy-but-not-productive trap lived one detour at a time: tremendous motion, the same ground covered over and over, nothing banked in a form that holds.
Nassim Taleb, in Antifragile, gives the cleanest test for whether a piece of process has earned its place:
The greatest -- and most robust -- contribution to knowledge consists in removing what we think is wrong -- subtractive epistemology.
Good process is via negativa. It is, at its best, a codified list of what not to do again, every line traceable to a specific scar. The post-mortem becomes a checklist item; the checklist item, once it's stable, becomes an automated guard that nobody even has to remember. That's the don't-repeat-mistakes half. The other half is making wins repeatable: the thing that worked once becomes the default path, the paved road, so the next person gets the good outcome by walking the obvious route rather than by being a hero. The very best process disappears entirely -- it stops being a document people are told to follow and becomes a pipeline that just does the right thing on its own. Nobody experiences a well-automated deploy as "process." They experience it as the deploy being easy.
And yet the word "process" tastes like ash to most engineers, for a reason Taleb supplies elsewhere -- this time about skin in the game. In a large organisation, process genuinely is dead weight, and the mechanism is structural. In a big enough company, the people who write the process are paid to write process. That is the entire job. They are measured on the volume and defensibility of the policy they produce, not on whether the team ships, and crucially they don't feel the downside of what they write. They don't get paged at 3am. They don't lose the customer. They don't watch the billet turn to scrap. They don't waste half a year of a PhD having to do paperwork to prove that they understand the risks of distilled water. With no skin in the game, they produce process the way any system produces what it's rewarded for: abundantly, defensively, and with no off-switch. Every incident adds a rule. Nothing ever removes one. It's via negativa run exactly backwards -- pure addition, forever, by people who never have to live inside the result.
Process written by people who never get paged ages into red tape. Process written by the people who do ages into reflexes.
The starkest example of process paying for itself isn't from software at all. On 10 April 1963, the submarine USS Thresher flooded and sank on a deep-diving test in the North Atlantic, killing all 129 aboard; a brazed pipe joint is thought to have failed, and the ballast system couldn't blow her back to the surface in time. The US Navy's answer was SUBSAFE, a submarine quality-assurance regime that is via negativa made literal -- a body of rules whose only job is to enumerate what not to do again, each line written around a specific failure. In the six decades since, the only submarine the Navy has lost was USS Scorpion, in 1968 -- and it had never been SUBSAFE-certified. The Navy is not a lean startup and SUBSAFE is not light; it works anyway. Process doesn't ossify because an institution is large. It ossifies when the people who write it never have to ride the boat down.
How to make it work
Step back, and the rot traces to a single source. In most organisations process hardens into bloat and barriers because the people writing it have exactly one assignment -- produce process -- and that assignment floats free of every outcome the business is actually chasing. They author the rule; someone else lives inside it. Shielded from the consequences of what they impose and rewarded only for the rules they ship, they have every reason to keep piling them on and none to ever take one away. A system built that way can only accumulate.
Hand the same process to the engineers who actually feel its consequences, and it inverts. It starts getting subtracted as often as it's added, because the person maintaining a check that no longer catches real bugs is the same person it slows down every single day -- so they delete it, and they're right to. It stays cheap to follow, because anyone made to follow something expensive and pointless is standing right there with the authority to fix it. It tracks reality, because it's owned by the people closest to the reality. The process stops being a cage built by one group to constrain another and becomes a tool a team builds for itself.
And once that's true, the three axes turn out not to be three separate burdens at all. They're one machine, and any engineer who's built a control system will recognise it on sight.
It's a feedback loop. Measurement is the sensor -- without it you don't control the quantity at all; at best you can only influence it, flinging an input out with no feedback on where it lands. Test is the comparison against the setpoint -- the error signal, the gap between what you wanted and what you actually got. Process is the controller -- the action that closes the gap, plus the wiring that runs the whole loop again next time. A team that has cut all three to "go faster" is running open-loop: full power to the actuators, no sensor, no error signal, no correction, just an honest hope that the trajectory was right when it was set. It feels fast because nothing is slowing it down. It is fast -- right until the moment it isn't, and by then it has no idea how far it has drifted, because drift is precisely the thing it stopped measuring.
This is what "lean" actually means, and it is nearly the opposite of what it gets used to mean. Lean isn't fewer controls. It's a tighter loop -- measuring sooner, catching the error smaller, correcting faster, with less ceremony between sensing and acting. Lean isn't spending less, either. It's spending effectively and measuring the result -- because it's the measurement that reveals the waste, and a lean team cuts what it finds, financial or operational, fast. A startup's real advantage over the incumbent was never that it has no process. It's that its loop can be tiny: the person who notices the problem, the person who decides, and the person who fixes it can be the same three people in the same room, or the same one. That tiny loop is what lets a startup make good on the case Mike Cassidy made back in 2008 -- that speed itself is the primary business strategy, not merely a nice-to-have. Throw the loop away to move faster and you've thrown away the one structural edge you had.
Without that loop, a team isn't slow so much as lost -- motion without bearing, a random walk in the dark, busy covering ground it has no way to keep. Run the loop instead, owned by the people who feel its consequences, and it stops being a loop and becomes a flywheel: every turn banks the last one's lesson, every correction makes the next one cheaper, and the longer it spins the harder it drives you forward. Standardising it -- the same checks, the same paved roads, across a team and then the whole organisation -- is what makes that speed point one way for everyone: a hundred people each correcting fast on their own is a hundred people moving fast in a hundred directions. Standardise the loop and they move fast in the same one.
The fast shop is not the one that skips the probe. It's the one whose setup is disciplined enough that it can trust the machine to run all night, lights off, no one watching, and find a bin of good parts in the morning. Speed isn't the absence of the three axes. It's what you're allowed to do once they're solid enough to stand on. A team that cuts measurement, test, and process to go faster is a machinist skipping the probe to save thirty seconds -- and the billet was always worth more than the time.
