Shipping fast is a habit, not a hack

Every few months someone asks me how our team ships as often as it does. They usually expect a tool recommendation. Some framework, some magic CI setup, something they can install.

The honest answer is boring: we ship fast because we've made shipping fast the default, and we protect that default like it's a feature of the product. Which, in a way, it is.

Here's what that actually looks like day to day.

Scope is the only lever that always works

You can't type faster. You can't review faster beyond a point. The only thing you can always shrink is the scope of what you're shipping.

When a feature is dragging, my first question isn't "what's blocking you?" It's "what can we cut and still ship something useful this week?" Nine times out of ten there's a smaller version hiding inside the big one — fewer settings, one platform instead of three, a manual step where we dreamed of automation. Ship that. The feedback you get from the small version will change what you build next anyway, so the grand version you postponed was probably wrong.

I've seen features sit in development for two months, and when they finally launched, the part users actually cared about was something we built in the first week.

Releases should be boring

If releasing is an event — a thing you plan around, schedule meetings for, or feel nervous about — you will do it less often. That's just human nature. Nobody volunteers for stress.

So we spent real effort making releases uneventful. Push to main, pipeline runs, it's out. No release captain, no war room. The first time a new engineer ships to production in their first week, something clicks for them: oh, this is just a thing we do, not a ceremony.

The counterintuitive part is that shipping more often made us safer, not riskier. Small diffs are easy to review and easy to roll back. The scary releases were always the big ones.

Momentum is a team feeling

This one is softer but I think it matters most. Teams have a metabolism. When things ship every week, people bring up ideas casually because trying something is cheap. When things ship every quarter, every idea becomes a negotiation, because the cost of being on the roadmap is huge.

I've worked in both modes. The fast mode isn't just more productive — it's more fun, and fun is weirdly underrated as an engineering strategy. People do their best work on teams where their work regularly reaches real users.

None of this requires special tools. It requires deciding, as a team, that shipping is normal — and then noticing every time something makes it less normal, and fixing that instead of accepting it.

That's the whole secret. It's a habit. Habits are boring. Boring works.