I have recently been reading "Think Again" by Adam Grant. One of the topics he talks about is Relationship Conflict (more interpersonal conflict, "I don't like this person") vs. Task Conflict (conflict about solving the problem at hand). Focus your team's conflicts on the tasks at hand vs. interpersonal conflicts and fundamental identity-based disagreements. This idea resonated with me, and I recognized this concept immediately as a principle I developed in my work without realizing it. It's a skill that I hope to cultivate more deliberately going forward.
Focusing on Task Conflict and avoiding Relationship Conflict is something I can admit I've performed poorly at in the past. I have found that sometimes it's hard to detach yourself from your ideas, making it easy to fall into the trap of being personally attached to your idea, resulting in a worse conflict. I can vividly remember a time in college while working on the Shuttle Tracker, when I found myself getting worked up over a code review. I was taking what was constructive criticism personally. Admittedly, I was new to the language and web development then, and I knew my code was not up to par. Looking back on this, I cringe at my behavior. I was in a Relationship Conflict mode-my identity was being attacked when I should have been in Task Conflict mode. Once I learned to let go of my attachment to specific details, I could take an analytical look at my solution and start to learn how to improve. Once I let go, I could utilize my colleagues' reviews to learn different perspectives, ideas, and strategies for developing software. I eventually came to realize often, in software, There is no "right way," and learning how other people solve a specific problem has given me an appreciation for the focus and drive that others put into their work, even if they don't do things the way I would have.
As my career and open-source contributions developed, I learned to detach from the specific implementation and ideas while focusing on the overarching task. After I learned to do this, I made significant strides in my abilities as a software engineer and learned and adapted to new roles. Now I try to keep the following in mind:
Note: very real interpersonal conflict issues can crop up, but here we are focusing solely on engineering problems.
Cultivating a task-based culture is crucial to working collaboratively and building an effective team culture. This Task Conflict style only works if everyone buys in. I have tried to bring this attitude to the table when joining a new team as an IC and found it can be infectious. I have done this through very explicit communication about the fact that I am focusing on the task, not the implementation. I do this on teams that I'm on by coming into every conversation about a code review and framing my suggestions as us working together to find the best solution.
This works best for me if I can incorporate people's solutions into my suggestions. Highlight the areas where they did well and frame suggestions as questions to build a better product. For example: "This solution is great; I like how you structured the data here; what do you think about leveraging that data structure more cleanly with a map-reduce instead of a for loop." By explicitly communicating your common goal repeatedly and often, you can direct focus toward that goal. It helps keep the team focused on the bigger picture during these discussions.
Going forward, I plan to define better how to maintain this team culture and keep everyone focused on a common goal.