I started working at a startup when I was 19. I was originally in the marketing department, then, after a year, in the product department.
Learning on the job and designing for an app with a steadily growing number of users was scary enough, but what most terrified me were the developers. Our developers were very talented, had years of experience, and were extremely vocal about their opinions.
Every time I had to lead a product design review meeting, I’d feel a ball in the pit of my stomach, knowing that my hard work was going to be scrutinized by them. There was also a mutual departmental disdain; the developers felt that we were dictating the company direction from our ivory tower, and we felt that they were unfairly antagonistic.
It seems that strained relationships between developers and UX designers, as I was experiencing, is a common issue in companies. As I grew into my new role, I decided that my job would be much easier if–instead of trying to assert control (something hard to do as a 20-year-old just starting in his job)–I invested in maintaining good relationships with them. Just befriending developers made all my interactions with their department so much more collaborative, pleasant, and less scary. I also still keep in touch with a lot of them, so I’d say on a personal level it was worth it, too.
While good personal relationships with developers may help, keeping your departments as a whole on good terms is harder, and it’s important to understand where these tensions come from in the first place and how to diffuse them.
On more than one occasion, an argument ended because we realized that we had been saying the same thing for the last ten minutes and just weren’t properly listening.
What are the sources of this animosity?
There are a lot of reasons these two important departments can find themselves at odds.
In my experience, these were the critical issues that were causing the rift.
Developers want a seat at the table
I’ve often heard that programmers feel they have no say when it comes to the product they’re working on. Being handed features as a fait accompli, they have no say over what makes them feel like a cog in a machine, not a valued coworker.
This is also a problem that can be baked into company culture. Not emphasizing teamwork or maintaining rigid divides between departments only deepens this divide.
Working on things developers don’t like is awful
Coding takes a long time. Coding a feature you don’t like takes much longer. Having to stare at each line of code that comprises something you didn’t want to build in the first place just creates resentment towards the designers and the company.
When the product department feels like a black box, and you have no context for why these features are needed, you’re basically doing grunt work.
UX designers don’t always react well to criticism
There are a lot of healthy (and unhealthy) disagreements between the teams, which can be hard not to take personally. For example, I realized that a lot of the anxiety I had around running product design review meetings was that, when the feature I had worked so hard on was critiqued, it would feel like a personal offense. As a result, I’d get defensive.
When working together, many disagreements are often escalated or unresolved because neither side is willing to consider the other’s case. Sometimes, we’re so invested in being right that we aren't able to listen. On more than one occasion, an argument ended because we realized that we had been saying the same thing for the last ten minutes and just weren’t properly listening.
In what ways are companies impacted when designers and developers are at odds?
It’s easy to shrug off interpersonal relationships in a company and say that not everyone has to get along. It’s true: We don’t have to be friends with everyone we work with.
However, tensions in the workplace can hurt the company by decreasing productivity, and strained relationships between product and development specifically can hurt your product in many ways.
Developers are less likely to be flexible to product needs
However our workflows are structured, there’s always going to be a small change that was overlooked, some copy or pixel tweaks we want to get in after development has started. I would often get told to ask developers to add product changes in as a favor.
This is one of the places the product department can hurt the most from strained relations because developers are well within their rights to say no to these (and they often do), if they were not in the original scope of the project. Sometimes, these changes can be important, and, if your developers haven’t warmed to you, it’s very likely you’ll get the cold shoulder, sending your changes to the backlog.