SOPs are dead. Transcripts are the new knowledge base.

Where is the knowledge that makes your team effective?

That’s the first question I ask every company I work with. The answer is always the same.

It’s in people’s heads.

Not in the SOPs. Not in the Confluence pages. Not in the shared drive nobody’s opened since Q3. The knowledge that makes the difference between someone who’s been there six months and someone who started last week lives in conversations, habits, and the institutional memory of people who’ve been doing the work.

None of it is written down. And that’s fine.

The SOP paradox

Every company has had this moment. Someone says: “We should document our processes.” A project is born. A few people write SOPs. They’re thorough, detailed, and immediately outdated.

Nobody reads them. Nobody updates them. Six months later, the SOP describes a process that no longer exists because the team found a better way, the tool changed, or the person who wrote it left and their replacement does it differently.

SOPs fail because they’re written once and forgotten. They’re a snapshot of how things worked on the day someone had time to write them down. The next day, the work moves on. The SOP stays frozen.

This isn’t a discipline problem. It’s a design problem. Asking people to stop doing their job to write about doing their job is backwards. They’ll choose the job every time. Because that’s what they were hired to do.

“Most people write SOPs once and then they get forgotten because nobody gives a damn about writing when you’re doing the work.”

That’s not a flaw. It’s human nature. And any system that fights human nature will lose.

The alternative: just talk

What if you didn’t have to write anything down?

Here’s what we do instead.

We find the best person on the team — the one who always has the answer, who trains the new hires, who has the shortcuts nobody else has figured out. We say: talk to me.

Explain your job. How do you start your day? What do you check first? When something goes wrong, how do you know? What are the edge cases? What would you tell someone brand new?

Record the conversation. Transcribe it. Structure it.

That one conversation — 45 minutes to an hour — produces more useful operational knowledge than any documentation initiative I’ve seen. Because it captures the real version. Not the org chart version. Not the compliance version. The version that lives in the gap between “how we’re supposed to do it” and “how we actually do it.”

Why talking beats writing

When people write SOPs, they edit themselves. They think about format, structure, making it look professional. They leave out the messy parts — the workarounds, the exceptions, the “well, technically we’re supposed to do it this way but actually we do it that way.”

When people talk, they don’t edit. They stream.

One thought leads to another. “Oh, and by the way — the reason we always do that on Tuesday is because the system updates overnight Monday and the data isn’t reliable until Tuesday morning.” That context would never make it into an SOP. But it’s the kind of thing that makes the difference between an agent that produces useful output and one that produces garbage.

Conversations also surface priority. When someone talks about their work, you can hear what they care about. The things they mention first are the most important. The things they get animated about are the pain points. The things they say “everyone knows this” about are the institutional knowledge that nobody ever bothered to capture.

From transcript to knowledge

Transcripts are inputs, not outputs. You don’t hand a raw transcript to an AI and say “good luck.” You structure it.

The transcription becomes a knowledge file. The knowledge file is organized by level:

Company level. Who we are, what we do, how we work, what matters. Every agent in the system reads this. Every new hire — human or AI — starts here.

Department level. How this function operates. What the team looks like. What the goals are. What the constraints are. What the culture is. Every agent in the department reads this.

Job level. How this specific role gets done. The tools, the shortcuts, the edge cases, the archetypes, the examples of good work, the examples of bad work and why. Only the agent doing this specific job reads this.

This structure makes the knowledge reusable. The company knowledge feeds every agent. The department knowledge feeds every agent in that function. Only the job-specific knowledge is unique.

And here’s the part that surprises every company we work with.

You never touch the knowledge after that. You just talk to it.

New insight? Record a 10-minute conversation. Update the knowledge file. Every agent that reads it gets the update automatically. No revision committee. No “who owns this document.” No quarterly reviews that nobody does.

The knowledge stays current because it’s captured the way it’s generated — through the work itself.

The compound math

The first agent requires all three knowledge layers. Company, department, job. That’s the most effort.

Every subsequent agent in the same department reuses two of the three layers. You’re only building the job-specific knowledge.

By the fifth agent, you’re adding two or three specialized files on top of a deep foundation. What took weeks for the first takes days for the fifth.

This is why “start with one” isn’t a limitation. It’s a strategy. That first agent builds the knowledge foundation every subsequent one accelerates from.

The problem this solves that nobody talks about

People leave. And when they leave, their knowledge leaves with them.

The coordinator who knows which vendors respond on Tuesdays. The salesperson who knows exactly how to position against the main competitor. The marketing manager who has the workaround for that one system limitation that’s been there for three years. The compliance expert who knows which claims always get flagged and which always pass.

All of it walks out the door when they give notice.

The two-week transition is a formality. Nobody captures everything in two weeks. Most of what they know was never written down in the first place — because it was never supposed to be. It was supposed to live in their head, available on demand, applied through experience.

With transcript-based knowledge capture, the problem shrinks. Not because you asked people to write exit memos. Because the knowledge was captured continuously, through conversations, as part of the work. The new hire doesn’t start from scratch. They start from everything the departing person knew — structured, organized, and immediately accessible.

The onboarding reversal

Something happens that surprises every company when the knowledge base reaches critical mass.

New hires stop being helpless.

Instead of shadowing a busy colleague for two weeks — hoping to absorb enough through osmosis — the new hire starts by interacting with the knowledge base. They ask questions. They learn the systems. They understand the edge cases.

By the time they sit down with their manager, they’re asking specific, probing questions that only come from already having the foundation. The manager who used to spend two weeks hand-holding now spends one focused hour on the stuff that requires judgment and context.

Onboarding in reverse: arrive proficient, then go deep.

How to start

Pick one role. The one where the knowledge gap is most painful — where new people take the longest to ramp up, or where one person is the bottleneck because only they know how to do it.

Sit with that person. Record a conversation. Forty-five minutes. Tell them: teach me like I’m brand new.

Structure the transcription. Company context, department context, job-specific knowledge.

You’ll have a knowledge file more useful than anything your documentation project ever produced. And you’ll have it in a day, not a quarter.

The SOP is dead. The conversation is the source of truth. And the companies that figure this out first will build a knowledge advantage that is very hard to replicate.