You don’t want Quality Engineers

“In order to understand how to show value as quality professionals we need to…” Yes!

“Understand what it is that engineering teams want and work to support them at that.” Oh good point but…

Callum and I are friends, in geekery, life and professionally. We’ve worked in similar spaces, had similar conversations, and arrived at similar places on what good quality work actually looks like. I was even lucky enough to go for a walk and hear some of his thoughts before his keynote at PeersCon 2026.

I agreed. And I didn’t. So I wrote the first take on this ages ago.

This is my “yes, but…”

Where I think he’s wrong, and why ultimately I agree. But like he said in his talk, “Drama!”

Why Framing over the Behaviour

Callum walks us through why the testing community is not ready for quality engineering because we fail to serve engineering teams. The well is poisoned by bad public messaging, and we’re accelerating it ourselves.

I agree on the evidence. I disagree on the cause.

For me the most damaging well-poisoning I’ve experienced didn’t come from other QAs posting bad content. It came from managers and leaders who’d already decided what a tester was before I arrived; and nothing I could do would shifted that mindset.

In one of my early consultancy roles I was put in a team with a very specific role that the client had defined. Automate the tests to help a migration. I found other issues, and raised a performance risk early. I flagged it to the manager client side and was put back in my lane. Three months later performance becomes an issue and I got a call from my account manager asking why I hadn’t raised it sooner. Guess who had been taking the meeting notes.

The reason this happened? I was a consultant. The manager was permanent staff. When it came to “whose word do we trust,” the answer was predetermined by my employment status. I did what Callum warns, I got put in a box and I stayed there. Yes I failed to communicate effectively. But there’s also an accountability and leadership failure behind it all.

We all see reposted memes poisoning the well, but it’s not just the Quality community.

What Quality Professionals Actually Do

Callum’s list of what engineering teams want from us is good. Builders, not breakers. Generalist skills. Trusted advisors. Systems thinking. Pragmatism. I agree with all of it.

But he has another list, the skills he’s had to demonstrate as a Quality Engineer: colour psychology, typography, branding, cloud architecture, business analysis, OKRs, agile ceremonies, observability, AI agents, threat modelling, ethical hacking, user personas, product domain knowledge.

That is not an engineering team’s skill set. It’s an organisation spanning skill set.

I’ve spoken about it before in [QA as Cosplay] and Stu points out quality professionals have been doing that work since he had hair (sorry!).

This isn’t new. What’s new is we keep changing the sign on the well and expecting the water to taste different.

Hot take: “Quality Engineering” might be the worst possible name for what we’re describing.

Engineers build software; that’s the execution stage.

Quality professionals build understanding; of risk, of user needs, of what good looks like before, during, and after the build. We don’t engineer quality. We cultivate it. And just like “Product Manager” crowding out “Project Manager” and “Programme Manager” made the PM acronym confusing, “QE” muddies exactly the language we need to be clear about.

Callum notes that “Quality Engineering” wasn’t coined by the testing community; it was coined by engineering, a rebranding exercise to distance themselves from bad QA experiences. So testers followed an invite to a well most of us are already at, but with a new sign.

What I’ve Seen vs What I Hear About

Callum interviewed engineers and leaders. They said they wouldn’t trust testers, wouldn’t hire them, wouldn’t ask for their advice based on what they’d seen online. He takes that seriously and so do I.

But those engineers are hearing what they expect to hear.

Callum points out that engineers don’t argue publicly about what “backend” means, I disagree. Terminology wars aren’t a QA problem. They’re a human problem. The signal that engineers are filtering for, and what QAs are actually producing, are not always the same thing.

What I find more instructive than what engineers say is the structural question underneath: when a quality professional gets excluded from a planning conversation, is it because they haven’t yet proven value? Or because someone already decided they wouldn’t add value before the invite went out?

In my experience, the second is more common than we acknowledge. The vicious cycle; testers disengage, get excluded, default to bug-hunting, expectations permanently degrade, doesn’t always start with the tester. Sometimes they arrive in a team that’s already mid-loop, placed there by decisions made before they existed, filling a seat somebody else designed for them.

This gives us two groups neither of us are really reaching. Not directly.

The first: quality professionals who’ve internalised the old ways and the box others put them in. Not because they’re lazy. Often because they were curious and got told no enough times that they stopped asking. The ones asked to just run the scripts, told not to rock the boat, ignored often enough that they stopped pushing. Callum describes this as learned helplessness, it’s not as a character flaw but as a reasonable response to a bad environment.

These people are stuck. They’re not seeing our posts, they’re just trying to survive. Blame gets us nowhere. So if we find them, sling a rope and help them help themselves.

The second group is harder to talk about, because they’re not in the room and they’re not doing it overtly. We could call them bad actors; the manager who celebrates the developers on a good release and looks for a QA to blame on a bad one. Who lets the tester go first when cuts come because thats just the way things are done. Who says “okay, prove your worth” but makes no allowances to do so. They’re often not consciously malicious. They’re trapped in their own frame, hearing what they expect rather than what’s actually being said.

This is the fox in the henhouse. You can’t fix it with better content strategy. You fix it by making sure other voices in the room have already seen your value, when the fox speaks, someone else can speak back.

What We’re Already Doing

Callum’s prescriptions are good. Know your audience. Build things. Get comfortable going fast. Show value in terms the room understands. I’d add one reframe.

He says lose the ego.

I say if you know Callum what he’s actually saying is “Own your ego”.

Watch how Callum actually behaves in conversation with Stu. When his team uses a different term to his preferred one, he adopts theirs; not because he’s being submissive, but because he’s redirecting his expertise from being right to being useful. That’s not ego loss. That’s ego discipline. When Stu challenges him on a point, he doesn’t back down, he explores and clarifies. Have his confidence in your expertise. Spend it on helping the room understand, not on establishing that you’re the one who understands (or on jumping into their box and being a yes man).

But I also want to push further than his article or the podcast actually go.

Callum’s frame is engineering-facing; intentionally so. He’s solving a specific trust problem with a specific audience. However Callum also asks us what a good quality professional looks like right now and he’s shown it through the progress of his talk, into his blog post and now the podcast.

His own skill list reaches far beyond engineering. Quality work lives in the BA conversation that shapes the requirement. In the PM decision that sets the scope. In the data that trains the model. Right now there are class action lawsuits against software companies for bias baked in at the data collection stage; bias that a quality mindset might have flagged if they were there (wonderfully well timed after I had a discussion on bias in AI and if QA’s should be involved).

Same Hymn Sheet, Different Pages

Callum and I (and I suspect you if you’ve read this far) are singing from the same hymn sheet. We just started on different pages.

He’s right that the conversation needs to reach engineering teams. He’s right that we need to stop naval-gazing and work with others to build things not just tell them they’re broken. He’s right that the market has moved and some of us haven’t moved with it.

So lets expand his ask, go beyond quality professionals showing up better for engineering teams. Lets ask engineers and leaders to look past whatever label is on the well. To listen to what’s actually being said, not to what they expected to hear. Both sides need to be giving “Yes and…” not just one.

Lets keep an eye for the people who need a rope, not a rebuke. They may be stuck in a box of another’s or their own making.

Lastly we need to remember the the BAs, the PMs, the data teams, the hiring managers the people who set the room before engineering or quality professional walk in. Oh and all the guys after too, cause QA wears many hats, but this is already getting pretty long.

A quality culture isn’t built by quality professionals alone. We’re just meant to be guiding the way, not dragging us down.

What’s your experience? Are you in the choir, throwing the rope, or spotting foxes?

Thanks for taking the time to read! If you found this helpful and would like learn more, be sure to check out my other posts on the blog. You can also connect with me on LinkedIn for additional content, updates and discussions; I’d love to hear your thoughts and continue the conversation.