Disagreeing Respectfully
Disagreements can happen in any professional setting, but are very common in software engineering because there are always multiple ways of solving a problem. on top of that, software engineers are an opinionated bunch. The result? Arguments, and they're not always pretty.
However, disagreements are good, even essential, for our line of work. Solving technical problems often involves trade-offs, so there's rarely ever one "right" answer. Diverse ideas help bring multiple solutions to light, not only enabling us to pick the best one for the problem at hand, but also contributing to our growth as engineers.
How then, do we encourage disagreements, while maintaining a positive environment? The key-disagreeing respectfully. Let's go through some ideas that will help you and your team to do so.
Seek feedback proactively: whether you're creating an architecture design, a proposal for a project or have ideas about reducing tech debt, it always helps to write them down in a document and ask your stakeholders for feedback. By doing this, you're providing a safe space to your stakeholders to disagree with you, which will help them feel included. And as a bonus, you're already mentally prepared to hear disagreements so you're more likely to handle them without getting upset.
Ask lots of questions: Before disagreeing with someone, make sure you first understand their ideas well by asking specific questions. This will either convince you of their rationale (avoiding the disagreement in the first place), or help you provide them with streamlined feedback when you do disagree with them. Asking questions also makes them feel respected as you're taking the time to consider their opinions before challenging them.
Use respectful language: Avoid labeling someone's ideas as "incorrect" or "incompetent". Instead, focus on presenting your side as an alternative. It might also help frame your alternative as a question, for e. g.. "Have you considered x?"-it might turn out they genuinely haven't even considered it yet. You can present your disagreements without beating around the bush by just saying, "I disagree with that becauseā¦" or "I think alternative x will work better because..." as long as you aren't attacking their ideas.
State your" why" : Present the rationale behind your alternative. This will help display that you're genuinely trying to find a better solution to the problem at hand, and not disagreeing just for the sake of it.
You are not your argument: This is an important one. Remember that it isn't you against your teammate when you're disagreeing, it is both of you against the problem. If you don't attach your self- worth to your arguments, you will find it easier to navigate the disagreement without bias.
Data decides : Further to the previous point, always consider the data supporting either side of an argument. Ensure final decisions are made based on data, and not based on how senior/junior the people making these arguments are.
Choose your battles: Software engineers tend to be passionate about trivial choices (spaces vs tabs, anyone?), but sometimes it is important to just let go. A prime example here is code style - as long as you are following *a* convention throughout your project, does it really matter which one it is (in the larger scheme of things)?
Commit to the outcome: Once the team has made its decision (hopefully based on data), show respect to your teammates by committing to the outcome even if things didn't go your way. Resist the temptation to restart the argument: just move on. Bonus points if you document both sides of the disagreement and the rationale behind the decision. This way any new team members or outsiders can understand why you're doing things a certain way, and a repeat of the same argument can be avoided unless there is new data to be considered.
Hopefully these tips will prepare you to express yourself firmly and respectfully the next time you disagree at work. If you have any more ideas for the same, I'd love to hear them via your comments!