Every studio has a story about the project that shipped in two weeks and looked, for one shining moment, like a triumph of velocity. The same studio has a quieter story, months later, about the rebrand that had to be redone, the component library that had to be rebuilt, the launch that slipped because nobody had agreed on what they were building. The two stories are usually the same project.
We've been trained to treat speed as virtue and slowness as waste. But after enough cycles of build, regret, rebuild, I've come to a quieter conviction: the projects that take less time overall are almost always the ones that move slowly at the start. Slowness isn't the opposite of speed. It's a method for getting to speed without paying for it twice.
What speed actually costs
The bill for moving too fast rarely arrives on the invoice. It arrives later, disguised as other things:
- Rework. The deck that gets rebuilt three times because the strategy wasn't agreed before the visuals. The feature that ships, gets pulled, and ships again because the problem wasn't understood.
- Debt. The token that became six tokens, the component that became a fork, the shortcut that calcified into a standard because nobody had time to do it right the first time.
- Misalignment. The launch where design, engineering, and the client each discover, on the day of, that they were building three different products with the same name.
- Exhaustion. The sprint that ran on adrenaline and takeout, and the team that ran on fumes for the next two months as a result.
None of these show up in a Gantt chart. All of them show up in the next quarter.
The value of the incubation phase
The most undervalued part of any project is the bit at the beginning where nothing visible happens. No screens, no components, no Figma frames to share in the standup. Just questions, interviews, half-formed thoughts, and a whiteboard that gets erased three times a day.
Stakeholders hate this phase because it produces no artefacts. That's exactly why it's valuable. Artefacts create momentum, and momentum is expensive to reverse. A sketch can be thrown away in an afternoon. A polished mock becomes a position that has to be defended, then compromised on, then lived with. The longer you stay in the cheap-to-change zone — words, questions, rough shapes — the less you spend defending decisions you haven't really made yet.
The cheapest hour in a project is the one spent deciding what not to build. The most expensive hour is the one spent building it anyway.
We've started treating incubation as a deliverable in its own right: a written brief, a shared vocabulary, a short list of things we've agreed to leave out. It looks like nothing on a calendar. It saves months later.
Critique is compression
A good critique session feels slow. Five people in a room for an hour, talking about one screen, leaving with two small changes. On paper, a disaster. In practice, it's the highest-leverage hour of the week — because those two small changes are the ones that would have cost a sprint to undo after launch.
Critique is a form of compression. It takes the diffuse disagreement that would otherwise surface as rework, late feedback, and "actually, can we try..." emails, and concentrates it into a single hour where it's cheap to resolve. Teams that skip critique don't avoid disagreement. They spread it across the whole timeline, where each instance costs ten times as much.
The trick is to separate the two things critique often collapses: judging the work and fixing the work. Do the first in the room. Schedule the second for later. Mixing them turns critique into a redesign meeting, which is slow in all the wrong ways.
Saying no is a scheduling decision
The fastest way to finish a project is to do less of it. This sounds obvious and is almost never practised. Most timelines I see are stuffed with features that exist because someone asked for them once, not because anyone can remember why they matter. Cutting them isn't a compromise. It's the only honest way to hit a date without mortgaging the next quarter.
The teams I admire treat scope the way surgeons treat tissue: cut generously around the thing that matters, protect the core, and accept that you'll leave some things on the table. The teams that try to keep everything end up shipping nothing well.
Slow is faster, eventually
Here's the counterintuitive part. Once a team has practised slowness for a while — the incubation, the critique, the ruthless scope — something flips. They start shipping faster than the teams that optimised for speed from day one. Not because they cut corners, but because they stopped paying the tax on corners cut earlier.
The shared vocabulary means fewer meetings. The agreed scope means fewer pivots. The well-worn critique process means feedback arrives in a useful form, not as a Slack message at 11pm. Slow, practised over months, compounds into a team that can move quickly because it rarely has to backtrack.
Speed is what you have left when you've removed the reasons to be slow. You don't get there by hurrying. You get there by being deliberate about which parts deserve the time — and defending that time, even when the calendar is screaming at you.
The next time someone asks whether you can ship it faster, the honest answer is almost never "yes, by working harder." It's usually "yes, by deciding less." And deciding less, paradoxically, is the slowest skill a team ever learns.