Someone who will not share knowledge needs a conversation about operational coverage, not a vague appeal to document more. Show where work waits for them, which incidents require their private memory, and what happened when somebody tried to learn. Assign a specific pairing outcome, protect time for it, and check that another engineer can operate the system without rescue.
What behavior should you name?
Bring examples where access to knowledge depended on the person. They took over every database incident, answered questions with “send it to me,” kept deployment steps in a private note, and postponed three pairing sessions. The concern is not that they know more than others. Expertise is valuable. The concern is that their choices prevent anyone else from becoming capable.
Check whether workload created the pattern. A person may rescue incidents because managers reward speed and never reserve teaching time. They may have written documentation that nobody used. Inspect the system before accusing them of hoarding. Then distinguish barriers you own from choices they must change.
How should you open the conversation?
Say: “The database service currently stops when you are unavailable. During the last incident, Priya asked to drive while you explained, but you took the keyboard and completed the repair. The deployment steps are still in your private notes. I need us to change coverage, and I want to understand what has made sharing difficult.”
Do not flatter the engineer as indispensable. That label can sound like recognition while reinforcing the risk. Recognize the depth of their expertise and explain that senior ownership includes making the system operable by others. Their value should grow through judgment and teaching, not through remaining the only safe pair of hands.
What might be behind the resistance?
Ask whether they fear errors, lack time, dislike teaching, or believe unique knowledge protects their role. Each answer needs a different response. A real production risk may justify a safer practice environment. Missing time requires you to change priorities. Dismissing every learner as incapable requires a direct expectation about coaching and delegation.
Do not force a confession about job security. State that keeping knowledge private will not be rewarded as ownership. Explain how broader coverage creates room for the expert to take harder work and time off. If trust in the organization is weak, listen seriously, but keep the operational requirement clear.
What pairing outcome should you assign?
Choose one operation, one learner, and one proof. For example, Jordan will lead the next staging restore on Thursday while the expert observes, then lead a production readiness exercise the following week. The learner will update the runbook from direct use. Completion means they can explain the checks, perform the action, and know when to escalate.
Do not ask the expert to dump everything into a document. Knowledge includes judgment, failure recognition, access, and sequence under pressure. Pairing exposes missing assumptions. Documentation then records what another person actually needed, rather than what the expert guessed a reader might ask.
Which transfer evidence matters?
| Area | Evidence | Failure signal |
|---|---|---|
| Access | Learner can enter safely | Private credential |
| Procedure | Learner leads the task | Expert takes over |
| Judgment | Learner explains checks | Steps without reasons |
| Recovery | Learner handles a fault | No practiced response |
Count capability, not meeting hours. Four pairing sessions can produce no transfer if the expert drives every step. One carefully designed exercise can reveal useful independence. Ask the learner what they can now do and where they still depend on the expert, without turning them into a witness in a personal dispute.
How should the transfer sequence work?
- Select one risky operation.
- Name the learner and reserve time.
- Let the learner observe once.
- Let the learner lead while explaining.
- Introduce a safe failure.
- Update the runbook from use.
- Test independent operation on a set date.
Protect the sequence from delivery pressure. If every session is cancelled for urgent work, the manager is choosing dependence. Move other scope or set a maintenance window. Also protect production by choosing suitable environments and approvals. Sharing knowledge does not require reckless access.
What if they keep taking over?
Describe the takeover in the moment or soon after: “Jordan was leading the restore as agreed. When the first check failed, you took control instead of asking what they would test next.” Ask what risk they saw. If intervention was necessary, define the trigger. If not, require them to coach through the next uncertainty.
Give the expert a teaching role with clear limits. They may stop an unsafe action, ask questions, and provide missing context. They should not convert every hesitation into proof that only they can do the work. Learning includes pauses and small corrections that expert speed tends to hide.
How do you separate sharing from losing ownership?
Tell the engineer what ownership remains theirs and what becomes shared. They may continue to set technical direction or handle the hardest failures while another engineer gains routine operation. Shared capability does not erase expertise. It makes expert judgment available at the level where it is most useful.
Update recognition accordingly. Praise a stable service and a capable second owner, not heroic interruption at midnight. Ask project reviews who can operate the result. Incentives that celebrate rescue while ignoring transfer will undermine your 1 on 1 message.
What should you check on the follow up date?
Watch the learner perform the agreed operation and explain decisions. Review access, runbook changes, and any moment when the expert intervened. The test is not perfect speed. It is safe independent progress and a clear escalation boundary. Ask both people what remains fragile.
If transfer worked, name the expert behavior that enabled it, such as waiting through uncertainty or explaining why a check matters. If sessions were avoided or control was repeatedly reclaimed without cause, state the missed expectation and set the next consequence through the appropriate performance process.
How can you make teaching part of the engineering result?
Put transfer inside the completion criteria for the next service change. The change is not finished when the expert deploys it alone. It is finished when a second owner can explain the design, use the operational path, and respond to a representative failure. This makes teaching visible in planning rather than an optional favor requested after all delivery time is spent.
Ask the expert to identify the judgment that documentation usually misses. They might know which metric lies during recovery, which vendor response signals a deeper failure, or when a rollback creates more risk than waiting. Turn each judgment into a scenario for the learner. A list of commands cannot transfer the pattern recognition that makes those commands safe.
Give the learner responsibility as well. They should arrive prepared, ask questions, update the runbook, and lead the scheduled practice. If they repeatedly cancel or expect passive instruction, solve that problem rather than blaming the expert for failed transfer. Shared capability requires real participation from both people and protected priority from the manager.
Watch language around ownership. “My database” or “only I understand this” may be shorthand, but repeated use can reinforce private territory. Ask the expert to name interfaces, owners, and backup roles in the team vocabulary. The goal is not to police every phrase. It is to make the service an organizational asset rather than an extension of one person's identity.
Plan for the expert's absence. Schedule a day when questions route first to the learner while the expert remains available for agreed emergencies. Tell the team the purpose so they do not bypass the exercise for speed. Record every rescue and why it happened. Those moments define the next transfer work more accurately than another broad request to share knowledge.
At the final check, ask what higher value work the expert can now do because routine dependence fell. This matters because transfer should create growth, not merely add teaching labor. If the expert sees that broader capability gives them room for deeper design and genuine time away, the new ownership model becomes a credible professional path rather than a loss of status.
How should this work appear in performance feedback?
Describe the operational result, not a vague willingness to help. Strong evidence says that the engineer taught a second owner to restore the database, tested the runbook through a failure exercise, and reduced incidents that required private intervention. A gap says that agreed pairing sessions were cancelled, the expert retained the keyboard during practice, and no backup could complete the operation by the review date. Connect this evidence to the role expectation for reliable ownership. Do not praise endless availability as a substitute for transfer. An engineer who answers every call may look committed while preserving the exact dependence the team needs to remove. Also credit the complexity of teaching. Explaining judgment, creating a safe practice, and allowing another person to struggle productively require real skill. If the engineer improves, name that capability and give them opportunities to use it on a broader system. If they resist after time and support are protected, treat the continued single point of knowledge as a performance issue with system consequences. The written feedback should make clear that expertise remains valued and that senior impact includes leaving more people able to operate, decide, and learn.
What are common questions?
Is documentation enough to share knowledge?
No. Another engineer should use the documentation, perform the work, explain the checks, and handle a safe failure.
What if teaching slows delivery?
Treat transfer as planned engineering work and remove other scope instead of preserving permanent dependence.
Can the expert still own the system?
Yes. Ownership can include direction and hard judgment while routine operation becomes shared.
What if the learner makes mistakes?
Use safe environments, clear stop conditions, and coaching that lets small errors become learning rather than immediate takeover.
How do you verify progress?
Observe another engineer leading the named operation independently on the agreed follow up date.
Related: having a difficult conversation with an engineer, talk to someone who treats junior engineers poorly, talk to someone who puts themselves first.
Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.