Support infrastructure - or the absence of it - is one of the most consistent causes of wasted productive capacity in growing organisations. Leaders rarely see it clearly from the top. Their teams live with it every day.

Your PM spends 40% of her time answering "Where is..." questions. Not shipping. Not designing. Searching for information that should take 30 seconds but takes 15 minutes, because nobody organised the knowledge her team actually needs.

Your engineer fields the same compliance question for the 12th time this week. Your manager spends half her day running interference - a human router, directing information so that other people can do their jobs.

You are paying all three to ship. They are spending their time being support staff. This is not a people problem. It is a support infrastructure problem.

---

The cost you are not calculating

The research on interruptions is specific. Dr. Gloria Mark at UC Irvine has studied knowledge worker attention for over two decades. After an interruption, it takes an average of 23 minutes to return to the same level of focused attention on the original task.

Your engineer does not just lose the 10 minutes of the support conversation. She loses the 23 minutes of focus recovery that follow it. In a day with four or five interruptions, she may complete only two or three hours of sustained, focused work - despite being present for eight hours.

Support burden does not sit on top of a clean productive workday. It compounds an already fragmented one.

---

Why leaders miss it

When ViVo Pulse diagnostics analyse support systems, this dimension consistently shows one of the sharpest perception gaps between leaders and their teams.

Leaders see that questions get answered. Support looks responsive. The system appears to be working. What they do not see is how many times the same question was answered, how many workarounds exist for documentation that technically exists but cannot be found, or how many people quietly stopped asking and adapted in ways nobody ever notices.

Teams cope. The system looks functional from above while productive capacity drains from inside. That perception gap is precisely what good diagnostics are designed to surface.

---

The five support failures

Support infrastructure breaks in five predictable ways. Identifying which patterns are active in your organisation is the first step to fixing them.

1. The reactive support trap

The whole system assumes people will ask when they need help. Therefore support only arrives after someone realises they have a problem, decides to ask, and actually does. Many people never complete that chain. The confident few get supported; the rest adapt quietly.

2. The documentation graveyard

Documentation exists. It is comprehensive and well-written. Nobody uses it - because it is organised by how engineers think about architecture, not how people search for answers. So teams ask a person instead. The documentation investment returns nothing on support reduction.

3. The bottleneck person

One person knows where things are. Not by choice - because deliberate decisions about knowledge distribution never happened. She handles 20-30% of the team's support needs simply because she became the default repository. If she leaves, critical knowledge leaves with her.

4. The context switching tax

Each support interruption costs 23 minutes of focus recovery beyond the conversation itself. Four interruptions per day can reduce effective deep work to under three hours, despite eight hours in the building. This is not a morale problem. It is a structural one.

5. Learned helplessness

After long enough asking and receiving, teams stop trying to help themselves. Asking someone is faster and more reliable than searching documentation that may or may not have what they need. The habit solidifies. New hires learn it on day one. The dependency compounds.

---

Five concrete steps to fix it

Step 1 - Audit where the burden comes from

Track for one week. What questions get asked most? Who gets asked most? Most organisations find that 20% of questions account for 80% of support time. That 20% is where to focus.

Step 2 - Build self-service for high-volume questions

The top questions have answers that already exist somewhere. Make them findable before someone has to ask. One hour documenting a question asked 50 times per quarter saves 49 hours of answering it. Organise by how people search, not how you think about the information.

Step 3 - Shift from reactive to proactive enablement

Proactive support means help arrives before people realise they need it. Onboarding that teaches "where to find answers." Office hours that share anticipated knowledge before questions pile up. Process announcements that explain "why" alongside "what."

Step 4 - Distribute knowledge deliberately

Have the bottleneck person document as part of normal work. Train two or three others to handle the most common questions they field. The goal is that the top 80% of questions can be handled by three people, not one.

Step 5 - Protect focus time structurally

Replace availability with reliability. Office hours instead of all-day "ping me." Asynchronous channels as the default. Defined response windows. People feel more supported when they know they will get a reliable answer within a timeframe than when they wait indefinitely for an instant response.

---

What changes when you fix it

One organisation we worked with had a 50-person team where support burden was consuming 30% of everyone's week. The audit revealed that 15 questions accounted for 70% of support time - the same questions, asked 50 or more times per quarter.

They spent four months building infrastructure rather than adding headcount. Within the first quarter: support requests dropped 40%. New team members reached productive contribution two weeks faster. Time to answer repeatable questions dropped from 15 minutes to 2 minutes. Interruptions declined because people self-served instead of asking.

The team did not become less helpful. They became less interrupted. Productivity increased without a single additional hire.