Shipping culture vs launch culture

Two engineering cultures, distinguishable by one question.

What gets attention around here.

In a launch culture, attention arrives at the announcement.

A date. A marketing beat. A big reveal, and a Slack channel filling with rocket emoji. Work gets organised into things that can be launched, because unlaunched work is invisible and invisible work isn't rewarded.

In a shipping culture, attention is on the rate.

Something goes out most days. There's a changelog. The interesting question isn't what launched this quarter, it's whether the line is going up.

Both ship software.

They select for completely different behaviour, and the selection happens quietly, through what individual engineers choose to work on in the hours when nobody is directing them.

What each one produces

Launch culture produces work sized to be announced. Which means bigger batches, which means everything in the small-batches lesson happens to you.

It concentrates risk on a date. And it rewards the visible half of the work while quietly starving the other half, because a reliability improvement has no launch moment attached to it and therefore no reward waiting at the end.

There's a specific pathology worth watching for. Features get finished for the launch and abandoned afterwards.

The follow-through, the second iteration once you can see how people actually use the thing, has no moment attached, so nobody chooses it. You end up with a product full of things that are eighty percent done and were announced as complete.

Shipping culture produces continuous small improvement, faster feedback, and a much healthier relationship with risk.

It has its own failure mode, and it's worth naming. Without any moments at all, work becomes an undifferentiated stream, nobody outside engineering notices anything, and the team loses the sense of building toward something.

A hundred small improvements can be worth more than a launch and feel like less.

So the answer isn't abolishing launches.

Ship continuously, and place the moments deliberately, rather than letting the need for moments decide how work gets batched.

The launches worth keeping

Some things genuinely need a moment. Fund those properly rather than pretending otherwise.

When a customer has to do something differently, they need telling, and telling them is a campaign rather than a changelog entry.

When you're entering a market or repositioning, the announcement is the product decision.

And occasionally a team just needs a shared thing to point at. Legitimate reason on its own.

The mechanics that stop a launch dragging your whole delivery model backwards: build it in small pieces behind a flag, ship each piece as it's ready, and let the launch be the day somebody turns the flag on.

Now the launch is a marketing event rather than an engineering one. The difference is that nothing is integrating for the first time in the week before a date.

That separation, deploy continuously and release when you choose, is what lets you have both.

Most organisations that feel trapped in launch culture are trapped by not having feature flags.

Making the invisible work visible

If the only work that gets seen is work with a launch, then reliability, performance, developer experience and cleanup are all unrewarded. Rational people will avoid them.

Fixing that is mostly a communication job. One of the highest-return things an engineering leader does.

The weekly demo does most of it, because a demo of an internal tool or a faster build lands in front of the same audience as a customer feature. It's covered in its own lesson, and it's the mechanism I'd put in place first.

A changelog in plain language does the rest, and it has to include the unglamorous entries alongside the features.

"Deploys now take four minutes instead of nineteen." A non-engineer understands the value of that immediately, if somebody tells them.

Then the framing job, which only you can do.

Translate invisible work into the currency the business already cares about. A performance improvement is a conversion number. A reliability fix is support tickets that never happened. A build-time reduction is engineering days per month.

Do that translation yourself, publicly and repeatedly, or nobody does it.

Celebrating without it feeling forced

Recognition in engineering goes wrong predictably.

It becomes a ritual. The ritual becomes obligatory. And obligatory enthusiasm is worse than none at all.

What works is specific, small, and attached to the actual thing.

Name the person and what they did, in the room where it matters, once, accurately. "The deploy pipeline is four minutes now. That was Priya. It's about two engineer-days a week back across the team."

Thirty seconds. No ceremony.

What doesn't work: employee of the month, a standing kudos slot, anything requiring people to nominate each other on a schedule.

Those produce reciprocal nominations and a slow drift into meaninglessness.

The strongest signal available is where your own attention goes.

Ask about reliability every week and about the launch every week, and both are important. Only ever ask about the launch, and no amount of celebrating maintenance will convince anybody it counts.

The tell

Ask an engineer what they'd work on if nobody was watching, and then ask why they aren't.

If the answer is a list of things they know would help and nobody would notice, you have a launch culture. Whatever the values page says.

The fix isn't a new value. It's changing what gets noticed, which is entirely within your control and takes about a quarter to show.