DEV Community

Cover image for The Knowledge That Leaves When Your Best Engineer Does
Ali Abbas
Ali Abbas

Posted on

The Knowledge That Leaves When Your Best Engineer Does

There is a particular kind of silence that falls over a team about three weeks after a senior engineer leaves. It is the silence of nobody knowing why.

Why is this flag never allowed to default to true in production? Why does this background job retry exactly twice and then stop? Why did we drop the vendor SDK and call their REST API by hand? These decisions made perfect sense at the time. Now they look insane, and nobody remembers the reason.
The person who held all of that knowledge walked out with it. What they left behind is a codebase full of decisions with the reasoning removed.
We call this a single point of failure when it is a database and treat it as an emergency. Somehow we treat it as normal when the single point of failure is a person's memory.

Documentation has not solved this

For years the answer has been "write better documentation." It keeps failing for the same reason. Documentation is a tax you pay now for a benefit someone else collects later. Humans are bad at that trade.
The wiki goes stale. The ADR folder fills up for one enthusiastic month and then goes quiet. You have seen this.

Now we have AI agents with the same problem

AI coding agents are fast and capable, but they are permanently contextless. They never accumulate the institutional memory a human picks up over years of standups and incidents.
A strong agent will cheerfully reintroduce the vendor SDK you spent a sprint removing. To the agent there is no scar. There is no scar anywhere it can read.
The cost of lost context is no longer just slower onboarding. It now also includes a fleet of fast agents that will keep walking your team into the same walls, confidently and at speed.

Capture decisions where they are made

The fix is not to write more docs. The fix is to capture the decision at the moment it is made, in the place it is already being made — including the options we considered and deliberately rejected.
Then serve that reasoning back to whoever needs it: the new hire and the AI agent alike. The reasoning should outlive the person who made it.

That is what I am building at decispher.com (it is live and 100 seats left). It will not bottle a great engineer's entire judgment. It captures the specific, costly, reusable decisions before they walk out the door.

Who on your team is the single point of failure right now? And what happens to all of that knowledge the day they give notice?

Top comments (0)