Creating a Culture of Quality
20 January, 2021
A few years back, I had joined a growing company where I had a loosely defined charter to improve the quality of the shipped products. I joined what was then a very young team of around 100 people, with an average age of around 24 years. The teams were divided into silos based on the technologies they work on or their function. I had a hard time figuring out which end was up, let alone improve quality. However, one thing became amply clear to me: quality cannot be a separate department -- everyone must chip in. Therefore, I had to be very cross-functional in my role and I needed the various department heads to row in the same direction. It was easier said than done.
I spent the first several weeks just interviewing people, irrespective of their seniority, discussing what they thought about their individual projects and teams. I sat in as many Sprint Planning and Milestone Planning meetings as I could -- being just a fly on the wall. When I had collected enough data, I could see clear trends. Chiefly, there was no dearth of passion or commitment, just that of direction. The company had grown quickly in a short time, but the stakes became higher over time. However, many people who had been around since the early days were still subscribed to the hustle mentality that served them well in the early days. Activity, not outcome or impact, was rewarded. I had to take some drastic measures:
- I discouraged working late hours. No one can work 14-16 hours a day consistently and that was shown in the quality of the products and the morale. A night-out was no longer celebrated, it was scrutinized -- an root cause analysis (RCA) was done to understand what we could have done to avoid this.
- We stopped popping the champagne when a release was done on time. I got a lot of push back for this, but my rationale was simple: the release timeline is easily quantifiable, but the quality (ironically) was not. As a result, we had done too many releases in a rush just to make a date; quality, of course, was an acceptable compromise. Moreover, I wanted a culture where the team understands that the release is just a start off of our customer journey - that's where things start getting interesting and where we could see if we have made an impact. Engineers were all too happy closing the chapter when their work was done, whereas the main thing was what happened after the release.
- I drove the peer review culture hard. There is nothing more effective than a peer review to drive quality in software. Not only do many eyes find better bugs, but it also brings about fresh perspectives. Most importantly, it fosters a culture of collaboration and establishes a sense of shared ownership.
- We invested heavily in automation. Testing, reporting, build processes, etc. I strongly believe that everything that can be automated should be automated. I realized that we were spending far too much time on mundane, repetitive tasks, which kills creativity and leaves a lot of room for human error.
- QA processes were tightened, and the Lead QA was given the full authority for the No/No-Go decision. Earlier, the QA process was perfunctory and all that we got out of it were reports that nobody read. The QA engineers had no real say in the quality and were just asked to rubber-stamp their approval, especially when the release date was overdue. There was no clear way of stopping the line and people were largely afraid.
- Organizations chase things like the number of hours worked, number of leaves taken, release dates, etc., not because they are very effective but because they are easy to track. Defining the parameters of success based on more nebulous things like quality is way harder. But it needs to be done!
- Empower people. The most junior person in the team often has a lot more to contribute than we think. Many people, especially QA & Project Managers, feel that they had a responsibility without any real authority. Empowering people is not enough. Instilling a sense of ownership is far more important and that is what helps them understand that they should call out bad things when they see them.
- It was a cultural shift more than anything else. And to change a culture, you need immense patience. It is easy to pick out people who are not pulling their weight or who fight change and then demonize them. But understanding “why” is often more illuminating than blindly pushing change through the power of authority.
- I have always been a great fan of one-on-one discussions. Nothing helped me more in this scenario than having scores of such meetings. Most of the resentment towards the changes went away when I sat down with the individuals and explained why. These were almost always two-way discussions through which I learned as much as I preached. It helped me calibrate the process changes.
- Groom your champions. There will always be a set of people who see the value add before others do. Invest in them and make them champion the cause. You just cannot do it alone. On the flip side, it is very tempting to side with the champions and dismisses the critics. Changing your critic into a champion is the biggest validation you can get.
- Go with data. It is easy to throw nice-sounding arguments about why such-and-such changes would work because I had seen it happen earlier in my career. But analyzing the outcome and helping the team understand the consequences was extremely helpful. Some of the changes did not turn out to be effective in several cases, as the data said so! That helped me phase out what is not working and try something else, which in turn brought about a culture of continuous improvement. People may argue with you or may resist the change, but they cannot argue with data. And when you show a willingness to change based on the outcome, admitting some has failed, the rest of your team follows suit.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.
Adi Purwanto Sujarwadi
VP of Product at Evermos
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.
Adi Purwanto Sujarwadi
VP of Product at Evermos
James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.
Head of Product at BT
Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.
Senior Software Engineer at Microsoft
Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.
Senior Staff Engineer at DoorDash
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.