The SEO Sprint is a fortnightly newsletter that provides tips, guidance and advice on Product and Agile Thinking for SEOs who work with developers.

Subscribe now

This week’s newsletter is going to be something a little different.

In March 2022 I interviewed 15 in-house SEOs with the goal of how they work and get things done with development teams to get a better understanding of the audience for my SEO Product Ownership course.

After completing the interviews and analysing the qualitative data from my notes I realised there were a lot of trends, lessons and details from the 20+ hours of interviews.

I want to share the top 5 insights from the analysis of these interviews.

I can’t share all of the details or name companies from the conversations. However, I hope these insights can help anyone who wants to know how others work with developers and product teams.

A Quick Thank you
I just want to say thank you to those in-house SEOs who spent time talking and discussing working with developement teams. I really enjoyed it!

#1 - Leadership Buy-in 💰

All in-house SEOs highlighted that getting buy-in from leadership is critical to getting SEO projects implemented by development teams.

I did make a note that many in-house SEOs I spoke to who managed to get things done reported to the senior executive at the company or leadership who understood the importance of SEO.

The buy-in from leadership helps to access the budget, resources and specialists in an organisation needed to complete SEO projects.

This doesn’t mean that these SEOs can submit whatever they wanted to the dev backlog. All SEOs I interviewed understood that just like any other technical project their SEO initiatives had to show ROI or value for the business before they were added to the dev backlog.

What was interesting was how different in-house SEOs used leadership buy-in to get things done:

Resource access: Engineering team made room for SEO projects in backlog.
Roadmap sign-off: The SEO roadmap for the next 3-4 months is signed off.
Independent teams: Get sign-off to create and lead SEO/Dev squad (see below).
SEO QA: Investment in tools to bridge the gap between SEO and QA.
Education: Get dev, product and content teams bought into SEO training.

Note
Tom Critchlow over at the SEO MBA has created a course on Executive Presence on how to get leadership to buy into SEO.

#2 - Team Structure and Culture 🎬

The other clear trend from the interviews was that the company culture and team structure were also critical for SEOs to get things implemented by the development team.

There are two key types of cultures in business according to agile literature:

Bureaucratic cultures
Agile cultures

Bureaucratic Culture

What was interesting is that those who found it difficult to get things done (compared to others I interviewed) with development teams worked in organisations with bureaucratic cultures.

These types of organisations have the following characteristics:

Siloed teams: Teams work independently from one another and there is little interaction (can only discuss things through a process).
Instructions: The teams and leadership pass on instructions to one another with no clear vision or strategy (limited discussions and testing ideas).
Outputs > Outcomes: The company focus on releasing “features” not solving customer problems (or testing ideas).
Bureaucracy: The middle management focuses on politics.
Big bang releases: The company’s release cadence is a lot longer (3-6 months) and once features are released they are never improved upon.

The trend in the data suggested that these bureaucratic cultures were usually in large well established organisations. Although small or SaaS businesses can suffer from this culture as well.

In enterprise SEO everyone discusses the “SEO tactics” to get things done but rarely does anyone discuss the impact of culture or team structure.

One of the key issues I noticed when interviewing SEOs in an organisation with the characteristics of a bureaucratic culture is how the SEO team is structured within the business.

There are two examples that came up a lot in the interviews:

Collaboration Gap
Resource Struggle

Collaboration Gap

The SEO Collaboration Gap caused by bureaucratic culture

For many in-house SEOs (and SEO Consultants), they need to submit a ticket through a long process, through different teams (usually product and project management) and never actually speak to a developer.

The “SEO Zone” is left on the periphery of the product and engineering team - with no input or little access to those who make the decisions.

This process and culture create a very large “collaboration gap” between the SEO team and the developers who are implementing the recommendations. In fact, the SEO might never speak to the devs who implement the ticket.

This sort of team structure creates:

Defects/bugs in releases
SEOs to be unaware that the change was released
The requirements from the tickets are missed as people who are not aware of SEO sign off on tickets

Resource Struggle

Other in-house SEOs “struggle and compete” with other teams to submit tickets to the development backlog.

These tickets are prioritised with project management based on mid-management backdoor dealings rather than an actual business priority. The reason for tickets not being implemented is never explained.

This sort of team structure creates:

Priority tickets to not be released (for example SEO projects)
Teams to compete for resources for projects, rather than working together
Developers are focused on "task completion” and not on solving problems

Note
I want to make it clear that it is possible the get things done in an bureaucratic organisation. The interviews have shown it’s definatly possible.
There was a clear trend in the interviews that certain organisations were harder to get things done if a company had bureaucratic culture characteristics.

(Hybrid) Agile Culture

In contrast, in-house SEOs who had success in getting things done I noticed worked in an organisation with the characteristics of a mature agile culture or a hybrid agile culture.

Agile culture reality in most organisations that call themselves “Agile”

These types of organisations have the following characteristics:

Independent cross-functional teams: Teams are made up of specialists who are grouped into squads who can independently solve problems.
Vision and strategy: The leadership team provide consistent vision, strategy and goals for teams to build roadmaps around (but still hand down instructions).
Outcomes > Outputs: The squads are focused on solving business and customer problems (not just “making changes” to the website).
Iterations: The teams release iteratively and incrementally to efficiently learn what will solve an outcome.
Continuous learning: The culture and mindset of the teams are to continuously learn through experimentation and customer feedback.

Many businesses over the last few years are trying to “become agile” but what is happening is that you get this hybrid agile culture model.

The engineering and product teams have an agile micro-culture but the rest of the business is still stuck in bureaucratic culture. It is the reality of many agile businesses.

This hybrid agile model allows SEO teams to get things done because they are part of the technical team. The culture and team structure allow SEOs to be part of the decision making process.

There are two examples that came up a lot in the interviews:

The SEO Squad Model
The SEO Product Specialist Model

The SEO Squad Model

The squad or tribe team structure was made popular by The Spotify Model.

A small group of SEOs in the interview actually led a group of developers. The squad was made up of front-end and back-end developers who were led by an SEO Product Specialist.

The SEO specialist acted as the Product Manager/Product Owner in the squad. They owned the team backlog, defined the projects and user stories the team worked on and created the SEO strategy/team roadmap for management.

It is in these team structures where SEOs could really get things done.

The squad was independent, self-organised and left to solve problems however they wanted. The culture of the engineering team meant that the squads used 2-week sprints to make incremental and iterative releases.

The SEOs would work with developers on a daily basis to break down projects into release slices to get them completed more efficiently. Also, if needed the SEO specialist could pull in other resources (UX design, CRO, etc.) if needed to get projects completed.

What was interesting was that these squads didn’t just solve “SEO problems” but other website related issues around CRO, UX and content.

It is important to note that the SEOs who had a squad of developers weren’t handed it.

They had to create a business case, get buy-in and tell leadership exactly how they wanted to work. They then had to continuously earn and develop confidence in the team structure.

The SEO squad is the best way to get things done but from the experience of leading squads it opens up an entirely new set of problems in managing a team (but that’s another newsletter).

SEO Product Team Structure

The SEO team is part of the product and engineering team.

Once the SEO initiatives are signed off by higher management the projects “slot” into the team that works on a certain section of the website or system. The SEO specialist talks directly to the developer or Product Manager who carried out the work.

The SEO team or specialist usually directly reports to the Head of Product or Chief Technology Officer (CTO) who was an advocate for the SEO channel.

All SEO initiatives are prioritised and weighted just like any other project in the SEO/Engineering team. What was interesting from the interviews was that those SEOs who were part of the product/engineering team completely understood why their projects were not implemented (“Not now” rather than flat out “No”).

The SEO Product team structure means that SEOs immersed themselves in the technical culture and processes of product/engineering.

They can quickly understand engineering and product rituals around releases, the processes the team go through and who they needed to speak to resolve issues.

This team structure doesn’t mean there aren’t problems between SEO, product and development teams but it does mean SEOs are able to speak with teams who make technical decisions.

#3 - Clear Documentation 📃

A clear trend from in-house SEOs who work with developers was the importance of technical briefs to explain the WHY, WHAT and HOW to developers.

Although many talks about user stories and epics, when you’re continuously working with developers adding every idea to large lists of dev tasks can become very unmanageable (SEO backlog management).

The other issue is that user stories or tickets can become lost in a sea of tickets or not well explain the WHY behind a feature request to a dev team.

Instead of adding new user stories to dev backlogs, it seems many in-house SEO specialists generally create three types of artefacts to help get buy-in from developers and explain the WHY behind the features.

Note: In engineering the term artefact is used for any supporting documentation that help developers build the feature or functionaly you made up in your head.

These document types can be split into three types:

Opportunity brief: This 1-2 page document explains the WHY behind the requested feature, fix or change to the website. For example ROI analysis, forecast model or user experience data.
Technical requirements: This 1-2 page document lists the requirements(the WHAT) that the developers must meet for the project to be marked as “done”. It is from this that developers can create user stories.
Visualisation: This artefact explains to developers HOW you’d like the output to look either visually or in the code. For example prototypes, designs or code outputs (e.g. schema.org markup).

Note on Visualisation artefacts
Tom Critchlow over at the SEO MBA talked about the “visual revolution” and how other teams use visualization in their work.
It wasn’t picked up as much as his other newsletters in terms of comments or likes but I cannot stress enough the importance of tools that help you visualise a request when working with developers.
In fact I use visulazation tools (Miro and Figma) more than any other tool to communicate ideas, collaborate and slice down projects into smaller releases.

All of these documents together can be used to help clearly communicate to developers exactly what you want them to do and why they should be doing it.

Once the idea or project is signed off the acceptance criteria are then turned into user stories and Epics (either by the product team, project managers or the SEO Product Lead themselves).

#4 - Conversations over Documentation 💬

One of the clearest trends from the interview data was in-house SEO and developer collaboration increased the chance the ticket was implemented.

There were two key insights from the interviews:

SEO Conversation over documentation
SEO Documentation over collaboration

Conversation over documentation vs Documentation over collaboration

SEO Conversations over documentation

I asked the SEO to take me through an example of a project that had been successfully implemented by the development team.

The answer always started with: collaboration and discussion with the dev team.

The collaboration and interaction that the in-house SEOs had with developers were direct conversations, which included:

Video calls
Phone Calls
Face-to-face meetings

These conversations and interactions helped in-house SEOs get things done by:

Breaking down ideas: Speaking to developers helped SEOs break down tickets into smaller but feasible release slices.
Clarifying feasibility: Speaking to a developer can quickly highlight the feasibility of an idea or clarify if your assumptions on tech are correct.
Reducing bugs: Directly speaking with developers helped to clarify rules around tickets and allowed devs to ask questions if uncertain.
Removing blockers: A frank or difficult conversation with a developer helped to unblock a ticket that was being pushed back.
Solving a complex problem: SEO and developers work together to debug and investigate an issue to identify the next steps.

This insight was not surprising, the impact of collaboration and interaction on “getting things done” has been well documented over the last decade in the product and engineering community.

SEO Documentation Over Conversations

In contrast, when I asked each SEO to provide an example where the development team didn’t implement a ticket or project the trend was quite clear.

The process favoured documentation over conversation.

The documentation types varied by can be grouped into the following categories:

Ticketing system: Submitting tickets without discussion with developers or using the comment section to have long debates.
Requirement Process: Project management process where SEO “inputted” requirements in a template but never directly speak to developers.
External Dev agencies: The company use an external dev agency that is not accessible to the SEO (or isn’t clear who is the owner).

The issue that many SEOs face only using documentation is that there is usually:

A) Too much to build in the instructions,
B) You need to write all the “requirements” up front, and
C) The person who reads the documentation says they “get it” but they don’t

All of these problems with documentation usually cause SEOs to face:

Bugs/defects: The dev doesn’t implement the “instructions” correctly.
Large projects: The idea from the SEO is too large to implement in the doc.
Poor feasibility: The idea is not in line with how the tech stack works.

The SEO documentation is meant to help recall conversations and requirements, not replace conversations.

The trend was quite clear from the interviews, relying only on documentation to communicate your recommendations is less effective than a conversation.

Note
Whether you are in a bureaucratic or agile culture will impact on your ability to discuss and interact with developers frequently.
The ability for an SEO to even get close to the developement team will depend on the organisation culture, team structure and even the developer mindset. Although that didn’t stop some SEOs from picking up the phone and speaking to developers.
Regardless of the culture or team structure the trend was clear: An SEOs ability to have hard conversations (or just interact with devs) increased the likelyhood that a ticket/project would be implemented correctly.

#5 - Develop Developer Partnerships 🎲

The last lesson and insight from the interviews is my favourite.

All in-house SEOs who got things done with development teams all had the same attitude towards their developers: they viewed them as people, not tasks.

This might seem an odd thing to say but it was clear from the interviews that in-house SEOs who got things done formed a partnership with their development team.

They didn’t just send a task down the line and expect it to be implemented, they understood the importance of getting to know development teams.

Those in-house SEOs highlighted a number of benefits of forming partnerships with development teams including:

Trust: The partnership helped build trust and phycological safety between SEOs and the development team (studies show this is the no. 1 factor for effective teams).
Collaboration: The partnership helped SEO and developers collaborate on projects which helped make sure projects were feasible, usable and valuable.
Communicate priorities: The partnership allows the SEO to communicate priorities quickly to the dev team when things change (and they will).
Avoid miscommunication: The partnership helps the SEO educate developers on how SEO works and what they are trying to achieve.
Technology immersion: The partnership helps SEOs get a better understanding of the technology stack (which can help them make strategic decisions in their roadmap).

The idea of Partnership models in business isn’t new but studies have found that forming partnerships with teammates is key to effective teams getting things done.

There are a number of ways to form a partnership with the development team and move outside the usual “transactional” relationship, including:

Being social: SEOs socially engage with the development team both in and outside work (grab a coffee, get lunch, play poker or DND (just me?))
Supporting and helping dev projects: SEOs help get development projects signed off or support the dev team where there is value.
Getting dev feedback early in discovery: SEOs get developers involved early in the initiative to make sure the idea is feasible (and get feedback).
Provide meaning: SEOs provide a clear explanation to developers on why a project is important and how it helps users.
Give feedback: SEOs provide feedback to developers on the performance of the initiative.

If you want to get things done with the development team, then the advice is clear: treat them like people and not like a task.

Note
Just like the Conversation over documentation lesson, the culture, team structure and developer mindset will impact how you can form developer partnerships.
There were some situations for SEOs in certain organisations where this was very difficult (working from home and teams were in different countries).

📌Summary

So, there you have it 5 lessons and insights from interview notes for 15 in-house SEOs.

To recap:

Leadership buy-in: Getting buy-in from leadership is key.
Team structure and culture: Where the SEO team is positioned in the organisation structure and the culture of the company is critical.
Clear Documentation: Creating clear documentation that answers the WHY, WHAT and HOW.
Documentation over conversations: Interacting and discussing your recommendation with developers is critical to getting them implemented.
Develop Developer Partnerships: Forming a business partnership with developers is critical to effective SEO campaigns.

The SEO Sprint

SEO & Devs: 5 Lessons from in-house