The Roman emperor Augustus had a mantra that built an empire to stand the test of time: Festina Lente—“Make haste slowly.” It’s a paradoxical yet brilliant principle: act quickly, but with caution when it matters most. For instance, when Augustus rebuilt Rome’s financial system, he acted decisively to stabilize the empire’s economy, but he carefully restructured tax collection methods over time, ensuring long-term success and minimizing resistance. Augustus expanded Rome’s reach with bold decisiveness but slowed down when laying the foundations of institutions that would endure for centuries.
For modern engineering teams, the lesson is just as critical. Most of the time, speed is your greatest weapon. If you’re not fast enough, you’ll never ship, never learn, and never outpace the competition. But the key to lasting success is knowing when to hit the brakes.
As the military saying goes: “Slow is smooth, and smooth is fast.” It’s a reminder that slowing down where it counts can lead to outcomes that are not only precise but also transformative. The companies that win aren’t just the ones moving at breakneck speed—they’re the ones who know when it’s time to think, deliberate, and get it right.
Reversible Decisions: Go Fast and Experiment
In software engineering, speed thrives on reversible decisions—those low-stakes choices you can undo without significant cost. As Martin Fowler put it: “The job of architecture is to delay decisions, to put them off as long as possible until you know more.” Reversible decisions allow teams to move quickly and iterate based on real-world data without fear of catastrophic consequences.
Of course, when you go fast, it doesn’t mean that you shouldn’t think. Always be aware of the risk but use your mental capacity and energy to go faster.
These decisions enable rapid iteration and learning:
- Rolling out A/B tests to gather data and refine ideas.
- Deploying features behind feature flags to test in production.
- Iterating on designs or workflows based on real-time feedback.
Pro tip: Staggered rollouts are cool—going from 1% to 5%, to 10%, 20%, and so on—you get the idea. But your teams should be able to explain what they’re learning at each stage of the rollout. It happens from time to time that people are just being careful to be careful, waiting for something bad to happen. If you do a very slow rollout with one project, chances are that the next one will be equally slow, at least!
By defining exactly what is holding you back from going to 100%, you can make a massive impact. Think about how much time you’re saving at a company with 50 teams if you’re shaving off even a week on each project.
Reversible decisions are where you move fast, fail fast, and improve fast.
Irreversible Decisions: Slow Down and Think
But then there are the big decisions—the ones you can’t walk back. Augustus knew the difference between seizing opportunities and carefully crafting the foundations of Rome’s legacy. Similarly, in engineering, irreversible decisions demand your full attention:
- Core architectural choices, like moving to microservices.
- Major database migrations that affect system performance.
- API contracts that external teams and clients depend on.
These decisions have long-lasting consequences, and rushing through them can lead to fragile systems, costly rewrites, or worse—eroded customer trust.
To recognize when to slow down, ask yourself:
- Is this decision hard to undo?
- What’s the blast radius if it fails?
- Does it constrain our options in the future?
- How many customers will this affect, and at what cost if we’re wrong?
Slowing down here isn’t a weakness—it’s strategic.
When I needed to slow down
One of the most critical moments when I had to slow down was when we built a mission-critical integration—one of the first at the company. We had the option to reuse an existing integration that was already in place. It had many great features, and the team behind it had a lot of experience supporting it. They strongly recommended we use their solution.
At the time, I felt this decision would really matter. I spent weeks going through their codebase, trying to understand what they had built and how they designed it. Their system included an elegant double-entry book keeping built in. While it was impressive, it was also complex, and I wasn’t sure it was the simplest or best approach for our needs. I had this nagging feeling that their solution, while great for its original purpose, wasn’t designed with our goals in mind.
In the end, I decided to create a brand-new solution. We designed it to meet our goal of being as generic and reusable as possible, and we successfully shipped this crucial integration. We added features like automated test cases to meet official testing requirements from the central bank, and we made the project reusable for other teams.
This decision had a big impact. The new system ended up being used by more than 10 teams worldwide and is now is the standard of how integrations are built. On average, it saves 3-4 weeks of development time compared to starting from scratch and provides a standardized way of handling issues.
The biggest lesson for me wasn’t about how I made the decision—it was that I recognized how important the decision was and took the time to get it right. I revisited it multiple times, asked for feedback (probably annoying some people), and made sure we delivered something that not only solved the immediate problem but could also be used by others in the future.
What Augustus Teaches Modern Engineers
Augustus didn’t build the Roman Empire in a day, nor did he try. He acted boldly when the stakes were low and took his time when the decisions mattered most. For engineering teams, Festina Lente is a timeless principle: move fast where you can, but slow down where you must.
It’s not just about building quickly—it’s about building to last.
What’s your take on balancing speed and caution in engineering? Share your thoughts in the comments!