You’ve likely encountered a problem that seemed obvious to you, only to find yourself unable to change things within your team. Whether this blockage stems from failed past experiences or a fear of criticism, know that you are not alone. This can be a challenging aspect of your work, depending on how comfortable you are with driving change within the team.
To illustrate this approach, I will use a real-life example throughout this article: the difficulty of adhering to priority levels for comments during code reviews (merge requests).
The key is to listen closely to your colleagues and tackle problems the team recognizes. By doing this, your proposed changes will be much easier to adopt within the team, as others are experiencing and sharing the same problems.
To determine which points to address, you must first be a good observer. Keep your ears open during pair programming sessions, listen to what people say during dailies, and observe and participate during retrospectives to understand the team's issues.
In my case, I had heard other developers complain several times that comments had not been addressed before the code was merged. This created frustration within the team and confirmed to me that this was a recurring problem.
After confirming that the issue is real, seek out allies to support you in managing the change to increase your success rate. This will be easier if these allies are people who already hold some influence within the team.
The goal here is not to carry the change alone, but to collaborate. If you don't have allies, the chances of adoption will be very low. With allies by your side, implementing change becomes significantly easier, shifting from a personal crusade to a collective team effort. Remember: it is very rare for a sustainable change to be driven by a single person.
In practice, I started discussing it with other developers, and one colleague in particular had already encountered this problem. He also wanted to see a change for this problem, so he became my natural ally.
You will learn, over time, that you need to be patient before seeing changes in your project. Change management can be complex, depending on the people involved and the changes.
Break your problems down into several manageable steps. This will help the team keep moving forward while improving. To make changes to the code, you can use the "Scout Rule". This rule lets you improve your source code without changing everything at once.
A good quote that reflects small changes is: "Perfection is the enemy of progress." - Winston Churchill
My colleague Julie Bazhergi actually wrote an article about using "Atomic Habits" to drive change within development teams. Read it here.
You can also propose solutions yourself, demonstrating that you want to see change and that it matters to you.
In practice, I started using Conventional Comments myself, which allow you to indicate the priority of comments left. Thanks to this, it is much easier to differentiate comments that are problems (issue:), suggestions (suggestion:), or minor details related to personal preferences (nitpick:).
Other developers also started using it and discussing it among themselves. Ultimately, we held a team discussion and agreed to use Conventional Comments as the standard for team contributions.
After these steps, team members may have taken ownership of the problem. That said, do not be offended if people start proposing solutions. If this happens, let people experiment and play along. Even if, for obvious reasons, the solution you are proposing is better, the chances of the change succeeding increase if the chosen solution comes from the team.
To help your team grow and improve, and to facilitate future changes, encourage them to think rather than give them solutions directly.
In my example, other suggestions were proposed to address the problem. One developer used a princess emoji 👸on a previous project to indicate that a comment was not critical. He continued this practice, which clearly showed what was less important to him. However, the team preferred to adopt a standard, and everyone eventually adopted the same solution.
Once you observe changes, you play an essential role in establishing a healthy climate for future changes. I suggest highlighting the initiatives of various team members. Whether during a retrospective, in a Slack channel, or verbally, it is essential that others feel valued.
In my case, I pointed out during a retrospective that it helped gauge the importance of comments more accurately when at least two of us were using this method. My colleagues were therefore more enthusiastic about adopting it, as they were hearing good things about it. I also privately congratulated those who made the effort to clarify their comments, regardless of the method they chose.
As you can see, there are several ways to bring a change to a team. This is not a recipe you can apply as-is; you must adapt it to your reality. When you struggle to bring a change to your team, you can ask yourself: “Was I missing any elements in my approach regarding the steps above?” Once a culture of change is established, it will be easier to implement changes within your team.