The False Trade-off
Teams that ship slowly often believe they're being careful. Teams that ship fast are assumed to be cutting corners. In my experience, both assumptions are wrong.
The slowest teams I've worked with are slow because of accumulated complexity and unclear ownership — not because they're being thorough. The fastest teams move fast because they've invested in the infrastructure that makes fast movement safe: good tests, clear boundaries, fast feedback loops.
Speed and stability are more correlated than they are opposed.
What Actually Slows Teams Down
In rough order of impact:
- Large PRs. A 1,000-line PR takes days to review, often gets rubber-stamped because reviewers give up, and is terrifying to roll back. A 100-line PR gets reviewed in an hour, merged confidently, and reverted in 30 seconds if needed.
- Unclear ownership. When everyone is responsible for everything, nobody is. Decisions get deferred, code doesn't get maintained, bugs linger because nobody knows who should fix them.
- Slow CI. A CI pipeline that takes 20 minutes trains engineers to batch changes and push infrequently. A pipeline that takes 3 minutes trains them to push small, frequent changes and get feedback fast.
- Missing observability. You can't move fast if you can't tell whether things are working. Basic logging, error tracking, and metrics are not optional for teams that want to ship fast.
The System I Use
For solo and small-team work:
- Work in branches, merge to main daily. If a branch lives for more than two days, it's too big.
- Write the test before you ship. Not TDD-dogmatically, but at minimum: before you call something done, write one test that would have caught the bug you were most worried about introducing.
- Feature flags for anything user-facing. Ship the code, enable the feature separately. Rollback is a config change, not a deployment.
- Review your own PR before requesting review. Leave comments on the things you're unsure about. It makes the review conversation faster and shows you've thought it through.
The Debt Question
Technical debt gets a bad reputation, but not all debt is the same. There's debt that compresses your ability to move in the future (bad), and debt that is a deliberate trade-off to ship something now and clean it up later (sometimes fine, if you actually clean it up).
The difference is intentionality and tracking. If you take a shortcut, write it down somewhere — a ticket, a comment, a TODO. If you never write it down, it will never get fixed.
One Thing to Start Tomorrow
If your team is moving slowly, the highest-leverage change is usually shrinking PR size. Not better planning, not more documentation, not architectural improvements. Just: smaller units of change, merged more frequently.
Try it for two weeks. The results will surprise you.