Resolving conflicts between two top engineers

Problem

Our startup, ebrary, was growing and, as the VP of Engineering, I chose to make organizational changes, to provide focus and ownership on seemingly separate architectural components and layers. As a part of this, more "experienced" engineers become leads or managers, based on their understanding of a given area. While the components progressed on fairly independent tracks, there were, of course, some interdependencies. Occasionally, opinions would differ on how to implement changes in the interdependent areas, but these conflicts would usually get worked out. However, two of our very senior architects were completely at odds over a change implementation for our search stack, and couldn't agree on anything. This was beyond the usual API proposal, but was still fundamentally simple - one wanted to expand the existing facility, the other wanted to establish a new one that was separate but linked to the existing one.

Actions taken

I started out by having a meeting with the two architects and I used the Columbo method (curious TV detective of the 1970's) - asking lots of innocent but pertinent questions (what problem are we solving? What are the constraints to it? What are the tradeoffs available? Why do you think that miracle will occur?), until I got to the point where the two employees were presenting very simple statements. I then drilled down on those statements with a why question. If you do this about six or seven times, you'll get down to the fundamentals of why they want to do a process in a certain way. And sometimes the answers will surprise you. We then put the answers on a whiteboard, so we could see what we were dealing with. It took a number of days, but this process helped the architects to distill what they were trying to say, and by having them defend their position, they were also able to expose the technology risks. It quickly became apparent to me that their conflict wasn't technical, but about who owned what, so each of them could own their own risk. They each had a desire to claim and implement the solution so their broader project objectives were met, and not risked by dependency on another team. The problem was one of ownership. The eventual solution did clearly favor one of the positions, but with some compromise for risk reduction.

Lessons learned

As you create teams and as you create managers, you aren't just asking them to perform a function in a completely separate environment from others. There will always be some level of interdependency between teams and managers. I hadn't built that into the process, and hadn't recognized that the interdependencies could create conflicts. Looking back, I should have seen this issue coming earlier on, as this would have allowed me to resolve it faster. It's important to be able to recognize early on when there is conflict, and get to the root of it quickly. Today, more modern agile project management methods do help us with earlier warning. However, as a manager, one shouldn't just step in and make a decision for the employees, taking authority and risk out of their hands and into yours. You are there to guide them to agreement on the essence of the problem, and help them negotiate a solution that they develop, and they commit to. It takes really hard work to resolve conflicts, and it's important to do it in such a way that preserves authority and responsibility for all parties, and fosters a culture of teamwork.