8 Tips to work with Engineers and Developers in SEO
Having worked with multiple Product, Tech and Engineering teams over the years, here are some fundamentals to encourage quality collaboration
TL;DR
Building relationships and understanding workflows and who the right contacts are is essential in fostering good working processes
If you become a key point of contact for the tech teams, you’ll become an infinitely more valuable asset to the rest of the company
Bring engineers into a project early. It will almost certainly save you time in the long run
Appreciate their work. Say thanks afterwards, it goes a long way
Top tips for working with tech teams as an SEO
Whilst developers and engineers will always know more than you about how websites really work, it’s not their job to know what will add value. That’s yours.
In every company I’ve worked in, there has been a divide between developers and the rest of the office. Which, given how important developers are to everyone’s career (it’s true, like it or not) has always felt unusual to me.
The reason why this is so important for you is because anyone with competent technical knowledge you can ‘speak’ with the tech team becomes an infinitely more valuable asset to the company. Engineers are far more likely to come to you with questions if you make the effort.
Build relationships
I could rehash this point on every list of ‘how to work with x.’ Sure, you might be put off from trying to build relationships with tech teams based on the lazy stereotypes you read. But that’s your cross to bear. They almost certainly don’t want to work with you, but they still have to work with you.
You need to build a relationship(s) where sending the odd message asking for support, if you can help or any other query doesn’t get the cold shoulder.
Learn how to create tech-friendly tickets
The best thing you can do when working with tech teams is to be ultra-specific.
The h1 should be a size 18, h2 should be a size 16 etc
The button should be xx colour
Ensure the URLs are implemented with a trailing slash
Learning how to create tickets in an AGILE-friendly manner and following up with how we can support them in terms of testing and defining what success looks like for each ticket will help significantly.
This guide on creating quality tickets from Atlassian is a useful resource to help you get started. The below is a classic example of a ticket that highlights:
What the issue is (bug, improvement of new feature)
What the expected behaviour is (what would be classed as success)
Steps to reproduce (or acceptance criteria)
Top tip: create a template if one doesn’t exist that everyone is happy with and re-use it time after time to ensure consistency
Don’t be afraid to ask questions
You aren’t meant to know everything, but you are meant to ask the right questions. Site speed is an excellent example. You aren’t meant to know more than a developer about making a site faster; you are meant to understand the why behind individual initiatives.
Here is how I tend to approach site speed projects;
Review the page experience and Core Web Vitals report in Google Search Console
Group pages together suffering from the same issues
Run some individual performance reports using Lighthouse and Developer Tools to identify the primary speed demons (demons, in this case, used negatively)
Collate reports that identify the biggest issues relating to each of the four key speed metrics
Take this project to review with your site speed expert and review anything that looks out of place
Create an EPIC with multiple speed tickets, focusing on a series of quick wins and larger site improvement projects
Communication is everything
Being communicative doesn’t mean spamming engineers and developers every two minutes. It means understanding the severity of the situation and using the appropriate communication channels.
Emergency: An IRL conversation (perish the thought)
High-priority: Direct message
General issue: Email or just creating a ticket
Once your ticket has gone into a sprint, the easiest thing to do is to forget about it. Whilst you don’t want to bug the devs (devs really don’t like being pestered), you do want some kind of regular check-in, particularly on larger, more sprawling projects.
Top tip: If you have any questions or follow-ups you need to log them on JIRA. You’re going to want a paper trail and in the spirit of fostering good relationships, the tech team(s) will appreciate you making the effort and a paper trail is always a good thing.
Understand the bug/improvement/new feature way of working
Most high-quality tech teams will want to work towards a certain ratio of bugs, improvements and new features. Typically the teams I have worked with like us to work towards;
20% bugs
30% improvements
50% new features
I would say this is only feasible once you have reached a point of maturity at a company. Your aim should be to set out some working parameters around the ratio of bugs, improvements and new features you work towards. Inevitably there will be some bugs that are non-negotiable. It’s not perfect, but it’s a brilliant mindset to get into.
You can find out more about bugs and new features here.
Make an effort
Go out of your way to be supportive. Coding is challenging work and, dare I say it, not something that is given the love it deserves in all companies. Finding good developers is hard, so when it happens (you’ll know, trust me) make sure you make an effort. This manifests itself by;
The tickets you create: sizing, relevant detail
The support you give
QA testing
Your attention to detail
Process improvement suggestions
Size your tickets
Size your tickets and (if you have the power), try to ensure that everyone follows the same sizing process. You will be competing against other priorities and you must understand that you aren’t the only horse in the race. Consider how valuable SEO is to the business so you can argue your case when appropriate. Knowing when to push and when to cede comes with experience and will go a long way to creating good working relationships.
I like to use a combination of effort, impact and scale. Typically people score each out of five which gives each ticket a score out of 15. I think this undervalues impact, which I tend to score out of 10.
Remove ambiguity - help engineers understand the what and why
Being precise and specific is fundamental to working effectively with engineers. Be very explicit with what you are asking and discuss with them why it’s important. If you are unsure about certain details or think that features or improvements may change in the future then let stakeholders know.
Engineers are detail-oriented problem solvers. Ambiguity slows us down; the more blanks we have to fill in, the more likely we’ll end up with a final product that doesn’t make anyone happy.
Some tickets are so straightforward that this isn’t essential. But for certain projects, you’ll want their buy-in. Essential background information about what you’re suggesting, why the current implementation is a problem and what the solution is will go a long way in helping you stand out from the madding crowd.
Bring an engineer into the project early. This will almost certainly save you time and prevent you from sinking time and effort into something unfeasible or, at best, improbable.
Example - structured data revamp
We are currently working on revamping our structured data for two primary reasons;
Currently, both JSON-LD and microdata are present on every page, which sends conflicting signals
Our current markup has substantial missing, erroneous or downright wrong information across multiple types
This is such an important project to get the tech team on side for. We aren’t asking them for an insignificant piece of work and it has to add value. More value than the combined resource(s) that will go into the project.
The project requires;
Update to JSON-LD markup
Addition of multiple information fields
Addition of multiple new page types in JSON
Parsing of relevant microdata
Removal of all microdata
Projects like this on sprawling, legacy sites have a habit of getting out of hand… So when constructing it, we have tackled it like so;
Project type: improvement
Project urgency: low-medium. A simple email and ticket solution is more than adequate
Ticket size: impact (7), effort (3/4 - one to discuss with the engineer) and scale (4). This gives an overall score of 14 or 15.
Project size: medium-high
Variables: types of structured data required (essential and nice-to-have), removal of microdata
Removing ambiguity: we have established we want to move the markup to JSON-LD, have pre-built every type of markup required, established page rules around when each schema type should be present