How to Spot the Person Holding Three Projects Together

Somewhere in your team is one person holding three projects together. They are not on the org chart as the linchpin, they are probably not the most senior, and if they resigned tomorrow you would find out how much of the plan was running through them.

You can find that person before they resign. They leave a pattern in ordinary project data, and the pattern is easy to read once you know what you are looking at.

Where they show up in the data

Look for the same name appearing across boundaries that were supposed to be separate.

• They are on tasks in more than two projects at once. Not as an owner every time. Often as a reviewer, an approver or the person a blocked task waits on.
• Their tasks are short but constant. Lots of small items, closed quickly, spread across teams. That is the shape of someone unblocking other people all day, and it shows up again in a two week audit of meeting load against focus hours.
• They appear in the comment history of work they do not own. Someone gets stuck, tags them, and the task moves.
• Blocked items cluster around their availability. When they take two days off, unrelated projects slow down in the same week.
• They are named in handover notes for people who left. Every departure quietly added something to their plate.

None of these on their own means much. Two or three together, on the same name, is a reliable signal, and a better one than utilisation, which is a poor target for exactly this reason.

The person holding several projects together usually owns few tasks and touches many. Look for a name that appears across projects in reviews, comments and blockers rather than in the owner column.

Why leave and promotion both become risky

This is the part that surprises managers. Two ordinary, good things become hazards.

Leave. Their two week holiday is not two weeks of one project slowing down. It is three projects slowing down at once, and because the dependency was never written anywhere, nobody planned cover. The team notices the gap on day three, which is too late to arrange anything. Unplanned absence does the same thing faster, which is why a cluster of short sick days is worth reading at team level.

Promotion. Moving them up usually means moving them sideways out of the work they were holding together. The promotion is deserved and the projects still lose their connective tissue. Managers sometimes sense this and quietly delay the promotion, which is the worst outcome available: the person stays overloaded, unrecognised, and eventually leaves for a title somewhere else.

If you catch yourself hesitating over someone's promotion because the work would suffer, you have found your person and confirmed the problem in the same thought.

How to spread the load before they resign

Do not start by removing work from them. That reads as demotion and it removes the thing they are good at.

Start with the dependencies:

1. Write down what only they can do. Sit with them for thirty minutes. Ask what would break if they were unreachable for a week. The list is usually shorter than you fear and more specific than you expect.

2. Pick the two items with the widest blast radius. Not the hardest ones. The ones that stop the most other people.

3. Give each a named second person. A second, not a replacement. The goal is that a question has two possible answers.

4. Make the second person do it once, for real, while the first is available. Documentation without practice does not survive contact with a real week.

5. Then take a small thing off their plate permanently. One thing. Enough that the change is visible.

Repeat next quarter with the next two items. This is slow on purpose. Fast redistribution usually means the work moves to whoever is next most willing, and you have just created a new single point.

Making it visible instead of remembered

The reason this problem persists is that the dependency lives in people's heads. Managers know that Priya answers the deployment questions, but nothing in the plan says so, so nothing in the plan changes when Priya books leave.

Putting project work and people records on the same set of records is what makes this visible instead of remembered. When a board can show who is on leave next to the work waiting on them, the collision appears at planning time rather than on the Monday morning it happens. That is the reason SicherOne keeps project management and HR on one set of records: the overlap between availability and workload is where most of these surprises live.

Whatever tool you use, the test is the same. Can you look at next month's plan and see, without asking anyone, which weeks depend on one person being at their desk? If not, the answer is currently stored in someone's memory, and memory does not send you a warning before a resignation letter does.

What to do this month

Pick one project. List its blockers from the last six weeks and count the names attached to them. If one name is on more than half, you have found your person, and you now have six weeks of evidence to start the conversation with.