Building a Quality Culture Across Delivery Teams | Amber Insights #006
Updated: Sep 8
By Amber Idumwonyi
A team can have experienced Quality Engineers, sophisticated automation, comprehensive test documentation, and excellent tools, and still struggle to deliver quality software.
Why?
Because quality is not created by tools alone.
It is shaped by culture.
Throughout my career in Quality Engineering, I have seen that some of the strongest delivery teams are not necessarily those with the largest testing functions or the most elaborate processes. They are the teams where people genuinely believe that the quality of the product belongs to everyone.
Developers care about what happens beyond their code.
Business Analysts consider whether requirements are clear and testable.
Product Owners understand the consequences of prioritisation decisions.
Quality Engineers are involved in conversations rather than simply receiving
completed functionality.
Delivery leaders create space for teams to raise concerns without being seen as obstacles to progress.
That is a quality culture.
And building one requires much more than telling everyone that "quality is everyone's responsibility."
What Does a Quality Culture Actually Mean?
The phrase quality is everyone's responsibility is widely used in technology.
But saying it does not automatically make it true.
A quality culture exists when the behaviours, decisions, and priorities of a delivery team consistently demonstrate that quality matters.
It means people do not knowingly pass problems downstream simply because resolving them falls outside their job title.
It means difficult questions are welcomed.
It means defects are treated as opportunities to understand what went wrong, rather than opportunities to assign blame.
It means delivery pressure does not automatically silence legitimate quality concerns.
Most importantly, it means quality is considered when decisions are made, not simply evaluated after those decisions have already been implemented.
That distinction matters.
A team cannot claim to value quality if quality only becomes important when something fails.
Quality Culture Starts with Psychological Safety
Imagine a Quality Engineer discovers a potentially serious issue shortly before an important release.
There are two possible environments.
In the first, the tester hesitates before raising it.
The deadline has already been communicated.
Senior stakeholders are expecting the release.
Everyone is under pressure.
Previous concerns have been dismissed as testers "blocking delivery."
So the tester stays quiet or understates the problem.
In the second environment, the tester raises the concern immediately.
The team examines the evidence, discusses the potential impact, and decides collectively what action should be taken.
The difference between those teams is not technical capability.
It is culture.
People need to feel able to challenge assumptions, identify risks, admit mistakes, and say "I don't think this is ready" when the evidence supports that position.
That does not mean Quality Engineers should become permanent blockers.
Quite the opposite.
Our role is to provide evidence that helps teams make informed decisions.
But evidence has little value if the culture discourages people from presenting it.
Stop Treating Defects as Personal Failures
One behaviour that can quickly damage a quality culture is blame.
"Who introduced this defect?"
"Why didn't testing catch this?"
"How did development miss this?"
These questions may sound reasonable, but when their purpose is to identify someone to blame rather than understand what happened, they rarely improve quality.
Software delivery is complex.
A production defect might originate from an ambiguous requirement, an incorrect assumption, a code change, missing test coverage, unsuitable test data, an environmental difference, an integration dependency, or several factors occurring together.
The better questions are:
Why was this possible?
Why didn't our existing controls identify it?
What can we change to reduce the likelihood of it happening again?
That moves the conversation from blame to learning.
Strong quality cultures investigate systems and processes, not simply
individuals.
Accountability still matters.
But accountability and blame are not the same thing.
Developers and Testers Are Not Opposing Teams
Another cultural problem I have encountered is the invisible wall that can develop between development and testing.
A Developer completes a feature.
A tester finds a defect.
The feature goes back.
The Developer fixes it.
The tester retests it.
Repeat.
Eventually, the relationship can begin to feel transactional—or even adversarial.
The Developer wants the feature accepted.
The tester wants to find what is wrong with it.
But those should never be competing objectives.
Both professionals are trying to achieve the same outcome:
Deliver software that works well for the people who need it.
When teams genuinely understand this, conversations change.
A defect is no longer "the tester rejecting my work."
It becomes "we've discovered something that could affect our product."
Likewise, testing should never become an exercise in proving that development has made mistakes.
Quality Engineering works best when Developers and Quality Engineers bring different perspectives to the same problem.
Shared Responsibility Does Not Mean Blurred Responsibility
There is an important distinction here.
Saying that everyone contributes to quality does not mean everyone suddenly performs the same role.
Developers still bring specialist engineering expertise.
Business Analysts still bring requirements and process expertise.
Product Owners still make product and prioritisation decisions.
Quality Engineers still bring specialist expertise in testing, assurance, risk, investigation, and quality.
Shared ownership should strengthen those disciplines, not erase them.
This is particularly important because organisations can sometimes misunderstand the phrase everyone owns quality to mean that specialist testing expertise is no longer necessary.
That is not what a quality culture means.
A football team shares responsibility for winning the match.
That does not mean everyone becomes the goalkeeper.
Different roles contribute different expertise towards a shared outcome.
Software delivery is no different.
Leadership Sets the Standard
Quality culture cannot be created solely from the testing team.
Leadership behaviour matters enormously.
If leaders repeatedly prioritise deadlines regardless of quality consequences, teams learn very quickly what the organisation truly values.
If teams are rewarded only for delivering features quickly, speed becomes the priority.
If raising concerns creates conflict while remaining silent creates no consequences, people learn to remain silent.
Culture is shaped by what leaders tolerate, reward, question, and prioritise.
Strong delivery leaders ask questions such as:
What is our level of confidence?
What remains untested?
What are the significant outstanding concerns?
What would be the consequence of releasing with this issue?
What information do we need before making this decision?
These questions demonstrate that quality information is part of delivery decision-making.
Metrics Can Shape the Wrong Culture
What organisations measure also influences behaviour.
Consider a team whose primary testing target is the number of test cases executed each week.
What behaviour might that encourage?
Potentially, executing large numbers of simple tests becomes more valuable than spending time investigating one complicated but significant problem.
Similarly, measuring Developers primarily by the number of tickets completed can encourage throughput without necessarily rewarding maintainability or quality.
Metrics are useful.
But metrics become dangerous when the number becomes the objective rather than the insight it was intended to provide.
A team with 98% of test cases passing does not automatically have a high-quality product.
A team that found 200 defects is not automatically better than a team that found 20.
Context matters.
Good quality cultures use metrics to ask better questions rather than to manufacture reassuring numbers.
Quality Conversations Need to Happen Regularly
Culture is built through everyday behaviour.
It develops in the questions asked during discussions.
It appears in how teams respond when something goes wrong.
It appears in whether concerns are investigated or dismissed.
It appears in how trade-offs are communicated.
And it appears in whether lessons from previous problems actually influence future decisions.
Teams should be comfortable discussing quality openly.
Not only:
"How many tests have passed?"
But also:
"What are we least confident about?"
"What haven't we considered?"
"What assumptions are we relying on?"
"Where do we need more information?"
"What have we learned?"
Those conversations are often more valuable than another dashboard.
Quality and Speed Are Not Enemies
One of the most damaging assumptions in software delivery is that teams must choose between speed and quality.
Quality is sometimes portrayed as something that slows delivery down.
I see it differently.
Poor quality can be incredibly expensive.
Repeated rework consumes development time.
Unclear requirements create unnecessary cycles of clarification and correction.
Unstable releases generate incidents.
Production defects interrupt planned work.
Customer complaints require investigation.
Technical problems accumulate.
A strong quality culture is therefore not about creating unnecessary gates around delivery.
It is about reducing avoidable waste and creating confidence in the team's ability to deliver.
The objective is not quality instead of speed.
It is sustainable speed with appropriate quality.
Quality Culture Is Built, Not Announced
Organisations sometimes attempt to create cultural change through slogans.
A presentation is delivered.
A new quality initiative is announced.
Posters appear.
Everyone is told:
"From today, quality is everyone's responsibility."
But culture does not change because a statement has been made.
It changes when behaviours change.
When a Developer asks a Quality Engineer for input before implementation.
When a Business Analyst invites challenge to an unclear requirement.
When a tester raises an uncomfortable concern and is listened to.
When a Product Owner considers quality implications alongside feature priority.
When a team investigates a production problem without searching for someone to blame.
When leadership chooses evidence over optimism.
Those individual behaviours accumulate.
Eventually, they become simply:
How this team works.
That is culture.
The Role of the Quality Engineer in Building Culture
Quality Engineers have an important role in influencing this environment.
Not by policing everyone else.
Not by positioning themselves as the sole guardians of quality.
And not by owning every quality activity.
Our influence comes from helping teams think differently.
We can ask questions that expose assumptions.
We can make quality risks understandable to non-testing stakeholders.
We can encourage collaboration.
We can share testing knowledge.
We can help teams learn from failures.
We can bring evidence into difficult decisions.
And perhaps most importantly, we can demonstrate that Quality Engineering
is not about preventing teams from releasing software.
It is about helping them understand what they are releasing and how confident they should be in it.
That is a very different relationship.
Final Thoughts
A mature quality culture cannot be purchased as a tool, installed as a framework, or delegated to a testing department.
It is created through hundreds of everyday decisions made across a delivery team.
It exists when people feel responsible for the outcome rather than only their individual task.
When questions are welcomed.
When evidence matters.
When defects create learning rather than blame.
When specialist Quality Engineers are treated as partners rather than final-stage gatekeepers.
And when leaders recognise that sustainable delivery requires both pace and confidence.
You can introduce better tools.
You can increase automation.
You can improve processes.
All of those things can help.
But if the underlying culture treats quality as someone else's problem, the organisation will continue fighting the same battles.
Quality becomes sustainable when it stops belonging to a department and starts becoming part of how the team thinks, communicates, and works.
About the Author
Amber Idumwonyi is a Senior Quality Engineering Leader with over eight years of experience delivering quality engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed enterprise Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Read More:
Amber Insights | Issue 001 – Why Every Successful Software Project Starts with a Test Strategy
Amber Insights | Issue 002 – Testing Is Not a Phase; It Is a Mindset
Amber Insights | Issue 003 – Understanding Software Quality Beyond Finding Bugs
Amber Insights | Issue 004 – The Evolution from Quality Assurance to Quality Engineering
Amber Insights | Issue 005 – Risk-Based Testing: Focusing on What Matters Most
Explore LEMP's Software Testing programme and learn how you can get started.
Comments