This article was originally published under OโReilly
Every company I consult with has a version of the same problem. The marketers want a flashy new feature, but either they donโt know how to communicate it to the developers, or they donโt understand the terrible effects it could have on the site functionality or usability. Or, conversely, the development team wants to implement new functionality without understanding how it can impact the brand, the organic search traffic, or other marketing efforts.
Often, it speaks to a disconnect in priorities, in knowledge and, obviously, in communication. Developers favor solving a problem and getting changes implemented with minimum debate and without disruption or change. Marketers often are abuzz with ideas for โflashโ (not Flash), for the hot new technology or functionality, and for having changes implemented for the user โnowโ. Infinite scroll is an example of just such a technology. When it first came on the scene, both marketers and developers began using it to display large quantities of content without having to load all the data at once or having users click through to a series of many pages. Unfortunately, many who didnโt consult with the other team saw a decline in traffic; one team or the other might have known that Google spiders canโt โscroll downโ, and because of it a lot of their content was rendered invisible.
Both teams are obviously crucial to the long-term health and growth of a company, but often each group does not fully understand the importance of the other. Although technology companies can often launch without a marketing team, they usually wonโt go far after the launch without one. Although many marketers believe that the brand is more important than product, creating that โminimum viable productโ in the online space canโt be done without a development team, and having a site that does actually work and satisfies the consumer is always going to be essential.
In many cases, solving these problems requires training and significant effort that many companies donโt believe they have the time or money for. In my role as an SEO, it has frequently fallen to me to be the โtranslatorโ between departments. By nature, a search engine optimizer has to be conversant in both the technical/code side and the marketing/customer side. However, I believe that if you arenโt making an effort to help your teams understand one another and to communicate effectively, you are squandering resources โ wasted time, lost traffic, delays, and significant rework that could have been caught in the early in the process with effective communications between these teams.
Lay down the most important tasks
Google recommends sitting down with your core team and listing the main tasks of the site. What must the website user be able to do most effectively? Out of all of these tasks, which are the most common ones? The ability to perform these actions should be optimized accordingly. A common complaint that marketers voice about their developers is that they donโt understand the needs of the end-user. A way to remedy this is to list those needs, as simply as possible, and walk them through the list.
Have both teams involved in a new project right from the beginning. When wearing my SEO hat I recommend that clients have me consult on a new site or functionality right from the planning and wire framing stage. This can nip major potential problems in the bud, preventing the need to go back and make time consuming fixes after something is already built/coded.
Action Plan: Write down the main tasks users perform on the site. This could range from a few to dozens of desired actions, but should be limited to the most popular or important actions a site user can take.
Donโt waste time over-communicating
There is a subtle difference between communicating well and over-communicating. An onslaught of unnecessary communication can waste precious time and resources better applied elsewhere.
A study published in 2003 by IEEE Transactions on Engineering Management found that email communication frequency had a curvilinear relationship with goal achievement and project efficiency. Too much email communication between teams resulted in a significant dip in efficiency and milestone achievement overall.
So how do you find that perfect quantity of communications? Much of it comes down to mutual trust and respect. Respect the other teamโs professional opinion, even if you donโt necessarily understand the reason behind it. Respect each otherโs time. Make sure each meeting you schedule is actually necessary. Spend time preparing for any meetings to save time during the meeting; decide on a clear goal and agenda. If it helps, set up a schedule for updates. Donโt bog down email inboxes by asking for updates constantly. Instead, create a deadline and schedules for updates. When you lay down clear expectations, the feedback loop is faster and more efficient.
Action Plan: Donโt plan unnecessary meetings. Keep a clear schedule for updates, and stick to them.
How will something affect the other team?
Make the effort to understand the demands that a task will put on the other team. Iโve seen situations where the marketing team heaps an enormous amount of work on a development team and then get frustrated when the coding isnโt spectacular after their 3-day deadline passes. Your team of two coders canโt handle the same kinds of deadlines that Amazonโs army of coders can. Often, development teams canโt predict exactly how much time a task will take. As the project progresses, the team will invariably run into snags. And of course, bugs happen.
If you want a project to take less time, perhaps ask the developers what kind of changes to the project could be made that would require less testing and less development time. They probably have some valuable input on alternate solutions that you would have otherwise never considered. Alternatively, simply ask yourself if the feature you want is really necessary.
If you want the project to take less time, be decisive about the features you want. Likely, the latest feature request, if left out, isnโt going to make or break your site. Thereโs nothing that can throw a project off-schedule like constantly changing your design needs.
Action Plan: Make a choice about the feature you want implemented by the developer, and donโt stray from that decision unless an urgent problem arises.
Have marketers and developers meet and hash out the site features and changes
Companies often donโt understand how decisions made by one team directly affect the otherโs ability to do their job. Before one team makes an important decision for the site, the other should be consulted and their opinion respectfully considered. Specifically, Iโve seen this happen with site navigation, โfaceted navigationโ for ecommerce, and site search. Although each can be helpful for the user, if they are not implemented correctly, each has the potential to create huge quantities of duplicate content or a confusing experience for the user.
Another significant concern can come when a development team makes a change to the site that seriously threatens user experience or search engine optimization (SEO). I have frequently encountered developers that have built site features with little to no oversight by the marketing department only to find that those features create massive duplicate content problems, or that they have built pages using code that cannot be crawled and understood by the search engines. Had they checked with marketing (in this case the SEO team), that issue could have been resolved. Another potential hazard is the development team deciding to create something via a solution or technology not previously discussed. Although to the developersโ minds, since the visible output is the same, the problem is solved, frequently how something is created for the web is just as important as the final output.
In one instance the SEO consultant was not able to see the code for, nor even a functioning preview of, a redesign of a site section that drove the vast majority of the siteโs highly converting traffic. When the new site section was finally presented to the marketing team and the SEO consultant, it turned out that the pages for this new site section appeared entirely blank to the search engines. The lack of communication in this case was exacerbated by the fact that the development was being done by a contractor outside the company itself. While a sub-optimal workaround was implemented to mitigate the damage, it took many labor hours to fix the site and to get back to a place where the site functioned effectively for both users and search engines.
A study done in 2001 published by the Academy of Management Journal found that the ability to express doubts seriously moderated the disagreements that resulted from task disagreement. Freedom to express doubts also had a negative relation to the amount of contentious communication between groups. Creating the kind of environment where people from all groups feel comfortable in asking questions and voicing concerns in a constructive way will result in greater rapport within the team, and because of it, a more innovative atmosphere that prevents problems on both sides.
Action Plan: Plan a meeting to discuss any site updates, technical or otherwise, and how they might affect site functionality. Make it a meeting goal to understand how the users and search engines will be affected. This should be the case for anything from small changes to a page template, up to and including site rebuilds from the ground up.
Encourage people to learn interdisciplinary skills
A fun way to get your marketers and developers communicating more is to reward your marketers for learning some coding. Or conversely, give your developers a small bonus for taking a course in user experience or reading a few books on marketing or SEO. This type of learning is just as valuable, perhaps more valuable, than reading a book in their own discipline. Treat it accordingly with raises, bonuses, or a few hours off.
Especially if you find yourself managing a group of developers, deeply consider taking a few coding classes. Anything that helps bridge communication gaps can make you a better leader, and can increase the likelihood that the developers will respect the choices you make for the product. Rightly so, because youโll know more about what they are going through.
Action Plan: Set up a reward system for your marketing and development teams to learn interdisciplinary skills with bonuses or time off.
Send marketers and developers to conferences together
Have some coders go to a marketing conference along with your marketing team. Do the same with a development conference. This keeps your whole team aware of what is going on in current events of marketing and coding that might directly affect the work they do. This also promotes bonding between the two groups.
Often, I find that developers have a general sense of good practice of SEO because solid site design is an essential tenet of SEO, but there is usually plenty of โlow hanging fruitโ (please pardon the โconsultant speakโ) they could implement to nudge you past your competitor. That knowledge could be easily obtained through an SEO conference or workshop (e.g. Search Marketing Expo or Traffic Control). More than anything, this helps the developers build a site that is technically correct from an SEO perspective as it is built, rather than what is all too often the case where a site is built, then checked by an SEO shortly before launch, only to find there are serious issues with the site. At that point the management has to make the choice to launch as planned with a suboptimal site, or to delay the planned launch.
Action Plan: Offer a reward for marketers or developers to go to a conference outside their discipline.
Take a lunch
Management guru Tom Peters suggests going out for lunch with people of different functions. He actually measures it as part of an evaluation for managers. How many lunches are they taking with people of different functions? Make it a metric discussed when considering them for promotion, a new project, or a raise. The way he reasons it is when you go out to lunch with a person you donโt normally interact with, suddenly they become a person. Youโll find out that you even have some things in common. They arenโt just โhead of marketingโ, they are โCynthiaโ, and Cynthia is much more approachable and easier to relate to than โhead of marketingโ is. Another great resource for this strategy is the book Never Eat Alone, by Keith Ferrazzi.
Action Plan: Encourage your teams to go out to lunch together. Designate a day of the week โInterdisciplinary Lunch Dayโ.
Take a personality test
This suggestion may seem flippant, but Iโm not talking about the type of quiz you see in your Facebook newsfeed where you find out which movie character you drive like or the type of dieter you are. Instead, Iโm referring to an in-depth personality assessment where you learn how your employees think, feel, and function. Believe it or not, providing the team with these personality insights can really make a difference in creating empathy in the workplace. Meyers-Briggs is industry standard and still a great option, but Dr. John Demartini also has a Values Determination Test that I highly recommend. His is based more on what each person considers important. When you can align your values to the project you are working on, youโll find that the team members are far more motivated to make a great product. When a whole teamโs values are aligned, magic happens.
Action Plan: Take the Demartini Value Determination test. If you are a manager, schedule a meeting with each of your team members to discuss their values and how to align them with team goals.
โLunch and learnโ sessions
Sometimes a free lunch is enough to get a group of people together, so what better cheap incentive for you than to get people together to learn a little bit of something that is out of their element. Get a person from the dev team to teach a few coding skills once a week, or try out a 2 week course of a more difficult topic. However, these should not be required, and they should not be info-heavy. Lunch can be a needed time for employees to unwind, and if they are expected to cram new skills in that period, they might not be interested, or they may burn out later in the day.
Action Plan: Offer a free lunch to any marketing staff interested in taking a lunchtime coding class.
Marketers and developers think/process information differently; of course theyโre going to butt heads. Helping them understand each other can make all the difference in the world to the effectiveness of the team, and perhaps even team morale. Cut out the communication barrier by getting them to work closer together, and see how closely your work depends on one another. Take the time to plan changes rather than rushing in without input from the other side. Have both sides involved in all stages of a project from planning to completion. It may slow the process somewhat, a hard sell at times in the first to market world, but in the end, a small delay will deliver a better product for your users, save time and money for the company, and youโll have a happier, more collaborative workforce.
