Knowledge Transfer is Hard

When I left my previous job, I wanted to do things right. I documented everything about my work so thoroughly that I thought my replacement could step in without missing a beat. I wrote down every detail: the clients I worked with, the special cases I handled, and even the unconventional ways I generated reports. I wrapped it all up before handing in my two weeks' notice.

During my notice period, I refined the documentation and answered any lingering questions. But a month after I left, my old employer reached out and offered me contract work to help them sort things out. I had already moved on, so I declined. Still, for the next year, I kept getting messages from former coworkers asking for help. The funny thing? Everything they needed was already in the documentation.

Have you ever had someone ask you the same question right after you explained it? It can feel frustrating, but it’s a reminder that knowledge transfer isn’t easy. One of the most common—and wrong—conclusions people jump to is that others are just not paying attention. More often than not, though, they’re missing some key piece of context.

In a perfect world, you could just hand someone all the information, and they’d get it. It’s like imagining you can read a Wikipedia page and instantly become an expert. But the reality is different. Reading one page usually leads to opening a dozen tabs to understand the definitions, the concepts, and the context, and suddenly you’re lost in a rabbit hole.

Here’s the thing: giving someone all the information doesn’t mean they’ll understand it. The key to effective knowledge transfer is focusing on what’s relevant and skipping the rest.

I apologize for such a long letter; I didn’t have time to write a short one — Mark Twain

As a programmer, I find myself answering questions with "it depends" all the time. It’s my way of acknowledging the complexity of a problem while also leaving room for the unknown. But when I’m talking to non-technical people, I’ve learned that I can’t just throw technical jargon at them or explain every detail of the system. It overwhelms them and usually doesn’t help.

Instead, the goal should be to tailor the explanation to the audience. What do they actually need to know? You don’t have to explain every moving part. For example, when documenting your work, you might be tempted to write something broad like, "The API supports all HTTP methods." That’s technically correct, but it’s not helpful. A better approach would be to say, "To update a user’s profile, send a PUT request with these fields." Specific and actionable information is what people will actually use and understand.

Another thing to remember is to confirm understanding. Never assume that someone "got it" just because you explained it once. Make things explicit. If you’re walking someone through a multi-step process, don’t just list the steps and expect them to connect the dots. Instead, say, "After Step 2, you’ll see X happen. That means you’re ready to move on to Step 3." And when possible, ask them to repeat the steps back to you or show you what they’ve understood. This not only ensures clarity but also opens the door for them to ask questions about anything they might still find confusing.

Repetition also helps. Just because you’ve explained something doesn’t mean it’s going to stick. People are constantly bombarded with information, so important details can easily get lost. Repeating key points, both in writing and during conversations, can make all the difference. A good rule of thumb is to introduce your main points early, bring them up again naturally as needed, and then summarize them at the end. What feels repetitive to you is often what helps others absorb the information.

At the heart of it, good knowledge transfer is about empathy. Put yourself in the other person’s shoes. What do they actually need to know? Are there any assumptions you’re making about what they already understand? Are there gaps in your explanation that could cause confusion? By focusing on clarity and relevance, you make it far more likely that the knowledge sticks.

In the end, transferring knowledge isn’t about proving how much you know. It’s about making sure the other person knows enough to do the job.

---