An 80% Team Beats a 95% Team

For years I've told my teams the same thing, whatever the work was: get it to 80% and ship it. It reliably makes people flinch, because it sounds like a license to be sloppy, and it's the opposite of that. It's the most demanding standard I know, because it asks you to give up the version of the work you'd be proud to show at a conference in exchange for the version that's actually learning something.

The reasoning I give them is simple. People are happier having things done than having them perfect. You learn from what you shipped, not from what you polished, and you carry that lesson into the next thing. And it compounds – a team that ships at 80% and learns gets better every cycle, until its 80% is genuinely better than another team's 95%, because one of those teams has been meeting reality every week and the other has been admiring its own work in a branch.

The cost of the last fifteen percent is invisible

Here's why over-polishing is so hard to catch yourself doing: when you ship something rough, the cost is visible. You can see the shortcut. You feel the cringe when a colleague reads it. It sits in your chest during standup. So your instinct is to eliminate that visible cost by polishing until it's gone.

But the cost of the polish is invisible, and it's usually bigger. One engineer wrote about tracking which shortcuts he actually had to go back and fix – the answer, for him, was about one in five. The other four-fifths were fine. Meanwhile, nobody counts the features that didn't ship while the one feature was being perfected, or the customer conversations that didn't happen because the thing wasn't ready, or the deadline that slipped because "we're almost done, just cleaning it up." Over-engineering even feels responsible while you do it – you're "doing it right," "avoiding tech debt." But debt you take on deliberately, with your eyes open, is a tool. Not shipping because it isn't perfect yet is just fear wearing a more professional outfit.

The shapes it takes are familiar once you look for them. Building an elaborate caching layer for data customers turn out not to access. Reaching for the perfect abstraction the first time you write something, before you've built it twice and actually know what the abstraction should be. Adding retry logic and graceful degradation and background jobs to a feature that ends up serving a fraction of the load anyone imagined. Each one feels like craftsmanship in the moment. Most of it is building for a scale, a flexibility, or an edge case you don't have yet and may never – and while you build it, the three things that would have told you what to build instead never ship.

The bar that actually matters isn't "would I be proud to show this." It's: does it solve the real problem, is it safe, and can someone else understand it. That's 80%. The remaining 20% is where most of the invisible cost hides.

Shipping is the learning loop

The deeper reason to ship early isn't speed – it's that shipping is the only feedback loop that surfaces the things you didn't know you didn't know. No amount of internal review reliably finds those; they only show up when the work meets a real user doing something you never designed for. Ship, observe, revise – the length of that loop is your learning rate, and a rough version that ships this week teaches you more than a polished one that ships next month.

This has gotten sharper, not softer, in the last couple of years. AI collapsed the build phase from weeks to hours, and as one product team put it, everyone ships fast now – the constraint has moved from building to measuring and learning. When building is the cheap part, the team that wins isn't the one with the highest polish. It's the one running the tightest ship-and-learn loop. And you have to make peace with the arithmetic there: a good chunk of what you ship won't land, and the small fraction that does pays for all of it. Treat that as a budget, not a verdict. A flat result isn't a failure; it's one loop's worth of information, and the team that keeps running loops keeps getting the information.

It's also how you get out of the way

There's a second reason I push teams to 80%, and it has less to do with the work than with the leader. If nothing ships until it's perfect, and your bar for perfect is the real bar, then everything routes through you. You become the exact bottleneck you keep complaining about. Accepting good-enough is the price of delegating – it's how you make yourself unnecessary to the day-to-day, which is the actual job of a leader who wants the team to grow rather than to depend on them. A team that can only ship at your 95% is a team that can't ship without you standing over it. A team that ships at 80% and learns is a team building its own judgment, cycle by cycle, until their calls are as good as the ones you'd have made, and then better – and you're freed up for the small number of decisions that genuinely need you. Underneath the maxim is a harder ask than tolerating imperfect work: trust a team enough to let them learn in public, and trust yourself enough to let go of the parts that were never the highest use of your judgment anyway.

Where 80% is the wrong bar

None of this applies to one-way doors, and it's important to say so, because "just ship it" gets quoted into places it doesn't belong. Ship at 80% is a rule for reversible, two-way-door work – the feature, the page, the draft, the thing you can watch and revise. The irreversible calls earn the extra time: who you hire, whether you take outside capital, anything that touches safety, security, or a regulated obligation. Those are one-way doors, and the whole point of moving fast on the reversible work is that it frees up your judgment for the handful of decisions that actually deserve to be slow.

That's the real trade. Not fast versus good – that dichotomy is fake, invented by people who've never watched a fast team compound. The real trade is where you spend your caution. Pour it into polishing reversible work and you starve the decisions that can't be undone. Spend 80% on the reversible and save the perfectionism for the one-way doors, and a strange thing happens: the team gets faster and better at the same time, because it's finally learning at the speed it ships.