Hello 👋,
Welcome to the Monday morning ideas newsletter ☕️.
Every Monday morning, receive 3 ideas on how to work more effectively in product and dev teams.
To receive articles like this, please subscribe to The SEO Sprint 👇.
[Sponsor]
Boost Your SEO Rankings with the #1 Source for High-Quality
Backlinks! Do you need help to climb the Google rankings?
With dofollow.com, you'll gain access to high-quality backlinks from top sites like HubSpot, BigCommerce and 100s more.
Why choose dofollow.com?
High DR90+ Websites: Get backlinks from reputable sources that Google loves.
Pay-for-Performance: Only pay for the results you see.
No hidden fees.
Link Guarantee Policy: This means you can ensure your link will not disappear.
Client Success Stories: But don't take our word for it.
"The results with dofollow.com have been incredible. From organic traffic, we went from booking zero demos a month to now over 50 a month." – NectarHR
Read our free case study and start boosting your online presence today.
1) The Kernel of the Strategy
Strategy is hard to define. Or, is it?
Any good strategy is really just about identifying a challenge worth solving and finding a way to overcome it. Regardless of the industry or channel you work in.
But what makes a strategy good?
The best consultants and in-house folk I know always reference Good Strategy / Bad Strategy by Richard P. Rumelt.
In his book, he outlines that the kernel of any good strategy is made up of these three parts:
🩺 Diagnosis - A clear definition of a challenge holding the company back from its goal.
🗺️ Guiding policy - A clear approach to dealing with the challenge identified in the diagnosis.
👟 Actions - A set of coherent actions (resources, policies and tactics) to be carried out.
But how can we use this to get SEO projects executed?
The kernel of the strategy is always praised as a great framework to help structure any strategy (I use it all the time).
BUT many professionals skip over or miss a key element in the framework.
Defining a clear challenge worth solving.
Being clear about the problem you are trying to solve in the first place is important. It’s the cornerstone of any good SEO, business or product strategy.
Both product and development teams need to understand the problem you are trying to solve. So they can help build the right solution.
How do you identify the problem?
I use a problem statement. I’ve already written about this framework in a previous newsletter (see it here). But I’ve found using this writing exercise helps to be clear to both tech and business teams the problem we’re trying to overcome.
So, next time you are putting together a strategy. Try to identify the problem or challenge you want the company to overcome (use the problem statement framework).
Then make the problem you want to overcome clear to the rest of the business.
A great newsletter that goes into more detail about using the kernel of the strategy for SEO is the SEO MBA by Tom Critchlow 👇.
2) SEO Technical Debt Explained
Technical debt is a BIG blocker to SEO growth. But, what is it?
Ward Cunningham coined the technical “debt” metaphor. In a YouTube video, he defines the technical debt metaphor as:
“If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.”
- Ward Cunningham
Simplifying Ward’s definition. Technical debt is the result of building solutions or writing code without a proper understanding of what we are trying to build.
Instead of focusing on poorly written code (which is a small part of tech debt). Ward describes the original idea behind the debt metaphor as a disagreement between the development and business teams.
In his debt metaphor failing to align business and technical teams creates tech debt. And just like any financial loan the debt has interest. The interest rate (just like on a loan) results in debt building up over time.
The greater the misalignment amongst the team. The bigger the debt. The slower the development team.
It’s this misalignment which causes SEO growth to get blocked.
What does this debt metaphor have to do with getting SEO projects executed?
Technical SEO debt happens when SEO professionals aren’t part of business decisions.
The result is that developers build things without really understanding the requirements needed to help get websites crawled, indexed and ranked in search engines.
For example, moving a SaaS business website from WordPress to React.js will create a number of debt problems. WP has the advantage of plugins like Yoast and RankMath adding a lot of SEO features. Removing these features means they need to be migrated to the new website.
The SEO team needs to be involved when building the new website. Otherwise, technical SEO debt will start to mount up fast. And it will slow down the SEO growth as teams need to stop to pay off the debt.
So how can we reduce technical SEO debt?
In my experience reducing technical SEO debt is about focusing on:
〰️ Alignment - SEOs need to be part of the product and development team.
🗣️ Decisions - SEOs must be involved in decisions that impact the tech stack.
🌳 Planning - SEOs need to help provide clear SEO specifications for devs.
When an SEO team is part of the tech team and decisions then this helps to stop misalignment between development and business teams.
Providing clear requirements and building a shared understanding of SEO features helps developers fully understand what needs to be built. And plan accordingly.
I don’t have enough space to get into detail about each bullet point.
If you want to learn more about each topic I’ve written detailed newsletters around each topic:
〰️ Alignment —> Conway’s Law
🗣️ Decisions —> Shared Understanding
🌳 Planning —> Specification by Example
3) The Five Whys
Teams make mistakes all the time. But how can you help avoid making the same mistake twice?
Enter The Five Why’s technique.
The Five Whys is an investigation technique which tries to understand the root cause of a problem.
The technique gets its name from asking “Why?” five times and was developed by Taddchi Ohno in the Toyota Production System (later called Lean Manufacturing).
Eric Ries, author of The Lean Startup, states that the root cause of any technical problem is a human problem.
The example which is provided in his book focuses on a machine not working properly:
Why did the machine stop? (There was an overload and the fuse blew.)
Why was there an overload? (The bearing was not sufficiently lubricated.)
Why was it not lubricated? (The lubrication pump was not pumping sufficiently.)
Why was it not pumping sufficiently? (The shaft of the pump was worn and rattling.)
Why was the shaft worn out? (There was no strainer attached and metal scraps got in.)
How can you use The Five Whys to get projects executed?
The Five Whys can help your team avoid making big mistakes more than once.
It can be used for:
Identify a root cause problem in a team’s process.
Identify the root cause of the problem in team communication.
Identify a root cause problem in the team’s release plan.
Identify a root cause problem in the team’s goal setting.
Avoiding BIG risky mistakes helps avoid wasting time and resources. Which will help keep the team focused on building features which drive growth.
When trying to identify the root problem. I’d always make sure you do the following before asking The Five Whys framework:
🥅 Goals - Set clear goals to measure and identify a problem.
💼 Work - Dig in and understand the work that has caused the problem.
🔎 Identify - Clarify and identify the real problem from a range of issues.
👥 Align - Make sure you discuss and agree with your team to identify the root problem.
Once these have been established you can start asking why five times from the initial problem to the root cause. Doing this can help identify the root cause of the problem and put in processes or training to fix the root problem.
BUT be careful.
Never do The Five Whys on your own or with only certain members of the team. It will turn into the five blames. And anyone left out of the conversation will be blamed for the problem.
To avoid this always make sure you get everyone in the team in a room. Then start to ask the five whys.
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 helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.