This article was authored as a contribution to the Log Rocket Blog - you can read it there too!
Being a software engineer is one awesome job!
Software developers strive to live up to our creed: solve problems with amazing people and follow best practices to make the (tech) world a better place. Engineering managers are tasked with leading groups of passionate, knowledgeable people as they work together designing architecture and features. As one can imagine, this can be a lot of fun.
Working in a close-knit team isn’t always sunshine and roses though. When you have a group of people from different places, with different experiences and various expertise, there is often discord with how to best develop, implement, and work on features.
But disagreement and discussions aren’t the main issues. In fact, when people are open-minded and focus on the result that’s best, instead of being “right,” disagreement can create better solutions.
Common causes for disagreements among dev teams
There are a few areas that typically generate discussion and lead to disagreements on dev teams.
Pull request reviews
Imagine this: one developer on the team spends hours writing code to complete a sprint ticket. He or she labors over creating the best names and abstractions that lead to readable, concise code and create tests to make sure all is working as expected. Then, the dev submits a pull request, which requires another developer’s approval once the code is ready for review.
Coding is an art, and our process for creating masterpieces is personal, but code reviews are a forcing function that ensures high-quality code and applications.
It’s easy to see how the reviewer, who is critiquing and asking for changes, can potentially cause tension with the author. There’s ego involved and the pesky “self-interest” bias that everyone has.
For example, developers are interested in getting their code approved without having to rework large amounts of it. Why? Because they have other work that’s due for completion by the end of the sprint, too.
At the other end of the spectrum is the reviewer, who is charged with maintaining and improving standards, and ensuring those standards are followed, even if the ticket will take longer to complete. How can the reviewer allow for sloppy code or code lacking in best practices into the codebase? Isn’t it their responsibility to ensure high-quality projects?
It’s quite evident why the back and forth between getting code approved and completing all the changes requested can cause disagreements. In fact, it’s totally normal. How you go about communicating and resolving this is what matters.
Team standards
Software engineering has the benefit — and sometimes the challenge — of not having specific best practices that are followed by everyone at all times. Opinions vary and standards evolve. These are not only brought up in code reviews, but are points of tension when different opinions between team members arise (such as tabs or spaces for indenting lines).
The key here is to continuously decide on and update code conventions in a centralized wiki or file. This gives reviewers documentation they can point to, and pull request authors a guide, meaningless points for tension.
Architecture discussions
As teams evolve their software over time, they must adapt and change their architecture to meet new designs or features. Database structures or new micro-services might be required, or they may adopt new frameworks or libraries into the stack.
Experience in these areas is varied, and opinions on naming conventions or tech stacks chosen can dictate so much of a project’s code base. It affects everyone on the team, and, because of that, individuals have reasons to prefer one solution over another.
A healthy dialog builds strong outcomes, but teams should outline some of the baseline goals they are trying to achieve for these discussions. By doing so, they can drive conversations toward a specific end result that they can weigh options against.
Personality differences
It’s become apparent that software engineers need proficiency in soft skills. Developers collaborate all day long, and being able to relate to others, communicate their ideas, and find common ground impacts the success of their projects.
Developing these skills can be tough for those who tell computers what to do all day.
At work, we can’t just stop working with someone we don’t along with. We might have true personality mismatches, stark differences in views on best practices, or overall communication style differences. Such is the life of working on a team.
Learning to put differences aside to get work done and accomplish goals for the team continues to be an ability of great leaders. You can do the same!
How you can prevent conflict on your team
There is one fundamental truth in all of the discussions and disagreements in your life: you are part of them.
Are you intentionally challenging the right things?
Creating self-awareness around discussions helps ground you, set aside emotions, and enables you to think with more clarity. As a teammate, you must understand that you can’t always get your way, and challenging everything will result in a huge loss of time and productivity.
In other words, challenging and pushing for a specific option should only be done when the impact and benefit are worth it. Here are some questions to ask:
- Does the result of this decision impact me, our code base, or our future depending on the resolution?
- Do I have the expertise, experience, or data to state reasons for or against the options in the discussion?
- Am I actively listening and understanding all viewpoints before making the push for my own view?
- Are there alternative solutions that incorporate parts of all options that lead to a stronger result?
- Am I letting my emotions run the discussion or my thoughts? A few deep breaths may be in order
If after answering these questions you still feel strongly about a particular solution, determine how you can best communicate the differences of each option and why you believe one achieves better results than others.
Are you keeping an open mind?
One of my favorite people that talks about open-mindedness is Ray Dalio. In Principles, his recent book, he outlines what being open-minded really means (check out my full article on this if interested).
The main point is this: If someone disagrees with you, the first instinct should not be to show why they are wrong, but to understand why they disagree… because guess what? They might actually be right!
Comprehending and then incorporating their reasoning could design a better solution, or it might help you see their concerns and better communicate how your solution eases them.
Having an open-mind within your development team creates a safe environment where ideas can be challenged, discussed, and improved upon.
Resolving disagreements on your engineering team
It’s definitely possible that even after both sides do their part, an agreement can’t be made. It happens and it’s fine! The question then is this: where do we go from there?
That’s where these steps of resolving disagreements come in!
Step 1: Talk instead of type
If the initial disagreement and discussion started over a non-verbal medium, and an agreement can’t be made, the next step would be a zoom call or in-person chat.
It’s quite common that disagreements are fundamental misunderstandings, where the ideas and differences being communicated are actually two people on the same page. It’s much easier discovering where and how an agreement can be made over a better communication medium.
If the conversation ends in a stalemate, no problem. Let’s move on to step two.
Step 2: Ask the team
Taking the debate and different ideas to a wider discussion can transform a stalemate into a solution. By laying out the different options and advantages or disadvantages of each view, you give a full-view of the ideas and allow contextual input from all teammates (even managers can weigh their thoughts here).
Typically, a majority will start forming and a resolution comes forth. I find most disagreements can be solved during this step.
If you notice that a higher level of conflict is forming, here’s your next step.
Step 3: Involve your manager
If you’re seeing that conflict, disagreement, or tension occurs often between you and a teammate that feels hostile, the next step would be involving your manager.
You can ask for their advice on approaching the situation or ways they can help mitigate the conflicts. Hopefully, this resolves the hostile work environment, otherwise, you may need to take things to HR.
Step 4: Involve leadership and/or HR
It’s possible that even after involving your manager, the tension continues. At this point, it’s best to bring in high levels of leadership or HR.
You should not feel threatened or uncomfortable at work and these are the resources who can help solve that.
Step 5: Find a new team, or, at worst, leave the company
Obviously, this step is the most drastic and is usually the final straw. But we spend a huge amount of time at work every week, and with the collaboration required on software development teams, it only follows that you want to be in an environment you feel comfortable and have fun in.
If after you’ve tried all previous levels and the conflict continues, the last options are to find another team within the organization that gets you away from the hostility or begin looking for work at a new company.
Both options can really make a huge difference in your life! The key is to choose wisely, ask a lot of questions during interviews, and find a culture you fit in with.
Conclusion
The software engineering profession is rare in its ability to constantly challenge and grow its members throughout their careers. Technology truly lives up to the mantra of: “The only constant in life is change.”
It’s an immensely rewarding career choice with the opportunity to accomplish great things in the world with great people. Like any team working in any industry, it’s likely that you’ll come up against conflict and disagreements with colleagues, but when you do, you are now equipped to handle it effectively.