If technical teams do not understand the concepts in conversations or docs it can cause a delay in both product and SEO projects.
This problem isn't isolated to SEO. Product and engineering teams can misunderstand one another if they don't understand the key concepts.
When working with dev and product teams it is critical to get teams using a common language around key concepts or ideas.
A mental model I've found useful to explain the problem with language amongst different teams is Ubiquitous Language.
In this newsletter we are going to cover:
The domain language problem in SEO
What is Ubiquitous Language?
Why is it important to develop a common language?
How can SEOs develop a common language?
The Domain Language Problem in SEO
One of the biggest problems getting things done in technical teams is trying to communicate the “rules” to change system behaviour for features, websites or products.
It can feel complex, frustrating and exhausting at times.
A key challenge for technical and business teams is a lack of common language around a concept or problem the team wants to solve.
For example:
Scheduling Content
I was working with a client who had a custom CMS. A pain point for the client was that the content team were not publishing content regularly, even though content was being written and inputted into the platform.
A quick meeting with both the development and content team identified the problem. There was no ability for the content team to schedule content.
To the content team “publish” meant a whole process of writing, editing and scheduling content at scale. They were having to book timeslots in their calendars to go into the platform to hit publish. Not ideal.
Both the developer and content teamhad different ideas of what the term “publish” meant.
Why does this happen?
It can happen for two reasons:
Domain expert language - It’s because each domain expert or specialist (marketing, product, SEO, etc) all has their own way of describing things.
Siloed teams - Specialists might never speak to each other if they work in a silo and develop their own “language” around shared processes or features.
What is interesting is that both these problems by developing a ubiquitous or common language.
🖖 What is ubiquitous language?
The concept of ubiquitous language is the practice of developing a common language between development teams and domain experts (marketing, product, SEO, etc).
Ubiquitous Language is about developing a common language around a “Domain Model” to help reduce complexity.
A Domain Model is a representation of real-world business rules and data that relate to the project.
In other words, developing a common langauge is about everyone working on a project aligning on what success actually looks like.
This can mean that specialists (marketing, product, SEO) need to develop a shared vocabulary around:
System or feature requirements
A team’s process
Testing plans.
This shared vocabulary is developed and maintained by the business and technical team and is used to:
Get on the same page around how a feature will work
Make sure it actually is solving a user or business problem
Communicate clearly to non-technical stakeholders.
🤔 Why develop a common language?
Developing a common language with your development and product team can help avoid:
Translations: Results in Bugs & Defects
Technical Jargon: Results in Overengineering
Rejection: Stops Releases
🗼 Translations
If common language is not built up and maintained over the course of a project this can result in bugs, defects or missing must-have features from a website.
If rules or concepts go through other teams this can cause them to “translate” rules and concepts. This translation between teams can cause developers to completely misunderstand requirements.
I’ve seen what can happen if teams don’t speak to each other and then get confused over a key concept.
Language around concepts and “rules” can be translated through teams
⚙️ Technical Jargon
Any development team will create a technical language/jargon around a feature that business teams won’t understand.
This usually causes further miscommunication between what the business requires and what has been built. As business teams can't make sense of technical documentation.
Technical jargon can cause developers to “overengineer” a feature or idea which results in the delay of a project.
🚨 Technical Word Alert 🚨
The term overengineering refers to making a solution which is overly complex but doesn’t solve a customer’s or business’ problem. It is surprisingly easy to “overcomplicate” a feature or product when you think it will help users. Assumptions are dangerous things.
🚨 Technical Word Alert 🚨
The greater the lack of understanding and language between teams, the greater the complexity of the project. Teams try to make up for their lack of understanding with more “work”.
Greater the uncertainty the higher the chance of complex work
😞 Rejection
If different teams try to use each other's language it can cause other teams to "reject" them.
As other teams are domain experts they will usually get the language wrong. For example, trying to tell a developer what to do to fix a problem but getting it completely wrong.
Rejection from the business “cell” for using incorrect language
I’ve seen this happen a lot between SEO, marketing and development teams. Each is trying to explain their point of view but the language is not properly explaining the requirements or why this particular initiative is important.
The result is that recommendations are delayed or rejected by the development team for priority projects.
🤠 How do develop a common language?
The best ways to develop a common language include:
Start with the end in mind 🔚
Engage with other teams regularly 🗣
Continuously document 📄
Industry Example
One of best examples to of developing a common langauge between SEO, development and product is from Areej AbuAli (found of TechSEO Women).
In her post Getting Tech SEO Implemented Areej explains her process to get developers on the same page around priorization rules.
This is a good example because she:
Starts with the end in mind - Focuses on an outcome (priority rules)
Engages - Talks to the technical team to understand their language
Continously documents - Creates an accessible glossary with the team
If you’re looking for what success looks like when an SEO develops common language between SEO, dev and productthis is a great real-world example.
Start with the End in Mind
One of the best ways to develop a common language around features is for SEO to start with an end in mind with any feature or activity.
It is about working backwards from the outcome before getting into the nitty-gritty of business and technical jargon.
A good way to get your head around this is to think about cooking a complex curry dish (or any meal).
When you cook for a partner or yourself you want a delicious curry (or meal) from all your hard work. The meal is the outcome you want.
Example of starting with the end in mind when cooking curry
If we work backwards from the outcome we want, then we can start to break down the stages we need to go through to cook a complex curry dish.
If you’ve cooked with a partner or a friend you’ll understand it isn’t a case of going off and going your own thing. You’ll need to:
Pick the meal based on the picture or description
Discuss when you’ll have the meal (weekend or weekday)
Read the recipe to learn the ingredients and rules to achieve the outcome
We need to go shopping to get the right ingredients
We need to prep the food and gather the right tools to cook
We need to make sure people are organised and know what they are doing
Finally, we then start to cook (it can take at least 3 hours to cook)
Cooking a complex meal in the kitchen is like building any feature, page or system with a technical team.
To get SEO features and recommendations implemented we need to:
Align on the outcome we’re trying to achieve
Use examples, sketches or diagrams to get across our ideas
Write down rules that we all agree to work towards
Agree on a way of working that helps us achieve the outcome
Discuss when the project needs to be delivered
All of these steps require a team to speak the same language and get on the same page to achieve success.
🧠 Recommendation
I recommend asking yourself the following questions:
How will the feature behave when users (including Googlebot) interact with it?
Do you have an example, sketch or diagram of the outcome you want?
What are the rules surrounding this piece of work?
How do I know these rules are technically feasible or meet business requirements?
Who is going to be working on this feature and do they understand the outcome?
How will we communicate and discuss these rules with technical teams?
How will you test these rules once the feature/pages are released to the website?
🗣 Engage with other teams regularly
A key way to develop a shared common language with other teams is to talk to them.
Why?
A huge drawback to keeping the end in mindis that it can lack context. When we engage with teams it builds context and creates a vocabulary that business and technical teams can understand.
Proactive conversations put business context to your recommendations and build a common language.
That common language gets everyone on the same page.
Internal teams are a form of user and getting a better understanding of the language can help:
Pivot - Make sure the project is solving a business or user problem
Reposition - Make sure the project is using the language used by the team
Reprioritise - Ruthlessly prioritise your project within the business strategy
Proactive conversations with technical teams (devs, designers, QAs, etc.) can help make sure that the team are on the same page around key concepts.
Discussing features or recommendations with technical teams can help:
Keep Focus - Make sure the technical team is focusing on the outcome
Clarify Context - Make sure you are aligned on the “definition” of rules
Prioritise - Help to ruthlessly prioritise any new problems that come up.
🧠 Recommendations
I recommend asking yourself the following questions:
Do you schedule regular weekly or monthly meetings with other business teams?
Have you had proactive conversations with business teams (marketing, sales, support, etc.) around features they use?
Do you discuss how these teams use these features? Any paint points?
Do you regularly catch up with development teams and discuss the vision or outcome of the work that is in the development backlog?
Do proactively discuss with development teams the rules and concepts around features? Can they explain them back to you?
Do technical teams have scenarios or examples they can test against which have been discussed with business teams?
📄 Continuously Document
The development of a common language requires the team to continuously document their breakthroughs and discussions.
Let’s take a look at a few examples to develop a common language.
Glossaries
A glossary is a document which clearly outlines key concepts within a project so that specialists can clearly and quickly understand.
A good glossary includes:
Agreed name of the concept
Other names used by the team
Clear examples for each concept
For SEO projects, I have found that creating glossaries for page templates, features and designs is very useful for reducing misunderstandings amongst the team.
Team Boards
A challenge for many specialists is to get on the same page around the concepts within features work.
A place where different specialists can discuss, ask questions and draw helps to develop a common language around a feature.
A team board is a visual or virtual board which can be that single source of truth for a team. It is a place they can discuss and ask questions about a project.
A challenge that many team members face is being able to understand the language around how to work together.
A process that I’ve found useful to help reduce barriers between SEO and technical teams is to create team working agreements.
Team working agreements are documents that are created by the team to agree on how they will work together when working on a project.
Source: Atlassian - Remote team votes on ways of working together
For more information on team working agreements check out Atlassian here.
📌 Summary
When working with development and product teams remember:
SEO is a language problem - SEO is a specialism that has its own language like other domain experts and a lack of common language can cause friction between different teams.
Ubiquitous (Common) Language - Ubiquitous Language is about developing a common language around a “Domain Model” which is a representation of real-world business rules and data.
Why develop a common language - Technical projects can slow down or become overly complex due to a lack of common language, as specialists within the team are unclear of what is required.
How to develop a common language - SEO can work with other teams to develop a common language by keeping the end in mind, visualising and discussing work, and continuously creating documentation with the team.
📚 Further Reading
Ubiquitous Language - A concise and clear explanation of Ubiquitous Language from Martin Fowler who has a lot of great articles around agile, product and development.
Developing the ubiquitous language - An article from Domain Driven Design on how to develop ubiquitous language within a technical team.
Getting Tech SEO Implemented - A really good example from Areej AbuAli of developing a “common language” between SEO, Product and Development around prioritising technical recommendations using her Recommend, Prioritise and Implement framework.
