From quality function to quality system: reimagining the Quality Engineer
Quality emerges from engineering systems — and from engineers with specialized depth who build quality into the work itself
At a previous company, my engineering team believed you need a QA team with full separation of duties: developers build, testers verify, never the twain shall meet.
I worked hard to change their belief that “quality is a function.” When I left, the team was living something different — quality as everyone’s responsibility, built into how we worked rather than bolted on at the end. Even if they couldn’t articulate it, they understood that quality emerged from our engineering systems, not from a separate quality department.
But the transition was brutal, especially for the testers who suffered a loss of identity. By the time I left they had adapted but hadn’t found anything to replace what they’d lost.
The question stuck with me: what does a Quality Engineer become when they’re no longer gatekeepers?
This isn’t just a structural shift. It’s also an identity shift. For many testers, the loss of the gatekeeper role feels like a demotion — or even erasure. Reimagining the Quality Engineer isn’t about reassigning tasks. It’s about reclaiming professional identity inside the engineering system.
The shift to systems
I learned this the hard way through my own career progression. When I was a Quality Engineer or QA Manager, there were never enough fingers to plug all the leaks. My team and I were always downstream:
Code’s already written
Architecture’s already set
Technical debt’s already accumulated
You’re finding problems after they exist
You’re reporting them and hoping someone prioritizes fixes
It wasn’t until I moved to engineering leadership that I could start systematically fixing quality problems. I could change:
What gets built and how it gets built
The feedback loops
The deployment process
The testing strategy
The metrics that matter
Production observability
I could build systems where doing the right thing became the path of least resistance.
Quality emerges from engineering systems, not from oversight. When the structure is right, quality follows. Not because people “care more” or “try harder,” but because the system makes quality the default path.
This is what Alan Page just wrote about in his piece on why Microsoft’s new “quality czar” won’t fix their system. As he put it: “Systems don’t respond to intent. They respond to structure.” Titles don’t change behavior. Creating an executive quality role might signal that leadership cares, but it doesn’t change the underlying incentives that taught teams to cut corners in the first place.
Page described a moment when a senior leader decided to move a release date rather than ship with known structural risk. That single decision — durability beating speed in a moment where they truly conflicted — did more to improve quality than any new role could have. It altered what the system taught people.
The identity solution
But if quality engineers aren’t gatekeepers anymore, what are they?
The answer I’ve landed on: an engineer with specialized depth that keeps the team, its timelines, and its outcomes on track.
Not “quality person embedded with engineers” but “engineer who happens to have specialized quality expertise.” Your primary identity is engineer on the team. You’re of the team, not attached to it.
“Specialized depth” reframes the role as amplifying the team’s capability, not policing its work. Like a backend engineer has database optimization skills or a frontend engineer has performance profiling skills, quality engineering becomes a specialization within engineering, not a separate discipline that interfaces with engineering.
The value proposition is concrete: you prevent the team from shipping broken stuff that derails timelines and damages outcomes. That’s measurable, visible, and appreciated by teammates. You’re not an advisor offering suggestions people can ignore. You’re an engineer whose expertise keeps the team from driving off cliffs.
One ladder, weighted responsibilities
Making this real requires rethinking how we structure engineering roles. Here’s what I’ve come to believe works:
Every engineer is responsible for:
Feature development
System design
Test automation
Quality metrics
Code review
Technical debt management
Documentation
On-call
But the weighting and depth expectation varies by focus:
Backend-focused engineer:
Heavy: system design, feature development
Medium: test automation, quality metrics
Light: frontend concerns, infrastructure provisioning
Quality-focused engineer:
Heavy: test automation, quality metrics, testing strategy, system observability
Medium: system design (especially for testability), feature development
Light: deep backend optimization, frontend work
Frontend-focused engineer:
Heavy: component design, UX implementation
Medium: testing, system design
Light: backend services, infrastructure
Infrastructure-focused engineer:
Heavy: deployment systems, observability
Medium: automation, system design
Light: feature development, frontend work
This framework eliminates “not my job.” Everything is everyone’s job, just at different depths. It makes collaboration natural — the backend engineer writes tests, the quality engineer writes features. Neither is crossing boundaries; both are doing their jobs.
It makes the single career ladder obvious. Progression is about growing scope and influence across all dimensions, not mastering just one. A quality-focused Staff Engineer shapes quality systems and culture across the organization, influences architectural decisions for testability, and mentors engineers on quality practices. That’s the same scope of influence and strategic thinking required of a Staff Engineer focused on backend or infrastructure — just demonstrated through different work.
The quality engineer doesn’t feel lesser because they’re expected to contribute to system design and feature work. The backend engineer can’t dismiss quality as “someone else’s job” because they’re responsible for quality at some level too.
When this is working well, it will draw, say, backend-focused engineers into conversations with quality-focused engineers because they share responsibilities but one has deep expertise the other needs.
Leadership required
This won’t happen organically. It takes leadership to make this shift real.
Engineers won’t spontaneously grant peer status to testers. The historical hierarchy — engineers build, testers verify — is deeply embedded. Testers won’t spontaneously claim engineer identity either. They’ve been socialized into “I’m QA, not a developer.”
Leadership has to:
Explicitly name the change
Adjust reporting structures (quality-focused engineers report to Engineering Managers, not QA Managers)
Change titles internally (everyone is Software Engineer with specializations)
Change expectations (quality-focused engineers contribute code, participate in architectural discussions)
Change hiring requirements (technical skills mandatory, not optional)
Model the behavior (treat quality-focused engineers as peers in planning, architecture reviews, technical decisions)
Help quality-focused engineers claim their engineering identity and help other engineers see quality specialization as peer expertise.
The technical skills requirement matters. You can’t be “an engineer with quality specialization” without engineering skills. That means:
Writing automated tests
Understanding architecture well enough to identify where quality risks live
Reading and, ideally, debugging code
Building tools and infrastructure
Contributing meaningfully to technical discussions about tradeoffs
The role they were hired to do no longer exists. Leadership must invest in upskilling them and acknowledge that the role they know how to do is obsolete. That’s brutal but necessary. You can’t pretend someone is an engineer when they lack engineering capability.
Systems over titles
When I tried implementing this at that previous company, I ran into a problem. I wanted everyone to have the same title — Software Engineer — to force the cultural shift. But the career ladder document broke down. The expectations for quality-focused engineers weren’t the same as for other engineers, so I’d signaled equality while communicating different standards.
The solution is one ladder with weighted responsibilities. A quality-focused Staff Engineer should have the same scope of influence, the same strategic thinking requirements, and the same leadership expectations as a Staff Engineer who specializes in backend. The difference shows up in the examples of how you meet those standards, not in different expectations.
When this works, quality-focused engineers don’t feel peripheral, and product-focused engineers don’t feel policed. The team feels unified around shared ownership.
I learned this the hard way. Titles don’t change behavior. Structure does. You can’t inspect quality in. You have to engineer it in. And that requires engineers, not inspectors.
Engineers who happen to have specialized depth in quality systems. Engineers who keep their teams on track. Engineers who make the whole team better.
Not advisors. Not gatekeepers. Not a separate function.
Engineers.