How SEOs can successfully collaborate with web developers

While some search marketers may face challenges when collaborating with developers unfamiliar with SEO, it’s not a universal experience.

In my decade-plus in SEO, I’ve worked with some of the most enthusiastic front- and back-end developers about implementing “SEO” tickets. 

Some SEOs seem to have fallen prey to survivor bias by focusing on problems rather than solutions.

In reality, SEOs and developers share a desire for respect and expertise acknowledgment rather than quick internet solutions. My past frustrations with developers were often my own shortcomings, not theirs.

In this article, I’ll go through with you a few things on how to collaborate well with developers, including: 

• My now standard operating procedure with developers, which could/should be your new baseline expectation.
• A few less common situations where you’re able to build trust with developers.

Working with developers: The bare minimum

My bare minimum for working with developers requires: 

• Going in with a desired end state rather than a specific solution.
• Being curious rather than accusatory.
• Following their process and providing all the information they need to get the job done or tell me why they can’t do it.
• Speak well about them behind their back, and share their success up and out.

Montse Cano summarizes this beautifully and expands on where she felt these issues originated: 

• “[in] the notion that engineering teams exist to do what you wanted them to do, and that they did so by simply pressing a button that would take them 2 minutes.”
• “In other words, no one understood what they did and I could tell they didn’t understand/ know what marketing and digital truly do either.” 

Part of our job, then, as SEOs, is to break down those walls and work towards understanding each other, rather than each of us assuming what we’re asking for or requesting to be implemented is entirely obvious. 

Going in with a desired end state should include examples and thoroughness. If you want a specific schema markup implemented, show what the end state of that schema should look like for your website. 

If you know there’s a weird requirement, take time to explain the why behind it. 

Being curious and going in with a desired end state means being an active listener and not dictating to your team members.

Unless you are in the code day-in-day-out as much as they are (and few, if any, SEOs can say that), they know the code better than you. Respect that. 

And once you’re able to work together and get good things done, share it with the metrics that matter to your business – revenue or otherwise.

Speak nicely about them when they aren’t a part of the conversation and when they are. 

Dig deeper: Learn to think like an SEO developer

---

---

Building trust when working with developers

If the new bare minimum I described above is still leaving you short when it comes to mutual respect and the ability to get stuff done with developers, here are a few less common ways to consider building up that rapport with developers.

Start with an ‘SEO task’ that shares their KPIs

This is an important one because it serves multiple purposes. It will get your job done, and it will make them look good, potentially pushing through their bonus for the year. 

In the current environment, you’ll find many developers have a KPI around site speed. This is fantastic because refactoring scripts, debugging them, windowing them or otherwise editing them is not for the faint of heart and usually takes dedicated teams a long period of time to execute.

So jump on the bandwagon and speak to their product (or project) owner about what their pipeline looks like for addressing site speed. If they have one, add your revenue or impact projections into the ticket, and include your two cents on the impact on the business.

If a part of the site speed or page weight management is around third-party snippets, they may not know who “owns” the snippet they’re making changes to, so be prepared to help out and do some legwork, asking around who does.  

Finally, if there are missing tickets, add them to the queue and do it properly. Continue to add clear and specific examples and documentation.  

20% time projects

Let’s all be honest here. We all want to work on the fun stuff. Assuming you aren’t completely slammed and have time to work on these projects, work closely with your developers to do so.

This could be something like a: 

• Product wizard.
• Interactive article (like the one on F1 car design from The New York Times).
• Wishlist creator.

Projects like these are great opportunities to work together more frequently and have more creative brainstorming sessions, which allow each of you to see the other’s expertise.

Plus, as The New York Times said in their leaked digital strategy way back in 2014: 

“‘We have a tendency to pour resources into big one-time projects and work through the one-time fixes needed to create them and overlook the less glamorous work of creating tools, templates and permanent fixes that cumulatively can have a bigger impact by saving our digital journalists time and elevating the whole report. We greatly undervalue replicability’”

These 20% projects might also be the internal tools or the internal framework to make either or both of your lives easier. Something like a Python script that hooks into Google Sheets and the Knowledge Graph API to classify article topics or another bit of code to make analysis on either or both sides easier.

Intrinsically, then, many times, these 20% projects will highlight the hard work of the person who built it and give the company the ability to replicate that work more than it gives credit and kudos to the person who came up with the idea (which is what you, as the person who came up with the idea, wants). 

Uplift your developers and give them credit for their hard work, just as you would expect for yourself. 

Learn together

The more time you spend with developers, the more likely you are to be able to find ways of working. If you aren’t an SEO lucky enough to be placed within the development team, you will have to manufacture some of this time together.

Enter: learning. 

Often, corporate learning, even post-COVID, involves in-person half-day or day-long workshops. It’s manufactured closeness, yes, but more often than not, it leads to genuinely getting along and understanding folks a bit better. 

To get SEOs and developers in the same room, an easy workshop would be user experience, in my opinion. 

Both teams will benefit from the training (and again, both teams may have personal “learning” KPIs – I know I did at my last enterprise-level job), and you’ll both be able to learn from each other because you’ll be coming at the concept with different perspectives and areas of expertise. 

Dig deeper: How to use SEO education for stakeholder management

What it takes to work well with developers

Working well with developers is about going in with a truly agile mindset: 

• Be willing to learn and be flexible. 
• Acknowledge and listen to their expertise and suggestions.
• Thorough documentation and patience with communication and expectation-setting.

Living in Australia, when struggling to connect with developers or colleagues, I prefer meeting them at the nearest bar, sitting in the sun, and talking it out. 

Who knows, they might be having a bad day or dealing with something in their personal lives. At the end of the day, everyone deserves to be treated like their own person rather than a means to an end.