I work as a software developer and the artists at work always get very defensive and nervous when they work with us. We don't think we look down on them at all, however they become quite upset when they work with us and try to make us out to be wrong.
We need artwork in a certain format from them and need them to follow our guidelines. It's to the point where I'd rather spend time cutting up my own art then having to talk to them.
Anyone else successfully navigate this kind of environment?
This question appears to be off-topic. The users who voted to close gave this specific reason:
Whether intentional or not, this is how lots of companies decide to structure their staff.
Techies over here, non-techies over there. You guys just toss stuff back and forth over this fence and we'll pretend that everything will just come together magically!
This, of course, simply doesn't work. The non-techies aren't treating you badly per se. They're just treating you the same way you are treating them. Both parties likely don't even realize it.
The issue isn't disrespect between groups--the issue is an incredibly poor org structure and work process.
What has happened in your specific case is something I've seen happen in many orgs I've worked at. Have someone 'design' the solution, then have technology 'build' the solution.
This stems from the concept that producing software is somehow related to the factory floor process.
Team 'a' designs the solution, team 'b' works on the factory floor to make it.
What many organizations fail to understand is that software takes place entirely in the design phase. The end product is the design. So there can't be a team 'a' and a team 'b' that work independently and sequentially.
There has to be a single team that has you techies as part of the design process and working in parallel.
How to fix that? You probably can't. Agile development and Minimum Viable Product and other processes are designed to help with this, but I haven't seen many companies that didn't embrace those from the start ever really transition fully to them. They drag a lot of baggage along with them.
Finally, to answer the very specific scenario you describe, the frustration is often because the UX/UI/Design/Art team are tasked with creating a solution. However:
This, of course, confuses the implementation team when they first see the solution. Inevitably there's a lot of issues that likely need to be resolved and since they weren't part of the process at the beginning, these all seem like brand new issues. This frustrates the team that handed the project off to you because the solution has already been approved. It's not your fault, of course, but you'll likely be the one to get yelled at (as they can't easily go back and yell at management).
I've seen this happen in many companies and have been on both sides of that fence before. And that's probably the best way to eventually fix situations like this. Get some cross-trained generalists hired on both teams. This can really help bridge the communication and process gaps.
We don't look down on them at all
Speak for yourself.
In my experience, it's fairly common for software engineers to look down on... well, almost everyone. And that goes double for people who keep us from getting stuff done, ask stupid questions, can't listen to instructions, and so on. The art/user experience sort of people tend to suffer from those problems.
Worse, most software engineers think that slapping together a set of UI elements takes like a week. Like their job is so hard!
Meanwhile, the art/user experience people think the same thing of software people. How hard can it be to push some images and text to the screen correctly! These guys can't even do that unless I get them a PNG that's exactly 160x160...
Conflict occurs for the same reason it usually does - ignorance.
You are asking the wrong people. You need to talk to the artists. Defensiveness and nervousness are symptoms of a lack of trust and you need to build that trust.
For example, you mention that you need art in a certain format and following certain guidelines. Is this documented? Do they understand and and agree to the format and guidelines? Are these written for the developers' benefit or the artists' benefit?
Alternatively, is there something else wrong? Are the artists under strict deadline pressure and your requirements just add to this?
Be aware, you (or your team) are likely to be part of the problem. If the focus is on the team creating a product, things will work out OK. If this is a competition between developers and artists on how bad each other has it, you have the source of the problem right there.
I think a large part of the issue is a cultural identity clash. Neither your team nor the artists appear to be talking to each other as people. Instead you appear to be talking to each other as "engineers" and "artists", each team reducing the other to cogs in a factory process.
Because technologists only see issues as technical issues to solve, they can miss the broader picture - and the finer details. Because artists focus on the more expressive side of things, they can miss the general details.
To solve this issue - to solve it, not feel satisfied that "the company is to blame" or "it's those over-emotional artists at it again" - you will need to start communicating with the artists. Maybe have drinks/lunch with them and ban work conversation?
Also, consider working on explaining issues to them in a sympathetic and considerate manner. The question as initially posted indicates that the style of communication from engineer to artist leaves a bit to be desired.
You will also need to consider that the artists do not understand why you need the picture in some weird format (they'll think, "well, just use photoshop to resize it properly, you technical ignoramus") ~ this is just the flip side of your casual comment about doing the artist's work.
Actually, to really fix the issue you should trade places with an artist for a week, and see how hard their work actually is. They will also get an idea around what you have to do. I suspect that isn't a viable idea of course, so work on opening meaningful channels of considered communication instead. And remember they're human too, they knock off work and have a meal and watch a movie just like you do.
I think there needs to be some improvement to the communication and some perspective taking by both groups.
You don't know what each other does. Programming makes a request and has no idea what else is on the artist's plate. Sorry developers, but your request just took a back seat to marketing's request for, "We have a presentation tomorrow morning with the world's biggest customer, so we need you to redo the entire Power Point presentation layout or we're all fired." You can't expect your whole team to know everything about each other but someone needs to have this conversation. It could be informal. Ideally there would be some managers or team leads that took care of it.
Both of you ignore the client/user It's like automobile engineers wanting the car to be designed around the engine. The engine is as big as it "must" be; nobody can tell us to change it. This is how the universe works. So now the buyer has to settle for a car that's too wide to drive down the average street? The solution to this is found in the next part.
There's suppose to be conflict Maybe that's too harsh of a word, but I'm pretty sure programmers and artists/graphic design/ux concerns are NEVER going to be in perfect alignment nor should they. You both have to recognize you both have conflicting constraints and the key is to go back and forth and work it out. Neither side is over-ruled by the other. Hopefully, the client/user gets the deciding vote because you may be the one who has to build the software, but they're the ones who use it and/or pay for it.
This has very little to do with them being Artists and you being Software Developers.
It usually has everything to do with them artists being THEM, and you software developers being YOU. The same rift can appear between software developers and sales, software developers and support, software developers and IT, IT and sales, sales and support, and support and IT, to name a few. I witnessed all of these and more.
The same problem also exists in companies that have exactly zero technical personnel.
By having divisions or teams - in your case software developers and artists - cut off from each other, a company can create distinct groups. As soon as you have distinct groups it doesn't take many quarrels between individuals in different groups to poison the relationship between the groups. Management can assist building the rift by disrupting communication between the groups, or they can try to stop the rift building by encouraging communication.
Of course there are often some individuals that can be blamed for the situation because they are very defensive, or aggressive, or lack manners. But take a large group and you will always find such individuals. Removing these individuals will often not fix the situation, and it may even make it worse. Imagine how you'd feel if the Artists get a Software Developer fired for no good reason (there's probably a good reason, but you hear only one side of the story).
On the level of the individual worker, without management involvement, there's only one thing you can do. Don't work with "the Artists". Work with John, who happens to be an Artist. Get along with John. If you need to work with other artists, work with Sue, who also is an Artist. Build relationships with people. If you can't build a working relationship with some people, try working with (or through) someone else.
On the level of a manager, they need to help you build relationships. This is one of their primary jobs, so expect them to already know that. They spot rifts as they build and take appropriate actions, such as company events, department reorganizations, 4-eyes talks with toxic people, interrupting the blame game, etc. Under some circumstances they will even want the rift because they intend to use competition between teams to increase productivity - this doesn't always work out.
You have a clash between two different cultures. If you don't understand each other, this will never work. You can either wait for the artists to understand your needs, or you can try to understand what they are doing, and/or try to explain your needs to them. The second seems the better approach.
I have seen problems with software development work flow (basically, artists not understanding source code control and the artwork that they are producing at some point turns into source code). That's your strength, so better you (software developers) just handle this.
I have seen problems with tiny icons being delivered as 100KB files. Which is no problem unless you have 400 of them and your customers complain about the program size. Solved by finding a tool that stripped 99% of the data leaving all the image data intact. That was a lot easier than trying to educate the artists.
Some artwork looks noticeably better if it isn't scaled. If your artists cannot deliver artwork that doesn't need scaling (like they cannot produce a 160 x 160 px image that you asked for but it is 158 by 158), then demonstrate to them how it looks bad. If they cannot learn, well that is bad. In that case, it might help to act stupid: You cannot scale that image, so you cannot use it.
