Resolving Conflict Within
Remote Teams

By Bill Flury

A few years ago, I was manager of a Law Enforcement Assistance Administration project on which we had small teams working in eight different cities. Each team was tasked to work with the local police, courts, or corrections agencies to seek out and document ideas for improving operational processes or equipment. We found office space in each of the eight specified cities and relocated the team members for the full year of the project.

Each team consisted of two senior engineers. All team members were experienced senior systems engineers with strong backgrounds in operations research and information processing. In most cases they worked well together, sharing the lead on pursuing the various ideas that came up depending on their specialties. However, in three cases, strong differences of opinion emerged regarding what the pair should be focusing on. The differences of opinion became heated and I had to intervene to keep the work going forward. The root of the problem was that both team members at the problem sites had very strong different technical convictions about what they should be doing. They both considered themselves as equals, and were unable to resolve their differences on their own.

In each of these cases I had to work with the two to reach a decision based on the full scope of the project, not just their local situation (i.e., what approach would be best for all police departments, not just their police in their assigned city). Escalating the discussion to this level seemed to make it easier to find a solution that would be equally satisfying (or dis-satisfying) to both. When that worked, things were fine. It did not always work. In cases where one of the original choices prevailed, I had to reassure the team member whose idea was not chosen that my decision was a business decision, not a bad mark on his technical expertise.

After the project was over, during our “lessons learned” sessions, we discussed this situation. Some thought the escalation process that we used worked well. One person suggested that we should have designated one of the team members as the site leader at the beginning of the project, before we sent them out. Another suggested we should have had a steering group to discuss and resolve such questions. A third suggestion was to have three person sites with one person clearly designated as the site leader. The final suggestion from this session was that, for projects like this, we should pre-brief all potential site members on this problem before they go and ask them how they will plan to resolve such situations.

What would you do?

Full Course: Don’t Deal with Difficult People – Learn to Work with Them (1 day)

Click here for our full list of available courses!