🔼 Business Partnership Pyramid
A framework to measure trust levels between SEO & dev teams
As a discipline, SEO treads on the toes of other teams.
The result is that SEOs can be rejected by the development, design and product team without even realizing it.
Just like any product manager, SEOs need to be able to build and forge partnerships with developers and individuals in a company to get things done.
I’ve learned these “collaboration skills” through observation, experience and getting things completely wrong. However, for other SEOs needing to learn how to build effective partnerships, this isn’t useful (or practical).
As SEOs, unless we have experience with the right team, we don’t have a way to measure “trust” between product, dev or design partners.
This is why I created the Business Partnership Pyramid.
In this newsletter, we are going to cover the following:
🔄 The partnership principle
😠 The reality of working in tech teams
🔋 Effective teams are built on trust
🔼 Business Partnership Pyramid
🧗 Tips for Climbing the Partnership Pyramid
🏛️ Company Culture vs Team Culture
Audisto - Hreflang tag testing tool
[Sponsor]
Before we jump into the newsletter, I wanted to promote Audisto.
Having trouble debugging hreflang and document languages?
Broken hreflang groups result in URLs not ranking within the designated country search index. Identifying the underlying problems requires to analyze hreflang across multiple sources and to compute the validity of the complete hreflang group - not just a single page.
Audisto provides an industry leading hreflang analysis capable to analyze complex hreflang groups based on a combination of data extracted from all hreflang sources (HTML head, HTTP header and XML sitemaps). This includes enhanced hreflang link graph exploration and debugging capabilities. The Audisto Crawler is suitable for large enterprise projects and can validate hreflang groups across multiple domains.
Learn how to debug your hreflang and localization
🔄 The partnership principle
Business and development team relationships are always strained.
Both play an important role in solving business and customer problems:
Business teams - Identify problems for the dev team that need to bed solved.
Development teams - Develop solutions to solve problems constantly.
From my time working with, and at, different organisations, I’ve noticed that there is an ongoing partnership between these two groups.
I call this the partnership principle.
The business teams (marketing, product, SEO, etc.) understand the target audience, identify impactful problems and brief the developers on these viable problems.
Meanwhile, the development team (engineers, UX designers, QA, etc.) are tasked with creating scalable and feasible solutions and working with business teams to ensure the solution meets the brief.
😠 The reality of working in tech teams
In reality, the partnership between these two groups is always strained.
Companies constantly jump from one problem to the next, and business teams don’t provide great briefs to development teams on impactful problems.
In development teams, it can be just as bad.
They over-engineer solutions using the latest technology that doesn’t solve the customer's problem that creates unnecessary problems. In extreme cases, I’ve even seen tech teams hold businesses to ransom and refuse to change the tech stack.
The constant strain between these two stakeholders within a business can cause delivery delays, poor-performing products or cause entire businesses to fail.
So, how can these two teams work effectively with each other? How can the partnership principle stay balanced so that teams can get things done?
The answer might surprise you.
🔋 Effective teams are built on trust
In 2015 Google conducted a study, code-named Project Aristotle, on 180+ teams at the company to answer a simple question: What makes an effective team?
The answer surprised them.
They hypothesised that effective teams would comprise individuals with a perfect mix of skills. When they analysed the qualitative data, they discovered they had been dead wrong.
What they found was that:
“Who is on a team matters less than how the team members interact, structure their work, and view their contributions.”
- Google Rework Study
The team that conducted the study found 5 key dynamics that make up an effective team:
Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Dependability: Can we count on each other to do high-quality work on time?
Structure & clarity: Are goals, roles, and execution plans on our team clear?
Meaning of work: Are we working on something that is personally important for each of us?
Impact of Work: Do we fundamentally believe that the work we’re doing matters?
The study highlighted that the most important factor in creating effective teams is psychological safety. In other words, how much the team trusted each other.
🦸 Trust Powers Team Collaboration
I’ve experienced this “trust” factor in action while working in multi-disciplinary teams. Both in-house as a product manager and working with client teams.
I quickly learned that it’s trust that powers team collaboration.
It’s imperative you learn to build partnerships when you work with other technical and business specialists. This partnership is built on a foundation of trust.
This trust factor means that the team must:
✅ Trust the product manager is solving the right problems
✅ Trust the developers are building the right solutions
✅ Trust the UX designer is usable for a great experience
This trust allows teams to collaborate, continuously discuss problems and, most importantly, get things done.
For example, when working closely with design and development partners on projects, it is critical trust is built to do the level of discovery work needed to figure out complex projects (like the one below).
If anyone in the triad team structure began to behave in a way that depleted the trust between each team member, then work would begin to slow and potentially even stop.
What I’ve observed and learned is that it doesn’t take much to erode trust between teams in an organisation. This is particularly true for SEOs who have just joined a company or have signed on to a new client.
🆚 SEO vs Everyone Else
As a discipline, SEO treads on the toes of other teams.
We audit, inspect and pull apart the work of other teams, which means we can immediately act in a way that depletes and drains trust. The result is that SEOs can be rejected by the development, design and product team without even realizing it.
They’re not an “effective team” player.
Just like any product manager, SEOs need to be able to build and forge partnerships with developers and individuals in a company to get things done. We need to make sure we build trust and create environments to work in effective teams.
For example, it took me 2-3 months of weekly calls with a senior developer to build up enough trust to be seen as a “partner” and someone who could help the team get higher-effort initiatives implemented (which also happened to alignw with SEO 😉).
These initiatives included:
⚡ Migration to a faster JS framework
📄 New content hub architecture
🧭 New navigation redisign
All of these initiatives took time and planning to be implemented, but it was trust that powers the collaboration between myself, the dev and the designer.
This means that in each meeting and communication I am always conscious that my behaviour can drain or charge the trust batteries of the team.
It is the continous collaboration with the developer, UX designer and content partners that get things done.
I’ve learned these “collaboration skills” through observation, experience and getting things completely wrong. However, for other SEOs needing to learn how to build effective partnerships, this isn’t useful (or practical).
As SEOs, unless we have experience with the right team, we don’t have a way to measure “trust” between product, dev or design partners.
This is why I created the Business Partnership Pyramid.
🔼 Business Partnership Pyramid
The Business Partnership Pyramid is a framework to help SEO teams measure the “trust” between themselves and the tech team.
The pyramid represents a hierarchy of trust. An SEO professional needs to work on moving up the pyramid gradually by proactively engaging with the development team. Each level of trust is built on top of the previous one.
As the trust between SEO and development teams grows, it powers collaboration and allows the SEO professional to get things done faster.
The framework itself is broken down into six levels, which represent the amount of interaction between the SEO, product and development teams.
🏴☠️ No Trust: No interaction between the dev or SEO.
📶 Networking: The basic level of interaction with the dev and product team.
🛒 Transactional: SEO and technical teams interact but only to allocate tasks.
🧠 Credibility: SEOs proactively work with teams to add value.
🤝 Relationship: SEOs are asked to collaborate with teams on initiatives.
🚀 Partnership: SEOs are part of the day-to-day decisions within the team.
📏 How to Measure Trust Levels
Measuring trust in a professional environment is impossible (unless you’re an empath).
However, I’ve observed a pattern across multi-disciplinary teams when individuals trust each other. They are happy to talk and join meetings. If team members don’t trust you, they will actively avoid engaging.
This means that I believe you can measure trust levels by the frequency of collaboration. The more SEO professionals speak to developers and get invited to important meetings, the greater the trust levels between these two stakeholders.
I’ve given some examples of what the frequency of collaboration looks like for each level in the pyramid:
🏴☠️ No Trust: No interaction between SEO and development team.
📶 Networking: Speak to developers every 3-6 months.
🛒 Transactional: Negotiate tickets with developers every 2-4 weeks.
🧠 Credibility: Proactively talk to developers only on a weekly basis.
🤝 Relationship: The tech team proactively seek out SEOs on a weekly basis.
🚀 Partnership: The SEO is embedded in the tech team communications.
🔄 Building partnerships is continuous
Establishing trust with anyone is a gradual process. It builds over time as scepticism is overcome, individuals get used to working with you, and then you can make further requests or asks.
This means you can’t just jump from No Trust to Partnership in a week. You must proactively work with the team over weeks and months to build trust.
Also, remember that trust can fluctuate from one quarter to the next based on your interactions. Just because you worked with them 3 months ago, doesn’t necessarily mean you will start back where you were.
🥅 Business Partnership Pyramid Goal
The framework's goal is simple: Climb the pyramid.
Easy right?!
Yeah, I know; if it were that simple to build trust, everyone would do it. The reality is that not every SEO professional needs to climb all the way to the top of the pyramid. For example:
Agency SEO - In an agency, you don’t have the time to build a partnership with clients’ development teams, so settling for credibility is enough to implement priority recommendations.
Independent SEO Consultant - As a consultant, you might work for a client whose dev agency only allows them 1 call a week, which means that you can only really get to transition.
Enterprise SEO Manager - If you work in-house and are in charge of an enterprise marketplace website, then you really do need to reach the partner level within the pyramid framework.
Remember, the Business Partnership Pyramid framework is designed to help you understand the hierarchy of trust, identify where you are and try and gradually build from there.
🧗 Tips for Climbing the Partnership Pyramid
This newsletter is already getting too long, and I could write a lot of tips for building trust with developers.
Instead, below are 5 tips to get you started on climbing the Business Partnership Pyramid.
Tip #1 - Be proactive in communicating
The no.1 tip for building trust and partnerships with tech teams is being proactive.
The problem is that every website is constrained by the communication structure of the team that built it. So, if SEO is outside of that communication structure, then it will reflect on the website.
The key issue is that many product and development teams are too busy delivering the work to focus on SEO.
So you must be proactive in reorganising the communication structure.
This is especially important at the start of any SEO project or if you’ve just joined a company. It is a natural “refresh” for the company, so it is important to build in the habits early.
When first speaking with developers and product teams, ask:
Can you take me through the tech stack and setup?
What can be implemented on a page level vs a global level?
What new functionality needs to be added to manage content at scale?
What is currently a priority for them?
What is a priority on the roadmap for the next 6-12 months?
What are your processes for getting projects delivered?
What is your process for creating tickets?
All of these questions signal that you are not just interested in SEO but also in how they work and what they are working on.
You also need to be proactive and persistent when working with tech teams. Keep joining the right meetings, helping other teams get things implemented (not just SEO) and learning to align SEO with prioritised projects they are working on.
If you want to read more about Conway’s Law in SEO, check out the newsletter for more details 👇.
Tip #2 - Ruthlessly prioritise
The reality is that development teamwork is prioritised by the business.
As a PM at DeepCrawl, I constantly have to prioritise requests from business stakeholders ruthlessly to make sure we can deliver prioritised projects on time.
Many requests are rejected because they can’t answer these three basic questions:
Impact - Why should the team work on it?
Specs - What is the agreed specification?
Estimation - How long will it take the team?
Now as an SEO professional working in tech teams, I understand the unspoken rule of ruthlessly prioritising the requests I send to the development team.
Flooding them with SEO recommendations that don’t take into account the priorities of the business is just wasting their time.
If you work hard to prioritise your own work consistently, then the product and development teams will notice.
They will be more likely to listen to your proposed ideas if you’re always proposing initiatives which clearly connect to the wider business goals.
If you want to read more about ruthless prioritization, check out the newsletter for more details 👇.
Tip #3 - Treat developers like people, not tasks
This isn’t about making friends, but SEO professionals need to recognise that people are more inclined to help you if you treat you like people, not tasks.
When interviewing 15 in-house SEOs, I found a pattern that a critical part of getting things done was that these SEOs treated the developers they worked with as people, not tasks.
They did a number of different activities, which included:
Buying them lunch
Grabbed coffee
Conversations
Interested in solving problems together
Joined team meetings.
At DeepCrawl, as a PM, I found it important to grab lunch or coffee with developers. I even joined in the occasional poker night.
If you treat the interaction with the developer, product or design partners like a transaction or tickets in a Jira backlog, don’t expect them to solve complex problems proactively.
If you want to read more about lessons from in-house SEO teams, check out the newsletter for more details 👇.
Tip #4 - Prioritise conversation over documentation
Documentation does not equal understanding.
Just because I send across an SEO audit does not mean the development or product team understand what is in it.
Instead, I always try to prioritise conversation over written communication with development teams. To do this, I focus on:
Visualizing work on Miro boards
Creating collaboration anchor points during the week
Communicating using examples, not abstract statements
The goal of shared understanding is to ensure that team members have the same mental model of the problem and why they are trying to solve it.
By prioritizing conversation over documentation, I work with developers to solve problems. Rather than just throwing it over the wall. It also allows me to frequently collaborate with them multiple times a week.
If you want to read more about shared understanding, check out the newsletter for more details 👇.
Tip #5 - Write down your requirements
Writing is thinking and allows you to crystalize your thoughts around a specific subject.
When building partnerships with dev and product teams, it is critical that an SEO professional can clearly articulate in writing the following:
Specifications: The requirements around the request.
Opportunity: The impact and opportunity of solving the problem.
Vision: Visualize the idea you want the team to work on.
This helps them save time and means they know your work is usually easier to review. It also signals to them that you’ve actually thought through your request and are not just “context switching”.
I’ve been using Specification by Example for years now to articulate my requirements to tech teams, and it’s like having a communication superpower.
If you want to read more about Specification by Example, check out the newsletter for more details 👇.
🏛️ Company Culture vs Team Culture
Finally, you also need to think about company culture.
Not every organisation you work in will allow you to build partnerships with other teams. Many companies are bureaucratic by their very nature, and so you will be naturally siloed.
This can be frustrating; however, it is not your job to change the entire company culture.
Instead, you should try to influence those around you.
I’ve had success in bureaucratic organisations by identifying key development, design and product individuals and focusing on building partnerships with them.
Above all, remember, self-interested teams do not build partnerships with other teams. The success of the team, and SEO, relies on everyone working together to solve problems that drive results for a business.
Effective teams are people who work well together, get things done and aren’t afraid to make mistakes.
📚 Resources
If you’d like to learn more about trust frameworks, I have provided links to a few below that I have found useful:
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, please consider subscribing.