The Reluctant Ancestor: Writing Your Own Obituary for the Next Admin
It’s a quiet Thursday afternoon, and an alert you haven’t seen in months, maybe years, flashes across your screen. You don’t even curse. You recognize the pattern, you know the precise sequence of commands to run, you understand the arcane output of the log file. You are the living archive for this little pocket of the digital world. And then a colder thought arrives: what happens when the archive is gone?
We rarely talk about the single greatest point of failure in our small, reliable systems. It’s not the aging server, the backup script with the silent bug, or the network switch on its last legs. It’s us. The keepers of the institutional memory that never made it into the documentation. We build these beautifully boring, resilient systems, only to anchor them to the most fragile component of all: a human brain and its fleeting attention.
There’s a peculiar kind of vanity in believing our own indispensability. We take pride in being the only one who knows why that particular service needs to be restarted in a specific order, or the exact keyword to search for in the logs when the database connection pool mysteriously drains. This knowledge isn’t power; it’s a time bomb. The most critical service we run is the one that ensures others can carry on without us.
The Unwritten Contract
So, how do we defuse that bomb? The answer isn’t more exhaustive documentation—that often becomes a sprawling, unmaintained garden of its own. Instead, I’ve started practicing a more morbid, and far more effective, form of ops hygiene: I write my own obituary. Not for a newspaper, but for the person who will inevitably take my place.
This isn’t a list of accomplishments. It’s the opposite. It’s a letter titled “What I Didn’t Tell You.” In it, I confess. I explain that the backup verification script in the cron tab hasn’t actually emailed a success notification since 2021, so you have to manually check `/var/backups/verify.log`. I admit that the ‘staging’ environment is actually an old laptop under Bob’s desk, and if it stops responding, you might need to ask him to jiggle the power cable. I detail the secret handshake for the ancient, un-upgraded application that will throw a 500 error if you look at it wrong.
This exercise forces a brutal honesty. You stop writing for the idealized, all-knowing future sysadmin and start writing for a confused, slightly overwhelmed human being—someone a lot like you were on your first day. You are forced to articulate the “why” behind the weirdness, transforming tribal superstition into reasoned, if unfortunate, explanation.
The act of writing this obituary is a continuous process. Every time I solve a novel problem or uncover a new piece of technical debt, I add a paragraph to the letter. It lives in the same repository as the infrastructure code, a plain text file called `handover.md`. It’s the most important file in the entire project, because it’s the one that ensures the system’s longevity extends beyond my own. It’s my way of being a good ancestor to the next caretaker, ensuring the quiet, reliable hum of the services continues long after I’ve fallen silent.
Notes & further reading
A few pages I came back to while writing this: