The Comfort of a Bad Outcome

There is a study from UCL worth sitting with before we get into software delivery. In it, participants played a computer game turning over rocks that might hide snakes (with a 50% probability). Participants were assigned into two groups. On the first group, when a snake appeared, they received a mild electric shock. On the other group, participantes received the same mild electric shock regardless. Guess which group participants preferred?

Interestingly: a 50% chance of being shocked produced more stress than the certainty of it. The uncertainty itself — not the outcome — was what people found hardest to bear (see the report here).

I find this a useful lens for something that shows up repeatedly in software teams. Consider how estimates get made. A feature is scoped, a date is committed, a spreadsheet is populated. The number in the cell feels like certainty. What it rarely accounts for is the variation that is intrinsic to the work itself: two engineers given the same task will approach it differently, complete it in different times, and produce solutions that diverge in ways nobody fully anticipated. It is the nature of creative, knowledge-intensive work.

The trouble is that acknowledging variation feels like introducing uncertainty — and as the UCL study suggests, uncertainty is genuinely uncomfortable. So teams compress it. They produce single-point estimates instead of ranges. They commit to dates that carry no acknowledgement of the unexpected. The result is a plan that feels certain, attached to a delivery reality that never was.

This dynamic also shapes how teams respond to the idea of changing how they work. Improvement requires a period of instability — a willingness to not yet know whether the change is working. That gap, between abandoning a familiar way of working and gaining confidence in a new one, is precisely the kind of uncertainty that the UCL research describes as harder to tolerate than a known bad outcome. Teams sometimes stay with processes that visibly aren’t working, not out of stubbornness, but because the discomfort of staying is at least predictable.

What tends to shift this is not a better argument for change. It is a smaller ask. One thing at a time, with enough structure around it to make the uncertainty manageable rather than open-ended. Incremental improvement compounds slowly, which makes it easy to underestimate — but it also keeps the uncertainty bounded, which makes it easier to sustain.

There is a further wrinkle worth noting, and one that will become increasingly relevant for engineering leaders over the coming months: AI coding assistants are now being positioned as a solution to delivery variation. The argument is broadly that they reduce unpredictability — that output becomes faster, more consistent, more controllable. Whether that holds under scrutiny is a question worth examining carefully, because trading one source of variation for another that is less well understood is a different proposition than eliminating variation altogether. That thread runs through the next few articles in this series.

For now, the simpler point is this: variation in software development is not an anomaly to be engineered away. It is a property of the work. The teams that manage it best are generally those that have learned to make it visible rather than hidden, and to plan around it honestly rather than around the comfortable fiction that it does not exist.

While the principles discussed here are straightforward, their effective implementation often requires a nuanced understanding of your team’s unique context. That’s where evidence-based coaching makes the difference, accelerating your journey to sustainable productivity. Start with the free guide — exploiting your retrospectivas as an engine of change — and take the first step toward more honest, more reliable planning.

If you’re ready to go further, let’s explore how making variation visible in your delivery process can work for your team. Reach out today, and let’s build a planning approach that reflects reality rather than wishful thinking.