The Phallacy of Fast

…or, Speed and quality aren't the tradeoff you think they are

The rocketship analogy is everywhere in tech. Leaders love it. "We're building the rocket while flying it" - you've heard it. I've heard it. I probably know said it once (regret it.)

Here's the thing though: actual rocket science does not tolerate rushing. Not even a little. The launch lasts seconds. The preparation takes years. And the years are why the seconds work.

We keep borrowing the romance of the rocket while quietly discarding its entire epistemology.

This is a POV about speed, specifically, the pressure to move faster that gets applied across product teams: to engineers, to PMs, and increasingly, to designers. It's about what that pressure actually produces, what it quietly costs, and why the intuition behind it - that faster equals more - is not just wrong, but measurably, documentably wrong across disciplines that have nothing to do with software.

This isn't a designers-defending-designers argument. The research doesn't care about org charts.

The Conflation

The conflation I keep running into is speed of innovation versus speed of design. They get treated as the same variable. They are not. But when they get mushed together - and they do, constantly - design is usually the thing that absorbs the pressure. Ship faster. Iterate in public. We can always fix it later.

I spent time at Apple early in my career. The bar there wasn't "ship fast." It was: does this feel inevitable? Is it so intuitive that the effort behind it disappears completely? That standard is uncomfortable. It requires you to go backward sometimes - to throw out something that works b/c it doesn't feel right yet. Post-Apple, I've lived on the other side of that argument too. Context matters. Tradeoffs are real. I'm not here to be absolutist about it.

But here's what I keep seeing, and what the research keeps confirming...

What the Research Actually Says (thanks to my trusty agent - say Hi, Chip)

Goodhart's Law says that when a measure becomes a target, it ceases to be a good measure. The moment speed becomes the metric, speed decouples from the thing it was supposed to represent - quality output. You're no longer measuring progress; you're measuring the appearance of it.

Amy Edmondson's work at Harvard found that the best medical teams reported more errors - not fewer. From the outside it looked like underperformance. It was the opposite: they were surfacing problems instead of hiding them. The "worst" teams by error-report counts were suppressing information. The metric said one thing; the reality said the opposite.

Deming spent a career arguing that "top performers" by conventional measures are often just people who found workarounds - not people building better systems. His research showed that most variation in output is systemic, not individual. Rewarding speed rewards the person gaming the system; it penalizes the person sustaining it.

The Cobra Effect makes this almost darkly funny: the British offered bounties for dead cobras in India, so people started breeding them. Reward the visible metric, get the opposite of the intended outcome. The incentive structure produced exactly what it was trying to eliminate.

In software, they call it the velocity trap. Teams that rack up the most story points do it by quietly cutting corners on testing and code quality - creating debt that slows everything down later. The "slowest" engineers are often writing the most sustainable code. Sound familiar?

Design has its own version of all of this. And it's been costing us - costing you (cross-functional partner) - in ways that don't show up until they're expensive to fix.

The Invisibility of Craft

What looks like craft taking too long is often craft bearing a cost the organization isn't measuring. A cost that doesn't disappear - it just moves downstream where it's harder to see and more expensive to address. Support tickets. Redesigns. User confusion. Churn. The elegance of a great product experience hides its own making; leadership sees a clean interface and thinks: that was easy. They can't see the thirty discarded directions, the three rounds of user testing, the Thursday evening argument that finally resolved the thing.

The invisibility of craft is what makes craft chronically undervalued.

Slow is smooth. Smooth is fast. That's not a platitude - it has receipts across every serious discipline that deals with complexity at scale. Rocketry. Medicine. Manufacturing. Music. The pattern is consistent enough that at some point you have to stop calling it a coincidence.

The question worth sitting with - for PMs, for engineering leads, for anyone making resourcing decisions about product teams: how do we make the preparation as legible as the launch? Because if you can't see what the years of work actually are, you'll keep mistaking the seconds for the whole story.

And you'll keep asking for more seconds, wondering why you keep running out of them.

So What's the Resolution?

This isn't an argument against speed. It's an argument for earning it.

The path to moving faster - genuinely faster, not just metric-faster - runs directly through the thing most product organizations treat as a cost center: the design system. Not as a library of pretty components. Not as a consistency exercise. As infrastructure. As the encoded institutional knowledge of every hard decision, every resolved argument, every "we tried that and here's why it didn't work" that would otherwise live only in someone's head until they leave the company.

When a design system is built with intention - when it captures not just the what (tokens, typography, color, spacing, motion, accessibility) but the why (the rationale, the philosophy, the logic behind the decisions) - something important happens. You stop relying on tribal knowledge to produce quality. The craft gets systematized. And with AI as a documentation and reasoning layer woven into that system, the intelligence embedded in it becomes accessible at a speed and scale that no team of humans working from memory ever could.

That's not a future state. That's the direction this is heading - and the organizations that invest in it now, deliberately and without rushing the foundation, are the ones that will actually win on speed later.

We can move faster. We want to move faster. But first we have to tie our shoes.

Because nothing slows a race down quite like stopping mid-sprint to deal with something you should have handled at the starting line.