Rethinking Technical Expertise in QA

There is often an ask in engineering teams for people to be more technical. I see this the most with QA roles. But it often boils down to one thing: more automated testing.

The general perception is that automation is fast, modern, and accelerates value delivery. While manual testing is slow, outdated and a bottleneck.

Put another way: manual = bad, automation = good.

But is that what “being technical” means or is it just a very narrow view of technical expertise?

Being technical is more than just code

For me, being technical is not just about automation or the ability to write code. It’s about understanding the technical details of the systems we work in and using that knowledge to design, develop, and solve practical problems.

It means:

• Understanding how the system behaves, where risks emerge, and how to influence those behaviours.

• Using feedback to improve how we deliver value.

• Making informed trade-offs—not just automating for the sake of it.

And because we work in a socio-technical system, the best solutions won’t always involve writing code. Sometimes they will, but that code might be written by you, someone else, or even an AI tool. The real question is: Does it help the team move forward?

Shaping the System for Sustainable Quality Outcomes

At its core, being technical is about making the system we work in healthier—so it produces more of the outcomes we want more often, and less of the ones we don’t. And when we do create outcomes we hadn’t intended, how quickly can we detect, adapt, and course-correct?

This is about more than automation. It’s about how quality is created, maintained, and lost in complex adaptive systems—what we call work.

So the next time someone asks for more technical skills, let’s ask: Are we just asking for more automation? Or do we really mean a deeper understanding of our systems and how to influence them for better outcomes?