Every organization has people who are holding it up in ways the org chart doesn't show. Not necessarily the senior ones, although sometimes. Not necessarily the loudest, although sometimes. The people the work flows through. The ones whose absence on a Tuesday changes what the team can accomplish that week. The ones who hold whatever it is that makes the rest of the function actually function.
A manager who can identify these people, and a manager who can act on what they find, is doing one of the most undervalued forms of leadership work in modern organizational life. Most managers don't do it. Most don't even know it's a job. The result is the organizational fragility that becomes visible only when someone leaves, gets sick, gets poached, or finally burns out, at which point the failure looks like a personnel surprise, when in fact it was a structural condition that had been present and unaddressed for years.
This post is about how to find the load-bearing people in a team you manage, and what to do about it once you have. The finding is easier than the doing, but neither is particularly hard. The reason most managers skip both is not difficulty. It's that the work has no visible payoff during the period when it's being done, and the visible cost, operating temporarily less efficiently while you redistribute capability, is real and immediate.
I'd push past that hesitation. The load-bearing problem is not a stable condition. It's a slowly accumulating risk that compounds invisibly until something forces the issue. Addressing it before the forcing function arrives is one of the small handful of things that distinguishes a manager who builds durable teams from a manager who happens to be running one that hasn't failed yet.
Load-bearing isn't one thing. It's four things, and the four require different interventions. The first job of the manager is to be able to tell them apart.
Knowledge concentration is when one person holds the context for some part of the work. They know how a system was built and why, what's been tried before, what the edge cases are, which conventions exist that aren't written down. The knowledge isn't secret, they'd share it if asked, but it lives in their head and nowhere else. Knowledge concentration is the most common form of load-bearing in technical teams, and it's the one most often misdiagnosed as expertise. Marcus is the expert on the identity system is, usually, a polite way of saying Marcus is the only one with the context, and the rest of us have stopped trying to learn it because Marcus is reliably available.
If you've read The Phoenix Project, you already have a name for this person: Brent. He is the most knowledgeable engineer at Parts Unlimited, and over the course of the book he becomes the bottleneck that no amount of process change can fix until Bill Palmer figures out that the problem isn't Brent. The problem is that Brent is the only Brent. Every IT organization I've ever worked in has at least one Brent. Most have several. The work of recognizing them is half-done by anyone in the field who's read the book; the harder work, and the one Gene Kim is gentler about, is what to do about it without losing what makes Brent valuable in the first place.
For the record, I am a Brent. I have been one at every stage of my career, in different shapes, and I am one now. The advice that follows is partly mine to give because I've spent a long time figuring out how to be less of one, for the sake of the teams around me as much as for the sake of the organizations I've served. The lessons in this post were learned by being on both sides of the load-bearing pattern, not by observing it from outside.
Decision concentration is when one person holds the authority for some category of work. They're the one who signs off on architectural choices, the one who decides what gets prioritized, the one who can say yes or no to a vendor change. The authority may be formal or informal; the team treats them as the decider regardless. Decision concentration is harder to spot because it often masquerades as appropriate seniority, of course the lead engineer decides on the framework choices, but the test isn't whether the decision authority is appropriate. The test is whether anyone else on the team could make the decision if the lead engineer were unavailable for two weeks. If the answer is no, you have decision concentration, regardless of whether the authority is well-placed.
Relationship concentration is when one person holds the external connections for some part of the work. They're the one who can call the vendor's account manager and actually get a response. They're the one the senior leadership in another department trusts. They're the one with the institutional history with auditors, regulators, key customers, or partners. Relationship concentration is the most invisible form of load-bearing, because it doesn't show up in any system you have access to. It lives in someone's phone, their inbox, their accumulated reputation. It's also the hardest to transfer, because relationships aren't documented, they're built over time through repeated interactions, and the transfer requires those interactions to happen again with someone new.
Operational concentration is when one person actually does the work, and nobody else has done it recently enough to do it well. The runbook exists, but it hasn't been executed by anyone other than this person in eighteen months. The code lives in the repo, but the only person who can make changes confidently is the one who wrote it. The vendor portal has logins for the team, but only one person actually knows the workflow for completing the quarterly review. Operational concentration is the easiest to spot, it shows up in who actually gets paged, but it's surprisingly stable, because the load-bearing person rarely complains about the work and the rest of the team is rarely volunteering to learn it.
These four are not always present together, and they don't always cluster in the same person. The most senior engineer on your team might be a knowledge bottleneck and a decision bottleneck without being an operational one. The most reliable person on your team might be operationally indispensable without holding any of the other three. The first diagnostic act of the manager is to map who holds which, and to notice that the four categories require different responses.
Finding the load-bearing people is mostly a matter of paying attention to specific signals.
For knowledge concentration: which questions get routed to the same person consistently? When someone new joins the team and needs context on a system, who do they end up talking to? When a problem comes up that requires understanding the history of a decision, who has to be in the room? The signals are conversational. The person whose name comes up reflexively when context is needed is holding knowledge that should be more broadly distributed.
For decision concentration: which decisions stall when one person is out of office? Which kinds of decisions can your team make in your absence, and which kinds wait for you? When you look at meetings where decisions get made, are there categories where the team defers to a specific person regardless of who else is present? Decision concentration is most visible in someone's calendar, the meetings they have to be in, and the decisions that don't happen until they are.
For relationship concentration: which external interactions go through specific people every time? Who in your team can actually get a vendor to respond same-day? Who has the history with the auditor that lets a conversation start at version four rather than version one? Who can pick up the phone with another department head and get something moved up the priority list? The signal here is to ask: if this person left, who would the vendor / partner / counterpart adjust to working with, and how long would that adjustment take? If the answer involves a perceptible decline in responsiveness or quality, you have relationship concentration.
For operational concentration: which tasks does the team avoid distributing? Which work, in your queue review, always goes to the same person? When you ask the team "who could pick this up if so-and-so were out next week," does the answer ever feel uncertain? Operational concentration shows up in queue patterns and in the team's own awareness of who-does-what. The team usually knows. The manager has to ask.
Once you have the inventory, the response depends on the category.
For knowledge concentration, the intervention is to externalize the knowledge in a form that survives the person leaving. This is harder than it sounds. The instinct is to ask the load-bearing person to "document what they know," which produces a wiki page that's a poor map of the actual knowledge. The better intervention is to pair the load-bearing person with someone who's trying to learn, on real work, and let the knowledge transfer happen through the conversations that arise from that work. The pair-programming model isn't only for programming, it works for any knowledge-intensive task. The cost is some short-term inefficiency. The benefit is that the second person learns the why and not just the what, and the knowledge becomes resilient.
For decision concentration, the intervention is to delegate decisions earlier than feels comfortable. The instinct is to keep authority centralized until the team is ready to handle it. The reality is that decision-making capability develops by being asked to use it. Reserve the right to be consulted on the hardest decisions; delegate everything else, and live with decisions you wouldn't have made yourself. The cost is some short-term suboptimality. The benefit is that authority becomes distributed, and the team builds the muscle that lets them function when you're not in the room.
For relationship concentration, the intervention is the slowest and the most deliberate. Relationships transfer through introductions and repeated interactions. The load-bearing person needs to bring a second team member into conversations with key external parties, gradually, over months. The first few interactions are awkward and feel inefficient, the new person doesn't have context, the external party doesn't know them yet. The discipline is to keep doing it until the new relationship is established. You cannot accelerate this. You can only start it earlier.
For operational concentration, the intervention is rotation. The work that's currently done by one person gets routed to other people periodically, deliberately, even when it would be faster to keep routing it to the person who knows it best. The cost is real, work that took the load-bearing person two hours might take the new person two days, and the quality might be lower at first. The benefit is that the team builds operational depth. The discipline is to accept the short-term cost as the price of long-term resilience, and to not let urgency-based exceptions ("we don't have time for the rotation this week") quietly become the new permanent state.
The common thread across all four interventions is that they require the manager to deliberately accept a short-term efficiency loss in exchange for a long-term resilience gain. The efficiency loss is visible. The resilience gain is invisible until something tests it. This is why most managers don't do this work. The performance review covers the efficiency loss. It does not cover the resilience gain that wasn't tested.
The ethical dimension is worth naming, because the load-bearing problem is usually framed in pure risk terms, what if Marcus gets hit by a bus, and that framing misses half of what's at stake.
The other half is that the people who aren't load-bearing in your team are, by definition, the people who aren't getting the chances to develop the load-bearing capabilities. If Marcus is the only one who handles the identity system, then everyone else on the team is being denied the opportunity to learn it. The longer that condition persists, the wider the gap grows. Marcus accumulates context and authority. Everyone else accumulates dependence. The dependence is not their fault, they're being managed in a way that produces it, but it's still their career limitation, in the form of skills they haven't been given the chance to build.
A manager who keeps load-bearing people in place because it's operationally convenient is, in a quiet way, holding back the other people on the team. The other people aren't getting the stretch assignments, the decision authority, the relationship exposure, the operational reps that would let them grow. They're getting the residual work that's left over after the load-bearing person takes the meaningful work. This is a fairness problem disguised as an efficiency problem, and it's worth seeing clearly.
The structural argument and the fairness argument point in the same direction. Distributing load-bearing capability is good for the organization's resilience and good for the development of the people on the team. The only thing it's bad for is the short-term comfort of the manager, who has to operate temporarily less efficiently while the redistribution happens. That's a cost worth paying. The managers who pay it consistently end up with the strongest teams. The managers who don't end up with teams that look strong as long as no one tests them.
A practical closing thought. The load-bearing inventory is not a one-time exercise. People grow into and out of load-bearing roles continuously, and a team that was well-distributed a year ago can become concentrated again through ordinary turnover, project shifts, and skill development. The good managers I've watched do this work treat the inventory as a quarterly discipline, not a project. They map the four categories, ask themselves what's changed, and identify the next intervention to start.
This is not a glamorous discipline. It produces no visible deliverable. It is, in my observation, one of the better predictors of which managers are going to end up running organizations that hold together and which are going to end up running organizations that succeed for a while and then unravel when the load-bearing people leave.
The unraveling looks like a personnel crisis. It was a management failure all along.
— Chris