Building a Search Organisation That Doesn't Depend on Its Leader

The instinct that gets you promoted into search leadership is the one most likely to hold the team back once you're there.

I spent the early years of my career being the person who found the answer. Rankings drop, someone asks why, and I'd be investigating before the meeting had finished. That instinct is part of what gets you promoted into search leadership. It's also one of the first things that starts working against you once you're there.

Most senior SEO people have spent years developing their technical knowledge and their ability to recognise a problem on sight. When something breaks, you investigate, find the cause and fix it, and it feels productive because the problem goes away. But once you're running a team across multiple markets and departments, every problem you personally solve is a decision someone else didn't get to make. Do that for long enough and you build a team that waits.

If everything needs your approval, something isn't working.

Experience doesn't mean having every answer

I've worked in SEO for over 25 years, and that experience is worth something, especially on complex technical problems, international sites and commercial decisions. It doesn't make me the person with the best answer in the room. Someone working directly with a particular market, platform or technical issue often understands the problem better than I do. They have the context, they've looked at the evidence and they're closer to the work.

AI search makes this plainer than it has ever been. Most of what we know about technical SEO, on-page optimisation and information retrieval still applies, and traditional organic search is still a major driver of website traffic. But the longest CV in AI search runs to three or four years, and someone who has spent the last six months investigating citations, retrieval behaviour and AI-generated answers has expertise their manager doesn't. I encourage that. My experience helps me ask better questions, challenge assumptions and see the commercial implications. It doesn't make my recommendation the right one, and if someone on the team has a better idea I want to hear it.

Ownership of outcomes, with the authority to match

At Iron Mountain I was responsible for organic search across more than 60 country websites, with SEO specialists, agency partners and development teams spread across time zones. You cannot be involved in every technical decision at that scale, and if you try, the team learns that the real decision happens whenever you're online.

What works is making sure everyone understands the strategy, the commercial priorities and what they personally own, and then meaning it. Ownership of an outcome has to come with the authority to make decisions, or it's just a task with a nicer name. Some decisions still warrant oversight: changes to international site architecture, a major migration, anything carrying significant commercial risk. Everyday technical and operational decisions belong with the people closest to the work. My job is to set direction, remove obstacles and hold people to what they've committed to delivering.

Backing their judgement before they do

I've worked with technically strong people who needed to hear "yes" before they'd act. Often they'd already understood the problem and identified a sensible fix. They had the knowledge. What they didn't have was enough confidence to back their own reading. It's tempting to give them the answer; it's quicker, and it's probably something you've dealt with before. It also teaches them that the final answer always comes from you.

So I ask what they'd recommend, why they've reached that conclusion and what evidence supports it. Sometimes the recommendation isn't the approach I'd have taken, and that doesn't make it wrong. What matters is that they've thought through the options, understood the risks and can explain their reasoning. They also need support when something doesn't land. If the reasoning was sound and the risks were understood, there's something to learn from the result. React badly and people become reluctant to make the next decision.

Confidence comes from being trusted, making decisions and occasionally getting things wrong without being made to feel incapable. Telling someone to be more confident rarely achieves much. What does help is giving them their own findings to present, their own recommendations to explain and their own stakeholders to deal with. It's uncomfortable the first few times, especially in front of senior management. And eventually, they stop needing you in the meeting.

Agile, as long as it stays practical

I'm a strong advocate of Agile working, although not of following a methodology because someone decided the team should be Agile. SEO has constantly shifting priorities. Product releases, technical issues, content programmes and international projects all compete for limited engineering capacity, and AI search has added another set of demands on top. Without some structure, everything becomes urgent and the manager ends up coordinating the work through meetings and corridor conversations.

A shared, prioritised backlog makes the work visible. People can see what they own, what's next and where they're blocked without having to ask me. Stand-ups are for resolving dependencies between colleagues; the moment they become people reporting their activity to the manager, they've lost most of their value. Monthly planning is where the team agrees priorities and commitments it can meet. Retrospectives are where everyone gets to challenge how we're working, including decisions I've made. Where Agile earns its keep is the relationship with Product and Engineering, because a shared view of priorities makes trade-offs easier to discuss and stops SEO work disappearing into an engineering backlog. The point is better delivery and people making decisions without me. If the result is more administration, we've got it wrong.

Make teaching each other routine

SEO changes too quickly for one person to know everything, and expertise concentrates more easily than anyone intends. One person understands the international website architecture. Another knows the platform's technical constraints. Someone has built a useful automation script, and someone else has spent weeks on a particular indexing problem. If that knowledge stays with individuals, the team is only as available as they are.

Regular training and knowledge-sharing sessions are the answer, and the team should lead them more often than the manager does. A colleague walks everyone through a complicated hreflang investigation, explains a technical problem they've resolved or demonstrates an automation that removes repetitive work. It doesn't need to be groundbreaking. Sometimes the most valuable training is simply showing colleagues a better way of doing something they encounter every week. Teaching also develops the person delivering it. They have to organise their thinking, explain their reasoning and take questions, and in doing so they find out that the thing they take for granted is expertise.

I also push people to document why an approach was chosen alongside the steps, because the reasoning is what's still useful when circumstances change. That sharing should reach Content, Product and Engineering too. A developer who understands the SEO implications of a technical decision is less likely to introduce the same problem again.

Relationships that don't route through me

Enterprise SEO rarely gets anything done alone. Most improvements worth making depend on Engineering, Product, Content or a commercial team, so building relationships with those departments is part of the job. I shouldn't be the only person who has them.

I want specialists working directly with developers, product owners and other stakeholders, comfortable presenting evidence, arguing a priority and agreeing a solution. That's how they develop judgement beyond their own specialism, and it stops the SEO manager becoming the channel every issue has to pass through. My role is to support those relationships, settle competing priorities when needed and step in when a decision needs senior involvement. If I'm continually being pulled into routine discussions, I want to understand why.

Measure whether the team is getting stronger

Search teams drift towards measuring activity. Audits completed, tickets raised, recommendations delivered. All useful, and none of it tells you whether the function is improving. I'm interested in two things. First, whether the important work got delivered and whether it improved business performance; rankings, traffic, conversions and AI visibility all help explain what's happening, but organic search has to contribute commercial value in the end. Second, whether the team is more capable than it was three months ago: people making decisions without waiting, challenging recommendations including mine, sharing what they know and working with other departments without an escort.

Knowing when to step back

I still think search leaders need to stay close to the technical work. I enjoy investigating performance issues, building automation and getting into difficult technical problems, and I'd be less effective if I lost that understanding. But there's a difference between getting involved because your experience adds value and getting involved because nobody else feels able to make the decision.

The strongest teams I've worked with have a few things in common. People understand the direction, trust their own judgement, share their knowledge and take responsibility for what they deliver. That doesn't happen on its own. It takes time, training, trust and a willingness to let people approach problems differently from how you would.

Leadership for me isn't measured by how many decisions I make or how many problems I personally solve.

It's measured by what the team can do when I'm not in the room.