It is difficult to move from working alone to working in a team. I don’t mean working as part of an organization where individuals run their own projects, I am talking about attempting to establish norms and standards across a team that individuals are then responsible for implementing in their work. At its core, you are asking people to change their behavior for some larger purpose. I have had a lot of conversations where teammates are unwilling to change and others where they are more receptive to ideas for change.
This blog post is an ongoing post about my experiences attempting to navigate disagreement in managing a small engineering and data analysis team. I don’t like disagreement but I recognize that disagreement leads to better teams and products, so I need to figure out how to handle it to lead more effectively. I have found many ways to fail in this regard, so this blog post provides some questions that I have developed to help myself better navigate awkward conversations and disagreement.
What is your commonality?
What is the root cause of the disagreement? Most often, disagreements about tool choices or how to structure code come from a surface-level understanding of the core issue. The core issue might be how to do something most efficiently or how to reduce the barriers for other developers to onboard or fill in for the individual who wrote the code.
Take a moment to zoom out and ask yourself why you are having the disagreement and are the options being proposed the end or only means to an end. In the most recent instance of this, I had a disagreement about how to store our R code. Our team has primarily used Python for a number of years and we have coalesced around a couple of core repositories for different purposes. R is the main programming language we use for data analysis, however we have had few discussions around how we should organize our data analysis projects. We have had discussions around common folders that you should include your data analysis for your various datasets (raw, clean, etc.) and we have begun developing a common set of functions that are widely applicable across our data analyses, such as integrating into various data sources. But we have discussed whether a new developer should always create a new repository or whether they should contribute to a small number of repositories, each which serves a purpose or has a uniting feature.
My gut reaction was to have as few repositories as possible to reduce local repository setup time and to enforce certain standards (deployment, PR contributions, etc.). And, unfortunately, I made this known. But this was putting the cart before the horse. I should have gathered more information, understood why my colleagues felt differently.
Are you at an impasse or can you coexist?
It is important to establish whether the decision you need to make requires one side to fully compromise and give up their position or whether multiple ways of working can coexist. It can be difficult to know the answer at first, but you should consider the size of your team, You should also consider how your team might grow or change in the future. Considering every possible future scenario can paralyze your discussion, but you should discuss the future scenarios and prioritize considering the implications of this decision on the most likely future scenarios. Do not consider scenarios or use cases that your team does not currently have and there is a low likelihood they will become more central to you work in the future.
Not all decisions require one side to adopt another’s practices. There are many good reasons to avoid standards and allow teammates to use the tools and practices they each prefer. Take time to consider whether your team really needs to coalesce around one option and change their practices or whether multiple practices can coexist without negatively affecting your overall goals.
Imagine you are driving down a narrow street that is technically a two-way street but, in reality, only one car can fit through at a time. You come across another car driving in the opposite direction and you reach a standstill. One of you will need to move over to let the other pass. Once this happens, you can proceed and both of you will go about getting to your destination. You might not want to pull over because you have somewhere important to be and getting there a couple seconds faster might seem really important. The other person might feel the same way. Without any communication between the drivers about where they need to be or mutual recognition that you both will benefit from one of you moving over.
Compare this entering a packed parking lot, where there are many cars but few open spots. When a space opens up, multiple cars might jockey to take it but only one car can ultimately park there. Only one person (or car) can ultimately prevail in this situation. This parking space might be a major architectural decision that you will need to live with for months or years.
Recognizing when the situation you are facing is a street versus a parking lot makes a difference in how you approach the decision. In both situations, understanding others larger interests is important. If someone has carefully considered the decision and the ramifications for your long-term goals, then that is a reason to give them priority. If you ask someone “Why do you feel that is the right decision?” and their main reason is “because that is how I am used to doing it”, you need to probe further to identify the similarities and differences between their previous experience and your current predicament. Without mutual understanding, then it might become a staring contest until one side concedes or the two sides will each continue to operate in siloes.