Quality Engineering is decision-making under uncertainty
Reflections from Agile Manchester on AI, strategy, systems, leadership and care
A few weeks back, I spoke at Agile Manchester and came away with far too many notes.
Rather than write a traditional conference recap, I wanted to pull out the Quality Engineering thread I noticed running through many of the talks.
For me, that thread was this:
Quality Engineering is not just about testing software. It is about helping teams make better decisions under uncertainty.
This piece is the synthesis.
For paid subscribers, I’ve also shared the work behind it: The notes behind “Quality Engineering is decision-making under uncertainty”. That includes the fuller notes from the talks and workshop that informed this post.
If you find this kind of Quality Engineering thinking useful, you can subscribe for free to get future posts in your inbox. Paid subscriptions help me spend more time turning notes, talks and messy ideas like this into practical reflections for testers, quality engineers and engineering leaders.
1. Look outside the system to understand the system
Holly Cummins’ talk reminded me that software does not exist in isolation. It interacts with other systems. Some technical, some social.
One small example was country codes. The short country code for Norway is NO. But out of context, that can look like “no”, which to a software system can also look like false. Suddenly Norway becomes false, and that could cause all sorts of problems.
It is a tiny example, but it points to something much bigger.
Software is never just software. It sits inside languages, cultures, standards, incentives, organisations, behaviours and assumptions. It’s a socio-technical system.
Holly also talked about Jevons paradox. As something becomes more efficient and cheaper to produce, demand for it can increase rather than decrease. Which is very relevant to AI.
If AI makes software cheaper to create, we may not build less software. We may build far more of it. That means more systems, more dependencies, more unintended consequences, and more need for people who can understand complexity.
So as quality engineers, we need to be curious beyond the codebase.
Economics, incentives, organisational design, user behaviour and social systems all affect the quality of what we build.
2. Better questions matter more than faster answers
Steph Wright’s session on AI asked a simple but powerful question:
What problem are we actually trying to solve?
A lot of AI adoption can feel like a solution looking for a problem. Steph’s advice was to slow down and think much more critically before reaching for AI as the answer.
She framed this around four questions:
What problem are we trying to solve?
Who could be harmed by it?
Who benefits from it?
Do we even need AI to solve this?
That last one really got me thinking!
These are useful questions for anyone exploring AI, but they also feel like quality engineering questions.
They are about risk, value, harm, purpose and context. They help us avoid jumping to the first tool that comes to hand. Increasingly, that tool will be AI.
They also give teams more agency. Instead of treating AI as something inevitable that is happening to us, we can ask better questions about what we are trying to achieve and what trade-offs we are willing to make.
3. Quality depends on how decisions are made
A few talks explored decision-making from different angles, and they all pointed to something I think matters a lot for quality.
Quality loss does not always come from people being careless.
It often comes from unclear decisions, hidden trade-offs, poor framing, missing context and weak organisational memory.
Three ideas stood out to me: connect decisions to strategy, start with the decision you need, and make the reasoning visible.
Strategy gives decisions context
Rachel Dubois’ talk on Strategy Sprints explored how teams can connect more meaningfully to organisational strategy.
There is something powerful about helping teams understand why they exist, what role they play, and the bigger story they are contributing to. That sense of purpose matters. It shifts work from “just doing a job” towards feeling connected to something larger.
Teams are far more likely to care deeply about quality when they understand why the product matters, who it serves, and how their work contributes to the wider mission.
Start with the decision
Kirsten Mann’s keynote on communicating with board members gave me another useful decision-making insight:
Start with the decision.
So often, we lead conversations by showing all our working out. We explain everything we’ve done, walk people through the detail, show the data, and eventually get to the decision we want them to make.
But that is often the wrong way round.
If you lead with all the detail, people can get stuck there. Instead, it is more useful to start with the decision you need from them.
One sentence she shared was:
The decision we need to make today is...
That is such a simple but powerful way to anchor a conversation.
And this is not just useful for boardrooms. It is useful with leadership teams, engineering teams, and any group that needs to make a decision.
Quality engineers often need to help people make decisions. We frame risks, share evidence, explain trade-offs, and make uncertainty visible. The clearer we can be about the decision needed, the more useful we can be.
Make the reasoning visible
Andrew Harmel-Law’s talk on decentralised decision-making added another layer.
He shared how ADRs can help teams make decisions in a more structured way by capturing what decision was being made, who had been consulted, what advice was given, what was decided, and where that decision was recorded.
That creates visibility and organisational memory.
It also helps teams move beyond relying on people’s memory, assumptions or the loudest voice in the room.
For quality engineering, that matters because so many quality-related decisions are not obviously “quality decisions” at the time. Architecture choices, product trade-offs, delivery shortcuts, team agreements, tooling decisions and testing approaches all influence future quality.
When we capture the reasoning behind those choices, we make it easier for future teams to understand why things are the way they are.
4. People are part of the system too
Daniel Susser and Geoff Watts both explored something we often underplay in software.
We talk about systems as if they are separate from the people inside them. But people are part of the system too.
Stress, fear, pressure, uncertainty, confidence, identity and values all shape the decisions we make.
Daniel’s session explored embodied cognition and interoception. In simple terms, how becoming more aware of our body’s signals can help us better understand and regulate our reactions.
A lot of the time, our body reacts before we consciously process what is happening. Our heart rate increases, our breathing changes, we get tense, hot or restless, and instead of recognising those signals, we react to them.
That can quickly turn into anxiety, fear, stress or panic, depending on how we interpret the situation.
The useful part is learning to notice those signals earlier. An increased heart rate or faster breathing can become a cue to pause, breathe, ground yourself and choose a more deliberate response.
That feels very relevant to quality engineering.
If quality is shaped by decisions, and decisions are shaped by stress, fear and uncertainty, then the physical and emotional state of the people making those decisions matters.
Geoff Watts’ talk on calm rebel leadership connected to this too.
He explored how, when things get hard, we can fall back into safety behaviours. We might distort what is happening, rescue everyone around us, shrink ourselves to fit in, or self-sacrifice until we burn out.
What I liked about the calm rebel idea is that it offers a way to stay values-led without becoming reckless, bitter or burnt out.
That feels especially relevant for testers, quality engineers and anyone who cares deeply about quality.
Sometimes we are leading on quality without the title, authority or permission. That can feel hard and lonely, especially when decisions are being made that degrade quality in ways we do not feel comfortable with.
Being a calm rebel is not about being disruptive for the sake of it.
It is about being steady, thoughtful, values-led, and willing to challenge when it matters.
5. Navigating uncertainty in complex systems
I also had the chance to give my own talk on navigating uncertainty in complex software systems.
What struck me, after listening to the other sessions, was how much of the conference circled around the same idea from different angles.
Whether we were talking about AI, strategy, boards, ADRs, embodied cognition or leadership, the question underneath was often:
How do we act wisely when we cannot know everything upfront?
And maybe that is my biggest takeaway from Agile Manchester.
Quality Engineering is not only about finding defects, improving tests or making releases safer.
It is about helping people, teams and organisations understand uncertainty well enough to act with care.
Because care is part of what helps us create healthier software systems, not just better, faster and cheaper ones.
If this helped you think differently about Quality Engineering, consider subscribing or sharing it with someone who is trying to improve how their team makes decisions under uncertainty.
For paid subscribers, I’ve also published the longer notes behind this post.
That includes fuller write-ups from the Agile Manchester sessions that influenced these reflections, with sections on AI, strategy, decision-making, communication, embodied cognition, leadership and systems thinking.
You can read them here: The notes behind “Quality Engineering is decision-making under uncertainty”.