I keep hearing the same story in conference hallway tracks. An engineer leans in and tells me their old boss or client still texts them every four to six months with a “quick question.” There’s usually a slight eye roll. They’ve moved on. They’re not being paid anymore. It feels like a boundary issue.
Then I ask what the question was.
It’s rarely random. It’s about the custom annual report they used to run before board meetings… whether it’s safe to delete a specific SPF value in DNS… why three staging hostnames are still sitting in the load balancer and the new DevOps person is afraid to touch them. Sometimes it’s a background job chain that behaves strangely under load. Sometimes it’s a migration that looked simple but has sharp edges nobody remembers.
These aren’t casual interruptions. They’re loose threads that never got tied off.
And that’s when the uncomfortable question shows up…
Did we fully hand off the system before we left?
What We Really Mean by Handoff
In long-lived systems, knowledge doesn’t live only in the codebase. It lives in decisions, tradeoffs, and context. The repository might show what the system does, but it rarely captures why it ended up there or what constraints shaped it.
While you’re still inside the system, none of this feels fragile. You answer quickly. You remember the nuance. You act as the compression layer between complexity and the rest of the team. It feels efficient and, if we’re honest, a little flattering. Being the one who “just knows” carries quiet status.
The risk appears later.
If only one person can safely interpret parts of the system, succession hasn’t happened. When that person leaves, the system doesn’t just lose a contributor. It loses confidence. The code still runs. The infrastructure still exists. But people hesitate before touching it. That hesitation is usually what triggers the text.
The House You Sold
Think about selling a house you’ve lived in for years. You know which breaker controls the backyard outlet. You know the upstairs shower takes a minute before it gets hot. You know where the sprinkler shutoff is hidden and which switch looks functional but does nothing.
You move out without leaving notes.
Three months later, the new owner texts asking about a breaker or a pipe noise. They aren’t trying to pull you back into ownership. They inherited something that works but feels uncertain because the context behind it is invisible.
I’ve bought a house from people who were excellent stewards. They labeled panels, left manuals, and wrote down the quirks. It made a meaningful difference. When I did text them once or twice, I had already flipped switches, checked breakers, and read the binder before reaching out. The message wasn’t laziness. It was caution.
You don’t owe infinite support after you sell a house, but you do owe a clean handoff while you still own it.
Software systems aren’t any different. If someone has to text you to feel safe deleting a DNS record or modifying a report query, the system may function technically… but it wasn’t fully transferred operationally.
The Part That’s Hard to Admit
There’s a pattern underneath those hallway conversations.
You can be the one they still text, or the one they never have to.
Being the one they still text can feel good. It confirms that you were critical. It reinforces the idea that you were the person who truly understood the system. There’s status in being indispensable, even if we don’t consciously chase it.
But indispensability is often just concentrated context, and concentrated context is fragile.
If your absence creates anxiety, you didn’t build resilience. If your absence creates confidence, you did. That difference has nothing to do with generosity after you leave. It has everything to do with whether you treated knowledge as something to hold or something to distribute.
There’s also no harm in changing your phone number. That’s definitely cheaper. It just doesn’t fix the underlying issue.
Run the Handoff Test
Open a blank document and write: “If I left tomorrow…”
Then list what would likely trigger a text four to six months later. Be specific. Would someone hesitate to run the annual board report without your guidance? Would they avoid touching a background job because they don’t fully understand its retry behavior? Would they pause before cleaning up infrastructure because they can’t see what depends on it? Are production accounts or key decisions still too closely tied to your memory?
This list isn’t an accusation. It’s a map of concentrated knowledge.
Each item marks a place where the system depends more on familiarity than on structure. It shows you where succession planning for code ownership hasn’t happened yet. Many engineers quietly wonder how things are going after they leave… did the migration succeed… did the architecture hold up… did the team refactor the risky part? When I ask whether they’ve reached out to find out, most haven’t.
That hesitation tells you something.
This Is Structural, Not Just Personal
Handoff isn’t just an individual virtue. It’s an organizational expectation. Engineering leaders should design for it, and teams should normalize it as part of professional completion. If your culture rewards heroics but never budgets time for transfer, you’ll recreate the same dependency patterns over and over. Engineers will leave, and the same operational uncertainty will resurface.
Succession planning for code ownership isn’t documentation theater. It’s risk management. It ensures systems can evolve without leaning on someone who no longer works there. Engineers need to externalize context. Organizations need to create space for that work.
Replaceability isn’t weakness. It’s maturity.
Redefining Done
Most teams define done as merged, tested, and deployed. That keeps velocity high. For long-lived systems, done should also include transferability. Someone else can run the board report without fear. Someone else can rotate keys confidently. Someone else can remove a staging hostname or refactor a risky job without Slack archaeology.
The real question isn’t whether you’ll ever get that text.
It’s whether you left the system in a state where they needed to send it.
