Shipping faster without shipping worse
Velocity is a design problem before it is an engineering one. Cut the decisions, not the corners.
Velocity feels like an engineering metric. So teams reach for engineering levers: more parallelism, more contractors, a faster CI pipeline, a sprint that's somehow one day longer. These help at the margin. They almost never fix the thing that's actually slow, because the thing that's actually slow is rarely the typing. It's the deciding.
Watch where a feature actually loses time and you'll find it stalled in ambiguity. Three people hold three different mental models of what "done" means. The Slack thread has forty messages and no resolution. An engineer is blocked not because the code is hard but because nobody will say which of two reasonable options to take. Shipping slowly is usually a symptom of deciding slowly, and you don't fix a decision problem with a faster CPU.
Cut the decisions, not the corners
The instinct under deadline pressure is to cut quality — skip the tests, ship the rough edge, leave a TODO that becomes a tombstone. That's cutting corners, and it's a loan against next quarter at a punishing interest rate. The corners come due, usually at the worst time, usually compounded.
The better move is to cut decisions. Most features carry a surprising amount of optionality that nobody actually needs: the configurable setting only one customer asked for, the second layout no one will use, the empty state designed for a path users never hit. Every one of those is a decision someone has to make, defend, build, and maintain. Remove the decision and you remove all four costs at once — without lowering the bar on anything you actually ship.
- →Pick one default instead of exposing a setting.
- →Support the real path; delete the hypothetical one.
- →Ship the version you can name in a sentence.
Speed comes from doing fewer things deliberately, not from doing the same number of things faster.
Decide once, in the open
When a decision does have to be made, the cost isn't in the choosing — it's in the re-litigating. A choice made in a hallway and never written down gets made again every time a new person touches the work. Three weeks later the same debate reopens, now with more context lost and more code already written against the unstated assumption.
So write the decision where the work lives. One line in the PR description, the spec, the ticket: we're doing X, not Y, because Z. It takes thirty seconds and it ends the conversation permanently. The point isn't ceremony or a heavyweight RFC process. The point is that a decision recorded once is a decision that stops costing you. A decision held in someone's head is a tax every other person pays on their way through.
This is why velocity is a design problem. Design — real design, not pixel polish — is the discipline of deciding what something is and, just as hard, what it isn't. A sharp design closes options on purpose. It hands engineering a small, clear surface instead of a wide, vague one. The team moves fast not because anyone is rushing but because there's simply less left to argue about.
Protect the floor while you raise the ceiling
Cutting decisions is not the same as lowering standards, and the difference is the whole essay. The floor — does it work, is it safe, can you trust it — never moves. What moves is the ceiling: how much you attempt. Going faster means attempting less in any given release, not building the same scope to a shabbier standard.
A good test for any deadline: if I have to be late or be bad, I will be late. Lateness is a one-time cost you pay and recover from. Bad is a recurring cost that follows the product around, eroding trust with every person who hits the rough edge. Teams that ship worse to ship faster usually end up doing neither for long.
Ship less, decide sooner, write it down. The corners stay intact because you never had to cut them — you simply built fewer of them, on purpose.
