Designing Roles That Do Not Concentrate

Everything else in this collection is remedial. This is the part that stops the problem forming, and it costs almost nothing at the moment a role is defined.

Putting the controls in “Designing Roles That Do Not Concentrate” into practice requires ownership that survives absence and can be reviewed without relying on memory. Teams can use the detailed explainer to see how responsibility and working time are distributed around recurring tasks, while keeping credentials and sensitive records in authorised systems and limiting activity data to a proportionate operational purpose.

For an independent benchmark, compare the local approach with O*NET occupational information; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Where concentration starts

A new activity arrives and is given to whoever is best suited.

They get good at it, so they get the next related thing.

Nobody else touches it because touching it would be slower.

And within two years it is a single-person dependency that everybody accepts.

Each step is sensible. The outcome is not.

The design questions

When defining or changing a role, ask: what will only this person be able to do?

And: who is the second person for each of those, from the start?

Two questions at the moment of design, which is when they are cheapest to answer.

Deliberate overlap

Design roles so that adjacent people share at least one activity.

Not full duplication: one meaningful overlap per person.

In a team of eight that produces a mesh where everything has a second pair of hands, achieved through role definition rather than through a cross-training programme.

Splitting concentrated roles

Where somebody already holds too much, a split is an option and it is rarely considered.

Move one significant activity to somebody else permanently, with proper transfer.

This is easier when the organisation is growing, which is the argument for doing it during growth rather than waiting for a crisis.

Titles and ownership

"Owner" of an area is useful for accountability and harmful for resilience if it means sole access.

The resolution: ownership means accountable for the outcome, not the only one who can act.

Say that explicitly, because the default reading is the other one.

Hiring into it

When replacing somebody, resist recreating their exact role.

A departure is the natural moment to redistribute, and it is almost always wasted by writing a job description from the previous one.

Its own note covers hiring for overlap.

What this costs

A little efficiency: the best-suited person does not always do the task.

Some duplication of learning.

Both are small and continuous, against a risk that is large and occasional, which is a trade most organisations would take if it were presented as one.

What to check

When you last defined a role, did anybody ask what would concentrate?

Does each person share at least one activity with somebody else?

Does "owning" an area in your organisation mean sole access?

And when somebody was last replaced, was the role redesigned or copied?

The point

Ask two questions when a role is defined: what will only this person be able to do, and who is the second person for each.

Cheapest at that moment.

Underlying all of this

Everything in this collection reduces to four habits: know where the dependence sits, do the cheap fixes first, use the absences that already happen as rehearsals, and decide deliberately about what remains. None of it requires a framework, a tool or a consultant, and an organisation that does those four things consistently is substantially harder to damage than one with a succession document nobody has read.