Making Quality Engineering Work: How to Build a Sustainable QE Transformation

You have seen the warning signs that your QE transformation may be failing: What next?

If you recognised the warning signs outlined in Part 1 – renaming roles without system redesign, automation without purpose, metrics without learning, improvement without prioritisation, fragmented collaboration, unclear ownership, or growing scepticism around QE – the natural question is: What now?

The good news is this: the solution isn’t more tools. It’s intentional change.

Awareness is the first signal of progress, but awareness alone doesn’t create transformation. Many teams recognise the challenges in their QE transition yet struggle to turn the insight into action. Not because they lack capability or commitment, but because Quality Engineering is a change management journey, not an operational mandate.

QE reshapes how teams think, collaborate, and make decisions. It requires new mindsets, new capabilities, and new systems of work. Like any meaningful organisational change, it must be designed and guided deliberately, not left to chance. That, is the purpose of Part 2.

Here, we explore how to make Quality Engineering work by grounding the transition in well‑established change principles. We’ll see how proven change frameworks can provide structure and predictability to QE initiatives, and how they directly address the failure patterns surfaced in Part.

By the end of this part, you’ll have a clearer understanding of how to shift QE from a fragile initiative to a resilient, system‑level transformation your teams can trust, rally behind, and sustain.

Quality Engineering succeeds not because teams adopt new tools, but because they redesign how quality is understood, created, and improved across the entire system.
Product Quality Insights

Why change management matters in QE transformation

Successful Quality Engineering requires more than new practices or a change in titles: it requires a system redesign.

If one lesson stands out from the failure patterns discussed in part 1, it’s this:

Quality Engineering doesn’t fail because teams lack capability.
It fails because organisations underestimate the change required to make it work.

Most teams treat QE as a tooling or process shift. But in reality, QE represents a deeper change in mindset, behaviour, structure, accountability, and culture – something no mandate or role rename can achieve alone.

This is why QE transition programmes must be approached with a change management hat. Teams must build the environment where QE can thrive, especially when the aim is to scale it across multiple squads or teams.

Just as TQM, Lean, Six Sigma, and Systems Thinking reshaped industries by transforming culture and systems, modern QE succeeds only when supported by similarly deliberate, structured change.

QE transformation is built on proven quality thinking

QE builds on the foundations laid by earlier quality movements, which teams can learn from. For example, TQM, popularised by pioneers such as W. Edwards Deming, outlined five timeless principles for building a culture of quality:

Use the Deming cycle (Plan–Do–Check–Act)
A structured loop for learning, experimentation and sustained improvement
Empower your staff
Those closest to the work must have the authority, time, and support to influence quality.
Apply data to decision-making
Focus on system learning, not individual blame.
Commit to continuous improvement
Small, frequent, disciplined improvements that strengthen the whole system.
Focus on your customers
Quality is defined by user perception and experience – reinforcing the idea that quality is perception.

These principles remain deeply relevant today. They remind us that quality is not owned by a single role, it is shaped by an entire system. And systems change only through intentional design.

QE transformation is a change management challenge

At its core, QE touches every dimension of how teams operate:

How work flows
How decisions are made
Who is involved and when
How risk is understood
How success is measured
How learning happens
How ownership is distributed.

This makes QE not just a technical shift, but a cultural and delivery transformation.

Put simply:

Quality Engineering is a cultural transformation wearing a technical hat.

And like any transformation affecting behaviour, collaboration, and decision-making, QE transformation programmes need a model that helps people:

Understand why the change is needed
Desire to participate in it
Know how to apply the change
Develop the ability to perform in new ways
Sustain the change over time

For this reason, adopting a formal change model isn’t optional – it is essential for steering a successful QE transition.

Applying the ADKAR model to QE transformation

To translate intent into sustained behavioural and system change, QE teams need a clear transition framework.

There are several well-known change management models – Kotter’s 8 steps, Lewin’s unfreeze–change–refreeze framework, Bridges’ transition model, and others. Each has its strength. However, a favoured model for QE transformation is: the ADKAR model.

The ADKAR model provides a structure and sequence of actions to guide people through change by encouraging those leading the change to create:

Awareness of why the change is needed
Desire to support and participate in the change
Knowledge of how to make the change happen (skills, practices and methods)
Ability to implement new skills and behaviour
Reinforcement to sustain the change

This model offers a practical, people‑centred structure that aligns perfectly with the earlier-stated requirements for successful QE transformation. Therefore, in the following subsections, we will use the insights from ADKAR, to address each failure mode highlighted in Part 1.

Establish a clear and shared vision of quality

Failure mode: Collaborating without a shared vision

Every successful quality transformation begins with clarity. Yet, different functions often hold different perceptions of quality – Product may prioritise speed, Engineering may emphasise architecture, Operations may focus on uptime, and users may care about reliability and usability.

Without a shared vision of quality, teams will optimise in different directions and can fragment a QE transformation.

What to do(ADKAR focus): create awareness and desire for change

Co‑create a quality vision
Run a workshop with relevant stakeholders – Product, Engineering, Design, Ops, and QE to answer:
- What does quality mean for our customers? and in our business context?
- How will we measure it? (choose 3–5 “North Star” outcomes)
Publish a one‑page quality narrative
Include the vision, principles, decision heuristics, and 3–5 quality commitments (e.g., “no silent failures”).
Define a shared ‘Definition of Quality’ (DoQ)
Pair this with the DoR/DoD and ensure quality gates reflect the DoQ.
Align metrics to quality outcomes
Link at least one team goal to the defined quality outcomes.

Signals you’re making progress

Teams reference the same quality outcomes during ceremonies and decisions.
Fewer cross‑team disagreements about “what quality means and what good looks like.”
Backlog items tied to quality outcomes increase – and get completed.

When teams share a unified definition of quality and organise around it, QE can stop being a functional initiative and becomes a strategic one.

Redesign the system – not just the role

Failure mode: Renaming roles without redesigning the system

Changing titles does not change systems. Yet, many organisations rename testers to Quality Engineers (QE’s), but leave value streams, incentives, workflows, and decision rights untouched – rendering QE as a cosmetic change.

What to do (ADKAR focus): build the knowledge & ability required for change

Map your value stream
From design, development, to delivery. Identify where quality is currently built in, and where it’s not.
Redesign operating cadence
- Add QE activities to discovery, design reviews, and delivery.
- Update DoR/DoD with quality activities (risk analysis, testability checks, observability criteria).
Realign incentives
Use team‑level quality outcomes. Avoid function-specific metrics that create local optimisation.
Clarify roles & decision rights
Use frameworks such as RACI to define who decides and recommends on release risk, test strategy, and reliability.
Create time and space
Allocate 10–20% capacity for systemic quality improvements.

Signals you’re making progress

Earlier defect prevention during refinement or design.
QE shifts from firefighting to partnering and influencing.
Teams report clearer decision pathways for quality‑related trade-offs.

System redesign may require adjusting several incentives, redefining release criteria, or modifying workflow expectations in your current context. This can feel uncomfortable – but without such structural change, behavioural change will not sustain.

Align automation with business value and risk

Failure mode: automating without alignment

Automation becomes costly and brittle when it isn’t anchored to risk, business value, or the feedback needed for fast learning.

What to do (ADKAR focus): create awareness, build the knowledge, ability and reinforcement required for change.

Write an automation charter/ strategy. Clarify for example:
- What risks are we reducing? (e.g., regression, stability or performance)
- Where is feedback most valuable and earliest? (API/component vs UI)
- Which defects are most costly? (target tests at that level)
Adopt the test pyramid with API/ integration emphasis:
Limit UI coverage to essential high‑value paths.
Budget for maintenance:
Treat automation as a product; plan flakiness remediation, refactors, and deprecations.
Set quality goals for test health:
For example, respond to test failures with the same urgency as build failures.
Use observability to guide testing:
Use production signals to inform test cases and oracles.

Signals you’re making progress

Faster, more reliable pipelines; fewer flaky tests.
Clear linkage between tests and business risks.
Stakeholders stop questioning automation ROI.

By taking proactive steps to align automation effort with business goals, trust in automation can increase and its value can become appreciated across the business.

Make metrics instruments of learning, not control

Failure mode: measuring without learning

Dashboards multiply; behaviour doesn’t change. Metrics become reporting tools – sometimes tools for blame – instead of mechanisms for learning.

What to do (ADKAR focus): build the knowledge and reinforcement required for change.

Define a metrics charter:
- Clarify the purpose (learning, not judgement), owners and review cadence.
Institutionalise learning rituals:
- Enact blameless, trend‑based, action‑oriented quality reviews.
- Organise post‑incident reviews that lead to systemic fixes, not individual blame
Shift from lagging to leading indicators:
For example,
- Move from defect counts to escaped defect trends
- From number of automated tests to test reliability
- From pipeline duration to pipeline stability
Create an improvement backlog:
- Tie backlog items to metric trends, and ensure they are prioritised.

Signals you’re making progress:

Fewer “reporting theatre” meetings; more decisions and follow‑through.
Teams surface insights proactively; defensiveness decreases.
Metric trends correlate with visible, positive behaviour changes.

When metrics drive learning rather than judgment, teams will surface issues earlier, and solve them faster.

Pair responsibility with empowerment

Failure mode: sharing ownership without empowerment

QE often expands expectations: earlier involvement, stronger automation, better risk identification etc. But if responsibility expands without authority, frustration grows.

What to do (ADKAR focus): create the desire, build the ability and reinforcement required for change.

Define decision rights:
- Who can block a release?
- Who approves risk trade‑offs?
- Who owns reliability decisions?
Create an empowering environment:
- Provide the space, time, and capacity for experimentation and learning.
Involve QE’s early:
- Make QE a standing member of discovery, design reviews, delivery planning.
Establish quality champions:
- Assign cross‑functional ambassadors who steward the quality vision.
Leadership advocacy:
- Get leaders to visibly back QE’s when trade‑offs are made.

Signals you’re making progress

QE insights influences scope, sequence, or design before development.
Fewer “we already knew this risk” moments in retros or incident reviews.
Teams report greater clarity and confidence around who decides on quality related activities.
QE receives real investment in tooling, observability, and continuous improvement.

When teams are empowered to fix systemic weaknesses, QE becomes credible – not aspirational.

Institutionalise continuous improvement with discipline

Failure mode: Improving without prioritisation

Teams identify the same issues repeatedly, but fixes languish in the backlogs because new features always win.

What to do (ADKAR focus): build the reinforcement required to sustain the change.

Allocate protected capacity:
- Reserve 10–20% capacity each iteration for systemic quality improvements.
Visualise improvement:
- Track improvement work alongside feature work, and prioritise it.
Adopt the Deming cycle (PDCA) explicitly:
- Plan – Do – Check – Act for each improvement item.
Build on stable foundations:
- Introduce new practices incrementally, and on top of existing ones where necessary.
Enact quality health check:
- Continuously review outcomes, retire stale items, and reset priorities.

Signals you’re making progress:

Recurring issues decline; and mean time to respond shortens.
Improvement work becomes predictable, not ad‑hoc.
Teams can point to shipped improvements each cycle.

When continuous improvement becomes part of a team’s infrastructure, QE has a better chance of being sustained.

Moving from Quality function to Quality system

One of the most important shifts in any QE transformation is recognising that:

Quality cannot be owned by a function – it must be designed into the system.

Treating QE as a role or set of tasks leads to predictable problems: late involvement, unclear ownership, reliance on downstream testing, brittle automation, and declining quality under pressure.

A quality system, by contrast, embeds quality into:

Work flow
Decision‑making
Risk management
Feedback loops
Learning cycles
Prioritisation mechanisms

When quality is built into the system, defects decline naturally, learning accelerates, and QE becomes a partner in delivery – not a last line of defence.

QE cannot succeed within a system still operating with a traditional testing mindset. It becomes sustainable only when the environment supports continuous, collaborative quality behaviours by default.

This shift sets the stage for the next step: assessing whether your environment enables or restricts QE – which we shall explore in the section below.

A quick self-assessment: Is your QE transition at risk?

Here is a lean, five-question assessment you can use to evaluate whether the foundations of QE are in place in your environment.

If you answer “no” to more than two of the questions below, your QE transition may be at risk.

In view of your context, ask yourself:

Do we share the same definition of “quality”?
If different teams hold different meanings, alignment may already be fractured.
Has the system changed, or only the titles?
If workflows, incentives, and decision paths remain the same, QE may be cosmetic.
Is automation aligned with risk and value?
If automation grows, but impact doesn’t, the strategy may need re-anchoring.
Do metrics drive learning, not reporting?
If dashboards increase but behaviour doesn’t change, learning loops may be missing.
Are quality professionals empowered early and meaningfully?
Without early involvement and decision rights, shared ownership may be symbolic.

If these signals feel familiar, the issue may not be your ambition, but system design. This does not indicate failure, rather, an opportunity for intentional redesign.

Final thoughts: Intentional change determines success

Quality Engineering doesn’t succeed because teams adopt new practices, titles, or tools. It succeeds when organisations redesign the systems, behaviours, and decisions that shape how quality is created every day.

The pitfalls outlined in Part 1 were not signs of weak teams: they were signs of weak change design.

The practices explored in Part 2 are not quick fixes: they are foundations for a durable, system‑level transformation.

The principles required for a sustainable QE transformation are not new:

Vision, leadership commitment, empowerment, data-driven learning and continuous improvement.

What is new is the speed and complexity of modern systems, which makes disciplined change more vital than ever.

So, if your QE transition is struggling, resist the urge to add more tooling or more processes. Instead, step back and examine the system that is producing your current outcomes.

If there is one idea to take away from this series, it is this:

Quality Engineering is achievable, but it’s success is never accidental.
It is the result of intentional change, grounded in vision, and guided by disciplined leadership.

Teams that recognise this, and build their QE transformation accordingly, are those who can turn QE from a fragile initiative into a long-lasting organisational capability.

In a nutshell, sustainable Quality Engineering is not something you announce. It is something you design.

Your transition can succeed. But it must be designed to – with intent.