When a team ships slowly, the instinct is to ask people to move faster. That almost never works. Speed is a property of the system, not the individuals – and a few systemic changes consistently produce outsized gains.
1. Make the pipeline boring
Releases should be a non-event. The moment shipping requires a heroic effort, teams batch changes, batching increases risk, and risk slows everyone down. Automated CI/CD with fast, trustworthy checks turns deployment back into something you do many times a day without thinking.
2. Shorten the feedback loop
- Fast local feedback: a developer should know something is broken in seconds, not in the next sprint.
- Small pull requests: they review faster, break less, and merge sooner.
- Observability in production: you can only move fast if you can see what's happening after you ship.
3. Pick boundaries on purpose
Most velocity is lost to coupling. When unrelated parts of a system have to change together, every feature touches everything. Clear service and module boundaries let teams work in parallel without stepping on each other – that parallelism is where the 40% comes from.
4. Automate the repetitive judgement
Anything a human does the same way every time – formatting, basic review checks, environment setup, repetitive outreach or data tasks – is a candidate for automation. Each one you remove gives the team back focus for the work that actually needs a human.
The takeaway
Cutting cycle time by 40% wasn't about pressure. It was about removing friction so that the fastest path and the safe path became the same path.