🏆 Conway's Law in SEO
Why your teams communication structure shapes your website.
To receive articles like this, please subscribe to The SEO Sprint 👇.
In SEO we’re all told that communication matters.
But, why?
Well, what if I told you that all systems, websites or software, will follow a simple law that they will mirror the team communication structure that built it?
Poor team communication structure = an unhealthy and poor-performing website.
This powerful law is known as Conway’s Law.
By understanding this simple but powerful law, you can begin to understand why SEO projects are doomed to fail from the start. Once you understand it you can work within your organisation to accept it, take action, and get things done.
Be careful, because once you’ve understood Conway’s Law, it is hard to unsee it.
In this newsletter, we are going to cover the following:
🗣️ What is Conway's Law?
📶 Communication Structure > System Design
💬 Conway's Law in SEO
🧵 How SEO Teams Deal with Conway's Law
🗣️ What is Conway's Law?
Conway's Law is a 50-year-old thesis (1967) and observation that the design of any system (software, website, web app, etc.) is shaped by your team's communication structure.
The law is best defined by its creator:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”
- Melvin E. Conway
In other words, a system's design is enabled and encouraged by human communication.
Conway argues that the team's communication structure eventually shapes any system into two architectural patterns: Monolithic vs Modular.
🧩 Monolith Architecture
A team with a centralised communication structure will create a system design that will include core functionality that solves problems for both the business and the customer.
Why does this happen?
Well, the different business teams (marketing, sales, content, product, etc.) can easily communicate their desired requirements to the development team. The team isn't siloed. The culture and structure of the company make it easier to allow teams to approach the development team, discuss the problem, and agree on a desired outcome.
The tight connection of the team communication also means that there might be multiple pipelines to release code, but it is all coordinated between the teams.
This culture and communication structure will lead to:
⚙️ Requirements - The teams work together to implement requirements from each team.
🚦 Ruthless prioritisation - The team can easily sequence and prioritise initiatives/tasks.
🔄 Being Agile - Teams can quickly take feedback and make changes to the app or website.
😃 Reduce rework - Communication allows discovery work, which reduces the need to fix things.
🤏 Less Complexity - The teams can break down initiatives/tasks into smaller realistic tickets.
The system being built is reflected in the communication structure of the team.
💠 Modular Architecture
In contrast, a team with a decentralised communication structure will create a system design that will not include core functionality that will solve problems for both the business and the customer.
Why does this happen?
The business teams working at the company are siloed and cannot easily speak to one another. This means that to solve problems a team will create separate independent services or processes that a single team controls to solve a problem, rather than being a core part of the system.
Although this might seem like a good solution in the short term, in the long term, it can lead to:
🐛 Bugs - The system easily breaks services or core components.
📄 Duplication of work - Siloed and isolated teams duplicate processes and workflows.
💥 Complexity - A growing number of services in the system which need to be maintained.
The system design being built is reflected in the lack of communication between teams.
📶 Communication Structure > System Design
Conway's Law might indicate that a single large team using a monolithic architecture is best. However, monolithic vs modular system design is a divisive topic in engineering.
The truth is that there are technical and organisational trade-offs when designing any system. In my experience, the system design is not as important as the communication structure of the team.
For example, at DeepCrawl, when I started on the product team, there were three independent teams: design, product and development. They made up a large single team, but the communication structure within the team was decentralized.
The large product and engineering team were running problems:
💻 Complexity - The large codebase and team meant every meeting was a minefield.
☄️ Misalignment - The product, engineering and UX team's goals were misaligned.
⏳️ Slow - The team was slow to implement anything.
It was hard to get things done, and the system reflected the team communication structure.
So, the teams reorganize into smaller independent product squads, each with a specific goal that aligns with the wider business strategy and a customer problem to solve within the system.
The team naturally gravitated toward a modular or microservice architecture, as the large team was broken down into smaller autonomous teams.
Each team worked independently and aligned to a specific business goal tied to a customer problem.
What was amazing was that this new way of working, and the team's culture, meant that we focused a lot on communication, both inside the product squad and outside the product squad.
This way of working wasn't perfect (what is?), but the reorganisation of the communication structure reflected in the system and our ability to get things done. We could see year-on-year the difference in Jira:
My time at DeepCrawl taught me one thing: Conway's Law matters. Your team's communication structure will literally shape the system design (whether you intend it or not).
What's fascinating is that since leaving DeepCrawl, and working with clients as an SEO Consultant, I've observed Conway's Law at work in SEO.
💬 Conway's Law in SEO
Just like Melvin Conway, I've observed that a company's communication structure will shape a website's system design, especially for SEO.
Based on Conway's Law, I've defined this observation as follows:
"A website’s system design (e.g. SEO, content, UX features) will mirror the team's communication structure."
Adam Gent (based on Conway’s Law)
I've observed that how SEO professionals and other teams communicate will be reflected in the website being "SEO-friendly".
If an SEO professional, or any business unit, is not part of a team's communication structure, this will be mirrored by the website system design.
I know what you're thinking, sitting in your chair, coffee shop or at your desk, Conway's Law doesn't affect me. Adam is just talking about software, engineering and other weird things.
The short answer to this response is: Yes, it does.
Unfortunately, Melvin E. Conway's 50-year-old observation still holds true for companies building websites, software or any system. For the last few years, I've seen it everywhere when working with clients to execute SEO projects.
Let's look at some examples to illustrate Conway's Law in action within SEO teams.
📆 Scheduling and Publishing Content
I worked with a client's development and content team to create content hubs from the ground up.
When planning the content with the content team, I realised that they didn't have the ability to schedule content in the custom CMS.
After a quick conversation with the content team, they had never discussed a "schedule" feature to be added by the developer. Instead, they booked events in their calendar, logged in, and then published the content. The system was only designed to publish content.
The design of the custom CMS mirrored the communication structure of the team.
It was an easy fix, as a quick conversation with the development team and a scheduling feature were added to the CMS in the next sprint.
🌰 SEO Audit Every 6 Months
I advised a large beauty brand to get a technical SEO into the engineering team.
The way they were working, the marketing and development teams were siloed. The marketing team relied on a large well-known SEO agency to produce a technical SEO audit every 6 months, which was sent to the development team.
The SEO audit recommendations in a spreadsheet were largely ignored by the development team (unsurprisingly).
The problem was that the SEO team were loosely part of the team communication structure that made decisions about the website. So, the website mirrors the communication structure.
I've noticed since that conversation they've employed a Technical SEO Manager who now sits with or within the product and engineering team. Reorganising the communication structure within the team.
🎫 Getting SEO recommendations implemented
I was working with a global enterprise ecommerce brand to get SEO projects implemented.
They had no SEO professional but previously had worked with other SEO consultants and agencies. What was interesting was that many of the "quick wins" had been implemented on the website, but the client's contact was looking for more strategic ways to drive revenue from SEO.
I noticed that the communication structure between the client and past SEOs had allowed many to implement easy fixes or bolt-on SEO that could be written down in a Jira ticket.
The website mirrored the communication structure between the client and SEO professionals.
When I recommended strategic "complex" SEO initiatives, I insisted that the client, developers and other business teams discuss the recommendations. Over the next few months, we used the triad team structure to break down each complex project into releasable SEO tickets. That was easily implemented in the monthly releases.
Not everything was implemented, but the actioned recommendations helped drive an extra $1 million in SEO revenue over 12 months.
All by reorganising the team communication structure around getting SEO projects implemented.
🧵 How SEO Teams Deal with Conway's Law
As SEO professionals, when working to optimise or improve websites, we have to take into account Conway's Law to get SEO projects executed.
To do this we must reorganise the communication structure in the:
🩳 Short-term (hard mode) - Be proactive in speaking to the development and business teams.
🧮 Long-term (Boss mode) - Restructure teams so SEO is a core part of the delivery teams.
🩳 Short-Term (Hard Mode)
In the short term, we must proactively reorganise the communication structure between SEO, development and product teams.
This isn't easy.
We must build partnerships within the engineering teams and proactively approach other business teams. This means as SEO professionals, we need to do SEO discovery to understand:
The business - What are the goals, priorities and key initiatives for the business?
The dev team - What are the development team processes, structure and owners?
The tech stack - What are the constraints of the current tech stack?
Team roadmaps - What do other teams already have planned for the next 6-12 months?
There are pros and cons to a short-term approach:
Pros
Relatively easy to do in small-medium teams
Quickly build low levels of trust with the technical team
Cons
Bad habits easily snap back into place
Teams misaligned on goals
A lack of ownership
The reorganisation of communication between SEO and other teams will take time, however, eventually, the website will begin to mirror the new team communication structure.
Not only do you need to do this on a strategic level, but also when delivering SEO projects. I've actually already told you how you could restructure communication in delivery teams.
I use the SEO triad team structure when working with development and product teams.
If you want to read more about this method, see the article for more details 👇️.
🧮 Long-term (Boss Mode)
In the long term, SEO professionals need to work with other teams to restructure the organisation so that SEO reports to product and engineering (who are usually in charge of the website).
This is impossible without the right level of support.
This is why I call this boss mode, not just because it is difficult, but because it requires support from someone in the leadership team to help drive change.
At DeepCrawl and other client organisations, I was lucky to have leadership support to restructure communication between the teams. This isn't always going to be the case at your company or within your team.
There are pros and cons to a short-term approach:
Pros
SEO can easily influence decisions
Part of the tech team culture
Cons
It takes a lot of resources and time to restructure
Requires top-down sign-off to restructure
Requires other departments to agree to restructure
However, there are companies, and SEOs in the wild, who are already restructuring their teams to ensure SEO is part of a centralized team. I've observed, experienced and discussed the team structures with other SEO professionals.
From these observations and experiences, I've identified 5 types of effective SEO team structures currently being used by organisations:
🤖 SEO part of an Engineering Team - The SEO specialist is part of the engineering team and reports directly to the Chief Technology Office (CTO) or Head of Engineering.
🙌 SEO part of the Product Team - The SEO Manager is part of the product operations team and works with product squads to "fit" SEO into the product roadmap.
🕸️ SEO in a Web Team - The SEO specialist is part of a centralized web team that is in charge of what changes are made to the website.
📚️ SEO in a Full Stack Team - The SEO specialist sits with the full stack development team in s small organisation and can easily talk to owners to make changes to the website.
🦾 SEO Product Squad - The SEO leads a product squad and is in charge of what the development team do, but the work lines up with the broader business strategy.
It's important to note that when I interviewed 15 in-house SEOs, those who proactively had conversations with developers or successfully reorganised the team structure improved the effectiveness of getting things done.
The reorganisation wasn't easy for those in-house SEOs. It's tough changing an organisation.
They had to be change agents within their organisation and show the financial benefit of restructuring the teams. Then drive the initiative through sheer strength of will. When finally implemented, these new team structures allowed SEO professionals to be a key part of the communication structure of delivery teams who make changes to the website.
Simply put: The website mirrored the team communication structure.
📌 Summary
We've covered a lot in this newsletter, but I wanted to leave you with this last point.
If you struggle to get SEO recommendations implemented or development teams completely ignore them, try to map out the communication structure of your team using Excalidraw (it's free).
Try to identify the communication pain points (hint: Usually because teams don't share knowledge very well).
You'll likely find that the problems in the team communication structure mirror the problems on the website.
Think about how you can reorganise the communication structure between the SEO and development teams in the short term.
Remember any system will mirror the team's communication structure:
"Dread it, run from it, Conway's Law arrives all the same. And now it's here."
Thanos
📚️ Further Reading
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, please consider subscribing.