Speed is an outcome, not a value

I've worked with teams that had "move fast" in their operating principles and a two-week PR review cycle. Both true at once.

Nobody found it strange.

That part is worth sitting with. Not that the team was slow, because plenty of teams are slow for good reasons, but that the value and the reality sat side by side for months, in plain view, and nobody felt the contradiction. The value was aspirational rather than descriptive. Everybody in the building understood that without having to say it.

The claim

Speed is an outcome. It is not a value.

Every fast company I've seen became fast the same way: they removed the things that made work slow. Not one of them got there by deciding speed was a value.

When speed is a value it lives in the handbook, the all-hands, and the recruiting pitch, while the work continues to move at whatever pace the system allows. And the system doesn't read the handbook.

Speed as a value gets announced. Speed as an outcome gets noticed, usually by someone who can't say when it happened.

Why declaring it doesn't work

A value is a statement about what people should prefer when they have a choice.

Most slowness is not a choice. An engineer does not wait two days for a deploy because she prefers caution. She waits because the deploy takes two days. Same with the finished feature she's sitting on. Not thoroughness. The one person who can approve it is in back-to-back meetings until Thursday.

Tell that engineer speed is a value and you haven't changed any of her options. Just added guilt to the wait.

Worse, you've told her something about how leadership sees the problem, because if the fix is a value, the implied diagnosis is that people are not trying hard enough. She knows that is not true. She can see exactly where her week went, and now she knows you can't.

Culture is downstream of friction

Removing friction is operational work, not cultural work.

Most of the lifting in this piece happens in that one sentence, so it is worth being concrete about what operational means here. Where a feature sits waiting after the code is written. How long a new engineer takes to ship their first thing. Who has to be in the room when a decision needs making, and whether they are ever all in it at the same time.

Unglamorous questions, all of them, with answers that are usually specific and a little embarrassing.

A two-day deploy process. A review bottleneck that traces back to one person. A spec that arrives late and gets rewritten twice.

None of those is a culture problem. Each one is a named, fixable thing with an owner, and no amount of values work touches any of them, since culture cannot override a broken deployment pipeline or a six-person approval chain.

The cultural piece is real, though. Just downstream. Once the friction is gone you have to actually let people move (tolerate quick, imperfect calls, stop relitigating what already shipped, trust the person closest to the work), and that only matters after the operational constraints are gone. Do it in the other order and you're asking people to move fast through a system that won't let them, which is how you get the handbook and the two-week review cycle living happily together.

Change a culture fast makes the broader version of this argument, that behaviour moves belief and not the other way round. Here it is the special case where the behaviour you want is blocked by plumbing.

What making it an outcome looks like

Start with an honest look at where work actually stops. Not whether you're fast enough in the abstract, because that question has no answer and invites a debate. Where it stops.

Trace one change. Follow a real feature from the moment the code was written to the moment a customer could use it, and write down every place it waited and what it was waiting for, because the waits will tell you more than any survey and they'll be embarrassing in exactly the way that makes them useful.

Then fix those. One at a time, in order of how much waiting each one causes.

Usually the pipeline comes first, since it touches every change, and straight to production covers that end to end. The review queue is usually second. Increasingly it's the real constraint, because review capacity is the new bottleneck the moment code gets cheap to write. Third, and hardest, is the decision path, where the fix is usually a person giving up a sign-off.

Then let people move. That's the cultural half, and it only works once the operational half is done.

Do not announce any of it

People find this instruction the hardest to follow, and I think it's the most important one.

Don't launch a speed initiative. Don't name it. No slide in the all-hands about velocity, no new line in the operating principles.

Three reasons.

First, announcing it turns it back into a value. The moment there's a programme with a name, the work becomes about the programme: its status updates, its metrics, its sponsor. And the friction you were meant to be removing becomes one workstream among several.

Second, an announcement sets up a scoreboard. People start measuring whether things feel faster, which is a mood, instead of measuring where things wait, which is a fact. Moods are easy to argue with.

The third matters most. When you fix the deploy process quietly, what engineers experience is that their day got better. Announce that you're fixing it and what they experience is a promise, and they've heard promises before. One version builds trust. The other spends it before you've delivered anything.

If it works, somebody will notice. They'll say something in a retro or a one-to-one like "I don't know when this happened, but shipping feels different now." That's the outcome. It is also the only evidence worth having, because nobody manufactured it.

Keeping it once you have it

Getting fast isn't the hard part. Friction comes back.

Slow pipelines are built by accretion. Approval chains too. Every step that slows work down was individually justified by somebody who'd been burned, and each one looks reasonable on its own, so an organisation left alone drifts back toward the pace it had before, one sensible addition at a time.

So the fix is not a project with an end date. It is a standing habit of looking at where work waits and removing what's there. Keeping speed at scale covers what that looks like once the org is big enough that nobody can see the whole path any more, and why the platform layer is what buys it back.

The short version holds at every size, though. You don't get speed by wanting it. You get it by finding the specific things in the way, removing them, and keeping quiet while you do.