Rebuttal- How to get devs to implement SEO recommendations

This morning I read an article called “How to get developers to implement SEO recommendations”.

I was looking forward to it because I assumed it would be trying to solve a specific case of the more general problem of “how to get a team of people to work on something they don’t fully understand or buy into”, which is an interesting problem worth fixing.

I was left disappointed. I think Search Engine Land can and should do better. What follows is a list of my issues and some counter points. I will try and grab enough detail so as to clearly not be taking things out of context, but I would suggest you read the article first to get a good overall picture.

I was already cross by the third paragraph (which, given the current global context, is actually pretty far down the article!).

We all walk into projects hoping to discover an internal champion that can take the developers to lunch and buy them beers in hopes that our suggestions get turned into actions, but sometimes that champion doesn’t show up. In some cases, getting things done may require social engineering. In other cases, it just requires a degree in engineering.

• Funny enough developers actually want to do a good by the company, we don’t do work based on who wines and dines us.
• Anytime people link developers and beer together I cringe. It is such a toxic stereotype.
• People viewing development teams as people you have to “social engineer” helps to reinforce the negative stereotypes of developers, which is incredibly backwards.
• Most of the best developers I know don’t have an engineering degree. Whilst I agree there is often a communication gap between developers and some other departments, it is one that can be easily overcome.

Alderson-type developers are itching to implement your recommendations right away. That’s not because they necessarily care about ranking, but because they care about being good at what they do.

This developer type is attentive and will call you out on your b.s. if you don’t know what you’re talking about. So don’t come in with recommendations about asynchronous JavaScript without understanding how it works.

• Good developers should rarely be itching to implement. The best developers will consider the impact of suggestions, come up with a good solution and then implement.
• Dictating solutions to development teams is a surefire way to get sloppy results, communication needs to be around the problems and goals. Talking about asynchronous JavaScript regardless of how much you know about it is hardly useful if the better solution is to not use JavaScript for that section.

While we were explaining some of those recommendations, the developer was sitting there in the room, not taking notes. Rather, this gentleman was committing code as we were explaining what needed to be fixed. By the time the meeting was over, all of our high-value recommendations had been implemented.

• I’m sure that code was well tested and code reviewed before being deployed. Without any prior knowledge or run through of the changes being made that type of live coding is going to be a mess, it will solve for issues being talked about in the room without regard for the rest of the issues on the backlog or in the pipeline. I would suggest avoiding working with flashy developers. Unless that was their purpose in the meeting that seems like a pretty poor waste of time and energy.

Web development, primarily on the front end, gets more and more complicated with each passing day. One of the more valuable concepts that have been introduced in the past five years is task runners.

• Minor gripe but task runners have been about for way more than five years, node based ones are what they are referring to.
• All of the talk around task runners and looking into what can be done seems very much like putting the cart before the horse. If you know what the tech stack is then it makes a lot of sense to recommend potential helpers based on that, but if you aren’t sure or aren’t technical this seems like a rabbit hole not worth going down.

Do you know that Nginx does not employ an .htaccess file? If you don’t, you may suggest placing the 301 redirects there, and the developer may ignore everything else that you’re saying.

• The author isn’t working with developers in this case, he is working with fools. People that ignore other people in a workplace setting should be fired and professionals hired in their place. I’ve worked with some pretty terrible developers and none of them have ever heard something technically incorrect and so decided to ignore everything else.

Business cases and prioritization. This is perhaps the most valuable thing you can do to get buy-in up and down the organization, which leads to added pressure on the development team to get things done.

• I don’t know why you would think that a development team who don’t want to listen to marketers would want to listen to a suit telling them to do something. Have actual conversations with people and stop trying to “add pressure”.

Backlogs

The development team’s backlog is made up of tasks from a range of sources, this will include input from marketing departments, the security teams, project owners, HiPPOs (regrettably), and more.

It should be no surprise to anyone that often these tasks are at odds with each other. It also means that sometimes technical decisions made in good faith in order to solve the current set of problems make new recommendations harder to implement than the blog post you read on “how to implement x”.

Knowledge of SEO

During any sort of formal training web developers do not get taught SEO, which means our training is mostly self-taught.

As SEOs you know how much rubbish is out there about your industry, you know how many bad actors there are spouting all sorts of nonsense, and you know the reputation the industry has for being spammers. (I don’t agree, but the reputation is there)

Posts like this which characterise development teams as a hindrance, in fact they are the hardest problem in SEO;

No, the hardest problem in SEO is getting developers to actually execute recommendations.

Do absolutely nothing to help educate developers on why SEO is important or why time is of the essence when making these changes.

Conclusion

I will be the first to admit I love a gentle poke at marketers, and if this post by Search Engine Land was just a bit of a rant I wouldn’t be so annoyed, but this is a serious article that well meaning people will read and I think leave slightly more ill-informed about the issues facing communicating between teams.

I’ve actually written about this subject before in an article called Lazy Developers or Poor Communication (spoiler, it isn’t lazy developers).

Maybe their plan was they wanted links from dev blogs, in which case Search Engine Land should keep churning out this enraging content!