Mike Phillips Tech

When critical processes live only in people’s heads, the cost is invisible — until someone leaves, and suddenly it isn’t.

By Mike Phillips

Every organization has knowledge that isn’t written anywhere. The engineer who knows which config flag to flip when the deployment pipeline stalls. The account manager who knows which client needs a call before receiving bad news. The operations lead who knows the three steps that don’t appear in the official onboarding doc but actually matter.

This is tribal knowledge — institutional understanding that exists in people rather than in systems. In small, stable teams, it functions as an invisible infrastructure. It keeps things running without requiring documentation, process design, or deliberate knowledge transfer. For a while, it works well enough that nobody questions it.

The problems emerge when circumstances change. And in tech organizations, circumstances change constantly.

The exit problem

Turnover is the most obvious trigger. When someone who holds critical undocumented knowledge leaves — voluntarily, involuntarily, or due to illness — that knowledge leaves with them. What remains is a gap that’s difficult to measure precisely because no one knew the knowledge existed as a discrete thing. The work just… stops happening correctly, or stops happening at all.

The cost shows up in error rates, extended onboarding times, repeated mistakes that the previous employee never made, and customer-facing inconsistencies that are hard to trace to a root cause. Organizations often attribute these to the difficulty of hiring good people. The actual cause is that they never built systems independent of any individual person.

The actual cause is that they never built systems independent of any individual person.

This problem compounds at scale. A five-person team with a tribal knowledge problem can course-correct relatively quickly — the remaining four people share enough context to reconstruct most of what was lost. A fifty-person team with the same problem faces a much harder recovery, because the knowledge was distributed across more people, more processes, and more informal relationships that don’t survive reorganization.

The scaling problem

Growth creates a second version of the same issue. A process that works when three people execute it from memory becomes unreliable when twelve people need to execute it consistently. The informal calibration that kept the small team aligned — the hallway conversation, the instinctive understanding of what the process is actually trying to accomplish — doesn’t transfer to new hires, contractors, or distributed team members who weren’t there when the process was developed.

Tech organizations are particularly exposed here because they tend to move fast, hire quickly, and treat documentation as something to do later. The logic is understandable: in an early stage, the cost of stopping to write things down feels higher than the cost of keeping things in people’s heads. That calculus inverts as the organization grows, but the inversion often isn’t recognized until something breaks.

The break usually happens in one of three ways: a key person leaves, a compliance or audit requirement surfaces undocumented processes as a liability, or an AI or automation implementation fails because the underlying workflows were never actually structured. The organization then has to rebuild its knowledge infrastructure under pressure, which is significantly more expensive than building it proactively.

What structured knowledge actually looks like

The alternative to tribal knowledge isn’t bureaucracy. It isn’t a documentation initiative that produces a hundred-page manual nobody reads. It’s a deliberate approach to capturing how work actually happens — in formats that are accessible, maintainable, and built around the way people actually look for information when they need it.

That means process documentation that describes real steps, not idealized ones. It means workflow maps that reflect current reality, not how things were supposed to work when the process was first designed. It means structured formats that new team members can navigate without asking someone who’s been there for three years.

Organizations that do this work don’t eliminate institutional knowledge — they convert it from a liability into an asset. The understanding that previously existed only in specific people’s heads becomes something the whole organization can access, build on, and update as things change.

Tribal knowledge is a structural risk that most organizations are carrying without fully accounting for it. The cost isn’t visible on a balance sheet until something goes wrong. By then, the option to address it proactively is gone.