How do you navigate engineering conflicts and disagreements?

Brainstorming is also a great way to solve engineering issues. Everyone in a room and you all write down your own ideas of how to solve these concerns. More than likely a lot of people will come up with similar ideas. Tally these up and then do five whys on these to get to the root cause and then work on a way to implement the solution.

When facing a conflict, start with this powerful question - "Please, help me to understand, [question towards getting more details about the problem] ....?" It demonstrates that you are open to hearing the other person's perspective and willing to acknowledge that you may not have all the information or insight. This humility can set a positive tone for the conversation to reach the root cause together. By asking for the other person's help in understanding, you invite them to express their thoughts and feelings, creating a space for dialogue collectively identifying the problem. On the other side, blame or accusations can lead to defensiveness and resistance that doesn't help anybody to make the first step.

I believe the best resolution method when engineering/product specification problems arise is to do strategic decision making in a peer-exchange trading pit style, where all the stakeholders are in the room and allowed to put in their $0.02 worth and hear all the arguments by all the other stakeholders and then agree to the best ideas. When the leader runs the process like the turntable in a railroad roundhouse, gathering information from this person and then that one and then that one and then handing down the decision from on high, there is little chance of strong buy-in by all the players because the sense is that worse ideas are adopted because they were put forward by those with the most political skill and not the best ideas.

I’m my experience, multi-functional teams often does not share the same goals (expected performance) and therefore by design roles enter in conflict. (That was the case when I first learned about RACI Model to help define accountability and responsibility, when one of my engineers and the material planner were discussing when to discontinue “current” material to allow for one new “on pending validation”… they both needed to be tied to the financial gains of the project as objective, while each individual had to play a different role). Clear Roles, and expectations, will help the Team move on!

Identify the Underlying Issues: Go deeper to identify the real issues causing the conflict. Often, conflicts are symptoms of more significant problems such as miscommunication, differing expectations, or resource constraints.

I think you have to give everyone the opportunity to air their views, so that they feel that they are being heard and being taken seriously. And then collaborate on a way forward. Or vote on the best solution.

Expanding further, the way the “final” decision is conveyed is important for the team. First off, a reminder of the problem being solved is crucial. Then the reasons why the particular decision was chosen should be presented, along with an acknowledgement of the opinions not chosen, noting the strengths and risks of each (managing a project is all about risk management). This ensures everyone feels heard (part of that scribe listening). Finally, knowing that I’m not omniscient, I will often add that if it is discovered down the road that this is not the best decision, I invite you to say “I told you so,” but we’ve gotta pick something, and this is what we’re doing for now.

Relationships matter. Having that preferred relationship with Quality means that Engineering can listen to potential resolution of the issue before running back to the design or repair desk. The resolution does not have to come from engineering as long as the weigh the recommendation against product performance.

Its very important to listen all stakeholders before concluding / suggesting. We have to pay attention to listening and ensure we understood the problem completely.

The emphasis has to be on the best ideas, not who came up with them. Engineering is unfortunately an unforgiving discipline engaged in by folks who often do not have the best of people skills, but can be navigated if the decision-making process is seen as fair and fact-based, not rigged and personality-based.

In my 20+ years of Engg management, I have only maneuvered conflicts. Conflicts upwards and downwards. The trickier ones are those upwards. Subordinates will subsume your opinion with respect and coercion at times, well that's probably because I know my men, their needs, professional requirements and therefore trudge a middle path with them. But, when the conflict involves a critical stakeholder or your superior, then the alignment needs a paradigm shift. Firstly, communication skills, secondly professional acumen, thirdly power of negotiation, fourthly but certainly humility in conviction.

When a manager considers a productive attempt to understand a major decision made without input from important stakeholders treasonous and then allows things like name-calling in meetings among those stakeholders, they will at best destroy trust and discourage productive input in the future and at worst drive good and productive people away from their organization and into the hands of competitors while filling them with significant motivation to help that competition thrive.

Foster an atmosphere where open and honest communication is valued. Encourage team members to share their perspectives and concerns directly with each other.

Do not think of knocking out another person’s brains because he differs in opinion from you. It would be as rational to knock yourself on the head because you differ from yourself ten years ago; Patience, Tolerance and Carpe Diem!

This “perceived step” should not be required if Quality & Engineering & Operations have already been to Gemba at the point of occurrence. Resolution is a team sport at the impacted area. We support teams work for frontline team leader and hourly value add associates, not the other way around.

Engineering managers often spend too little effort understanding the business realities and competitive situation and too much effort on doing nifty engineering things that may not help the company sell more volume, capture new markets and improve financial performance. It is not a one-or-the-other it is a both-and. Add on the possibility that the engineering manager is on a mission to show that the engineering function is smarter than the rest of the organization on the grounds that if the others were smart they would be engineers, and if the engineering manager is also good at company politics the resulting overemphasis on nifty product that does not address real customer needs can cost a company years of heading down a wrong road.

I agree. But as Engineers often like to follow recipes, a good way to accomplish collaboration and creativity, is to help everyone speak ONE LANGUAGE. Therefore, embracing Problem Solving techniques (or any other designed to follow a standardized sequence of steps) makes a huge difference, while also allows -and requires- for everyone to participate and therefore ownership of (not just credit for) ideas is shared, ultimately driving faster implementation. Try Lean Systems 8-Steps Problem Solving! (I personally like Kentucky University for their ties to Toyota’s)

As engineers, we often want to analyze and dissect solutions until we find a roadblock to the solution, only to have another problem to solve. Finding options to build prototypes, run samples, or experiment, at very small scales for even a portion of the solution, provides a team insights otherwise only debated. As leaders, our role is to help the team see when they are giving themselves roadblocks so they feel empowered to take the next step. This often means allowing them to fail as they learn and grow as individuals and a team and providing the safety net in the event of failure.

Again, if you are choosing speed in support of your actual customer (frontline team leaders and hourly value add associates) and you have taken this long to collaboratively & pragmatically to collaborate, you have already lost the confidence of your frontline works.

True collaboration is an act of faith. It means believing that together we can be far greater than alone. By joining different pieces of ourselves, a brighter picture will emerge. Collaboration requires vulnerability. We must be willing to share raw, unpolished ideas and expose our flaws. Every weakness is an opportunity to grow stronger as a team. Collaboration takes courage. Speaking our truth even when voices shake. Listening without judgment when it would be easier to turn away.

The loudest voices in the ears of decision makers need to always be the customers'. The focus of the company needs to be outward, not inward, strategically opportunistic but not foolish in heading down technological roads that look promising but ultimately add features that customers don't care as much about or add unnecessary complexity. It can be hard to know sometimes if customers can actually express what they really need versus what they think they want. But I believe a wise company will try to do much more of the former than of the latter, and if they succeed their future will be consistently bright.

After solving the conflict, make sure to clearly communicate how it has been solved, how and why you and your team got to the final accomplishment. The idea of learning with the (“bad” or not) experiences is to share and pass them along, so they won’t be repeated. New conflicts or problems will come, that’s inevitable, but remember, problems were meant to be solved, they are a great way to learn, grow and improve. Face them with an open mind.

After resolving the conflict, take the opportunity to learn from the experience or the past. Discuss what led to the conflict and how similar situations can be prevented.

I can get behind this one. BUT, Learn and Improve is a fancy way of just saying Plan, Do, Check, Act, every time, all the time. Solving problems is not a “project”, where one can say I have checked the box on my way to some company “certification”. It means you have earned the respect of your team leaders and hourly associates so they feel comfortable coming to you on a daily basis asking for your help to resolve their problems. If you can’t do this, get out of the CI, OpEx business.

Each disagreement contains a hidden gift if we're willing to unwrap it. Feedback, even critical, is precious - it illuminates blind spots. I try to seek it out, not shy away. After a confrontation, I take time to reflect with humility. What triggered reactions on both sides? How could I have communicated or listened better? I share lessons learned to help others avoid similar missteps. Our struggles connect us to wisdom. My experience may spare someone else hardship. There are always better practices to uncover, new conflict-resolution skills to build. I read, listen to others, and never stop honing my approach.

1. If you look into the history, 5% of conflict is caused by a difference of opinion, while 95% is caused by tone of voice and poor timing. 2. Dale Carnegie rightly said, " You can't win an argument because, if you lose it, you lose it. If you win it , you lose it". 3. I've learned these 3 things while handling conflicts.. a. Take it behind doors. b. Communicate (ensure) to concerned parties that we are only interested in discovering the truth, not the "Argument Winner." c. Link the outcome (result) to the overarching goal of the delivery/project/organization.

There is an excellent book, “What got you here won’t get you there” by Tommy Danielson. One important thing for leaders to remember is your team has massive knowledge compared to any one individual especially someone considered “a leader”. Understanding team strength is very important

Conflicts are a very natural part of any team open communication, empathy, and a focus on finding common ground are key/essential to successfully navigating engineering conflicts.

Well said Prasad while providing feedback it should constructive and in a tone which acceptable. As soon as you raise your voice and humility someone. They shut their ears and environment becomes toxic. In such cases people don't have leadership skills.

To me the key is actively listening to all parties. Understanding each perspective is crucial for problem-solving. Technical debates often arise from different sets of priorities/assumptions. Also pushing for open and honest communication: When people feel safe and empowered, they’re more likely to take part meaningfully to the chat. Then I’d look to identify common goals and any data or metrics that can help guide the process. Stats can often provide an objective ground for discussion, reducing emotional bias (data-driven tests can be helpful in a stalemate). Then once resolving the issue, we conduct a retro to talk about what went well & what didn’t as a way to prevent future instances and learn.