How was this conflict allowed to continue?
When two teams cannot move forward, it is easy to focus on a person: they’re difficult, they’re a blocker, or nobody wants to work with them.
Sometimes that behavior really is the problem. But the systems thinking we’ve been exploring gives us another question: how has this situation been allowed to continue or exist in the first place?
I tend to describe managers in three broad buckets: secure or advocate managers, passive or absent managers, and insecure managers. In my experience, a passive manager can allow harmful behavior to persist by avoiding confrontation and hoping people will work it out themselves. They like to bury their head in the sand. And just like everything else, I don’t always blame them. Managers are terribly trained to move from running projects to running people.
Understanding why someone behaves badly doesn’t make it your responsibility to change them. You can have empathy without accepting the behavior. Sometimes someone with authority needs to address it, and raising specific examples with your manager can help bring it to the people responsible.
But there are also situations where the teams are capable and willing, yet every attempt to agree on a path forward falls apart.
What were the teams actually trying to accomplish?
I once took over a project to integrate an acquired product into the acquiring company’s portfolio. Leadership told me the project had been starting and stopping for two years.
Different people had tried to lead it. Each time, the teams disagreed about what to do next, attempts at compromise went nowhere, and the project eventually stopped until someone new tried again. This cycle repeated over and over.
When I stepped in, people wished me good luck because “you’ll need it.” The teams were skeptical, saying nobody had been able to solve this before so what makes me different?
These are the situations I thrive in. Systems thinking and pattern recognition are part of my craft: the overlap between who I am and the work I do.
I spoke with each team separately. I asked where they were headed, what they wanted to accomplish, and why. Then I kept following the reasoning behind their plans.
Their answers revealed that they were pursuing two different goals. Their preferred next steps made sense in the context of their own goal, but those goals were sending them in two completely different directions.
I brought key people from both teams together. See, before discussing another plan or compromise, we needed a shared understanding of what this project was meant to achieve. It wasn’t about the right step or even what the end state should look like, it was about the reason for the acquisition and integration. Why were we even doing this? What was the goal?
After about 30–40 minutes of working through the original intent and goal, I asked what the next step should be.
Both teams gave the same answer.
Neither felt that it had given something up. Once the goal was clear, the next step became clear too. Within less than a week of taking over, I had the project moving. The teams began making progress and shipping software, and leadership was surprised that something stuck for two years had started moving so quickly.
How do teams end up with different goals?
A goal can be agreed at the beginning and still drift as people develop their plans.
Someone sees another possibility. We could add this. We could also solve that. A useful extension starts to feel essential, and gradually the plan grows beyond the original intent. And there’s this weird thing that happens where the new ideas end up getting retrofitted into the original goal. They start imagining a future that had nothing to do with the original intent of the project. This happens all the time.
If each team follows different possibilities, they can end up pursuing different versions of the project without explicitly deciding to change its goal.
That’s why I keep returning to the intended result when projects go off track. NASA’s guidance on stakeholder expectations likewise emphasizes agreement on goals, clear success criteria, and an approval process for later changes.
While a new idea may be worthwhile, it still needs an explicit decision about whether it belongs in this project, a later phase, or a different piece of work.
What should we revisit when the project gets stuck?
Before negotiating another compromise, ask:
- What was the original problem we were trying to solve?
- What result are we trying to achieve now?
- Are we all describing the same goal?
- What is the smallest scope that meets that goal, and what can wait?
The current goal may need to change. The important thing is to make that change visible and shared, rather than letting different teams revise it independently.
The friction in front of you may be a symptom of something elsewhere: a goal mismatch, unclear authority, or behavior that management has allowed to continue. There may be more than one contributing problem.
Finding what is sustaining the conflict gives you a better place to intervene. In my project, that meant returning to the goal. Once we resolved that disagreement, the teams could move forward.
The key to all of this is this… whenever you’re faced with a really big problem at work, 9 times out of 10, I’d bet that it isn’t the real problem. The real problem is somewhere else. Go find and fix that, and whatever is in front of you will resolve itself.
