🚀 Shipping Slow Changes Your SEO Strategy
“How often do you ship to production?” How asking your development team a simple question can change your SEO strategy.
A weekly newsletter that provides practical advice for SEOs on how to work with product and development teams.
If you want to help improve The SEO Sprint please feel free to leave feedback!
A simple question can tell you a lot about a development team.
“How often do you ship code to production?”
A product and engineering release cadence, shipping code to production, is the heartbeat of a company and can impact an SEO’s ability to get things done.
In this newsletter we’re going to talk about:
🔃 What is a release cadence?
💙 Shipping code is the heartbeat of a company
🤷 Why release cadence matters in SEO
🧮 How to calculate annual release cadence
📈 How shipping impacts your SEO strategy
🔃 What is a release cadence?
The release cadence is how often a product and development team releases code into production. This is part of release planning and as agreed upon between the development and product teams.
A release cadence can happen:
Daily
Weekly
Fortnightly
Monthly
Quarterly
Annually
The planning of releases and the release cadence depend on a number of different factors within an organisation. These factors include:
Team - The structure of teams and communication networks can impact releases.
Infrastructure - The technical complexity of your product can impact delivery.
Culture - Agile vs bureaucratic cultures can have a MASSIVE impact.
Cost - Deploying more frequently can be a large upfront investment for the business.
DeepCrawl Example
For example, at DeepCrawl the product and engineering team moved to a two-week release cadence. This required a lot of planning and work from the engineering team who had to set up CI/CD processes to test both staging and production environments.
A 2-week release cadence helped increase code output by +700% year-on-year AND I witnessed the positive impact it had on both the engineering and product teams.
💙 Shipping is a company’s heartbeat
The interesting thing about my experience at DeepCrawl is that it’s an example of what happens when an engineering culture shifts from a low-performance team to a high-performance team.
Luca over at Refactoring (engineering newsletter) splits defines these two team types as:
High-performance teams spend their time focusing on delivering features, solving customer problems and driving business results.
Low-performance teams spend their time fixing past releases, waiting too long for things to be released and dealing with technical debt.
What is the difference between these two teams?
Shipping fast and often ⚡.
A survey conducted from 2,000+ companies between 2013 and 2017 by Nicole Forsgren, Jez Humble and Gene Kim found that what separates elite engineering teams from average ones is mostly how fast and often they ship code.
Why does shipping fast create successful high performing elite teams?
Well, the greater the complexity of a feature or piece of functionality the longer it takes to ship.
This increases risk and cost for features. Until the feature or product is in the customer's hands there is a greater chance it will miss the mark and not solve a customer’s or user's problem.
This is why in 2013 Intercom famously wrote that shipping is your company’s heartbeat. It brings life to your team, product and customers.
Shipping fast often helps a business get feedback quicker and helps “steer” the business forward in the right direction.
🤷 Why release cadence matters in SEO
The release cadence of a development team (how often they ship code to production) can directly impact how much an SEO team can get done.
The survey showed that more than 50% of companies surveyed had average or poor-performing engineering teams.
This means that most SEO teams will be working with a development team that ships code every 1 - 4 weeks.
If we look at this from a macro point of view and plan release cadences over a 12-month period we can start to see the number of attempts you can get SEO recommendations implemented:
1 code release a day = 255
1 code release every week = 52
1 code release every 2 weeks = 24
1 code release every 4 weeks = 13
1 code release every 12 weeks = 4
I know many would argue that the release cadences are all over 12 months so it should equal the same amount of outputs. However, I know from experience that time spent on shipping code increases the complexity of a code release.
The longer it takes to push code the greater the chance that there is:
Scope creep – Specifications are complex which creates uncertainty on what is needed.
Blockers – More code means there is a greater chance 1 line of code will block the entire release.
Bugs – The greater the code the higher the chance that bugs are missed.
Also, the fewer code releases per year the more other teams will want their projects prioritised over others.
The overload of requests from other teams is that dev backlogs become bloated and noisy from all the requests. Unfortunately, this means that unless SEO is truly made a priority then tickets will be given less attention per code release.
🧮 How to calculate annual release cadence
It is important that SEOs ask a simple question when working with development teams:
How often do you ship to production?
Once you know the answer to this question you can do a quick calculation to understand just how many attempts you have to get SEO recommendations implemented.
The calculation is quite simple:
Number of weeks in the year / how often they ship code
For example, I’ve worked with different organisations that have different release cadences (usually called sprints or iterations in agile teams):
Using these figures you can roughly calculate how many attempts you have in a year:
DeepCrawl = 24 sprints
SaaS client = 52 sprints
Enterprise client = 13 sprints
I’d also take into consideration the time developers spend on holiday, sick or out for Christmas:
DeepCrawl =
2420 sprintsSaaS client =
5246 sprintsEnterprise client =
1310 sprints
This leaves you with the number of productive sprints or release cadences you have to work with.
I know the calculation is very simple and not completely accurate but it can quickly help you understand how many attempts you might have to get SEO recommendations implemented.
SEO Product Planning
For example, let’s say you have one quarter to release a complex feature like a new set of product-led page templates to capture traffic for a set of keywords (like Canva or Zapier).
If your developemant team release every 2 weeks, you actually only have 6 code releases to get something out.
This is how product teams plan. In release plans and time bugdets.
They look at the resource and time that they have and work backwords to get things done. Things move fast in product teams and you need to think in quarters or anually to keep on top of development teams who ship fast and often.
📈 How shipping impacts your SEO strategy
Any SEO team’s strategy, roadmap or audit needs to take into account the release cadence of a development team.
Let’s look at the two most common scenarios: high-performance and low-performance teams.
🚀 High-performance teams (1 - 2 weeks)
The development teams who ship code every week are going to allow SEOs more chances to get both big bets and smaller technical fixes implemented.
This continuous delivery opens up a number of other problems for SEO teams:
Ticket Planning - Product and engineering teams will need to work on a daily/weekly basis to discover and plan SEO tickets to get them ready before sprint planning.
Discovery planning - Getting more done means you’ll constantly need to do quarterly planning to make sure high-performing teams are releasing the right things.
Project Management - The SEO team will need to keep track of actions, owners and blockers for planning and discovery work to make sure SEO tickets are implemented.
Automated monitoring - The more code that is released the greater the chance of unexpected bugs, so it’s important SEOs run weekly automated crawls to monitor frequent code releases.
SEO QA Testing - The development team will need to be worked with to create an SEO QA process to catch defects before they hit production for critical SEO problems (noindex, canonical tags, etc.).
SaaS B2B Client
For example, I am currently working with a B2B SaaS business whose development team releases on a weekly basis.
I not only need to make sure that tickets are planned ahead of the sprint planning meetings but also need to make sure that I do continuous discovery work to feed the roadmap. The planning of the tickets requires me to spend time talking with tech, content and design leads on a weekly basis to make sure we’re aligned.
If planning and discovery work is delayed you miss your window of opportunity for it to be released. This isn’t a big deal as there is any release next week but it just means there are fewer attempts to drive the business forward.
🚛 Low-performance teams (4+ weeks)
The development teams that ship every 4+ weeks an SEO team will need to be more strategic in what bets they put forward to move the needle. If you fill the dev backlog up with too many “technical fixes” the dev team won’t be able to make room for big SEO bets that move the needle.
The monthly code releases open up a different set of (familiar to many) problems for SEO teams:
Buy-in - An SEO team will need to create a very strong business case to get sometimes the most basic SEO recommendations implemented.
Ruthlessly prioritise - The SEO team will need to really focus and prioritise their recommendations to make sure every release drives forward the SEO business.
Check feasibility - A low-performing team might be a sign of technical debt caused by past decisions, an SEO might need to make sure that their prioritised recommendations are feasible.
Chunk items - An SEO team might need to work with the development team to break down complex recommendations into small manageable items that can be implemented by the development team.
Do things that scale - An SEO team should think about recommendations that not only drive the business forward but also take work off the development team (devs love this!). This can be done by building functionality into a custom system that manages title tags at scale across your platform.
Invest in third-party tools - An SEO team should try to get investment into a third-party tool that also takes work off the development teams like SearchPilot or Similar.ai. These sorts of advanced tools allow SEO teams to make changes without the need for dev resources.
Ecommerce client
For example, I worked with an enterprise ecommerce client whose development team released every month. I did a technical SEO audit for them but as part of the onboarding process, I asked about their delivery process. They mentioned that they shipped the code every 4 weeks.
I took this into account when putting together a technical SEO strategy and highlighted to them that they needed to do 3 key pieces of work to drive more revenue from Google organic search. All of these initiatives required breaking down into smaller items which the devs could implement.
The team began to implement the items in each initiative over the course of 6 months and the ecommerce business began to see steady growth in both non-brand organic search traffic and revenue.
All because I asked a simple question: How often does your development team ship?
📌 Summary
Any SEO team working with a development or product team should be asking:
“How often do you ship to production?” - This question can quickly reveal the culture and problems that SEOs might face over the next 6 -12 months.
SEO strategy should consider shipping - SEO teams need to take into account the release cadence of a development team to get things done.
High-performance teams. - A development team that ships code in a day or every week can allow SEO teams to get big initiatives and small fixes implemented which drive a business forward.
Low-performance teams - A development team that ships code every 4+ weeks will most likely need to have initiatives ruthlessly prioritised to make each attempt count.
📚 Further Reading
Read: Shipping Fast Changes Your Life - A great read by Luca over at the Refactoring engineering newsletter on why shipping code fast separates elite development teams from average ones.
Read: Shipping is your company’s heartbeat - The article by Intercom on why shipping is the heartbeat of any company that relies on development resources to drive a business forward.
Read: It is time to fulfil the promise of CI/CD - A fantastic presentation by Charity Majors on why shipping code frequency using CI/CD can create elite development teams.
📋 Newsletter Feedback
How did I do this week?
If you enjoyed reading this article then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it useful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already then please consider subscribing to the newsletter.