Nobody wakes up in the morning deciding to be wrong, even though it can feel like someone did when you wade into a technical debate. Even in professional development organizations, debates about architecture, technology or technical design can feel like internet flame wars, with people on both sides of the conversation making their points with ever increasing vigor. The answer is so obviously self-evident to both, that it’s hard to even begin to entertain the idea of merit in the other sides position.
Let’s Assume everyone is thinking about the same problem, though that is not strictly a given. In the worst case, the outcome is decided by clout. Rather than persuading the opposition, one side appeals to either their own authority or escalates the discussion to a level too far removed from the situation to decide it on the technical merits. A proclamation is made and both sides are instructed to “disagree and commit.” The work gets done and nothing is learned.
At the next layer down, you find debates that are resolved by data. Pit two ideas against each other and measure which one comes out on top. If you gather the data, you at least have an objective measure you can point to the next time a similar question is raised. The problem with this tends to be how hard it is to acquire the needed data, or what even agreeing on the critical measurement in the first place. In fact, in many cases if everyone agrees on the right questions to ask, we don’t need to collect data to learn the answers.
Very often, the reasons that technical debates are so contentious is that they are optimization problems in disguise, and not everyone agrees on the right variable to optimize for. Settling this confusion can be much more fruitful than answering the immediate technical debate in front of you. Yes, you will also solve that, but you will probably also solve the next technical debate too, and you will make more self-consistent decisions throughout the project. Not every potential disagreement boils to the surface – by agreeing on goals you not only solve many of the debates that happen, you also resolve the debates that should have happened, but that were not noticed in the moment.
There is one step further we can take this. Rather than focusing on the immediate objective of the work we are doing, we can discuss the values that lead to those objectives. This is where some of the most valuable conversations happen, and where the most genuine disagreements stem from. If you value something different from your peers, disagreement is inevitable. From what I’ve seen, the most effective organizations are clear about their values, and actually believe in them.
None of this is to say that you should never disagree and commit. It is a failure, but the kind of pedestrian failure that is a necessary part of moving forwards and getting things done. It is an opportunity to do better next time, not a catastrophe to avoid at all costs. However, if you see different flavors of the same disagreement continually returning, it’s time to dig deeper rather than side-stepping the underlying cause of the issue once again.
It’s also possible to do both – disagree and commit to the immediate problem under consideration, and follow-up to debug values and goals after the fact, once the dust has settled. Hopefully you will find that the decision you took ultimately aligns to your values, once you have learned what they are.
This analysis doesn’t even require both sides of the debate. If I’m ever a witness to what looks to be a poor technical choice, I find it to be very fruitful to try and understand what set of values and beliefs could lead someone to that other conclusion – the person I’m arguing with didn’t wake up intending to be wrong, so what is the context in which they are right? Sometimes I even find that new position more to my liking, and can adopt it as my own. I didn’t wake up intending to be wrong, so maybe I need to update my goals to be right the next time. At the very least, I can come to the next discussion with more empathy, if not more agreement.
Leave a Reply