Opinions expressed here are my own and do not necessarily reflect that of my employer
Conflicts between developers (or any other roles for that matter) is usually inevitable. When every voice matters on a team, how do you balance that when it roadblocks you from getting work done?
A little background. I'm typically the risk taker on a given team. When we're given a new idea, my first instinct is to jump right in. Who cares if I fail a few times? It's just part of the process. On the other side, more cautious developers would want to pump the brakes and do research first.
Lets paint a scenario: The goal is making a living style guide work for multiple sites. I sided with the designers in wanting to give each site a distinct look. When dealing with a common style guide, this meant that most CSS properties could be adjusted to fit design's mocks. The opposing view was that this was too extreme, that only colors should change between sites.
You can picture my reaction. We're building a new site and it'll just look like palette shift version of another? Bleh.
Earlier in my career, I would have gone into attack mode. I would had made it clear that they were overstepping their bounds - this discussion was a courtesy my team was bringing to the table and in return, they wanted to impose their restrictions on my work.
Probably would had thrown in several colorful metaphors for good measure.
Problem with my first instinct to direct confrontation in the example is that I was looking to jam a square person into a round hole - metaphorically and literally. And in doing so, it'll make them even more set in their views.
Whenever a clash happens and it's escalates to the point voices are being raised, I like to take a step back. There's nothing to be gained at this state without understanding your opponent.
Ok. Took a moment for a deep breath. Now how do I proceed?
That is my frequent go-to template to make it clear that I've acknowledged the other side's reasons. It took me a long time to come to the realization that my end goal should never be to directly change one's opinions, but to show that I'm open to and have heard their thoughts. I may not always accept it, but I've given them a venue to voice their concerns.
For round 2 of the scenario discussion: "I know that giving designers more freedom in altering the style guide would add work for us. But we want to visually distinguish this site but still reuse all the components that you built for your site."
I deduced the reason for the team member's view was that they had a template - and what's the purpose of building a template if we're going to change it? I wanted to show that their work is valued, that's the entire reason we're re-using the style guide. And with a little more work, I could add more value to their components.
If I had gone the route of shutting down their arguments, they may feel less engaged, breaking team cohesion and making it harder to collaborate in the future.
End of day, our teams all share a common goal - to make something epic.