In a series of recent interviews, I've been asked how I would deal with a deep disagreement among the development team - what if two camps vehemently disagree on an item of architecture or implementation and can't get through it.
How would I deal with this, if I were THE BOSS. So here's my advice. First of all, every time you break a logjam by MAKING the DECISION, because you are THE BOSS, you lose part of the team. Even the "losers" might be ok with having the issue decided, but they really don't like being walked over, and part of them - the part of them that you are most trying to engage - their deepest, most committed, most passionately attached spirit, will stop coming to work. So, when I am THE BOSS and we are stuck, I use a method of "Pushing on the stack". I'll get the team into the polarized discussion, then press the pause button. Say something like: "Let's just suspend this conversation for right now. What is the quality of the conversation that we're having right now? Is anyone feeling productive, energized, motivated? What are you noticing?" The first time I do this with a group, I'm from Mars. Blank stares. Many attempts to dive into the content. Things like "Jim is saying that it won't scale, but I shared that whitepaper from the HP architect..." I have to go zero tolerance on this... "Let's just not worry about the content right now. What do you think about the form of the conversation? The quality of the turn taking? The level of building on ideas? The effectiveness of our use of the group's time?" If I keep speaking Martian for long enough, someone will get fed up. "We're covering the same ground over and over. We never get anywhere. Anil says it will scale, Jim says it won't. We're stuck." Great. Now we can get somewhere, because the real problem has been identified. The problem isn't about the scalability of the product, its about the willingness of the team to stay stuck. "What is it about this team that makes us persist in staying stuck? What would we do if we didn't want to stay stuck? Are we missing information? Expertise? Courage? Is part of our team ignorant? Stupid? Stubborn? Blind? Or is this just a type of problem that we like to keep arguing about? The thing that is amazing about this "Pushed" conversation, is that it engages the debugging skills of engineers on the real problem of debugging the system that they are part of, rather than the system that it yields. So, stuckness in a team becomes a great problem for the team to work together on. As the team learns how to ask and answer the "what does this tell us about us" question, the team accelerates its own work in lasting ways. Rather than being the ruler with the more right than wrong answer, as THE BOSS, I'm able to be the catalyst of the team coming up with way smarter answers than either of the initial "sides" and certainly than whatever mamby-pamby compromise I might have come up with on the spot. Don't settle for stuck. Don't settle for suck. Get the team into "getting it" together.