Quality Engineers – Who Are Your Customers?

An important part of taking a holistic approach to Quality is understanding who you are actually serving. If you ask most Quality Engineers who their customer is, they will instinctively point to the end user, the person buying or using the software. And they aren’t wrong, the end user is the ultimate customer.

But to build a high-performing engineering culture, we need to broaden that definition. I take the approach that anyone whose experience can be improved by our work is our customer.

That covers a huge range of people. It includes the obvious end user, but it also includes the Developers, Customer Support, Product Managers, and even the Sales team.

Stakeholders vs. Customers

You might ask: “Aren’t you just describing stakeholders?”

In a way, yes. But words matter. I prefer the term “Customer” because it carries a specific weight.

A Stakeholder has an interest in your success. They check the metrics; they want the green light.
A Customer consumes what you build. They have a “User Experience” with your work.

If I view the Engineering team as a stakeholder, I just report my test results to them. If I view the Engineering team as a Customer, I have to care about the “User Experience” of my testing framework. Is it fast? Is it reliable? Does it make their life easier, or is it just another hurdle they have to jump over?

By adopting a “Service Mindset,” we move from being gatekeepers to being enablers. Here is what that looks like in practice across different internal “Customer” groups.

Customer 1: The Software Engineers

The Pain Point: Slow pipelines, flaky tests, and context switching.

Our Job: Improve Developer Experience (DevEx).

When we treat engineers as customers, we stop building bloated test suites that take hours to run. Instead, we treat the Test Automation Framework as a product. We ask: What features do my engineers need to move faster?

I’ve seen this transformation happen when we shifted focus to building automation that engineers actually loved using. We stopped optimizing for “100% coverage” and started optimizing for speed and reliability. We built tools that ran quickly in CI pipelines against deployments of feature branches, provided instant feedback, and handled data setup automatically.

The result? The engineers didn’t just tolerate the tests; they started contributing to them. We reduced their cognitive load, and in return, they improved the quality of the code.

Customer 2: Customer Support

The Pain Point: Flying blind when users report issues, leading to vague tickets and frustrated developers.

Our Job: Bridge the gap with better triage and observability.

Support agents are often the first line of defense, yet they are frequently starved of information. If we treat them as customers, our job is to empower them to solve problems without needing to interrupt an engineer.

In a previous role, we redesigned the engagement model between Support and Engineering. Instead of them being frustrated and feeling unheard, we built better triage methods and promoted routes for collaboration between engineers and support agents.

This led to an empowered the support team who felt heard and could deliver valuable end user feedback directly to the people who could make a difference. It also protected the engineering team’s flow state by reducing interruptions and making dedicated time for feedback and collaboration. Everyone won.

Customer 3: Product & Delivery

The Pain Point: Surprise blockers at the end of a sprint.

Our Job: Shift Left to provide early confidence.

For Product Managers, “Quality” isn’t just about bugs; it’s about predictability. Their “User Experience” of the Quality team is often defined by the fear of a release day delay.

We serve this customer by shifting testing left. By getting involved in the design phase and asking the hard questions early (“How will we test this?”, “What happens if this service fails?”), we de-risk the delivery. We give them the confidence that when the engineering teams say “It’s done,” it’s actually done.

Summary

When you limit your definition of “Customer” to just the end user, you miss the opportunity to improve the machine that builds the product.

Your internal tools, your processes, and your communication styles are all products that your team consumes every day. If those products are hard to use, your “internal customers” will suffer—and eventually, that pain will trickle down to the end user anyway.

So, look around your organisation today and ask: Who is consuming my work, and is their experience a good one?

Join the flock

Subscribe to get the latest posts on the messy reality of software delivery sent directly to your mailbox. I regularly share new thoughts on leadership and strategy —zero spam, just value.

Newsletter