The Knowledge That Lives in the Moment

Think about how you learned the most important things you know.

Not the things you read in a manual or sat through in a training session. The things that actually changed how you work. Someone showed you. Or you watched someone who had done it a hundred times before you Or you made a mistake in front of someone experienced enough to turn it into a lesson. The knowledge passed from one person to another through proximity, observation, and time.

That chain, each generation learning from the one before is how expertise has always moved. It is also, I think, one of the quietest assumptions underneath everything knowledge management tries to do.

Which is why I keep returning to a question I cannot fully resolve yet.

Every system I have encountered captures knowledge in one of two moments: before a decision or after a decision. Before a decision, you have policies, guidelines, training materials, and processes written by someone who understood the task and hoped the document would last beyond them. After a decision, you have lessons learned, retrospectives, and post-mortems that everyone agrees are valuable but often sit forgotten in a folder.

What remains unsolved is everything that happens in between.

Some frameworks get closer to this by capturing knowledge at the moment of use, during the workflow rather than after the fact. Others go further by building knowledge incrementally, recording even incomplete answers in the moment of need and refining them over time as the same problem arises again. That is a genuinely elegant idea. But even this process starts with someone recognising the problem they are facing.

The ten seconds before that recognition still don't fit into any system.

Consider the mechanic who drives a car briefly, returns, and points to the rear left wheel. The diagnostic tool revealed nothing. The mechanic heard something not recorded in any database yet. Three weeks later, if the driver ignored it, the issue would present itself at considerable cost. The best approach to capturing knowledge would document how the mechanic fixed it. It would miss what led them to listen to that particular corner of the car in the first place.

Then there is the baker whose decision delights me, the one who pulls a cake out five minutes early not due to a mistake in the recipe, but because the weather is humid and the oven runs hot in such conditions. They learned this not from a document but from hundreds of batches over ten years. That knowledge is in them, not in any recipe. When they stop baking, it goes with them.

This knowledge, the pattern recognition built through years of observation, adjustment, and occasional mistakes is among the most valuable any organisation possesses.

And yet it hasn't found a true home in any system. I find this deeply fascinating. It is also a significant gap in a field that has worked on this problem for decades. This could mean the problem is genuinely difficult, or it could suggest we have been looking in slightly the wrong direction. Possibly both.

Here is where my thinking took an interesting turn.

If the junior mechanic always receives a recommendation before their own instincts have time to form. If the answer is always there before uncertainty develops into experience, will they ever build the thirty years of pattern recognition that informed those recommendations in the first place?

I want to be honest here. I don't have the answer to that question. I have been in knowledge management long enough to recognise when I am at the edge of what I understand — a skill that takes longer to develop than it probably should, and that I am still not entirely sure I have mastered.

But here is what I keep returning to.

The knowledge that informs these systems came from human expertise. That expertise took decades to develop, shaped by the specific experience of not knowing and having to act anyway. It came from being the junior mechanic who needed to develop their own ear because no system provided one yet. It also came from pulling a cake out too late a few times before learning what humid days feel like.

Here is the question I haven't been able to shake.

The AI systems being built today are trained on human expertise accumulated over decades. Real judgment, real mistakes, real pattern recognition developed through years of uncertain, consequential decisions.

But if the next generation of practitioners grows up with an answer always ready, if the instinct never gets the chance to form because the system always steps in first - what does the AI of 2045 get trained on? The outputs of the AI of 2025, which was trained on humans - who learned by struggling, who developed judgment precisely because no system did it for them.

There is something quietly circular about that. Each generation of AI potentially a little further from the original source. Not wrong exactly but thinner like a photocopy of a photocopy — technically the same content, but something lost in each reproduction that you only notice when you put the original next to the tenth copy.

I am genuinely curious about it and think it is worth asking now, before the answer becomes obvious in hindsight.

This began as a knowledge management observation. Which it is. Then I took my thinking further than planned as one does when a question proves more intriguing than expected and ended up with more questions than I had at the start.

But before I leave you with something abstract — here is the practical question I keep revisiting.

The next time an expert in your organisation prepares to leave - do you know what knowledge they possess that has never been documented? Not their files or handover notes. What they know in the ten seconds before making a decision.

That is the inventory most organisations is yet to build on.

There is some encouraging movement in this direction. A recent piece in California Management Review described what a major automaker actually did when they faced this problem, their most experienced engineers were retiring and taking decades of judgment with them. Instead of asking them to write documents, they captured something different. The discussions, the debates, the way problems were talked through in engineering reviews. Not the answer but the reasoning that arrived at the answer. It is not a complete solution. But it is closer to the ten seconds before the decision than anything purely document-based has managed before.

If your organisation is facing this and most are — it might be worth starting there. When your experts solve something difficult, are you capturing how they thought about it or only what they concluded?

Reference:

1. California Management Review — "Tacit Knowledge Is Your Next Competitive Moat", by Teresa Tung and Philippe Roussiere

   Published: March 16, 2026; cmr.berkeley.edu/2026/03/tacit-knowledge-is-your-next-competitive-moat