Developing complex software at scale almost always requires coordination across potentially many teams and functions. People are people, and every now and again, such coordination results in disagreement or conflict. For example, an engineer might disagree with the user experience proposed by a designer. Or, a team responsible for a key dependency for a project may not share the project owner’s prioritization of that dependency, risking the project’s timeline.

Earlier in my career as a manager, when someone on my team was having trouble getting along with someone outside my reporting structure, my default was to help them as best I could, assuming I agreed. I’d take their story to the appropriate manager on the other side of the disagreement and make the case as best I could.

Unfortunately, this strategy causes more problems than it solves. For one, it’s a lot of work in partnership with that other manager to try to understand the problem by piecing together the disagreement second hand. Worse, going to bat for one’s reports against another team or function reinforces an “us vs. them” mentality in the organization, only compounding future problems. If complaining to one’s manager is effective, people are less inclined to fix problems themselves.

I’ve since learned to give my team the tools to recognize misalignment and raise disagreement productively. Now, when someone on my team comes to me with a complaint, I coach them to understand why they disagree and direct them to work with the other party to propose solutions together.

Our first example involved an engineer and designer disagreeing on a particular design. When two functions disagree, it’s important for each to understand their roles and responsibilities. Engineers are accountable for shipping high-quality software on time. Designers are accountable for creating a delightful, useful experience for users. While building software is inherently collaborative and it’s best to leverage ideas from all involved in its creation, ultimately, designers are accountable for the UX, so they get the final say. Engineers are accountable for quality and timeline, and if a design decision risks either, the engineer has a right to push back. By helping the team understand each function’s roles and responsibilities, they might better understand their conflict and frame their disagreement accordingly when raising to their leads.

Our other example involves one team asking another to prioritize some work to ship a project. This can be perceived as a chore since the work invariably replaces something else the asked team wants to do, and they may push back or schedule the work at a time that risks the project’s timeline. When teams recognize this misalignment, the best solution is for the teams to work together to lay out the complete set of options objectively (e.g. bump the priority for this dependency, delay the bigger project, reallocate staffing from elsewhere to help). Sometimes, with the options on the table, the best solution is self-evident, and when it’s not, both teams can discuss tradeoffs with their own management effectively.

Reframing conflicts like these disagreement about what’s best for the company lowers the personal stakes for those involved and enables those involved to come to unbiased solutions together. Once the options are laid out, it’s just a matter of finding the appropriate person to make the decision. Easy peasy!