What if...slower wasn’t safer?

What if…slower wasn’t safer?

Ever heard (or even said) something like this: "If we want to get it right, we need to go slow"?

But what if we've got that the wrong way around? Or what if we need to flip that idea on its head?

Think about it this way—if you ride a bike too slowly, you're more likely to topple over.

I've spent years working with teams and leaders to help them make safer "mistakes" more quickly. Sure, there have been plenty of times when I've messed up or been careless because I rushed. As a self-confessed pre-crastinator, I should probably proofread more before posting.

However, maybe I'm overthinking the negative impact of a typo. Perhaps getting an imperfectly proofread post out there is better than delaying for perfection. It could even be a quicker way to spot those typos—after all, people love to point out others' mistakes, and hey, that's engagement, right?

Greater agility isn’t about avoiding mistakes. It's about making the inevitable process of making mistakes quicker and cheaper, then learning from them swiftly.

I recently listened to Charity Majors talking about Observability 2.0. While I'm not technical enough to grasp all the practical applications of this version upgrade for making our systems less buggy (I might have even misunderstood it), I loved the concept of "testing in production"—but doing it safely and quickly.

I would add to that…only some of us do it consciously and well.

Testing in production was once a scandalous suggestion when I was a younger software project manager. And for good reason. But given the increasing complexity of the systems we've built, arguably, this is the only real way to find out whether something works.

So, the assumption that going slower leads to higher quality is perhaps outdated. We can't ensure quality by slowing down because it’s impossible to predict what will happen until it happens.

Perhaps, counterintuitively, going faster is the way to better quality, and maybe we need to strive harder to make that the case.

Because it cannot be done recklessly. And great teams know this. It requires:

It requires:

1. Short feedback loops

   Getting feedback on what we've done as soon as possible is key because the longer we wait, the more knowledge about the task we lose. So, do something, test it properly, and then act while the knowledge is still fresh.

2. Quick and cheap recovery processes

   Testing something in the real world of the end user is intimidating, but it’s less scary if we can revert back quickly and cheaply—so quickly, it’s almost as if it never happened.

3. Ownership and accountability

   The person who performed the task should remain accountable for learning from the consequences and iterating towards success.

Sure, there are times when going slower can help increase quality, but we can't rely solely on that. Those who find ways to improve quality by speeding up will be the ones who ultimately succeed.

How do you make it easier to go faster AND better?