Speed beats perfection

TTL 21

Think longer-term, work in shorter cycles.

👋 Good Morfternight! Paolo Belcastro here, welcoming you to the twenty-first issue of TTL: Tools & Thoughts for Leaders, your weekly dose of leadership insights.

In a world obsessed with moving fast, we often focus on the wrong kind of speed.

In software development, it’s easy to get caught up in the race to ship features or outpace competitors.

But there’s a different, more impactful speed worth focusing on: the speed of learning and iteration—the ability to quickly adapt, test ideas, and refine with intention.

Speed is about learning, not rushing

When properly harnessed, speed becomes a multiplier for innovation.

It accelerates the feedback loop, enabling your team to make better decisions. Speed here is not about cranking out product features at a frantic pace; it’s about spinning the flywheel of iteration—learning quickly, making adjustments, and improving steadily.

Every iteration, no matter the outcome, contributes to improving the next one. This kind of speed is what differentiates teams that stagnate from those that thrive.

Think of it as the flywheel that powers your product development process. Every time you:

• Ship something small
• Gather user feedback
• Learn what works and what doesn’t

…you gain insights that enhance the next iteration. The faster this cycle, the more you learn, and the closer you get to a solution that truly resonates with your users.

The key here is not the pace at which you finish—it’s how quickly you learn and adapt.

The more cycles you go through, the more efficient and informed your decision-making becomes.

“Ship often” is a culture

You might think that speed is all about individual actions—breaking down tasks, shipping frequently, and gathering feedback.

But the truth is, speed is a cultural phenomenon.

Teams either have a “ship often” mindset or they don’t, and that mindset makes all the difference.

Teams that lack this culture typically fall into a vicious cycle. Fear of failure or hesitation about making a mistake can lead to delays in delivery. When delivery becomes infrequent, every single release starts to feel critically important. The stakes become so high that any setback seems catastrophic. This slows everything down, making the team even more risk-averse.

Teams with a “ship often” culture are unafraid to deliver work regularly, even if it’s imperfect. It’s all about momentum: the more you ship, the less frightening it becomes, and the more effective your iterations are.

The paradox of constraints

Some time ago, I shared how limitations, rather than restricting us, can actually enhance our creativity. (actually, it was the last edition of Morfternight!)

I think time constraints work similarly in software development.

When you have limited time to iterate, you focus on what’s essential, cut through the noise, and make decisions that drive meaningful progress. These boundaries force creativity—they push teams to find the simplest, most elegant solution rather than overcomplicating things.

The paradox of constraints is that they create freedom.

I don’t like annual reviews

I think you might’ve figured this out from my latest newsletter, Against New Year’s Resolutions.

But here I am, advocating for my point again.

There are two reasons why annual reviews are ineffective: first, one year is too long, making it difficult to adapt quickly and iterate effectively; second, it’s too short to achieve significant strategic shifts that require more extended timelines for truly impactful results.

So, think longer-term and work shorter-term.

But most importantly: be flexible.

Roadmaps are not maps—they’re compasses

When teams hear the word roadmap, they often imagine a precise, step-by-step plan.

However, successful product roadmaps are not fixed itineraries—they’re adaptive tools. Think of your roadmap not as a static map, but as a compass that helps guide your direction while allowing for flexibility along the way.

A good roadmap should:

• Break down the journey into small, manageable steps. Each step should deliver standalone value so that progress is not dependent on a grand finale.
• Adapt based on feedback. Just like sailors adjusting their course based on changing winds, you need to be ready to navigate around obstacles or seize new opportunities.
• Focus on learning along the way. The goal is not just to “arrive,” but to continuously improve with every step.

This approach allows for constant adaptation, similar to a fleet of sailboats working toward a shared destination. It’s not enough to declare, “Let’s sail to Athens”—you need to chart smaller waypoints that can shift as needed. Even if the final destination changes from Athens to Istanbul, those small steps and adaptations make the journey worthwhile.

Every experiment counts

When running tests—whether it’s an A/B test, a prototype, or a usability study—failure is not the enemy. A test that yields unexpected results is not a failure if it provides new insights. The key is to isolate hypotheses, measure their impact, and refine your approach.

Every test, regardless of outcome, contributes to collective learning. Even when your experiments don’t turn out as hoped, they provide valuable data for future iterations.

This ties back to a concept we discussed in previous newsletters: the vase analogy. Imagine two groups tasked with making the best vase:

• Group A: Make one perfect vase.
• Group B: Make as many vases as possible.

Which group produces the best vase? Group B wins every time. Why? Because by creating more vases, they learn from each iteration. Mistakes become stepping stones, not setbacks.

The same applies to software development. Your team is far more likely to create something exceptional by shipping frequently, collecting feedback, and improving incrementally than by chasing a single “perfect” release.

Gaining the marginal edge

When Blackjack is played optimally, the house odds of winning are 50.9%, with 49.1% of hands ending with a player win or a draw.

Some people manage to shift those odds—even just slightly—in their favor by counting cards, and playing strategically at times their odds of winning are slightly above 50%.

That tiny edge can mean the difference between losing everything or making a profit, which is why it is not permitted to count cards in casinos.

This is similar to how speed in iteration works in software development. It’s not about always getting everything right or winning every round—it’s about accumulating small, marginal advantages over time.

Just as in Blackjack, where you can’t win every hand, you can’t expect every iteration to be a winner. But if you keep iterating, those small improvements add up.

Shipping often and gathering learning from experience is the product equivalent of counting cards, except that it is not only legal, it is recommended!

Speed in action

How do you put this principle into practice for your team? Here’s a simple framework to ensure speed is working for you:

1. Break down features into the smallest possible deliverables. Smaller deliverables mean faster iterations, which means faster learning.
2. Ship frequently (every 1-3 weeks). Each delivery should stand alone so that even if you pivot, nothing is wasted.
3. Prioritize feedback loops. Build fast, measure regularly, and always use what you learn to refine your next step.
4. Value speed over certainty. Don’t wait for the perfect plan. Move forward with the best information available and adjust as needed.

---

That’s it for today.

If someone forwarded this to you, you can subscribe to get your copy next week. If you enjoyed reading this, please share it.

Here on TTL, we dig into practical leadership tips and effective strategies, with a particular focus on tech leadership and managing distributed teams (that’s what I do every day, add me on LinkedIn).

Whether you’re steering a tech startup or leading a remote team, these insights are designed to help you navigate the complexities of modern leadership.

---

I also publish on paolo.blog and monochrome.blog

Cheers,