5 Keys to Preventing Marketers and Developers from Pissing Each Other Off.

For almost three years, I was privileged to lead the web marketing development team (or WMD's as we liked to be called) at the Lampo Group. That provided a unique opportunity to better understand what often trips up communication between development and marketing teams. More often than not, I was the one doing the tripping, so I learned a lot. I shared a few things with some marketing folks over burgers recently and figured it might be helpful to others as well.

Without further ado, here are 5 reminders to keep your marketing and development teams working together smoothly:

Marketers:

1. Don't let your lack of knowledge for the technology details come across as not valuing them.
   
   If you say things like "nerd stuff", "geek stuff" and "code magic" with a roll of the eyes or a hint of condescension, it will be picked up on and it will hurt your credibility with the developer team. They may have spent years in school and countless hours researching and learning online to understand the "tech stuff" while others were out doing more socially interesting things. Respect that investment and be sure to communicate how much you value their abilities and the complexity involved.
2. Don't say things like, "It's just copy/paste, right?"
   80% the same can be very different than 100% the same. It can be like saying, "Remember that Ferrari we had you build last month? We'd like to use it to transport about 40 people at once. What's that you say? A Bus? No, we can just use the Ferrari. It has wheels, an engine and a steering wheel and you already built it. That should be fine." If you ever need a reminder of what's really going on "under the hood" have them show you a few thousands lines of code every once in a while. Just for fun, have them show you how if they mistype even one character the entire thing will no longer compile.
3. Include the developers when planning out the project.
   
   Developers are often like artists with a wide range of brush types and paints to work with. Involve them in the process, communicate what your ultimate goals are (not just your immediate ideas for reaching them) and let them work as partners, not order takers. The timelines, the budget, the objectives... those all need to include the development's point of view. For example, if you didn't schedule time for testing and remediation in the project plan, you're probably going to miss the deadline.
4. Learn what is expected of you and treat it seriously.
   If you're given an admin interface that is confusing or you're having trouble figuring the system out, make sure you let the developers know and ask them to help you learn it. Take notes, write procedures or ask them to make changes but no matter what, don't simply abandon it. Few things frustrate a developer more than building something and then finding out later no one is using it. In my experience, developers love helping people and solving problems. If it doesn't get used, the problem hasn't really been solved which makes them feel like their work wasn't valued.  Or worse, that those making the priority decisions didn't think things through.
5. Developers are usually very specific.
   
   If you ask them to do X, Y and Z and assume they will understand that (obviously) 1, 2 and 3 are also needed to complete the project, don't be surprised if you only get the last few letters of the alphabet. Be specific. What you may see as skipping a few annoying, unimportant details a developer may see as a critical lack of planning.

In a nutshell: Respect is the currency of knowledge-workers. Pay well.

Developers:

1. Don't assume you're the only one who cares about the user (and, thus, the user experience).
   Most developers like to be arm-chair marketers, but notice how few marketers try to tell you how to optimize that recursive method you've been working on? Bring your opinions and experience but keep in mind there is probably a lot to a marketing campaign that you know nothing about. There may be 20 different plates spinning all at once and, if you happen to see one crash to the floor, give the benefit of the doubt and assume the other 19 plates were more important.  
2. Develop a deep, genuine respect for your marketing team and communicate it often.
   The marketing team's ability to promote your work pretty much pays for your salary. Don't ever assume they are ignorant or unintelligent. Chances are, they know more than you, just in different areas. For example, they probably understand people better than you. You work with code all day, they work with people all day, that's just the way it is. That means every gesture or comment you make, subconscious though it may be, communicates to them how you really feel. If you don't completely respect what they do or if you don't know how to communicate that respect, it will seriously hinder your ability to work well together.
3. If you get invited to a brainstorming meeting, GO!
   Yes, you'd rather be coding, but meetings are important. When invited, participate, but don't say things like "can't", "won't", or "not possible". Remember, you're the miracle worker so just about anything is possible given the right budget of time and money. It's your job to let the marketing team know what's reasonable given all the parameters. More often than not you have a solution that is not only faster and cheaper, but it also better meets the needs of the campaign. Also, don't get frustrated if they are bouncing around 10 different ideas before landing on something and needing your input, that's just how they work.
4. Don't go into the details unless you have to.
   Even then, have some metaphors to explain what you're talking about. I honestly suck at this. It's not uncommon for me to go way overboard with technical details either to stroke my own pride or to say, "see how hard that was?" Usually it's best to have the details on hand and ready, but just communicate the summary in a way that fits the audience: not too watered down so they feel patronized and not too technical so they feel stupid.
5. You are employed to help generate profit or further the cause, not just write code.
   It's very frustrating for a marketer to hear you missed the deadline because you rewrote the application 3 more times just because the code "didn't feel right" the first time. I'm all about refactoring when it improves performance, security or maintainabilty for constantly changing components, but keep in mind that even 1.0 code released to serve your customers is far better than perfect code no one ever uses.

In a nutshell: Good marketers work their asses off. Give them a break and serve them well. 

---

Want more on this topic? When thinking about this stuff, I stumbled upon a similar post from 2009 written by Jon Samsel.

This post is already too long and there are way more than 5 things to keep in mind. Got some great ones of your own? Please include a comment!