Knowledge loss

Many employees change jobs in the Fall. They’ve received their annual rewards, returned from vacation, and then get reorg’d or decide it’s time to move on. When people change teams, their knowledge goes with them. Good teams handle these transitions smoothly because they’ve ensured that every area has a primary person and a backup. When one of those people leaves, the other retains the know-how.

However, not every team is good, and knowledge often gets concentrated in single individuals. When that subject matter expert (SME) gives two weeks’ notice, you as a manager or team member have a problem. What should you do? Force the SME to write documentation? Schedule marathon team meeting(s) for the SME to provide a data dump? Beg the SME to stay an extra couple of months or years? These are all terrible ideas with long track records of failure. Why? And what should you do instead? Read on.

That’s so wrong

It’s easy to panic when you think your team might lose vital information, especially if a critical SME provides short notice before they leave. However, panicked decisions are typically poor decisions. Let’s review common poor decisions made when a SME provides short notice.

• Force the SME to write documentation. Such a bad idea. SMEs are typically terrible at writing documentation, even when they have plenty of time. (That’s why companies hire technical writers.) Under time pressure, when their minds are on their next job, SMEs are even worse. Plus, how are you supposed to know which areas are the most important for the SME to document? You’ll almost certainly guess wrong. Usually, the SME runs out of time, and you’re forced into the second bad decision—the verbal data dump.
• Force the SME to provide a verbal data dump. Another terrible idea. At least SMEs can typically describe their areas verbally and on a whiteboard. So, you schedule several hours, bring the team together, and let the SME spew forth. However, retention is low in these settings. Your team doesn’t know what questions to ask, hasn’t developed the mental framework to retain the answers that are provided, and can’t focus long enough and deep enough to develop the level of understanding necessary for a smooth transition. Now you’re truly screwed, but at least you have a bad recording of the meeting, right?
• Beg the SME to stay. An awful idea. If the SME wanted to stay, they would’ve sought a counteroffer rather than given short notice. Often, they can’t stay. Even if they could, is an extra month or two going to make much difference? The SME is going to be focused on their next job, not your team. You’re delaying the problem, not solving it. If your begging and concessions persuade the SME to stay a year or more, you’re really in trouble. The SME now can demand special treatment, leading to internal strife that will only be resolved when the SME leaves the team as they planned to do in the first place.

You need a different approach to knowledge transfer that is more effective and sustainable.

I’m the new owner

The solution to knowledge loss is to focus on something other than the critical SME who provided short notice, because they’ll be gone shortly. It’s the team and the SME’s areas that need attention.

Assign primary owners to each of the SME’s areas (each area can have a different owner, or people can own multiple areas). Assign backups for each area as well (to avoid future turnover issues). Inform the primary and backup owners that they now have full responsibility for their new areas. The SME is only responsible for answering questions, and they’ll only be around for a limited time.

Each pair of owners (primary and backup) can determine how they’d like to proceed. Some may choose to document their area. Some may choose to fix bugs in their area or make other small improvements. Some may choose to read up on their area and get a data dump from the SME. Often people choose a combination of these approaches. Regardless, the pairs are motivated and committed to learning their areas because they own them—and they aren’t leaving.

The SME’s only responsibility will be answering questions from the new owners, which is work that is easy, reasonable, and in their core competency. When they leave, the SME will still be reachable, even if they work for another company. At that point, the new owners shouldn’t and generally won’t ask many questions (out of sight, out of mind), but the SME can still assist in an emergency. (If the SME is working for a competitor, be careful to only discuss past work for your team.)

Only I can fix it

If this conversation about a critical SME leaving has your heart racing, even though your team membership is stable, you might want to make some adjustments. Ensure there is a primary and backup owner assigned to every area, including legacy portions of your codebase. Those owners should review every code change for their area, track all the bugs and feedback for their area, and provide the estimates and designs for improvements to their area.

You might get pushback from a longtime area owner about sharing responsibility with a backup owner. The longtime owner might feel the area is their baby, and no one else can or should touch it. Those are understandable emotions worthy of acknowledgment. Explain the importance of shared knowledge and the advantages of having two sets of eyes on problems and backup for when someone is sick or on vacation. If the longtime owner still refuses to cooperate, they have become a pariah on your team and a danger to your business. Ownership of their area should be reassigned entirely before catastrophe hits. If that means the person leaves your team, so be it.

Onward and upward

Having turnover on your team is a good thing, even when you’re losing a longtime member who has critical knowledge. Turnover gives teammates a chance to try new areas, learn new skills, and grow in responsibility. It also brings in new people who provide fresh ideas and perspectives.

If a critical SME decides to leave and gives you short notice of their departure, there’s no need to panic. Don’t put the responsibility of knowledge transfer on the SME—they’ll do a poor job because they can’t read their teammates’ minds or the future and are already moving on to their next role. Instead, assign new primary and backup owners for all the SME’s areas. Allow them to determine how best to ramp up on their area and make use of the SME’s limited remaining time. Only expect the SME to be available to answer questions—a job they can do well.

If you’re worried about what would happen if a critical SME on your team left, ensure there is a primary and backup owner assigned to every area (including legacy code). If a SME refuses to share an area, reassign them entirely before the problem gets worse.

It’s easy to get comfortable on an experienced team with established knowledge and well-defined roles. However, change is inevitable. You can fight it or embrace it. Since fighting change is a losing proposition, I recommend embracing it.