Move fast and build things without breaking people

I spend my weekends painting Warhammer 40,000 miniatures, and there's a rule in that hobby that transfers directly to my day job: thin your paints. One thick coat looks faster than three thin ones, right up until it buries the detail and you're stripping the model back to bare plastic, which costs more time than every coat you thought you were skipping. Anyone can slap paint on a model quickly. The speed you get to keep is set by the discipline of the layers underneath.

Our fifth commitment reads "move fast and build things," and people who remember the original slogan usually wait for the irony. There isn't any. We mean it. We just refuse the false trade the industry attached to it, the assumption that speed is purchased with recklessness. The evidence says otherwise, and so does every 2 a.m. rollback I've ever been on the wrong end of.

The trade-off that isn't

The DORA research program, the largest ongoing study of software delivery performance, published in book form as Accelerate, spent years testing the folk belief that you can have speed or stability but not both. Across thousands of organizations, the belief turned out to be simply wrong. The teams that deploy most frequently also have lower change-failure rates, and they recover faster when something does break. Speed and stability aren't two ends of a dial. They're joint outputs of the same underlying system: small batches, continuous integration, automated tests, deployment pipelines you actually trust.

In other words: fast is an outcome, not an input. You don't get it by pressing harder on the gas. You get it by building the machine that makes going fast survivable.

What recklessness actually costs

If you want the canonical counterexample, it's Knight Capital, August 1, 2012. A manual deployment pushed new trading code to seven of eight servers. The eighth kept running an old code path, reactivated by a repurposed feature flag, and began firing orders into the market with nobody aware and no kill switch ready. Roughly forty-five minutes later the company had lost more than $460 million, the SEC's figure, several times its annual profit, and was effectively finished as an independent firm.

Notice what killed them. Not slow engineering. Not too much process. A missing deployment gate, a missing verification step, a missing safety system. The thin, boring layers underneath. Knight was moving fast right up until the moment it mattered.

Where the speed really comes from

The practices behind this commitment are mundane, which is the point. Real speed is boring:

• We write the spec first. Clarity is the cheapest accelerator we own. Most "slow" teams aren't slow; they're confused, and their velocity is being eaten by rework. An afternoon spent making the goal precise routinely buys back weeks of building the wrong thing quickly.
• Validation runs continuously. Tests, review, and working-software checkpoints happen throughout the work, so surprises surface while they're small instead of all landing on the last day of the sprint. Batch up your validation and you've batched up your risk.
• Every stage has a quality gate. Nothing ships unreviewed, not because we distrust the team, but because gates are what let the team move without fear. A pipeline that catches mistakes is the psychological difference between driving fast on a track and driving fast in fog.
• We push back on invented deadlines. A date with a real constraint behind it, a contract, a season, a regulatory window, deserves respect and gets it. A date somebody made up to create urgency is a defect in the plan. Performative urgency doesn't make teams faster; it makes them skip exactly the steps that keep speed sustainable.

That last point connects to the part of the commitment I'd underline twice: never by burning out the team. Sprinting people past their limits is borrowing speed from next quarter at a vicious interest rate. The roadmap doesn't care how fast you went in March if half the team is gone by June.

Judgment is the multiplier

Speed without responsibility breaks products and people; that's on our values page. The version I'd add from the painting desk: speed with judgment compounds. Every solid spec, every trustworthy pipeline, every gate that catches a mistake early makes the next sprint faster than the last one. Recklessness spends the future. Judgment invests in it. We intend to still be fast in five years, which is exactly why we won't be reckless this week.

Sources

• DORA, "DORA's software delivery metrics: the four keys", and Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate (IT Revolution, 2018): the research archive lives at dora.dev/research.
• U.S. Securities and Exchange Commission, In the Matter of Knight Capital Americas LLC, Release No. 34-70694, October 2013.