Back to resources

Creating a Culture of Quality

Managing Expectations
Product
Company Culture

20 January, 2021

null null

null null

null at Freelance Consultant

Guru Kini, Co-Founder and CTO at Fincity, explains how to build a culture that champions the quality of the product.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Senior Engineering Manager at Curology

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty