The best infrastructure is the kind nobody thanks you for because nobody knows it's there. I've been thinking about what it means to build things that are designed to survive your own departure.
This isn't a retirement plan. It's a design principle.
The bus factor conversation
In engineering, there's a concept called the "bus factor", the number of people who could get hit by a bus before a project is in serious trouble. If your bus factor is one, you have a problem. If that one person is you, you have a bigger problem, even if it feels like job security.
When I took over technology for the group, I inherited systems that lived in people's heads. Passwords in notebooks. Processes that only worked because one person knew the exact sequence of clicks. Configurations that existed as tribal knowledge passed down like folklore.
My first instinct was to fix everything. My second, better instinct was to document everything first and then fix it, because if I fixed it without documenting the old state, I'd just become the new single point of failure. Different person, same structural weakness.
Writing for the stranger
I now write documentation as if the person reading it has never met me and never will. No assumptions about shared context. No "as we discussed" references. No shortcuts that only make sense if you were in the room when the decision was made.
This sounds tedious. It is tedious. It's also the difference between a system that scales and one that quietly collapses the moment its creator stops paying attention.
The same thinking applies to code. Every function I write, I ask: could someone who doesn't know me understand what this does and why? Not just what it does, the "why" is the part that usually gets lost. The code tells you the what. The comment, the commit message, the documentation, those carry the why. And without the why, the next person will rewrite your work not because it was bad, but because they couldn't understand the reasoning behind it.
Infrastructure as institution
There's a pattern I've noticed in companies that grow quickly: they build for today. Every decision optimizes for the current headcount, the current workflow, the current quarter. And it works, until it doesn't. Until you go from 30 employees to 100 and the system that ran fine at 30 is now a bottleneck that everyone works around but nobody owns.
When I designed the Nextcloud storage platform, I didn't build it for how the company worked that month. I built it for how it would work in two years with twice the people and three times the files. Custom frontend, Elasticsearch-powered search, clear folder hierarchies with access controls that map to the org chart.
Was it more work upfront? Absolutely. But the alternative, and I've seen this play out, is rebuilding the same system every 18 months because each version was designed for the present and the present keeps changing.
Letting go as a feature
The hardest part of building systems that outlive you is accepting that they will be changed by someone else. They'll rename your variables. They'll restructure your database. They'll look at your beautiful architecture and think "this is over-engineered" and simplify it in ways that make you wince.
And that's fine. That's actually the point. If your system is so fragile that it can't survive someone else's opinions, it was never really infrastructure. It was a personal project with a company logo on it.
The goal is to build something solid enough that future decisions can be made on top of it, even decisions you'd disagree with. That's what "outliving you" means. Not permanence. Adaptability.
Build like you're leaving tomorrow. Document like the next person starts Monday. Design like you'll never be asked to explain it.