How to get buy-in from Product to prioritize quality

It is common for Engineers as well as Engineering Managers to have difficulties prioritizing quality. Almost always do we all feel a certain pressure (albeit an artificial one) to deliver. However it is essential to remember why we’re building the things we’re building in the first place. It is not to satisfy some artificial delivery goal or our bosses, it is to satisfy customer needs.

After all, the customers pay our salaries.

You are the expert

Imagine that you are a surgeon who is an expert in your field. You work in a
hospital which is being run by an old friend of yours from high school. Of
course, you both need each other to be able to keep the hospital running. You still need to be able to operate on a high level. Making sure that you don’t hurt patients and get the job done. However you also need your friend to pay the electricity bills, manage the hospital staff, dealing with finances etc…

It is a symbiotic relationship.

Then comes a patient, who seriously needs medical attention. You make the call that the operation needs to take place today and that it will take 6 hours and a fair bit of the hospital’s resources. But then your friend comes in and tells you that the hospital’s finances are in a bit of a pickle and that it would be better if you could do the operation in less time using less resources. What will your answer be?

If your thinking that our field has nothing to do with medicine and that there are no lives at stake, I would challenge you to think otherwise. At the end of the day, independent of the industry we’re in, we are nothing without our customers. And if we’re not able to have happy customers we will definitely start losing them to our competitors.

Going back to the hospital, the success of the operation is ultimately in your hands. Not in that of your friends. If you make the wrong call, the patient will be unhappy and will go to another hospital the next time (if they’ll survive this operation). If this behavior of you sacrificing quality in exchange of quantity continues, little by little you will go out of business.

Don’t forget that you are the expert. You’re the one who knows how difficult it is to make a change and how much more difficult it will be if you keep
producing technical debt.

Need to Change

When one desires a certain change, there needs to be an initial need for that change to happen. This idea is integrated into various change models. When we for example look at the Kotter model, we can see that the
first step is to create a sense of urgency. Meaning that if there is no sense
of urgency, no need for the situation to change, then everyone will be opposed to it.

In the context of prioritizing quality, we first need to make the Product
Manager (as well as the team) feel the need to want to change. This would not be necessary if, say each feature the team has been working on took months to deliver. In that case, the team probably is already feeling the pain and would therefore want to address the issue. However if all seems to be functioning relatively well, no team member will feel the need to change. Then it us up to you to create that sense of urgency.

There is no better way to create this sense than to use data. There are
various ways in which one could measure and visualize the effects of increased technical debt on the performance of the team, however when it comes to creating a shared understanding with your product counterpart, “Lead time for changes” can be the most powerful of them all. After all, the time it takes to release features is one of the main success metrics of a Product Manager as well as an Engineering Manager. This is a metric that is relatively easy to calculate if you’re already using a tool like Linear or Jira. All you’d need to do is to create a small script to see when an Epic has moved to “In Progress” and when it has moved to “Done”. The difference between the two will give you a good enough estimation of your lead time.

If one would make a simple line graph where on the x-axis we have time (or
sprints) and on the y-axis we have lead time for changes (in hours) then seeing the graph with an increasing slope should (and most probably would) scare anyone in the team. Then they will come asking how you think we can remedy the issue where the answer would be to focus more on quality.

Tips & Tricks

Here are some techniques which I believe would be beneficial to create common understanding of the importance of quality between the Engineering Manager and the Product Manager.

RACI Matrix

More often than not, the problem is nothing more than a form of
miscommunication. Where the Engineering Manager and/or the Product Manager do not fully understand their roles and responsibilities. This situation causes both of the parties to take on the leadership role and to tear the team apart by trying to pull it on way or another.

Both the Engineering Manager and Product Manager want the best for the team, but do forget that they’re both in the team as experts of different fields and they should trust each other and collaborate closely. The Engineering Manager will look into the technical excellence and come up with processes to ensure that the quality standards are met, whilst the Product Manager focuses on the quality of the product from the user’s perspective. One without the other is worthless.

One method which could be used to create this awareness and to allow the
visibility of the lines between the two would be to build up a RACI
matrix. This will allow both the Engineering Manager as well as the Product Manager better understand what each others’ roles are and where each others’ domains end. Having done this exercise there would be a shared agreement to what you both expect from each other.

Engineering metrics

Nothing is more moving than numbers. Numbers well used in context, well
visualized. Measuring helps one see where the weak spots are so that we can focus on them. But it also allows us to see change over time. As an Engineering Manager, you should be able to stress the effects of low quality on product delivery as well as customer experience. You should also be able to prove to yourself as well as to your team mates, that your gut feeling (of wanting to have more tests for example) has actually helped the team improve something.

I would recommend to start with the following basic measures which will allow you to tell a story to your product counterpart. Once the basics are in place you can always add more metrics to help strengthen the storytelling.

Lead Time for Changes

This is one of the key metrics to look into. It is also one of the DORA
metrics used by many companies across the globe to help measure their performance. Above all, it is a metric which is well understood by product. Being able to explain the correlation between the quality of software being built and the time it takes to ship a feature is a very powerful
tool.

Change Failure Rate

If one would solely focus on “Lead time for Changes” then they might end up wanting to ship faster which could be achieved by omitting to write tests. This is of course not what you want if your goal is to try to improve quality.

This is why the second metric I would recommend (which is also coming from the DORA metrics) is the “Change Failure Rate”. What is the percentage of deployments causing a failure. This metric is slightly more involved if you want to measure it accurately. The poor man’s solution would be to count the number of errors per version deployed. In other words, if V0.1.0 of the software is live in it produced in average 12 errors per day. Then you released V0.2.0 and the average increased to 20. Then you know that you’ve made the software worst than it was. This decrease in quality would mean that there would be more bugs coming back to the team which not only will distract the team form delivering new features (aka. Lead time for change) but it will also frustrate your users.

Team Manifesto

Last tip is that of leveraging the herd mentality. As social animals, we’re all hardwired to not stand out from the heard. So if everyone in the herd is writing tests, then the chances are higher that a new joiner to the team will feel the urge to do so as well. Similarly if everyone in the teams keeps underlining the importance of quality and the lack of focus on it, then it is more likely that the Product Manager will also play along with the herd’s mindset.

One technique which I’ve seen being used quite often is to have a team
manifesto. This manifesto will serve as a document in which all things which the team finds essential will be covered. Not only will this manifesto serve as a soft contract among all members of the team but it will also define the values.

Conclusion

It is rare that any member of any team, willingly wants to make things more difficult for themselves as well as their teammates. Using the above mentioned techniques, an Engineering Manager should be able to desire to change and help move the team in the right direction. Eventually once there is more focus on quality, everyone’s lives will start getting easier.