Pawel, CTO of a mid-sized fintech company, had reasons to be proud. His development team numbered thirty people, used Scrum, had a dedicated QA department with five testers, and test automation tools costing tens of thousands of zlotys per year. On paper, everything looked professional. Yet every third sprint ended with a deadline postponement due to critical bugs discovered only at the acceptance testing stage. Developers complained that testers “nitpicked details.” Testers responded that they received “untested code.” The Product Owner was frustrated because successive deployments were delayed by weeks. Pawel tried to solve the problem the classic way — he hired two additional testers. After three months, the situation had not changed, and costs had risen by twenty percent. It was only when an external consultant asked him a simple question: “Who on your team feels responsible for the quality culture of the product?” that Pawel realized the problem lay not in the number of testers or the tools, but in the organizational culture of his development team.
See also
- 7 common pitfalls in dedicated software development projects (and how to avoid them)
- Anatomy of a project failure: why “cheap” suppliers cost the most and how strategic partnerships with ARDURA Consulting save projects
- 4 key levels of software testing - An expert’s guide
Pawel’s story is not unique. Across dozens of projects we have delivered at ARDURA Consulting, we observe the same pattern. Organizations invest in processes, tools and people, but overlook the most important element: building a culture in which quality is a shared value, not a task assigned to a single department. Quality culture in IT is not a slogan on an office wall — it is a concrete set of habits, practices and attitudes that determines whether a development team delivers software that is reliable and valuable, or merely “works on demo.” In this article, we will show why most teams fail at building a quality culture, which practices actually work, and how ARDURA Consulting’s approach creates an environment where every team member feels like a guardian of quality.
What exactly is a quality culture in a software team?
Quality culture is much more than a set of testing processes or code coverage metrics. It is a system of shared values, beliefs and habits that determines how every team member approaches their daily work. In a team with a strong quality culture, a developer does not finish a task the moment the code compiles — they finish it when they are confident that the code is readable, tested and easy to maintain. An analyst does not close a specification until they have verified edge cases with a tester. A DevOps engineer does not deploy changes to production without confidence that the CI/CD pipeline will catch potential regressions.
It is worth distinguishing quality culture from quality control. Quality control is the reactive inspection of a product after it has been built — searching for defects and flagging what does not meet standards. Quality culture, on the other hand, is proactive — it builds an environment in which defects have a harder time arising, because every stage of the process contains preventive mechanisms. Quality control answers the question “does this work correctly?” Quality culture answers the question “have we done everything so that it works correctly from the start?”
In practice, quality culture manifests itself in everyday, small decisions. A developer who sees an untidy piece of code written by a colleague does not walk past — they leave a comment in code review or talk about it over coffee. A tester who discovers an unintuitive flow in the interface does not limit themselves to filing a bug — they share the observation with the UX designer and together they look for a better solution. Quality culture is a culture in which no one says “that is not my problem,” because everyone understands that the quality of the final product depends on the sum of all the daily decisions made by every member of the team.
Why do most IT teams fail at building a quality culture?
If quality culture is so important, why do so few organizations have it? The answer lies in several deeply rooted organizational patterns that actively hinder its development.
The first and most commonly encountered problem is organizational siloing. In the traditional model, the development team and the QA team are two separate entities with their own goals, priorities and even office spaces. Developers are measured by features delivered, testers by bugs found. This division creates a natural conflict of interest: the more bugs a tester finds, the “worse” the developer’s work looks. Instead of collaboration, an atmosphere of rivalry and mutual blame emerges. A developer “throws code over the fence” to a tester, and the tester sends it back with a list of defects. Nobody feels ownership of quality — everyone feels responsible only for their own stage of the process.
The second problem is deadline pressure and a culture of “speed at all costs.” In organizations where delivery speed is all that matters, quality is the first victim of compromise. Code refactoring? No time. Writing unit tests? We will do it later. Code review? A quick glance will do. These “minor” compromises accumulate into what the industry calls technical debt — a growing mass of problems that over time slows the team more than any deadline ever could. Paradoxically, giving up quality in the name of speed leads to even greater slowdowns in the longer term.
The third and often underestimated reason is lack of leadership support. Quality culture cannot be a grassroots initiative that flourishes in an organizational vacuum. It needs the active support of managers and executives who confirm through both word and deed that quality is a priority. When a manager says “quality matters to us” but simultaneously insists on cutting testing time because “the client is waiting,” the team quickly learns that declarations are one thing and real priorities are another. Leaders who tolerate quality compromises, even unconsciously, destroy quality culture more effectively than any technical problem.
What does a quality culture maturity model look like in IT organizations?
Building a quality culture does not happen overnight. It is a transformational process that passes through several distinct stages. Understanding which stage your organization is at allows you to plan a realistic development path and avoid the frustration of trying to skip essential steps.
| Maturity level | Characteristics | Responsibility for quality | Typical practices | Result |
| **1. Reactive** | Quality = testing at the end. QA as a gate. | QA department only. | Manual tests, no automation, fixing bugs after deployment. | High defect escape rate, delays, inter-department conflicts. |
| **2. Defined** | QA processes are documented. Coding standards exist. | QA + partially developers. | Unit tests (inconsistent), code review (formal), basic CI/CD. | Fewer critical bugs in production, but still siloed. |
| **3. Integrated** | QA is embedded in the process. Testers and developers collaborate. | The entire development team. | TDD/BDD, pair testing, test automation, shared definitions of done. | Faster delivery cycles, fewer defects, better collaboration. |
| **4. Cultural** | Quality is a value built into the team's DNA. Everyone is a guardian of quality. | Every member of the organization, including business. | Shift-left and shift-right, continuous improvement, quality retrospectives, mentoring. | Minimal defects, high customer satisfaction, competitive advantage. |
| **5. Predictive** | The organization anticipates problems before they occur. Data drives quality decisions. | The entire organization with AI/ML automation. | Predictive analytics, automatic identification of risky changes, continuous [machine learning](/glossary/machine-learning/). | Proactive problem prevention, highest team efficiency. |
Most organizations we encounter at ARDURA Consulting are at level one or two. Moving to levels three and four requires a fundamental shift in thinking — from “quality as a stage” to “quality as a value.” This transition is possible, but it requires a strategic approach, patience and the support of an experienced partner.
Why does shared responsibility for quality change everything?
The foundation of quality culture is a principle that sounds simple but in practice requires deep transformation: the entire team is responsible for software quality, not just the QA department. This shift in perspective has consequences that go far beyond organizational matters.
When responsibility for quality is shared, the way developers write code changes. They no longer create it thinking “the tester will check it,” but rather “I need to be sure this works.” This subtle change in mindset leads to a fundamentally different approach to coding — more unit tests, cleaner code, better variable naming, more thorough error handling. A developer who feels ownership of quality naturally strives to produce code they can be proud of.
The role of the tester also changes. Instead of being a “bug catcher” at the end of the production line, they become a quality consultant who supports the entire team. They participate in requirements reviews, help developers design tests, share knowledge of testing techniques and analyze the root causes of defects. This role change is often the hardest for the testers themselves, who must step outside their comfort zone and learn to work in an entirely different way.
Shared responsibility also eliminates a phenomenon psychologists call diffusion of responsibility. In the traditional model, when a bug appears in production, a game of “who is to blame” begins. The developer claims the tester should have caught it. The tester replies that the specification was incomplete. The analyst blames the client for changing requirements. In a culture of shared responsibility, nobody looks for someone to blame — the entire team looks for a solution and draws conclusions to prevent the problem from recurring. This is a fundamental difference that determines whether a team grows or remains stuck.
How does pair testing build bridges between developers and testers?
One of the most powerful practices for building quality culture is pair testing — joint testing of software by a developer and a tester in a single session. At ARDURA Consulting, we treat pair testing not as a testing technique but as a tool for building culture and mutual understanding between roles.
The mechanism is simple, but the effects are profound. A developer and a tester sit together (physically or virtually) in front of one screen and jointly explore newly implemented functionality. The developer explains how the code works, what architectural decisions they made and where they see potential risks. The tester brings their perspective — thinking about edge cases, negative scenarios and user experience that the developer may not have considered.
This exchange of perspectives benefits both sides. The developer begins to understand how a tester thinks — what questions they ask, what bug patterns they know, what they pay attention to. Over time, they internalize these skills and begin to apply them independently while coding. The tester, in turn, learns the technical context, enabling them to better prioritize their tests and focus on the highest-risk areas.
Pair testing also has an emotional dimension that should not be underestimated. When a developer and a tester spend time together, talk, discover problems together and solve them together, a relationship based on mutual respect and understanding is built between them. The stereotype of “the tester who nitpicks” and “the developer who writes buggy code” disappears. It is replaced by the awareness that both roles are complementary and jointly pursue the same goal — delivering software of the highest quality.
How does systematic code review shape quality standards in a team?
Code review — the review of code by other team members before it is merged into the main branch — is one of the most valuable practices in the quality culture arsenal. At ARDURA Consulting, we treat code review not as a formality or a control mechanism but as the primary mechanism for sharing knowledge and raising standards across the entire team.
A well-conducted code review is a conversation, not an inspection. The reviewer does not look for reasons to reject the code — they look for ways to help the author make it better. Comments in code review should be constructive, educational and specific. Instead of “this is poorly written,” the reviewer writes “consider using the Strategy pattern here, as it will make it easier to add new variants in the future.” Such a comment does not just improve a specific piece of code — it also teaches the author a new approach that they will be able to apply independently in the future.
Code review also serves to level out knowledge within the team. When a junior developer sees how a senior approaches a problem, they learn patterns and practices they will not find in any textbook. When a senior reviews a junior’s code, they are reminded of the perspective of someone who is just learning a particular technology. This two-way exchange is one of the most effective mechanisms for developing competencies in a software team.
It is important, however, that code review does not become a bottleneck that slows down the team’s work. At ARDURA Consulting, we follow the rule that every pull request should receive a review within four hours of submission. We also maintain small, focused pull requests — easier to review and faster to move through the process. As a result, code review becomes a natural part of the workflow rather than an obstacle the team tries to bypass.
Why is team empowerment a prerequisite for quality culture?
Quality culture cannot exist in an environment where team members lack autonomy in making quality-related decisions. Empowerment — granting authority and trust — is a sine qua non of true quality culture. Without it, all processes and practices remain merely an external obligation rather than an internal conviction.
Empowerment in the context of quality means that a developer can refuse to merge code that does not meet standards, even when deadline pressure is enormous. It means that a tester has the right to block a deployment when they discover a critical issue, without fear of political consequences. It means that every team member can raise a quality concern and be confident they will be heard and taken seriously.
At ARDURA Consulting, we build empowerment on several pillars. First, we encourage developers to write unit and integration tests as an integral part of the coding process, often using the TDD (Test-Driven Development) approach. Tests are not an add-on written “if there is time left” — they are a fundamental part of the definition of done. Second, we give testers autonomy in choosing appropriate testing techniques and tools, trusting their knowledge and experience. A tester who knows the project context is in the best position to decide which approach will deliver the greatest value.
Third, and perhaps most importantly, we promote openness in raising concerns and potential risks by every team member. In organizational psychology, this is called psychological safety — the belief that one can express a concern, ask a “stupid” question or admit a mistake without fear of negative consequences. Teams with high psychological safety learn faster, make fewer repeated mistakes and deliver higher-quality software.
How does continuous learning drive quality in a software team?
The world of technology changes at a pace that makes knowledge from two years ago potentially outdated. New frameworks, new architectural patterns, new testing tools, new security attack vectors — a team that does not invest in continuous learning inevitably begins producing lower-quality software. Continuous competency development is the fuel of quality culture, without which even the best processes become ineffective over time.
At ARDURA Consulting, investing in the development of our specialists’ competencies is not a cost but a strategic priority. We organize regular internal knowledge-sharing sessions in which specialists present new technologies, share project experiences and discuss interesting problems they had to solve. These sessions have an additional effect — they build a sense of community and demonstrate that the organization values knowledge and the willingness to share it.
A particularly valuable practice is root cause analysis of defects found in production. Instead of treating a production bug as an incident to be quickly fixed and forgotten, the team should treat it as a learning opportunity. Why was this bug not caught earlier? Was a test missing? Was the specification incomplete? Was code review not thorough enough? The answers to these questions lead to systemic improvements that prevent similar problems from recurring in the future.
Equally important is mentoring — deliberately pairing experienced specialists with less experienced ones to transfer tacit knowledge, that elusive practical knowledge that cannot be learned from books. A senior developer who mentors a junior does not only pass on technical knowledge but also models an attitude toward quality — showing how to think about edge cases, how to write readable code, how to approach code review. This transfer of attitudes is one of the most effective ways to build quality culture.
What is the role of leaders in building and sustaining a quality culture?
No organizational culture can endure without the active support of leaders. This statement is particularly true for quality culture, where leaders must not only declare priorities but consistently confirm them through their decisions — especially the difficult ones.
The leader’s role in building quality culture has several dimensions. The first is giving teams time and space for quality activities. Code refactoring, writing automated tests, pair testing sessions, training — all of these activities require time that cannot be entirely consumed by new features. A leader who understands quality culture deliberately plans time in every sprint for quality and maintenance work, even at the cost of lower team “velocity” in the short term.
The second dimension is modeling desired behaviors. When the CTO personally participates in code review, when the project manager asks about test results before asking about new features, when the department head publicly praises a developer for finding and fixing a performance issue — all of this sends a signal to the team that quality truly matters. Leaders who “walk the talk” build quality culture more effectively than any training or presentation.
The third dimension is responding to attempts at quality compromises. In every project, there comes a moment when someone proposes to “skip tests because the deadline is approaching” or “not do code review this one time because the change is urgent.” The way a leader responds to these proposals defines the team’s culture. A leader building quality culture does not agree to compromises but at the same time helps the team find other ways to meet the deadline — for example, reducing feature scope instead of cutting quality.
What metrics allow you to measure and develop quality culture?
Quality culture, although it has a strong human and values dimension, must be measurable so that progress can be tracked and areas for improvement identified. Properly chosen metrics not only measure quality but also shape team behaviors — people naturally strive to optimize what is measured.
The most important quality culture metric is defect escape rate — the percentage of defects that “escaped” the development process and reached production. A low value for this indicator means that the team’s preventive mechanisms are working effectively. Equally important is mean time to detect (MTTD) — the average time from the introduction of a defect to its discovery. In a team with a strong quality culture, this time is short because problems are caught at early stages through automated tests, code review and pair testing.
It is also worth measuring code review coverage — what percentage of code changes go through review before merging. The goal should be one hundred percent, but the quality of those reviews matters just as much. The metric “average number of constructive comments per pull request” can help assess whether code review is superficial (quick approval without remarks) or substantive (meaningful discussion leading to improvements).
A less obvious but very valuable metric is time from defect report to fix, broken down by priority. Short fix times for critical defects indicate that the team takes quality seriously and can respond quickly to problems. Long fix times may signal that defects are treated as “second-class work,” which is a symptom of weak quality culture.
One should not forget about process metrics such as quality retrospective results. Regular retrospectives dedicated exclusively to the topic of quality allow the team to identify systemic problems and plan specific corrective actions. Documenting the results of these retrospectives and tracking the implementation of agreed actions is one of the most effective ways to continuously improve quality culture.
How to build a quality culture step by step, starting today?
Transforming quality culture is a marathon, not a sprint. It requires patience, consistency and the awareness that changing the habits of an entire team takes longer than deploying a new tool. The following action plan, based on ARDURA Consulting’s experience from dozens of projects, allows you to begin this transformation in a pragmatic and measurable way.
The first step is defining a shared definition of quality for the project. The entire team — developers, testers, analysts, DevOps, the Product Owner — must jointly establish what “quality” means in the context of their specific product. Is it reliability? Performance? Security? Usability? All of the above? Jointly defining quality priorities and acceptance criteria creates a foundation on which further practices can be built. Without this shared understanding, every team member optimizes quality according to their own subjective definition, leading to chaos.
The second step is introducing pair testing as a regular practice. There is no need to start with a full rollout — it is enough to begin with one session per week in which a developer and a tester jointly explore newly implemented functionality. Over time, as the team sees the benefits, pair testing will become a natural part of the process.
The third step is raising code review standards. Establishing clear guidelines for what a reviewer should look for (readability, testability, error handling, architectural compliance) and ensuring that every pull request goes through review creates a mechanism for continuously improving code quality.
The fourth step is introducing quality retrospectives — dedicated meetings where the team analyzes quality issues from the last sprint, identifies their root causes and agrees on specific corrective actions. These retrospectives should be separate from standard sprint retrospectives, to give the topic of quality sufficient space and attention.
How does ARDURA Consulting’s expertise help build a lasting quality culture?
At ARDURA Consulting, we understand that quality culture is not a matter of tools or processes — it is a matter of people, their attitudes and daily habits. That is why our approach to supporting clients in building quality culture goes far beyond providing QA specialists. We build teams that from day one bring quality culture standards and habits to the client’s organization.
Our experience spans 211+ completed projects in which we have consistently applied the practices described in this article: pair testing, systematic code review, specialist empowerment and continuous learning. Our 99% client retention rate is the best proof that this approach works — companies that have once experienced collaboration with a team built on the foundation of quality culture do not want to return to old patterns.
Our 500+ senior specialists are not only experts with deep technical knowledge but above all professionals who understand the value of quality and know how to promote it in the teams they join. Every ARDURA Consulting specialist goes through a verification process that evaluates not only technical competencies but also their attitude toward quality — willingness to write tests, participate in code review, share knowledge and collaborate with testers.
Thanks to the staff augmentation model, our specialists join the client’s team in just 2 weeks, bringing quality culture habits with them and becoming its ambassadors. Clients regularly report that the presence of ARDURA Consulting specialists on their team raises quality standards not only in the area they are directly responsible for, but across the entire team — an effect that delivers benefits far beyond the duration of the engagement. And 40% cost savings compared to in-house recruitment means that investing in quality does not have to mean higher costs.
What are the most frequently asked questions about quality culture in IT teams?
Does quality culture slow down software delivery?
This is one of the most common myths. In the short term, investing in quality practices may slightly extend the time needed for individual tasks. However, over the span of a few sprints, a team with a strong quality culture delivers faster because it spends significantly less time fixing bugs, handling production incidents and dealing with technical debt. Industry research consistently shows that teams using TDD and code review deliver software faster than those that forgo these practices.
How do you convince the board to invest in quality culture?
The most effective argument is hard financial data. Calculate the cost of production defects in the last quarter — developer time spent on fixes, support time, lost business opportunities, contractual penalties for downtime. Compare that cost with the investment in preventive practices. In most organizations, the ratio of reactive fixing costs to proactive prevention ranges from five to one to thirty to one. The board understands ROI.
Does quality culture require specialized tools?
No. Quality culture is primarily a change in attitudes and habits. Core practices — code review, pair testing, quality retrospectives — do not require any specialized tools beyond those the team already has (version control system, task management tool). Tools for test automation and static code analysis are valuable, but they are not a prerequisite at the start of the journey.
How do you measure progress in building a quality culture?
In addition to technical metrics (defect escape rate, test coverage, defect fix time), it is worth regularly surveying the team’s subjective perceptions. Anonymous surveys with questions such as “Do you feel responsible for product quality?” or “Do you have time to write tests?” capture the cultural dimension that technical metrics alone cannot convey.
Is quality culture possible in distributed teams?
Yes, provided that communication and collaboration are deliberately cultivated. Pair testing can be conducted via screen sharing, code review happens asynchronously in tools such as GitHub or GitLab, and quality retrospectives work well in videoconference format. The key is that quality practices are explicit and documented, because in distributed teams there is no opportunity to “observe” good habits at a colleague’s desk.
What is the difference between quality culture and DevOps?
DevOps is a set of practices and tools focused on automating software development and deployment processes. Quality culture is a broader concept — it encompasses the attitudes, values and habits of the team regarding quality. DevOps can be one element supporting quality culture (e.g., test automation in the CI/CD pipeline), but automation alone is not enough. A team can have an excellent CI/CD pipeline and at the same time lack quality culture if developers do not write tests and code review is superficial.
Building a quality culture in a software team is an investment that delivers benefits at every level — from higher-quality code, through better team collaboration, to greater customer satisfaction and lower maintenance costs. It is neither an easy nor a fast path, but as ARDURA Consulting’s experience from over two hundred projects shows, it is a path that leads to a lasting competitive advantage.
Want to build a quality culture in your IT team? Consult your project with us — we will show you how ARDURA Consulting specialists can become the catalyst for change in your organization.