How to level up your interactions with developers
Maybe you’re an art director or a project manager. Maybe you’re a UX designer or product leader. But, you’re not a developer. You spend your days doing creative stuff, in meetings and generally making eye contact with other humans.
You feel like a successful communicator. Capable of calmly explaining what you need to your manager, your team and your colleagues. But, somehow, when you get in front of the developer building out your project you feel helpless. Lost. A dull (or maybe pulsing) sense of rage that you can never get what you want because you never know enough to keep up with them. It’s never awesome. But it doesn’t have to be that way.
There are a few things that time and again tip conversations to your developer’s favor. They are:
- Your lack of technical expertise.
- Their lack of empathy about the customer/end user.
- Their lack of interest in all disciplines that don’t involve code.
These can feel like insurmountable odds. But they aren’t. Here’s a gameplan to level up your interactions with every developer you encounter – starting…now.
Focus on building effective cross-team communication.
This might sound like Management 101 BS from the Harvard Business Review, but it is still sound advice. Long term success depends on good communication and if you set out to make this your primary goal, you can make it happen. Ask questions, try to uncover what you don’t yet understand and keep a sense of humor.
Don’t assume your emergency is their emergency. Because it isn’t.
Developers work in a specific way. Usually involving things like agile sprints, scrum masters and hours spent defining tasks and stack ranking them in order of priority. When you show up with your “emergency” they could feel instantly attacked – or at least annoyed.
The foundation of order and stability is being challenged by your chaos. Instead, turn it into an opportunity to build team morale. Show up with a game face, understanding that getting your task bumped up in priority will require some negotiation and the less emotional you can be the better. Figure out who needs to weigh in on prioritization and try to understand the process. Work within the process whenever possible. This will improve your odds 1000%.
Bring problems, not solutions.
Have you ever asked a developer to implement a solution that you came up with to address a customer complaint only to discover that you were in effect asking a genie to grant a wish and you did not consider the myriad of ways it could go wrong? I have. It sucks. And, when you ask for revisions to refine it, you are unceremoniously informed that the solution was implemented exactly as you asked for it.
So, here’s the thing. Bring the problem to your developer and ask them to help you figure out a solution. Maybe even ask for a couple of options. Treat them like they are a part of the team. An important part. They are the best at solving problems – and can come up with things you never could. And, it’s not too hard to see that they why they don’t appreciate taking orders from people who don’t understand what they do. I mean, we all could say that, right?
Make your deliverables developer-friendly.
Spend a little extra time making sure that design deliverables, wireframes and bug reports have the specifics developers need to get the job done right. You may need to enlist the help of a developer to determine what is needed. Do it.
You do not want to absent-mindedly delegate decisions like font size, row height and form submission behaviors to your developer. I once worked with a developer that would make any unspecified font flashing, red Comic Sans. Adorable. Plan ahead and give them these deets. Build it into your own process, so it becomes the way the team works. Isn’t this whole thing feeling better already?
Memorize this phrase. Everything is possible.
The number one conflict between developers and everyone else begins with their utterance, “That’s not possible.” And, I’m here to tell you – it is. Nearly everything is possible. But, it’s an issue of time and money. Remember that old adage when you want something good, fast and cheap? You can only have two. This wisdom holds true with web and software development, too. Something has to give.
So ask your developer what would be required to achieve the thing you want. You might still find yourself in a barrage of words you don’t know. But over time, they will come to understand that the argument, “That’s not possible,” isn’t going to immediately win the war.
Lean in to understand the complexity of implementation, time constraints or maybe a skills gap on your team – and over time you will be a much more formidable opponent and (more importantly) a much more empathetic colleague. You might even end up enjoying your developer arguments – I sure do. And, in time, you won’t have to argue (as much) because your team will be functioning at a higher, much-more-awesome level.
You can do this. I believe in you.
Disclaimer: If you want to avoid all of these developer communication challenges, find developers that get the user experience and care about design. You’ll be instantly ahead of the game. Yeah…we might know a couple.