The moment the plan stopped working
The agenda said one thing. Reality had other plans.
A session was running over. The next speaker was waiting. The schedule was getting tighter. There were still conversations to facilitate, people to keep engaged, and an audience that had no idea what was happening behind the scenes.
I was standing on stage as the emcee of QonfX Singapore, looking at the clock and thinking: What do I optimise for?
Do I protect the schedule? Do I protect the speaker? Do I protect the audience experience?
There wasn't a perfect answer. There was only the best decision for the situation we were in.
And that was when something clicked.
The audience doesn't experience the plan. They experience the outcome.
That thought stayed with me long after the event because it reminded me of something central to Quality Engineering.
A plan is only a hypothesis
Every event starts with a plan. There is an agenda, a set of speakers, session timings, breaks, activities, and transitions. Everyone knows what is supposed to happen and when.
That sounds a lot like software delivery.
We have requirements, designs, tickets, test cases, automation suites, release plans, dashboards, and deployment pipelines. We put a lot of effort into making sure the plan is right.
And we should.
But a plan is still a hypothesis about how reality will unfold.
At QonfX, the plan met reality. Sessions took longer than expected. Timings shifted. Decisions had to be made in real time. Things that looked perfectly reasonable on paper had to be adjusted once they met a room full of real people.
The interesting part wasn't that the plan changed.
The interesting part was what happened after it changed.
Nobody in the audience cared that the schedule had slipped. They cared whether the next transition felt smooth. They didn't care what was happening backstage. They cared whether they knew what was happening next.
They didn't experience the schedule.
They experienced the event.
And that distinction matters far beyond conferences.
The customer doesn't experience our process
This is something we sometimes forget in software.
We talk about our processes: how many automated tests we have, how much code coverage we achieved, how many defects were found before release, how quickly our pipeline runs, how many tests passed, and whether every step in the release process was completed.
These things matter.
But they are not the outcome.
Our customers don't experience our test strategy. They don't see our CI pipeline. They don't know how many test cases passed. They don't care that a dashboard was green if the feature they need doesn't work for them.
They experience the product. They experience whether it solves their problem, whether it is reliable when they need it, and what happens when it isn't.
The customer experiences the outcome, not the process that produced it.
That is why we need to be careful about how we define quality. If our definition of quality ends at "we completed the process," we may be measuring activity rather than impact.
What was I actually trying to optimise?
As an emcee, success wasn't measured by how many words were spoken. It wasn't even about perfectly following the script.
The real questions were different:
- Did the audience stay engaged?
- Did speakers get the space they needed to deliver their message?
- Did people know what was happening next?
- Did the transitions feel intentional?
- Could we recover when the schedule changed?
- Did the overall experience feel coherent by the end of the day?
These are outcome questions. And once you start thinking that way, your decisions change.
Imagine a session is running over. The plan says the next session should start at a particular time. But abruptly cutting off a speaker may create a worse experience than adjusting the transition.
So what do you do?
The answer isn't simply:
"What does the schedule say?"
The better question is:
"What outcome are we trying to protect?"
That is a very familiar question for a Quality Engineer.
In software, we make similar trade-offs all the time. We rarely have unlimited time, people, or information. We have to decide what matters most given the risk and the context.
The goal isn't to optimise every variable. It's to protect the outcomes that matter most.
When reality changes, the system has to adapt
There was rarely a perfect answer during the event. There was only the best decision given the circumstances.
If we were running late, the question became what could be shortened without damaging the experience. If the audience was highly engaged, there was value in allowing a moment to breathe. If energy dropped, the approach needed to change. If a speaker needed more context before going on stage, the priority shifted.
The same thing happens in software.
There is no universally correct testing strategy. The right level of testing depends on risk. The right amount of automation depends on the feedback we need. The right release strategy depends on the impact of failure. The right quality signals depend on what we are trying to learn.
Context changes the answer.
This is one of the reasons I believe strongly in Context-Driven Quality. Quality isn't about blindly following a predefined checklist. It is about understanding the situation well enough to make better decisions.
A good event isn't one where nothing goes wrong. That's almost impossible.
A good event is one where small problems don't become large problems for the audience. The work happens in the recovery. Someone notices that the schedule is slipping. Someone communicates the change. Someone adjusts the next transition. Someone makes a decision backstage so the audience doesn't have to experience the chaos.
That is a form of resilience.
We should think about software systems in the same way.
Software systems fail. Networks fail. Dependencies fail. Deployments fail. Users behave in ways we didn't anticipate. Requirements change. AI-generated code introduces new risks.
The question isn't whether we can eliminate every failure.
How does the system behave when reality doesn't match our assumptions?
Can we detect it quickly? Can we understand the impact? Can we respond? Can we recover? Can we learn?
That is Quality Engineering too.
The best quality work is often invisible
When an event works well, most of the audience doesn't notice the work happening behind the scenes. They shouldn't have to.
The audience sees a speaker walk onto the stage at the right time. They see a smooth transition. They hear the next announcement. They participate in an activity. They move into the next session.
What they don't see are the dozens of small decisions and adjustments happening around those moments.
This reminded me of good engineering systems.
When quality is working well, it can become almost invisible. A customer doesn't say, "Amazing job having a robust risk-based testing strategy." They simply say:
"It works."
That doesn't mean the engineering work wasn't valuable. It means the work created the outcome we wanted.
Invisible doesn't mean unimportant. Sometimes it means the system is doing its job.
From checking quality to creating quality
This experience reinforced something I've been thinking about for a while.
Quality Engineering shouldn't be reduced to finding defects. It should be about designing systems that make better outcomes more likely.
That means asking questions earlier, understanding customer impact, making risk visible, creating fast feedback loops, designing for resilience, using automation where it creates useful feedback, using exploratory testing where uncertainty demands it, and helping Product, Engineering, and QA make better decisions together.
The goal isn't to execute more checks.
The goal is to increase confidence in the outcomes that matter.
That distinction becomes even more important as AI accelerates software development. When the cost of producing software keeps falling, our ability to generate more code, more tests, more automation, and more artifacts also increases.
But more output doesn't automatically create more confidence. In fact, it can make the distinction between activity and outcome even more important.
We need to get better at asking:
- What are we trying to protect?
- What could matter most if it fails?
- What evidence would increase our confidence?
- What feedback do we need, and how quickly do we need it?
- What does the customer actually experience?
These are much more valuable questions than simply asking whether we completed the process.
A different seat, the same mindset
I took on the emcee role at QonfX because it was an opportunity to contribute to the community in a different way.
I expected to learn about being on stage. What I didn't expect was how much the experience would reinforce the way I already think about Quality Engineering.
The context was different. The system was different. The stakeholders were different. The feedback loops were much faster.
But the underlying mindset was surprisingly familiar: understand the outcome, understand the context, identify what matters, watch for signals, adapt when reality changes, and keep the experience at the centre of every decision.
That is how I increasingly think about Quality Engineering. Not as a gate. Not as a checklist. Not as a collection of tools. But as a way of helping teams build and deliver better outcomes.
The audience doesn't experience your plan. They experience the outcome. Whether you're running a conference or shipping software, that difference matters.
A huge thank you to The Test Tribe for trusting me with the mic and giving me the opportunity to contribute to the community in a different way.
And thank you to the speakers, attendees, organisers, volunteers, and everyone working behind the scenes who made QonfX Singapore such a memorable experience.
Sometimes changing your seat gives you a completely different view of the same problem.