April 26, 2020


Personal responsibility or gate-keeping?

Note: this is taken from something I wrote to encourage discussion and thought around quality process within my team. In the end, I thought it was worth making public, but readability without context may vary.


Quality can feel like an intangible thing at times, we are more likely to see and feel lack of quality than its presence. Sometimes we see it as things crumble underneath of us, sometimes it sneaks up on us as lots of not quite perfect things build into a fractured whole.

Harder still is understanding how we arrive at ensuring quality. Is that even a thing we can do?

Quality for me is like productivity, it is one of those problems that acts like a bar of soap - the harder you try to hold on to it - the more likely it is to fly out of your control.

One of my favourite product development productivity wisdoms is from the book The Principles of Product Development Flow by Reinersten.

…the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to its very core. Today’s product development orthodoxy is broken. What’s wrong? Companies are pursuing the wrong goals. They maximize capacity utilization, and wonder why cycle times are so long. They strive to conform to plan, and wonder why new obstacles constantly emerge. They try to eliminate variability, and wonder why innovation disappears. They carefully break processes into phases and gates, and wonder why things slow down instead of speeding up. Ironically, each of these actions actually hurts more than it helps.

My take on software and product quality follows a very similar path, people want to stop others from making mistakes so they remove their responsibility and ability to make decisions. They want to remove variability in outputs, preventing better more appropriate practices and checks for a given situation. They want to force quality on others, preventing anyone from contributing to it. Every gate put up in the name of quality eliminates far more opportunity for quality than it ensures.

Over the past 12 months, I have made 1000s of commits, is it actually possible for me to outsource the quality to someone else? or something else in the form of some fixed process? It feels naive to the point of absurdity that anyone but myself could possibly be responsible for the quality of what I do - yet in most product development spaces there is an inordinate amount of effort and misguided process put to take that responsibility away. It just doesn’t make sense, doesn’t work, and I think it is debilitating to actual attempts to improve the quality of outputs. So what is the alternative?

Quality as a Personal Responsibility

Let me start with the position that I think doing the best that you can do is everyone’s default, then there are things that degrade it: conflicting constraints (time etc…); poor incentives to balance those constraints; lack of skills or abilities to execute; lack of knowledge and tools to help improve what you have produced. And, I don’t think this is an optimistic position, it is far harder to believe that people are actively looking for ways to do poor work.

So the question isn’t one of how do we make it a personal responsibility, it is how do we support it as a personal responsibility. How do we provide the space and support required? How do we put the right incentives and goals in place that allow good decisions and the right balance on dealing with competing needs? How do we remove constraints? What tools do we provide to make it easier to achieve, to increase skill and individual potential?

The Role of Process

Does that mean process has no place in quality? Well, no. But the role is very distinct to how it is normally presented. The role of process should clearly be one of assistance and support for individuals rather than as a force for removing variability or forcing quality on others. Process should be seen as a tool that individuals can lean on for working through unfamiliar waters, helping them understand and work to team norms, helping teams discuss and contribute to improving norms. But process can’t be seen as the goal, if someone genuinely thinks that a team process helps them in a given situation, they should do it (obviously). If someone genuinely thinks that it is something that definitely does not help in a particular situation, they should not do it just for the sake of it (probably not so obviously) - but should use that as a trigger to let people know to expect a variation in norms. Note well that people should treat these variations with trust and respect, rather than fear and distrust, as it means people are making decisions and the upside is that they will apply that in the positive as well - doing more than the norms - when the situation demands it. When someone doesn’t have a particularly strong opinion, or is in unsure, then normal processes should be the default.

This is a long winded way to say do things that make sense, don’t do things that don’t (just because you normally do them), and always be looking for opportunities to do more and improve - don’t just slump over process lines like you just climbed Mount Everest and couldn’t possibly go higher - treat it like a minimal standard for interacting with the rest of your team.

The important thing here is the perspective on what process is, and how it should be thought about. Process is neither inherently good nor bad, it can often help but thinking of it as a control mechanism is almost certainly bad.

Simple Tools Go Further

What tools or processes can support quality the most? The word support here is not an accident. Repeating stuff must make it important I guess.

For me, the simplest and most effective tool has always been having a second perspective to analyse my work from. Depending on the change I am making, that might mean one person, or it might mean a bunch of different people for different aspects of the change, or in some cases it is just a matter of me stepping back from the problem to really think it through. More formally this can take the form of reviews: code reviews; design reviews, product reviews etc… but informally it is just about getting others involved in my outputs.

How can you get people involved in your work? I think the first thing is that it has to happen at the start of your work, not at the end. You need to take people on a journey, from start to finish, give them some context, get them invested in helping you, give them the tools to help you. I constantly refer to this as bookend-ing, you want to bookend your work with different perspectives, getting different people involved. If you think there is someone who could help you do a code review at the end, get them involved in a whiteboard session before you start.

One problem that often pops up with the more formal side of this (for example in code reviews) is that the same tools are more often used for what I refer to the bad side of process, for control/gate-keeping etc… and it taints the thinking around these tools, and how they are useful. Some things that might help you think about review in a different way.

Responsibilities in asking for help in the form of a review:

Responsibilities in responding to a request for help:

So yeah, feedback, review, communication around it. These are good things.

Completing work

Finish things. Everything else is irrelevant when things do not reach a state of completion. That doesn’t mean that everything that could possibly be done is done, but for the things that are attempted there should be a done state, that is good and speaks to the quality that you want if nothing else happens after.

Getting to that point where you can put it down is critical. If you (or someone else) has a list of things that makes the current work “not done”, you can never move on, there will be friction with how it interacts with other work - are we talking about what is there - or are we talking about what is there plus the “stuff to fix list”. It creates a fractured jigsaw, that no matter how good things are, they will never fit together.

Incomplete work is also baggage that will weigh you down. If you pick up some maintenance/fix list from every piece of work - over enough time - that maintenance list will be all you have.

Finding ways to complete things is a team exercise. It requires thought, flexibility and clear communication on all sides. But it is something that people find very challenging. I am not sure what to really suggest here, but try… talk to people.

Some good ways to have those conversations:

Some bad ways to have those conversations:

Broken windows

The completing work discussion dovetails nicely with the idea of broken windows. This is an old trope/idea, and I have no idea whether the actual broken window theory is a thing or just some nice sounding pop-psychology, but there are some practical outcomes of being aware of broken windows and not letting them get out of control.

This short story is if you don’t have time to sort it now, why would you think there is time to solve it later when you will have this and something else to do.

Leaving broken/low-quality work, will lead to broken/low-quality work being more acceptable in the future. It gives you less time to do future work. Every bit of work needs to be better than the norm, or it is most likely making all future work worse off.

Looking back

Another important, but very under utilised tool for ensuring the quality of my own work is to look further back than what I am working on right now. Often we want to complete work, check it off our list and move on never to think about it. And completing work is critical, but that doesn’t have to mean never thinking about it again. A little bit of baggage is a good thing. Something as simple as setting a reminder to review a big change 1, 3 and 6 months after is was “done” is a very effective tool.

Looking back you will personally have more perspective, but there will also (hopefully) be someone using or being impacted by that change to learn from. Is their experience good/bad/indifferent? It gives you an opportunity to make an explicit decision to keep a change, not have things exist just because they were done.

From a technical perspective, time away will remove a bit of the completion anxiety and personal attachment to the work. It will allow you to evaluate how it was done, how well it was documented, how much it makes sense. Can you even revisit it easily? If you struggle to get back up to speed with the change after 3 months, how could someone else. It is an opportunity to spend some time retroactively improving the documentation, the code, the tests, things that really help.

Acknowledgement over Blame

Ok, this all sounds fun when things are going well, but what happens when they don’t?

Firstly, blame is not helpful. Blame, particularly in the form of negative language shifts responsibility to address things to the people least likely to be able to do anything about it. Again, it isn’t likely that they wanted to do poorly.

For a different, non-technical perspective (but a relevant reminder), something I read some time ago: “The language of blame, responsibility and accountability” that really hits this issue home (in my opinion).

Teams have the ability to provide tools to help individuals in that team. If the tool/process/whatever doesn’t help, the default position should be that it is the tools problem not the individuals. So when things don’t go well, we ship a regression, something isn’t polished well enough, a customer finds a bug before we do. We need to address it as a team, not blame an individual who probably won’t be able to do anything different next time unless the team can provide them with different tools/skills/perspectives.

Instead of blame, the thing we want to have is acknowledgement. Ignoring problems isn’t any better than blame, neither are likely to stop it from happening again. So we need to have ways of acknowledgement without blame.

I don’t have anything as concrete as I would like here, but I think it starts with being mindful of how you respond to failure:

There is more that can be done here, things like error budgets are interesting, but I don’t think they scale down to small teams well. Perhaps there is something to be adapted here into personal or other types of error budgets as drivers for a change to personal priorities/incentives?

The Point

There are too many words above to have an actual point to this article. I guess I feel like I think about quality differently to others, this captures some of it. Maybe it will make you think about it some. Thinking is good.