Quality: We need to talk about accountability

Quality is everyone's responsibility, right? But precisely what does that look like? Having a basic understanding of what quality means for your organisation is essential. You can do quality workshops to get a shared agreement.

But what about the responsibility bit? What does that mean for a product team, Director of Engineering, VP of Engineering, or even a CTO? And how does responsibility differ from accountability?

As a director of quality engineering, it will be on you to help your peers, senior leadership and teams to understand and come to a consensus on who owns and who is accountable for quality. If you don't, people will make assumptions about what you do.

Responsibility versus Accountability

These two words seem almost identical, but there's a subtle difference. Responsibility indicates owning a task or a thing. Accountability expands responsibility to include owning the consequences of responsibility normally measured by actions taken(or not taken).

Accountability = Responsibility + Impact of Actions

So when we say everyone is responsible for quality, we indicate that we all own quality regardless of the outcome. That may not be what we want. What we might want to mean (especially in the context of quality coaching) is that a team is accountable for quality; the team owns the consequences of actions that result in poor or sound quality.

As a quality coach, having discussions around this distinction is vital. Do you understand what you are accountable for? And what you're responsible for? Do your manager, peers, and teams have a different perspective?

Accountability: Responsibility’s evil twin

Let's face it: the word accountability comes with baggage. Accountability has an association with consequences. Consequence suggests failure. Ideally, accountability should be neutral. The impact of actions can be either (or both) positive and negative. Taking accountability for good outcomes feels excellent! But in many cases, that's not how it's used. How many of us have experienced blame in a PIR for allowing bugs into the wild?

If accountability is not explicit, people will assume and allocate some accountability to you. And it may not be one you like. Teams may accept that we are all responsible for quality, but VPs of Engineering believe that final accountability sits with the quality coach. Directors of Engineering may assume teams are accountable for quality, failing to realise they are accountable for ensuring teams have the necessary skills and time to build quality into the product.

Accountability in Quality

We all have accountabilities in quality. But what they are will vary according to role and seniority. For example:

• As a team quality coach, I'm accountable for ensuring that the team has the necessary skills and tools to perform quality-related activities
• As a team, we're accountable for bugs in the wild
• As a Director of Engineering, I'm accountable for ensuring teams have sufficient bandwidth to deal with tech debt
• As a VP of Engineering, I'm accountable for engineering quality aligning with business and market and allocating suitable budgets to tooling and training.
• As Product Manager, I'm accountable for setting expectations around the importance of quality and its tradeoff with speed.

Using RACI as a Quality Coach

RACI (Responsible, Accountable, Consulted, Informed) is a much-loved or loathed framework. The RACI model defines responsibility as 'doing the work' instead of owning the work. I've used RACI to help manage conversations around quality and who is accountable for what. This is useful, especially as the quality coach role is new and unfamiliar to many. This gives people certainty that tasks are not being overlooked or inadvertently dropped.

Here's a miro version of a Quality RACI model I've used to good effect. Work out your stakeholders and critical categories. I've chosen Test Automation, Strategy, CI/CD Infrastructure, SLO's Test Environments, Process, Metrics and Risk Identification to demonstrate how the RACI works. As your context differs, you will likely have different categories. You will also have different stakeholders.

It may be helpful to get more granular by having different RACI for team, senior leadership, and platform contexts.

And remember, the purpose of the RACI is to have that discussion, not once, not twice, but over and over each time the organisation restructures or significant senior hires are made.

An alternative approach without RACI

When working with senior leadership, RACI is helpful as it offers clarity. However, within a team, a more consultative approach can be beneficial. Try this excellent post written by Katrina Clokie on 3 ways to define your role without a RACI matrix. 

What do you think? Have you used something similar in your company?

Thanks to Nick Pass and Nick Lee for reviewing and offering feedback.