In The Fellowship of the Ring, Pippin grumbles about taking an unfamiliar route through the woods, and Frodo answers with a line that has outlived the journey: “Shortcuts make long delays.”
Hobbits, it turns out, understand software delivery.
We’ve been thinking about this lately because it keeps coming up in our work, in coaching conversations, in off-sites, in the quiet moments after a team has missed another date. The pattern is nearly always the same. The pressure mounts, so the team speeds up. They cut a corner here, skip a refactor there, push the cleanup to “after the release.” Each shortcut feels rational in the moment. And each one quietly takes out a small loan against the future.
That’s all technical debt really is: a shortcut with interest. As we wrote in Speed vs quality and technical debt, the cost doesn’t show up immediately. It shows up months later as slower delivery, harder-to-change code, and a team whose morale erodes a little with every workaround. Pressure can create the illusion of speed, but illusions don’t compound. Debt does.
The counterintuitive bit, the bit that research on high-performing engineering teams keeps confirming, is that quality is not the enemy of speed. Quality is where speed comes from. Teams that invest in their code, their understanding, and their practices build confidence, and confidence is fast. Slow is smooth; smooth is fast.
But “go slower” is not, on its own, useful advice. Nobody has the luxury of moving slowly on everything. The real question is: slower on what, and faster towards what? That’s a prioritisation problem, and it’s the subject of the companion piece, Productivity, prioritisation, and progress. A few ideas from it that pair nicely with Frodo’s warning:
Narrow your focus until anyone on the team can recite the goals casually and accurately. Most “shortcuts” are really detours, work that felt urgent but wasn’t on the path at all. A team that knows exactly where it’s going takes fewer wrong turns.
Target the toughest problems early. The hardest part of the project defines constraints for everything else. Deferring it is the grandest shortcut of all, and it produces the longest delay, usually discovered when half the app is already built.
Trade urgency for momentum. Urgency pushes people to rush; momentum pulls them forward and increases motivation. Small pieces of work, finished properly and frequently, beat heroic sprints that leave a mess behind. (We have feelings about the word “sprint”, but that’s another newsletter.)
None of this means never taking a shortcut. Sometimes shipping something quick-and-dirty is the right call, to hit a market window, to test an assumption, to keep the lights on. The difference between a deliberate trade-off and a long delay is honesty: naming the compromise, making the cleanup visible, and actually budgeting the time to pay the loan back.
Frodo and company did eventually reach their destination, not by finding a faster road, but by keeping a small, clear goal and walking towards it, steadily, one unglamorous step at a time.
May your roads this month be smooth, and your shortcuts deliberate.
P.S. If your team is stuck in the rush-cut-corners-slow-down loop and you’d like a thought partner to help break it, reach out to start a conversation.