The Selfish Senior

Last week I got on stage at T3chFest to talk about something I was embarrassed about. This is the extended version of that talk, with the references and context that don't fit in 50 minutes.

When I submitted the proposal back in November, I thought I'd be talking about mentoring. About how seniors should share more. An important but calm topic.

Since then, things have happened. Models have been released that do things that four months ago seemed like science fiction. 84% of developers already use AI tools. The speed at which code is being generated is unprecedented.

And I realized that the problem I wanted to talk about wasn't a "it'd be nice to improve this." It's urgent. Because the talk isn't about AI. But AI is what makes it urgent. Because what truly matters is people. And what happens when people stop sharing what they know at the exact moment it's needed most.

It all starts with one sentence.

"I'm the only one who knows how this works."

Maybe you've said it. Maybe you've heard it. I've said it many times. With pride. It feels good. It feels like you're important, like you're indispensable.

But it's a trap.

The migration I did alone

A few years ago I led a critical migration: adapting a system that managed warehouse orders to also work in stores. In practice, it meant converting single-tenant software into multi-tenant. Each store had to see only its own orders, its own routes, its own inventory. A deep architectural change that affected nearly the entire system.

I did it practically alone. Not because nobody could help (I had a capable team). But the sprint ended on Friday, it was faster if I did it myself, and "I'll explain how it works when it's done." I never found the time.

One morning, the system failed. Stores were seeing other stores' orders. A data isolation issue (exactly the kind of bug where you need to understand the design decisions to know where to look). My team couldn't diagnose it. Not because they were bad engineers. Because nobody but me knew how the tenant separation had been implemented. They had to track me down to fix it.

What frustrated me most wasn't the incident. It was that it was my fault. Not because of a bug. Because I had built a system where only I could put out the fire.

We spend our careers designing systems with no single points of failure. Replicas, backups, rollbacks. And then we become exactly that for our teams: a single point of failure, but in human form.

What hurt the most wasn't the technical side. My team wasn't just frustrated with the system. They were frustrated with me. They had the talent to solve it, but I hadn't given them the tools.

The selfishness you don't know you have

For years I thought my case was a discipline problem. Not documenting, not doing pair programming, always having something more urgent. And that's true, all of it plays a role. But there's something deeper that took me much longer to understand.

In my article on invisible heuristics I wrote about Gary Klein's research with veteran fire commanders. Klein asked them how they made decisions when a building was burning. They all said: "We don't make decisions. We just follow procedure."

That wasn't true. Not out of malice (they weren't aware they were deciding). In reality, they recognized patterns at lightning speed and acted without deliberating. In 80% of cases, the first thing that came to mind was what they executed. And it worked.

Polanyi had described it: "We know more than we can tell." Tacit knowledge. Acquired through experience, not instruction. It can't be easily transmitted because the expert themselves doesn't know they have it.

Senior engineers do exactly the same thing. When something breaks at 3 AM, they look at a few signals and something tells them "look there." They don't start with the code -- they start with the symptoms. They classify before they investigate. They know what to ignore. Thousands of hours compressed into intuition.

This changes how I understand my own story. That morning when stores were seeing each other's orders, the problem wasn't just that I hadn't documented the migration. The problem was that there were heuristics in my head (about how a multi-tenant system fails, about where to look when data isolation breaks, about what to check first) that I couldn't even articulate. It's not that I didn't want to share them. I didn't know I had them.

The most valuable knowledge a senior has is exactly the knowledge they don't know they have. And if they don't make it visible, it leaves with them when they leave.

It's involuntary selfishness. But the result is the same.

The gap that's opening up

Everything above existed before AI. Seniors who didn't share knowledge, low bus factors, tacit knowledge that disappeared with turnover. It's an old problem.

What AI changes is the speed at which it gets worse.

As I wrote in The code nobody understands is already in production, we're filling production with systems that no human fully understands. AI enables producing from day one at incredible speed. But the heuristics that allow you to operate those systems (diagnose, debug, make decisions under pressure) were built through friction. Wrestling with a bug for hours. Watching someone experienced solve something right in front of you. Touching production code and feeling the consequences.

AI absorbs exactly those tasks. It's like giving a rookie firefighter a drone that puts out small fires. Great. But when the real blaze hits, they've never felt the heat.

There's a generation entering the workforce that produces more than ever but with fewer mental models. And another that has the models but doesn't share them. The space between the two is widening. And it's nobody's fault (it's a consequence of the shift). But someone has to close it.

The average lifespan of a line of code is about 3 years. The shelf life of a yogurt. But the knowledge you pass to a person compounds. That person passes it to another. And five years later there's an entire team making better decisions because of something you shared one afternoon.

AI makes code cheaper by the day. What's expensive is context. And context can only be transmitted between people.

Four ways to make the invisible visible

The good news: this is solved between people. Not with tools. With people talking to people.

In the talk I shared four practices. All four are bridges between the senior who doesn't know what they know and the junior who doesn't know what they don't know.

1. Document the why, not the what

In a commit, a message, a document (the format doesn't matter). Three questions: what problem it solves, what I decided, and what I discarded and why.

The paths you DIDN'T take are invisible heuristics made visible. It's exactly what Klein did with the firefighters: extracting the decisions the expert didn't know they were making. You're not writing documentation. You're writing a letter to the person who comes after you.

If I had documented why I implemented tenant separation the way I did (and what alternatives I discarded), my team could have diagnosed that failure without me.

2. Debugging out loud

Directly inspired by Klein's Critical Decision Method. When someone experienced investigates a problem, they narrate their process: "I'm looking at the gateway logs because the latency suggests the problem is before the service, not inside it."

Every sentence is an invisible heuristic made explicit. It works in any format (in person, over Slack, on a call). What matters is that the reasoning ends up somewhere.

And there's an unexpected bonus: by narrating your process, you discover things about your own reasoning you didn't even know.

3. Questions nobody asks

One session a month. No filter. "Why does this table have 47 columns?" "Why is this service called OrderProcessor if it validates inventory?"

Every unanswered question is knowledge debt. And the most valuable questions are usually the ones that seem most obvious (because they're the ones the team has been avoiding for years).

If you're a junior, you have a superpower you don't know you have: the ability to ask questions without assuming things are the way they should be. Don't lose it. And if you're a senior: your reaction in the first second when someone asks something "obvious" dictates whether they'll ever ask again.

4. The bus document

Write down the three things that would cause someone to call you on vacation. Just three.

When you write them down, you'll be scared by how much lived only in your head. And then you'll feel relief. Because you're no longer alone with that weight. Your team can function without you. That doesn't make you less valuable. It makes you free.

People, at the end of the day

Klein's firefighters weren't smarter than the rookies. They had a richer library of patterns. And the best ones found ways to pass that library to the new ones. Not out of obligation. Because they understood that their job didn't end with putting out the fire. It ended when the rookies could put it out without them.

Code is a means, not an end. And people are at the center.

And what we know doesn't belong to us. It belongs to everyone who comes after.

Question for you: How much of what you know lives only in your head? If you left tomorrow, could your team function without calling you?