One engineer is the only person who understands the payments integration, and four of your workstreams queue behind them. How do you manage that as a program risk?

Short answer

Treat it as a throughput constraint first and a knowledge risk second: measure the queue, take work off the expert that only needed their review, and buy down the single point of failure with paired delivery on real tasks rather than with documentation.

Measure the queue before proposing anything

A single-expert bottleneck feels like a knowledge problem and behaves like a queueing problem, and the queueing view is where the fast wins are. So the first week is measurement rather than intervention: for two weeks, capture every request that lands on this engineer, who it came from, what it was, and how long the requester waited. That log is short, it takes almost no effort to keep, and it consistently produces a distribution nobody expected.

What it typically shows is that a minority of the requests genuinely require deep payments knowledge and the rest are review, configuration, questions answerable from a runbook, and access requests routed to them because they happen to hold the credentials. If two thirds of the queue is the latter, the program's bottleneck is largely an addressing problem, and relieving it does not require anyone to learn the payments integration at all.

The right column is the plan for the next fortnight, and it is available without anyone's headcount changing. The rows that stay are the actual key-person risk, and they are a quarter of the queue rather than all of it — which also makes the longer-term transfer tractable, because you now know precisely what has to be transferred.

Two mitigations on two clocks

The mistake is to run one plan. Knowledge transfer takes a quarter or more and does nothing for the workstream blocked next Tuesday, so the schedule mitigation and the knowledge mitigation have to run at the same time on different horizons.

flowchart TD
    A[Queue log, two weeks] --> B[Split real expertise<br/>from routing habit]
    B --> C[This fortnight:<br/>reroute the routable]
    B --> D[This quarter:<br/>pair a second engineer]
    C --> E[Resequence the two<br/>workstreams with float]
    D --> F[Second engineer leads<br/>a real change, expert reviews]
    F --> G{Handled an incident<br/>unaided}
    G -- No --> F
    G -- Yes --> H[Risk downgraded,<br/>not closed]

The loop between the last two nodes is the part that most plans omit. A second engineer who can make routine changes has reduced your throughput problem and barely touched your continuity problem, because the expensive moments are the ones that were never written down: a failed settlement run at month end, a provider changing behaviour without notice. Until the second person has been through one of those with the expert available but not intervening, the single point of failure is still a single point of failure.

Transfer through delivery, not through documentation

The reflex mitigation is to ask the expert to document the system. It reliably fails, for two reasons worth being able to state. Documentation produced under instruction records what the author thinks is important, which is systematically not the tacit knowledge that makes them irreplaceable — the failure modes they recognise by shape, the provider quirk they route around without thinking. And it consumes the exact person whose time is the constraint, so the mitigation makes the bottleneck worse while it is being executed.

What works is assigning the second engineer a real change on the critical path, with the expert as reviewer rather than as author. The second engineer produces the documentation as a by-product of needing it, and every question they cannot answer is a precise map of what has not transferred. It is slower for that one change and it is the only version that actually moves the risk.

The runbook rows in the table above follow the same principle: written by whoever asked the question, checked by the expert. That inverts the cost so the many pay it rather than the one.

The person is not a resource

An answer that discusses reallocating this engineer without ever considering their position is a poor answer, and interviewers listen for it. Being the only person who can do something is a mixed experience: it produces status and job security and also means no holidays without interruption and no chance to work on anything else. Which of those dominates determines whether your plan is easy or hard, and you find out by asking them rather than by inferring it.

If they want out of the position, the conversation is straightforward and they will help. If they are attached to it, the framing that works is what they get back — the escalations they stop taking, the settlement redesign they have wanted to do and never had a clear week for — rather than an argument about bus factor, which lands as a threat to their standing. Sample phrasing:

Four workstreams are queued on you and about two thirds of what reaches you is review and config that Priya could take once she has shadowed four of them. I would like her to lead the next reconciliation change with you reviewing. That gets the queue off you, and it frees the two weeks you have been asking for to fix the settlement retry properly.

Reporting it without naming a person in a status pack

At program level this is a resource-concentration risk and it belongs on the register, but a named individual in a steering pack turns a delivery issue into something about a person, and the engineer will hear about it. Describe the constraint by capability: "payments integration changes have a single qualified owner; four workstreams depend on them; mitigation is a second qualified engineer by end of quarter, with routine changes rerouted from next sprint". Their manager needs the name and the detail. The committee needs the constraint, its mitigation and the date.

Half of a single-expert bottleneck is usually routing rather than knowledge, and the routing half is fixable in a fortnight without anyone learning anything.

© 2026 Preptima. Originally published at preptima.com.