ADR Techniques for Coding Disputes in Tech Startups

Last week, I had the pleasure to give a presentation on conflict resolution principles and techniques at a fast growing NYC based startup called Greenhouse. Greenhouse is a Software-as-a-service (Saas) company and offers an innovative system to optimize recruiting in companies of all sizes and stages of development. 

One of the reasons why Greenhouse VP of Engineering, and good friend, Mike Boufford asked me to speak about conflict management and resolution to his team of developers and others at Greenhouse, was to help them manage efficiently disagreements and disputes that may arise in the peer code-review process.

For the non-geeks reading, peer code-review is a process by which members of a team of software engineers give feedback on the coding work done by someone else in the team. Apparently, disagreement regarding coding choices and solutions within a tech-team can evoke escalating reactions and sometime affect the harmony and efficiency of the team’s communication and work.

I wasn’t familiar at all with the peer code-review process, but I found fascinating to be asked to think about dispute resolution techniques applied in such a specific, technical setting. The instant-chat means of communication, the dry and highly technical language generally used, the extremely fast-paced dynamic of such exchanges and a sense of ownership and pride often felt by the developer that created the criticized “line of code”, within the team environment, represent some of the peculiar characteristics and challenges in effectively managing and resolving coding disputes.

My slides touched upon basic principles of conflict theory, simplified concepts of neuroscience, which offer compelling information about the biological limitations to engage in rational thinking and the importance of emotions in a conflict situation, as well as practical dispute resolution tips for developers, and non-developers. The presentation was designed as a primer on conflict management and resolution to address a broad spectrum of potential conflict situations, and was not intended only for software engineers and coding disputes. However, the discussion, also thanks to some great questions from the audience, expanded on specific examples regarding the peer code-review process, and it inspired me to put together a small list of quick tips to stay away from conflict, or manage it efficiently, in a peer code-review process.

Here it is: 

5 Easy Tips to Prevent and Manage Conflict in Peer Code Review

• First, acknowledge the quality of a teammate’s work.

The optimal balance between criticism and positive feedback would be 1 to 10… in peer code review that drastic proportion wouldn’t work, but validating a teammate’s skills and hard work BEFORE expressing any criticism, will have a positive impact on how the feedback is received, and it will increase the likelihood of the ideas expressed to be listened to and integrated in the work.

• Be Specific!

Feedback is only useful if it refers to specific aspects of the work. Both in positive feedback and in criticism, it is essential that the feedback receiver be given the opportunity to recognize the actual element in their work that generated the approval or disapproval of the reviewer. A general criticism is more likely to sound like a criticism towards the person or their abilities and skills, whereas a specific feedback is more likely to not be taken personally, and it will give the receiver an opportunity to focus on the part of the work being criticized.

• Explain the basis for your Feedback.

 By explaining the reasons why a certain feedback is given, both positive and negative, the reviewer helps the receiver understand their thinking process and have founded reasons to be proud of his work and to seek improvements where needed.

• Use objective criteria & neutral language. 

Refer to criteria that are widely recognized and accepted in the industry/company/team as valid guidelines for the type of work. Phrase the feedback as objectively as possible, preferring neutral language and avoiding characterizations that may sound diminishing of someone’s ability.

• Don’t assume, ask!

As it is often the case in coding, if there are two, or more, equally valid ways to achieve a certain result, ask whether the teammate had considered a specific alternative that you may find preferable. Don’t just assume they didn’t!

Hope this tips are helpful!