There’s a pattern I see most often in technical and specialist teams, where individuals have distinct skills, such as lawyers, engineers, policy advisors, and security experts. They hold knowledge that isn’t easily replaced.
Sometimes the go-to person is also the keeper of internal history: where things live, what was decided, and what happened last time.
Either way, the pattern tends to look the same. They get copied “just in case”. The Go-To person gets pulled into meetings “for context”. They get asked to review a document so someone else can feel safe moving forward.
Individually, each request makes sense. Collectively, it becomes a tax. The team pays in interruptions. The go-to person pays in attention and unfinished work.
Rob Cross, author of Beyond Collaboration Overload, and the Edward A. Madden Professor of Global Leadership at Babson College in Massachusetts, describes the wider pattern as collaboration overload: requests for help and coordination aren’t evenly spread, and a small number of people end up carrying far more of the load than leaders realize.
That’s why this can be easy to miss. It looks like teamwork, but it leaves one person doing their job in the gaps between interruptions.
What’s actually happening
When the go-to person is a specialist, the demand is often driven by risk. Every project lead is trying to avoid getting it wrong. Every team is trying to move without creating downstream trouble. So they pull the specialist in early, or often, or both.
When the go-to person holds “how things work around here,” the demand is often driven by speed. Searching takes time people feel they don’t have. Asking the person who knows feels faster.
In both cases, the organization starts treating one person’s attention like a shared utility. Nobody intends to create a bottleneck. It happens because the path of least resistance is to rely on the person who can answer quickly and accurately.
The predictable result is that the specialist’s own work slips because their time gets chopped into other people’s meetings and deadlines. Other people then wait on them because the specialist has become the fastest route to context, judgement, or sign-off. That’s a recipe for overwhelm, even when everyone is working hard.
What leaders can do that makes a real difference
This isn’t solved by telling people to “stop asking questions.” That’s not realistic, and it ignores what people are trying to do: reduce risk and keep work moving.
It is solved when leaders treat specialist attention as finite, and then deliberately build how it gets used. The following three moves align with Cross’s recommendations to identify where collaboration load concentrates and restructure how requests flow, so the same few people aren’t carrying it all.
1) Make the load visible
If you lead a team with specialists, you need to know where their time is going before you try to fix it.
Start in one-to-ones. Ask where they’re getting pulled in most, what types of requests keep repeating, and which meetings they attend mainly to provide background or reassurance. Then ask what work they are carrying that nobody sees.
One practical check helps more than most leaders expect: ask them to list the projects they are currently supporting, including the ones that aren’t officially “theirs.” Leaders often discover the same name showing up in far more places than they realized. At that point, you can make trade-offs. Until then, you are asking one person to absorb the cost privately.
2) Set rules for using specialist time
If anyone can pull a specialist into anything, you will get exactly what you already have: “just in case” invites, last-minute reviews, and a calendar owned by other people.
This is where leaders need to be specific and slightly stubborn. Pick a small set of engagement rules and make them public. These are not meant to be harsh. They’re meant to protect capacity while still supporting the work.
For example, you can set expectations like these:
- Meetings are for decisions. If someone wants the specialist in the meeting, they need to name the decision and what input is required.
- Reviews require questions. A document dropped in someone’s inbox without a clear ask is not a review request.
- Turnaround times have a standard. Exceptions are agreed, not assumed.
- Copying someone “just in case” is replaced with “copy only when you need input, and say what you need.”
These rules don’t reduce support. They reduce waste. They also change behaviour because they remove ambiguity. People stop defaulting to meetings when they can get what they need asynchronously.
3) Reduce repeat pulls and build backup
Some requests will always require specialist judgement. Many do not. Many are repeat questions, repeat risks, and repeat context.
A simple norm helps: if the same question comes up twice, capture the answer once, where others will actually find it. This isn’t about building a grand knowledge base that nobody uses. It’s about small, practical capture points that match the work:
- a decision note at the top of the project document
- a pinned “what we decided and why” message in the project channel
- a short checklist for common review requirements
- a “start here” page for project leads working with that specialist group
Then there’s the part leaders often avoid because it takes planning: build backup. Pair specialists on key work so knowledge isn’t held by one person. Rotate attendance on recurring meetings. Train a second person on the most common requests.
If there is truly only one person who can do the work, then their time is a strategic constraint. Treat it like one. That means making trade-offs visible and shared, rather than expecting the specialist to absorb them.
The leadership decision underneath the Go To Person Tax
The Go-To Person Tax isn’t solved by asking the go-to person to cope better.
It’s solved when leaders stop treating specialist attention as freely available. Your best people can be incredibly valuable to the organization. That doesn’t mean they should be constantly accessible to it.
Good intentions don’t protect anyone. It has to be deliberately built that way.