Real speed looks like deliberate slowness

Speed is the most celebrated and least examined value in product. Everyone wants to move fast. Almost nobody wants to talk about what moving fast actually costs, or who pays for it, or when the bill comes due.

I’ve watched teams ship five product lines that each solved the same problem five slightly different ways, because every team was moving fast and none of them were coordinating. Fast, in isolation, felt great. Collectively, it produced a mess that took far longer to untangle than the coordination would have taken up front. The speed was real. It was also an illusion, because the organization as a whole had moved slower than if a few people had paused to agree on a shared foundation.

This isn’t just my observation. It has a price tag, and researchers have put numbers on it. McKinsey, in its work on technical debt, found that companies that actively manage the debt they’ve taken on can free up their engineers to spend as much as 50 percent more of their time on work that actually supports business goals. One CIO they interviewed described going from 75 percent of engineering time spent paying the “tax” of accumulated shortcuts down to 25 percent. Sit with that for a second. In the worst case, three of every four engineering hours were going to maintenance and rework rather than new value, and most of that debt was taken on in the name of moving fast.

The “move fast” tax shows up in independent research too. Studies drawing on Stripe’s developer survey and McKinsey’s engineering work consistently land in the same range: somewhere between a quarter and 42 percent of developer time goes to dealing with the consequences of shortcuts, depending on how mature the codebase is. That is not a rounding error. That is months of every year, per engineer, spent paying for speed that was booked earlier and never really earned.

At a healthcare company building for 27 million users, I saw this pattern about to repeat across five product pillars, each staffing up to build its own version of search, scheduling, and intake. So I pitched something that, on the surface, looked like the opposite of moving fast: stop, and build a shared component library first. It covered the pieces every pillar needed. It took time we supposedly didn’t have. Then every launch after it went faster, because nobody was rebuilding the same wheel, and feature adoption climbed 33 percent because the experience was finally consistent enough to trust.

Here’s what I actually believe. “Move fast” is not a strategy; it’s a preference, and it only produces good outcomes when it’s paired with a clear answer to “fast toward what, and at whose expense.” Velocity without shared direction is just a lot of teams generating divergent work that someone will eventually have to reconcile. The reconciliation is the hidden cost, and it’s almost never on the roadmap.

This isn’t an argument for slowness. It’s an argument for honesty about tradeoffs. Real speed at the organizational level often looks like deliberate slowness at the team level: agreeing on primitives, investing in reuse, saying no to the tenth bespoke solution. The teams that feel the fastest day to day are frequently the ones accumulating the most debt for everyone downstream, and the McKinsey and Stripe numbers are simply that debt made visible.

The next time someone frames a decision as “we need to move fast,” it’s worth asking the quiet follow-up: fast for us this sprint, or fast for the company this year? Those are often different answers, and the gap between them is where a lot of product organizations quietly lose their momentum, one unpaid shortcut at a time.

Sources: McKinsey & Company, “Tech debt: Reclaiming tech equity” (2020); Stripe / Harris Poll Developer Coefficient survey; industry analyses of developer time lost to technical debt.