Three approaches to foster a culture of quality
Creating a culture of quality is not determined by roles but rather by the way people think, behave, and act. There are various approaches to achieving this, each with benefits and tradeoffs.
Welcome to part three of the Culture of Quality series. In part one, we discussed Quality Engineering as philosophy, a framework and a tool to build quality and create a culture of quality throughout an organisation. In part two, we talked about Who should build a culture of quality and how it can be done at different levels within an organisation. In this part, we will explore three different approaches an organisation can take to foster a culture of quality, each with its benefits and tradeoffs.
Key insight
Creating a culture of quality is not determined by roles but rather by the way people think, behave, and act. There are various approaches to achieving this, each with benefits and tradeoffs.
Top takeaway
Building a culture of quality is not limited to specific roles. It depends on individuals' thinking, behaviour, and actions within the organisation.
Leaders can take different approaches to foster a culture of quality, such as developers as quality engineers, a hybrid approach to quality engineering, or a dedicated role as quality engineers.
Each approach has its benefits and tradeoffs; those looking to foster a culture of quality should factor in criteria such as time, perceived loss of skills, leadership support, learning opportunities, siloed focus on quality and diffusion of responsibility before deciding on an approach.
In the last two posts, we explored how leadership can build quality into an organisation using a culture of quality and how leadership can do it at different levels. In this post, I'd like to explore three different approaches organisations can take to foster a culture of quality. But first, where are all the Quality Engineers? From Who should build a culture of quality?:
Working in teams means you have the most significant influence on building quality at the product level, allowing you to leverage Quality Engineering as a tool. Working as a Discipline Manager (or more general people manager), you'll have the most significant influence on the people you line manage, allowing you to leverage Quality Engineering as a framework. Working at the Head of Department or function level means you'll have the most influence on the culture of a department, allowing you to leverage Quality Engineering as a philosophy.
You may have noticed that all the roles mentioned above are more traditional in teams, e.g. Developer, Testers, Delivery Managers, etc, but there was no mention of Quality Engineers.
Not roles but behaviours
Creating a culture of quality isn't about roles but about thinking, behaving and actions. It's about creating the condition to make the socio-technical system you work in healthier and more conducive to the desired quality outcomes. Who within your organisation does this depends on your particular context and situation.
Developers, Hybrid or Quality Engineers?
It may be that the software engineering discipline is more suited to fostering a culture of quality as it has traditionally done all the quality assurance work.
For other organisations, they may take a more hybrid approach. For instance, the Delivery disciplines may have focused more on the processes side of things. Therefore, they may be more suited to Quality Engineering as a framework approach. The organisation may have a Head of Test to handle the philosophy. Still, Developers and Testers decide to take on the Quality Engineering as a tool approach.
While some organisations may want a dedicated discipline to help foster a quality of culture and create a new job family of Quality Engineers.
Benefits and tradeoffs of different disciplines fostering a culture of quality initiatives
Each approach has different benefits and tradeoffs, which should be factored into your decision on which approach you take.
Developers as Quality Engineers
Developers as Quality Engineers approach (or any existing discipline, e.g. Testers, Delivery Managers, Product Managers, etc) are team members who take on the additional tasks of fostering a culture of quality alongside their existing duties.
Benefits of Developers as Quality Engineers
Immediate start: The organisation does not need to create new roles; they can start immediately. There will be no need for recruitment or authorisation from other people for the initiative other than immediate leaders' support for it to happen.
Leverage existing networks: They also have the added benefit of leveraging their existing role and relationships throughout the teams, departments and organisation to help them.
Tried and tested approaches: They may even have some tried and tested techniques for building quality into people, processes and products, e.g. developers may already have a good unit testing culture using TDD or BDD. Delivery Managers are using Kanban with WIP limits and working with small batches. Testers could be advocating for a whole team approach to testing.
Tradeoffs of Developers as Quality Engineers
When one discipline takes the lead, others may assume they don't need to contribute, limiting the collaborative efforts necessary for a healthier system.
Other factors that may also limit the impact of one discipline fostering a culture of quality could be:
Time: Doing Quality Engineering work alongside existing duties may be too much and limit the amount they can achieve.
Loss of skills: People may worry that doing Quality Engineering work limits their current skill set.
Limited Leadership support: Leadership may only see Quality Engineering work as a secondary or tertiary objective and not give adequate support to team members.
Limited learning opportunities: Quality Engineering work being wrapped into another discipline limits its exposure and opportunities to learn from others. How do you find others who are doing quality engineering work and are willing to talk about it? Do they consider it QE work or just a part of their day job? Are they downplaying the work to limit any self-perceived stigma of being considered a Quality Engineer?
Siloed focus of quality: Depending on which discipline takes on the Quality Engineering role, they may exclusively focus on their area of influence alone. For example, developers may look to improve quality only for the areas they are responsible for, e.g., the code. Delivery Managers may only focus on the process, and Testers may only focus on testing at the end of the delivery process.
Multidisciplinary Approach to Quality Engineers
A multidisciplinary approach is working with what you already have but with different disciplines working together to foster a culture of quality by each taking on different aspects of building quality into the system.
Benefits of a Multidisciplinary Approach to Quality Engineers
Alongside all the benefits of a single discipline, a multidisciplinary approach also limits some tradeoffs. The main one being quality now becomes a whole team responsibility, which helps with the following:
Running quality experiments: All team members can now work together on quality experiments to make their work system healthier. For example, the team comes up with an idea, and the organising, executing, and Delivery managers, Testers and Developers support analysis with their unique process perspectives.
Lower skill erosion: With all team members now involved with quality initiatives, concerns of eroding existing skill sets are lowered.
Support from leadership: With more disciplines working on improving quality, it can be easier to persuade leadership teams to support the initiative. Assuming someone is working with the leadership team to help them understand the quality initiatives.
Learning networks: With more people working on improving quality, it should be easier to learn from them. Assuming systems are in place to help share that learning.
Broader focus on quality: With multiple disciplines taking on quality initiatives, quality improvement is more likely to be spread across the system. For example, Delivery may be looking to improve the team's processes and allow developers to spend more time improving their unit testing strategy. These results help testers decide where they should focus their testing efforts.
Tradeoffs of a Multidisciplinary Approach to Quality Engineers
When quality is everyone's responsibility, it can sometimes lead to diffusion of responsibility. This results in decreased responsibility for each member's quality improvement and less effort when attempting to accomplish a quality initiative. Diffusion of responsibility is most likely to occur in large groups when there are no clear expectations, or no one is accountable for the outcomes.
With no central lead, it can make it difficult to coordinate efforts and see who is working on what. It can also lead to a more stop-start approach to initiatives, minimising their impact. Especially when things inevitably go wrong or it's hard to see how it's improving the overall system's health.
Dedicated role as Quality Engineers
A dedicated Quality Engineering role is when an organisation decides that it needs a specific role to drive the culture of quality throughout an organisation.
Benefits of a Dedicated role as Quality Engineers
Time: A dedicated role will have more time to work on quality initiatives without feeling conflicted that they are not working on their core responsibilities.
Developing Quality Engineering Skills: A dedicated person will develop skills that enable them to work more effectively as a Quality Engineer.
Leadership support: A dedicated role indicates that leaders see quality engineering as an essential task and are likelier to have quality goals as part of their objectives.
Develop learning networks: Finding and learning from other Quality Engineers will be much easier as you will likely be under the same management structure. The role's title acts like a signpost to help find others doing similar work. Quality Engineers are also incentivised to develop and share quality engineering knowledge across teams and departments, furthering the learning culture across an organisation.
Recruitment: A dedicated role means people are recruited specifically for this task and are incentives to drive quality and sharing initiatives. A specific role will likely mean recruiting supporting management structure, e.g. QE Managers, Leads, Principals, etc., making it easier to follow Quality Engineering as philosophy, a framework and a tool approach.
Support multidisciplinary approach to quality: A dedicated Quality Engineer will work with engineering teams and support them with running quality experiments. But also proactively share that learning back out so other teams can benefit and build on the work. QEs will help mitigate other disciplines' feeling like their skills are being eroded as they can still feel focused on their core responsibilities but have the support of a QE to speed them along their quality journey. QEs can help with reframing failed quality experiments and support teams to reflect and share their learnings across teams.
Centralised responsibility for supporting quality initiatives: QEs can act as a lead to coordinate actions and make quality initiative work more visible across the organisation, mitigating issues that can occur due to diffusions of responsibility.
Tradeoffs of a Dedicated role as Quality Engineers
Needs organisational support and finance: Creating a new discipline within an organisation is often time-consuming and requires dedicated internal support and finance.
Recruitment: Quality Engineers within the software space are new and need to be better understood, so recruiting them will take time, and they may need to be trained to be effective in their role.
Limited training resources: Training resources for Quality Engineering still need to be expanded and have yet to be proven.
Slow to get going: Quality Engineers are starting from scratch, so their initial team, department or organisational impact could be limited due to
Lack of support networks: Quality Engineers attempting to drive quality initiatives in teams and departments will need support. Whether it is goal setting, feedback, or people who are positive towards them and their work, having others to bounce ideas off helps keep things moving forward. Creating a support network takes time, especially for a new discipline.
Building networks takes time: Helping people understand what Quality Engineering is and what Quality Engineers do takes time.
Building trust takes time: Building relationships with teams to run quality experiments takes time. Engineering teams are unlikely to just let new people into their team and change things, especially if it could disrupt current and future work.
Competing team priorities: The team may already have priorities with a backlog of work. Working on quality initiatives may be a lower priority and not get the attention it needs, slowing down progress.
Teams may think their quality is good enough: Teams may even think their quality is good enough (we do testing and ship regularly. What more do we need?). Therefore, it may take Quality Engineers time to start working with teams on quality initiatives.
Behaviours to make the system healthier
The above approaches illustrate that none are perfect, and each has tradeoffs. And while none of those tradeoffs are insurmountable, each will need someone, whether a group or an individual, to work through.
Some tradeoffs you may be able to predict (diffusion of responsibility), others may emerge over time (the siloed focus of quality), and some issues will be masked by other problems (slow to get going). Without someone working on these issues, most quality initiatives will likely slow down, stall, or have limited impact.
Whether it's a Developer, Hybrid, or Quality Engineer approach, we should remember that it's about making our socio-technical systems healthier than they were and continuing to be so. It's about creating a better system, not a perfect one.
We need to understand our context and go with the approach that gives us the most benefits with the least impactful tradeoffs. However, we should be fully aware that there are tradeoffs that will result in issues we may not be able to anticipate. So, working with what you have and going from there is often a better approach than creating the perfect environment before starting.
This is a free post 🔓 so if you find it helpful, feel free to forward it on as others may do too, and if you’re not already a subscriber, then sign up so you can stay up-to-date with the latest Quality Engineering posts.