What Happens When You Build a Team Around One Superstar?

For most of a decade, both Barcelona and Argentina were built with Messi at the centre. That produced remarkable results — and a documented question that followed both teams for years: what happens when he is unavailable?

Key-person dependency is not an accident. It is a design decision, usually made because it works. Concentrating your best resource where it has most leverage is good management. The problem is that the decision is almost never priced, reviewed or written down.

The people question this raises

There is a line between leverage and fragility, and most organisations only discover where it sits during a resignation, a serious illness, or a two-week holiday that turns into a crisis. The question is not whether you have dependencies — every company does — but whether you know which ones would stop the business, and whether anyone has decided that consciously.

Where this shows up at work

One engineer understands the billing system, so every release waits for their review.
One founder holds every key client relationship personally, and renewals stall whenever they travel.
One operations manager knows the undocumented workarounds that keep month-end from breaking.
One salesperson owns 40% of revenue, and their compensation plan gives them no reason to share an account.

Price the risk before you manage it

Dependency register — one page, reviewed quarterly

Critical process	Stops without	Time to failure	Mitigation in place	Owner
Monthly payroll run	One payroll lead	1 cycle	Runbook written, no tested second owner	Head of HR
Billing releases	One senior engineer	2 weeks	Second reviewer being trained	Eng manager
Top 5 client renewals	Founder	1 quarter	None — relationships not shared	CEO
Month-end close	Ops manager	1 cycle	Partial documentation	Finance lead

The value of this table is not the data. It is that "none" appears in writing next to a revenue-critical row, in front of the people who can fund a fix. Dependency risk survives on vagueness.

How to keep the leverage and cut the fragility

The dependency audit

1
Name the single points
For each critical process, write the name of the person it stops without. Keep the whole list to one page — if it runs longer, you are listing tasks, not critical processes.
2
Rank by damage, not seniority
Ask how long the business functions in their absence: a day, a cycle, a quarter? Fix the shortest fuse first, regardless of job title.
3
Document, then rotate
Written runbooks first, then a deliberate second owner who actually performs the work sometimes. Untested backup is not backup — schedule the rotation.
4
Pay for the sharing
Recognise and reward the expert for building others' capability. If sharing knowledge reduces someone's status or bonus, the dependency will quietly rebuild itself within two quarters.

This is not about reducing your best people

The aim is not to make the star smaller. It is to make the team large enough that the star's absence is a setback rather than a stoppage — and to free your best person from being permanently on call for work only they can do.

A worked example

A 60-person company runs the audit and finds three red rows. The engineering one is easy: pair reviews for six weeks, then the second reviewer signs off alone while the first watches. The client one is harder, because the founder's relationships are real and cannot be transferred by memo. The fix is structural rather than heroic — every top account gets a named second contact who joins all calls, owns the notes and leads one review per quarter with the founder present. After two quarters the accounts have two relationships instead of one. Nobody's importance was reduced; the failure mode was.

What readers often get wrong about this

Documentation alone does not remove dependency. Unread, untested runbooks fail exactly when you need them. The test is whether the second owner has actually done the task unaided.
Full redundancy everywhere is waste. Duplicating every specialism is unaffordable and demotivating; you are buying down the risks that would stop the business, not all risks.
The star is usually not the villain here. Dependency is created by managers who kept routing the hardest work to the safest pair of hands, and it is theirs to unwind.
The football analogy is loose. A squad has a fixed roster, transfer windows and no ability to hire mid-season. Companies have far more freedom to redesign roles than clubs do.

Interpretation, not fact: how much either team's fortunes actually depended on one player is debated by people with much better data than mine. The documented part is only that both were built around him and both were repeatedly asked the succession question in public.

A 90-day plan

Days 1–15: build the one-page dependency register with your leadership team; force a time-to-failure estimate on every row.
Days 16–45: for the three shortest fuses, write runbooks and name a second owner in each case.
Days 46–75: run a live rotation — the second owner does the task, the primary owner observes only.
Days 76–90: add capability-building to the primary owner's goals and review the register; put it on the quarterly calendar permanently.

Common questions

Our star resists sharing. What now?

Find out which fear is driving it: loss of status, loss of bonus, or a belief that others will do the work badly. Each has a different fix — explicit recognition for capability-building, a compensation plan that pays for it, or a supervised rotation where they still hold quality control.

Is it not cheaper to accept the risk?

Sometimes, and that is a legitimate decision — as long as it is written down, priced, and made by someone with the authority to accept it. What is not acceptable is discovering the risk during a resignation.

Where do we start with no spare capacity?

One row. Pick the process with the shortest time to failure, and buy down that single risk this quarter. A register with one fixed row beats a comprehensive plan nobody funded.

Over to you

If your most critical person disappeared for a month, which process breaks first — and who else could run it today, without help?

References

FC Barcelona club history and squad records — FC Barcelona
Succession planning and key-person risk guidance — CIPD
Building organisational resilience — Harvard Business Review