What high performance actually means
Speed is a symptom. A high-performing org is one that converts judgment into shipped outcomes with very little loss along the way.
Also available as a standalone Playbook →
Ask ten engineering leaders whether their organisation is high-performing and nine will answer with a story about speed. We ship fast. We got that feature out in three weeks. We deploy on Fridays.
Fine. Fast at what?
An engineering organisation is a machine for turning judgment into working software. Somebody decides a thing is worth building. Some number of weeks later, a version of that thing is running in front of customers. Everything in between is the machine. The only question that matters is how much of the original judgment survives the trip, and how long the trip takes.
That framing is unfashionable because it refuses to make engineering the hero. Most of the loss in a slow organisation happens outside the code editor.
Three places the work goes
Waiting. A change that took two days to write sits for four days in review, one day behind a release train, and two days behind a QA sign-off that finds nothing. Nine days of lead time, two days of work. When teams map this honestly for the first time, the ratio of active work to elapsed time usually lands somewhere between five and fifteen percent. People find this genuinely hard to believe about their own team, which is why mapping it beats arguing about it.
Rework. The feature ships, the requirement was misread, it comes back. Or it ships correctly and the design makes the next three features cost double. Rework is the most visible of the three because everyone can feel it, and it's the one engineers most often get blamed for when the cause was upstream.
Work that should never have started. This one is bigger than the other two put together, and almost nobody measures it.
A team that delivers the wrong thing with perfect efficiency has produced nothing. Worse than nothing: they have produced a thing that now needs to be maintained, supported, monitored, migrated, and eventually deleted by someone who wasn't there when it was built. Every feature you ship is a permanent liability that arrived disguised as a one-time cost. Shipping faster multiplies whatever your hit rate happens to be. If half of what you build gets used, doubling your delivery speed doubles the amount of dead weight you're carrying at the same time as it doubles the value.
This is the part of the argument people resist. It feels like an excuse for slowness, and it gets used that way by organisations that want permission to deliberate for six months. It isn't one. The correct response to a bad hit rate is not to slow down, it's to shorten the distance between shipping something and finding out whether it mattered. Small batches do that. Big careful plans do the opposite while feeling more responsible.
What the numbers actually tell you
The four DORA metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) are the best cheap instrumentation available, and I'd rather have them than not. They are also measuring exactly one of the three losses. All four describe the pipe between "engineer starts work" and "customer has it." None of them has any opinion about whether the thing was worth building.
An organisation can be elite on all four keys and still be one of the least effective engineering groups in its market. It happens constantly. The team is deploying eleven times a day, the dashboards are green, and the roadmap is a list of things a well-liked executive asked for in March.
So use the four keys as a smoke alarm rather than a scoreboard. If lead time is trending up, something is silting up and you want to know. If change failure rate is climbing, your safety net has a hole in it. Neither number will tell you that you're building the wrong product, and treating them as a definition of performance quietly hands that question to nobody.
The definition I had wrong
The first version of this lesson defined performance as output per engineer per unit of time. It's a tempting definition because it divides, and things that divide feel rigorous.
It's wrong for a specific reason. Output per engineer treats engineers as interchangeable units of production, which means the moment you optimise for it you start rewarding volume of change. Volume of change is trivially gameable and mildly harmful. The teams that score best on it are frequently the ones building the most maintenance debt per quarter.
The better version divides differently: outcomes delivered per unit of organisational attention. Attention is the genuinely scarce resource. Every engineer, every manager, every review cycle, every meeting where four senior people re-litigate a decision that one of them could have made. A high-performing organisation spends very little attention per delivered outcome. A slow one spends enormous amounts of it and produces meeting notes.
Headcount is the least interesting variable
Fred Brooks wrote The Mythical Man-Month in 1975 and the industry has spent fifty years agreeing with it in public and ignoring it in planning. Adding people to a late project makes it later. Adding people to a healthy organisation adds coordination cost immediately and capacity eventually, in that order.
The practical consequence: when someone tells you the constraint is headcount, they're usually wrong, and the fastest way to find out is to look at where work is currently sitting still. If the answer is "in review," "waiting on a decision," or "blocked on the platform team," then hiring five engineers buys you a longer queue and a worse onboarding experience.
Sometimes the constraint really is headcount. It's just the fourth or fifth thing to check, not the first.
How to test your own organisation
Pick the last five things you shipped. For each one, reconstruct two dates: the day somebody decided it was worth doing, and the day a customer could use it. Then estimate how many working days of actual effort went into it.
You now have three numbers per item. The ratio between elapsed days and effort days is your loss to waiting. The number of items you'd build again is your hit rate. Multiply them.
Most teams doing this for the first time get an uncomfortable answer, and the discomfort is the useful part. It's also usually the first time everyone in the room has been looking at the same picture of the machine they work inside.