Progress Over Perfection

Dave Leigh

• 3 min read

I’ve been talking to our tech leads and architects recently about the concept of progress over perfection. One recurring theme I see is not moving from planning to execution quickly enough meaning we don’t see enough impact from technical improvements. 

With feature development we follow good agile principles (think experiment, learn rapidly and deliver value continuously) but sometimes we forget this with the things end users don’t see - internal tools, pipelines, test frameworks, observability upgrades, the developer experience - the things that increase the maturity and velocity of our software delivery capability.

I use the word perfection in a deliberately provocative, but nuanced way. We need to ask, do we have a good balance - can we reduce the effort to be ready to actually do something? 

Are we de-risking more than we need to? Do we tend to prefer fully understanding everything upfront before we ship some code?

How we can move from planning to execution quicker, fail fast if necessary and iterate. 

Strategy is important, but action is impact

Our work is only impactful after it’s delivering some value. Whilst strategy and planning is important alone it delivers no value. We can spend disproportionate time in planning and design, waiting for that moment when our assumptions are fully validated, and the design is complete.

But in many cases especially with internal technical initiatives or continuous improvement work emerging from our teams it’s more valuable to start small and deliver chunks of incremental impact. An example of this might be rolling out a new test framework on a single service rather than waiting for wider alignment, or even in our process, for example documenting an architectural decision in a fast lean ADR rather than spending weeks on something more comprehensive - especially for less significant decisions which could be reversed.

Progress over perfection is not about cutting corners or neglecting design. It's about recognising that impact happens when the work moves from thinking, talking and documenting to something we can use and measure.

Safety in readiness

There can also be  a cultural element at play - see Westrum model - the fear of taking risks and repercussions of getting things wrong. It’s also true that many tech leads feel a strong sense of responsibility - they want to do things the right way.

This shows up in things like:

  • Fully specced, exhaustive requirements
  • Lengthy squad alignment sessions before any code is written
  • Seeking multiple layers of approval before starting something.
  • ADRs & design specs that become essays, regardless of decision scope

This can make sense, we want to avoid rework and ensure consistency, however ironically this can slow down the very improvements that would make our teams faster, more consistent, and higher performing.

Sometimes, the right thing is to take a small step forward, even if it’s not perfect, and use that as a forcing function for alignment.

Lean ADRs

I’m a big advocate of Architecture Decision Records (ADRs). In writing things down it forces us to think and they prompt good questions. However, I’ve seen ADRs become a bottleneck - small, local decisions take weeks to write and then get stuck in review cycles.

For technical decisions that are local, low risk, and not of enterprise significance, I wouldn't try to speed up by avoiding ADRs (because writing is thinking) instead we treat ADRs as lightweight scaffolding for fast collaboration.

Instead of weeks spent debating, reviewing, and rewriting an ADR, briefly ask:

  • What’s the context and key constraints
  • What options exist and what are the key trade-offs.
  • Who else cares about this decision?
    • Important: Quickly talk to those people and capture their feedback.
  • What do we recommend, and why?
  • Who needs to know?

It doesn’t need to be polished. It needs to be shared, understood, and actionable.

This can all happen quickly and within our teams. We can quickly capture the thinking, make progress and then replay the thinking in an architecture forum, ideally through conversations we’ve understood if the decision is significant enough to block progress, but in 95% of cases it shouldn’t.  

That’s it - capture the information, share it quickly, then move. Revisit if we learn something new.

What’s the smallest thing we can validate today?

Improving technical maturity is a long process, it moves forward through small, local improvements. When evaluating any technical improvement, ask:

  • What can we do today to move this forward?
  • What’s holding us back?
  • Can we make this safe-to-fail?
  • What is the cheapest path to feedback?

Our work only has impact when it enters the system

Strategy, alignment, and design thinking are essential but only action creates impact when it leaves our headspace and documentation and gets real usage, generates feedback, and drives learning.

Let’s resist the urge to wait for perfect readiness and instead move faster on the things that make us better.