No time to change: When Knowing There's a Better Way Isn't Enough

If you have led a development team through a pressured sprint, you will likely recognise this: the awareness that something in how you are working could be improved, sitting alongside the conviction that right now is not the moment to address it.

The logic feels airtight at the moment. There is a deadline. There are shifting requirements. There is a product to ship. Stopping to reflect, to experiment, to change even one small thing feels like a luxury the calendar won’t allow.

What I find when I sit with that logic, though, is that it contains an assumption worth examining. The assumption is that the current way of working is a known quantity — painful, yes, but predictable. Change, by contrast, introduces uncertainty. And uncertainty feels costlier than pain, even when the arithmetic suggests otherwise.

This is not a failure of intelligence. It is a very human response to variation. Research into decision-making under uncertainty has shown repeatedly that people will accept a guaranteed bad outcome over a probabilistic better one, simply to avoid the discomfort of not knowing. The anxiety of the 50% chance costs more, psychologically, than the certainty of the harm itself.

In software development, the creative nature of the work means variation is structural — two engineers given the same task will take different paths and different amounts of time. That is not dysfunction; it is the nature of knowledge work. But when a team is already stretched, that inherent variation can feel like evidence that things are out of control. The (frequent and incorrect) response is often to grip tighter: more process, more reporting, more commitment to dates that were never grounded in a sound estimate to begin with.

I notice this particularly around deadlines. When I ask who owns a deadline, and what engineering reasoning sits behind it, the answers are often thinner than the confidence placed in them. A date was set, committed to, and has now become load-bearing — not because the estimate was rigorous, but because the certainty of the date feels more manageable than the uncertainty of saying we don’t know yet.

The harder question — and the one I find myself returning to with technical leaders in this position — is not whether there is a better way. Most already know there is. The question is whether the team has ever been given permission to stop, even briefly, to look at one thing and try one change. Not a transformation. Not a methodology overhaul. One thing.

In my experience, the teams that find a way to do that — even under pressure, even imperfectly — begin to build something that deadline-driven teams rarely have: evidence. Evidence that change is survivable. Evidence that the uncertainty of trying something different is, in practice, less costly than the certainty of staying stuck.

That evidence does not arrive all at once. It compounds.

If you’re ready to go further, let’s explore how building reflection into your delivery rhythm can work for your team. Reach out today, and let’s find the one thing worth changing first.