The cadence eats vision: what fifteen years of shipping taught me.

It's never the technology. It's never the strategy. It's never even the people, exactly. After fifteen years of watching teams ship — or fail to ship — what I keep coming back to is something much smaller, much more boring, and much harder to talk about: the cadence of the conversation.

Here's what I mean. Two teams set out to build the same thing. They have the same budget, the same talent pool, the same six months. Three months in, one team is showing demos at all-hands. The other is still rewriting their product spec for the fourth time. Same inputs, opposite outputs.

Cadence eats vision

People love to talk about vision. Vision is exciting. Vision is what you put on the homepage. But vision is also free — every company has one, every founder can recite theirs in fewer than thirty seconds, and yet most of them won't ship.

Vision tells you where you're going. Cadence tells you whether you'll get there.

What separates the team that ships from the team that doesn't is almost never the quality of their vision. It's the tempo of their decisions. Daily standups that actually move blockers. Weekly demos that show real artefacts. Monthly retros that produce changed behaviour, not just changed slides.

How to measure cadence

You can't optimise what you don't measure. But cadence is slippery — it's not "tickets shipped" or "lines of code". It's something more like: how long does it take for a question to become an answer?

• How long between "we need to decide X" and "X is decided"?
• How long between "this is broken" and "this is fixed in production"?
• How long between "I have an idea" and "we have a small experiment running"?

Track those three. If they're trending up, your cadence is decaying. If they're trending down, you're getting faster — and almost everything else will follow.

A caveat

Cadence is not the same as speed. A team that ships ten half-baked features per quarter has bad cadence, not good speed. Cadence is the regularity of useful output — not the volume.

This is the part that's hard to teach. The instinct, especially in a startup, is to confuse motion with progress. To celebrate shipping for shipping's sake. But cadence at its best feels almost ordinary — a kind of metronome. Things just keep happening, on time, at quality.

What this looks like in practice

Three habits I've seen in every high-cadence team I've worked with:

1. They write decisions down.
2. They demo, not deck.
3. They have a default for everything.

Write decisions down. This sounds boring. It's the single highest-leverage habit I know. Decisions that aren't written down get re-litigated. Decisions that are written down compound.

Demo, not deck. Slides are a tax on cadence. They take time to make, they require an audience, and they let people present the work without doing the work. Demos do the opposite — they require working software, and they make the gap between "talked about" and "actually built" undeniable.

Have a default for everything. The teams that move slowest are the ones that re-decide every small thing. Should we have a Monday meeting? Should we use this tool? Should we add this person to the channel? The fast teams have a default — usually "yes by default, opt out if needed" — and they save their deliberation for the rare important choices.

None of this is revolutionary. None of it shows up on a roadmap. But it's the actual mechanism behind every team I've watched ship something hard. The cadence is the work.