Opinion

Leadership Insights on Managing Code Quality Conflict

The competitive nature of today’s digital business environment makes it critical for software development teams to embrace change, especially if it leads to improved software quality and efficiency. As a manager or team lead, your leadership plays a role in guiding your team through these metamorphoses.

At Qodana, we’re all about code quality and security for teams, so in this installment of our Leadership Series, we will explore the intricacies of implementing new tools that can help with this. We will also look at how to overcome the professional challenges that come with process improvement and managing change. 

Joining us to share their insights are Team Lead in Kotlin Build Infrastructure Nikolay Krasko and Development Lead in Kotlin Compiler Simon Ogorodnik. 

---

Importance of quality and process improvement

The first step in driving quality improvement is recognizing the significance of creating superior products or services. Quality boosts customer satisfaction, enhances your company’s reputation, and gives your business a competitive edge. Similarly, well-defined processes lead to increased efficiency and productivity, paving the way for superior performance and growth.

According to the MIT Sloan Management Review, “Having fewer defects or field failures results in lower manufacturing and service costs. As long as these gains exceed any increase in expenditures by the firm on defect prevention, profitability will improve.”

However, process management, new tools, and changes are often required to achieve better quality, and software development teams are not always open to change. 

Defining and identifying the problem

As an example, take a look at this Reddit post and its upvotes to see how championing new tools and emphasizing code quality can be a challenge. 

How can this developer, and others, address this? 

“I would say that it depends a lot on their code review practice. Do they have to fix review suggestions before merging, for example? It also depends on the type of project that they are working on. But if they are trying to raise the bar here, I would first talk with the team lead or tech lead to acknowledge the problem and find a solution. These discussions can also be had in the reviews, not just in the comments,” says Development Lead in Kotlin Compiler, Simon Ogorodnik. 

“If the team, team lead, tech lead, architect, and CTO don’t care, then it will be nearly impossible – but if they do, there’s room to start the conversation with the team.” 

Kotlin’s experience

“We’ve always cared about code quality, but one of the first challenges we faced was getting enough data to make an educated decision about which tools to integrate into our stack. We identified the problem that we weren’t working as a team and needed stricter quality rules, but then we needed to gather information from different stakeholders, team leads, and developers. Understandably, our team needed to see a lot of value in a solution in order to advocate for it – and this can be a major hurdle,” says Simon.

“You can’t measure something you don’t understand in detail because once you have asserted there’s a problem, there are many potential solutions. You need to be able to summarize, view, and present data on why this change will fix something and not introduce unnecessary problems,” adds Team Lead in Kotlin Build Infrastructure, Nikolay Krasko. 

“First, identify the problem, the fears, and the concerns. Then come the hard questions like if it’s really a problem or whether there are key people who aren’t on board. Does everyone agree it’s the highest priority problem? Often they don’t. Then we have to say, ‘I have this solution. Can you explain why you don’t like it, and do you see other solutions?’ In the end, you either get a better solution or points that challenge your beliefs.” 

However, these conversations can also be difficult. With this in mind, the first step is to provide comprehensive data to your team to open the discussion and start generating internal buy-in. However, this works on the assumption that you have already made an autonomous decision or have a bias. 

Question your own biases and assumptions

This is another important part of introducing a change, with the help of your team. 

“You should avoid an authoritarian style,” says Simon when asked about what happens when teammates don’t agree, “It works to make a change in the short term, but you still need to provide some reasoning. Saying ‘We hired an external auditor who said our practice is bad, so now we are getting a new tool’ won’t cut it. People won’t buy into things just because you tell them to.” 

“It would be easier if there is one decision-maker who’s going to say, ‘I know what I’m doing, I’ve got this, let’s go.’ But we need to convince a lot of people sometimes and this is hard,” says Nikolay, also erring towards a more evidence-based decision-making style. 

“Saying ‘We hired an external auditor who said our practice is bad, so now we are getting a new tool’ isn’t a good idea.”

Embracing new technology with an open mind

It’s clear that change is often met with resistance, but as a leader, your role is to turn this challenge into an opportunity. Successful change management requires clear communication, employee involvement, effective training, time management, and patience. Taking these steps reduces anxiety, fosters open dialogue, and encourages employee buy-in and new perspectives. 

How do you deal with detractors and those against proposed changes?

An important point to consider is that teammates with opposing views are not necessarily wrong. This is not a revolutionary concept, but sometimes leaders must check their egos to gather useful information that could benefit them in the long term. That said, stakeholders can typically be divided into supporters and detractors – and both groups have something valuable to offer. 

“Speak to people who don’t like the change,” says Nikolay, “you might identify a misunderstanding. Perhaps it’s not the tool or the change they are opposed to, but maybe they are scared of doing more work or losing their position. By opening up the floor to these perspectives, you can get to the root reasons for the resistance. 

Maybe someone will tell me, ‘I don’t want it because it promotes architectural patterns I don’t like,’ but the core fear is additional tasks or complexity, or becoming redundant themselves.” 

On the other hand, both Nikolay and Simon agree that it is important to share the perspectives of supporters. “I’m not going to talk only with people who are against it, but I also want to understand those who are for the change. There will be some who are strictly pro. 

Using Qodana as an example, maybe they came from another company where they had static analysis tools, and they used Qodana and liked it. This will help to share the vision and convert people who are neutral one way or the other,” says Simon. 

Guiding your team through the implementation of quality processes

Transforming your team’s way of working comes with challenges, but a leader guides, not dictates. Let your team in on why these changes are happening and how they can contribute to the overall success and quality improvement.

“With stakeholder management, you can’t always ask everybody,” says Simon, “It would be great, but it wouldn’t work in the scope of 100 people, for example. For that, I would try to gather a representative working group of people who will be stakeholders or those with strong opinions.”

Nikolay adds, “For smaller teams, it’s not a big deal to just talk with everybody. Bring it up in a team meeting and say okay, here it is. We have our quality level and our number of regressions. Maybe the QA team will be happy about that. 

It would be nice to detect problems automatically and for your tech lead to say, ‘We are not going to push those strange patterns into production anymore. I need those static checkers so I can stop constantly mentioning the same issues during the code review. I’m tired and want to free myself from that.’ Choose people who have strong opinions and authority.” 

In summary:

• Explain clearly why changes are necessary and how they can improve quality and efficiency. 
• Seek your team’s input during the decision-making process and make them feel involved. 
• Offer training that will equip your team with the necessary skills and knowledge to adapt to new quality processes.
• Regularly track your progress using key performance indicators (KPIs) to identify what’s working and what could be improved.
• Celebrate small victories along the way and acknowledge those who are driving the change.

There is also another important point: Ease the burden of change with small, incremental adjustments. 

“If it’s a gradual change and initial processes aren’t deeply affected, it may be a better strategy to introduce it in stages. You don’t need to uproot everything before you get some traction and adoption. Do this gradually and you’ll have a new baseline and support from your team members who enjoy it. This is one of the most natural ways to introduce any new technology,” says Nikolay.

“I think that way of managing change should be an industry standard,” Simon adds, “If you’ve read Leading Change, it will tell you similar things. I presume that at least for most large companies, it’s the default way of doing things. It’s the same values that Agile and chaos engineering promote.”

“If it’s a gradual change and initial processes aren’t deeply affected, it may be a better strategy to introduce it in stages. You don’t need to uproot everything before you get some traction and adoption.”

Leading quality improvement 

Improving quality and refining processes in your organization is neither a quick nor solitary task but one that requires collective effort, patience, and strong leadership. As a leader, your attitude towards change will significantly influence how your team adapts. Keep communication transparent, involve your team in decision-making, and remember to acknowledge their efforts – it’s these subtle actions that make a big difference. 

Quality improvements and process upgrades are vital for business success, and with effective leadership and a committed team, your quality upgrade will not only be possible but will also become a key driver of your future growth.

Final words on managing conflict

From Simon: “Don’t take change management as a black-and-white thing. You’re going to end up in a gray area, you’re going to implement it halfway, and you can sell it like that as well. You can say, ‘Let’s just give it a try and see how it goes, and if it doesn’t work, let’s try again and try something else,’ so that people don’t feel like it’s so extreme. It’s an iterative process.”

From Nikolay: “In general, speak to business goals. People usually understand this, as they are a strong motivator, and if it’s justified by data, it can be a powerful driver for change. 

Nothing works exactly as it’s intended. You will always find flaws and bugs, and you need to adjust. It’s better to anticipate the evolution process right from the beginning to make it easier to commit to changes.” 

Tell us what you’d like to see

Thanks for joining us for the Qodana Leadership Series, which aims to create discussions about real-world problems facing quality-focused leaders in software development and AI. Let us know which topics interest you the most in the comments, and we will invite experts to weigh in. If you’d like to know more about Qodana for code quality improvement and compliance in teams, take a look at our website. Special thanks to Nikolay and Simon from Kotlin for their participation!

About our participants

Simon Ogorodnik

Simon is a Development Lead from the Kotlin Compiler who enjoys talking about performance, code quality, compiler architectures, and project management. Now, he is trying to find the best ramen restaurant in Amsterdam and wondering how AI will challenge the code quality landscape. When he’s not sitting in a meeting or at coffee-point, you can find him kitesurfing or just relaxing at home.

Nikolai Krasko

Nikolai is a Team Lead of the Kotlin Infrastructure team who enjoys finding small changes in the development process that make a big difference in productivity. He loves playing guitar and exploring new technologies. When he is not figuring out how to make things work better without breaking other things along the way at work, you can find him playing with his kids, reading books, or playing computer games.

What’s next?