A recurring theme for my clients is knowledge transfer from one group to another. With these transfers’ regularity, one might expect a certain level of expertise in these transitions, but more often than not, they are full of challenges and surprises. So here are my current thoughts on how to handle knowledge transfer.

Set Objectives

The first step is identifying how you know the new group has enough knowledge to succeed. The obvious start is saying that they can perform the previous group’s duties without too much added support. We want to break this down further. I’ve seen some groups get down to the minutiae of detailed tasks, but I think that is overkill. So here’s an example for a typical agile team’s transfer objectives:

• Develop a user story to the existing definition of done
• Deploy code to current practices and standards
• Work with another group through a dependency
• Troubleshoot a bug or defect

You can likely identify more, but these likely represent the core items of an agile team transfer. You’ll want to pay attention to things that might be a little more invisible as well, like:

• Refine features with product owners
• Provide high-level scoping for new initiatives
• Update standard reports and metrics

I’ll put one more here that everyone seems to forget, but it is so simple and yet so annoying to get wrong:

• Transfer calendar meetings and invitations

Seriously, don’t forget that one. If I got paid every time a team didn’t show up to something because nobody remembered to invite the new team, I’d retire.

Pair As Much As Possible

Ok, now we want to talk about how to accomplish those objectives. My default way of accomplishing knowledge transfer is through pairing.

I know this is an ideal scenario, and many groups don’t have much overlap between the two teams, but any amount helps.

The incoming team adopts a “See one, do one, teach one” approach to everything that happens. The exiting team recognizes that the imperative they have is to slow down enough to facilitate that approach.

Take time to tell the exiting team that you expect their capacity and delivery to drop significantly, but not the quality. They are moving into a different mode. They are moving from delivery to teaching.

Both groups update relevant documentation as they work.

I also recommend having a few touchpoints where people can reflect on how the process is going. The moments they have together are invaluable, so reflecting on how to improve them in those few moments is worthwhile.

Document

Documentation is the default answer many groups resort to when transitions occur, and unfortunately, it’s very inadequate—most people who write struggle to write to their audience.

That means the documentation they produce makes sense to themselves, but their audience remains confused.

A great test of this is having someone get the project started using the documentation the team has. You’ll find within minutes that the instructions are woefully incomplete.

The point here is that belief that you can document your way through a transition is dangerous, but sometimes it’s all we have.

So the way I recommend people document is in pairs again. One person writes, and the other executes against those documents as though they were a dumb robot. They take a, “Well you didn’t tell me that” approach. This is infuriating, but it helps work through massive gaps in documentation.

When it comes to documentation, document according to your objectives, don’t get lost doing lots of architectural documentation if it won’t help directly with your objectives. Time is finite, and focusing on the best bang for the buck here matters.

Leaders Stepping In

Ok, my last variable here is with the front-line managers who tend to remain through transitions. When the odds are that the transition is a mess, they have a unique option. They become experts themselves.

In the options I provided above, most front-line dev managers can join in. They can pair with the team. They can help document and be the dumb robot.

While many managers will get cold-sweats reading this particular advice, it is a bit like jumping into cold water for one big shock vs. tip-toeing in and experiencing long gradual misery. The shock of becoming an expert quickly vs. suffering a prolonged struggle as the new team starts.

I don’t expect in this scenario that managers become experts, but the amount of context they can fill in and have moments where they remember some obscure thing will be invaluable to the new team that shows up cold to the situation.

It Is Messy

I’ve gone through this process many times and even used formal frameworks to accomplish knowledge transfer. There isn’t any magic here, unfortunately. The key ingredient is recognizing that equipping the new team becomes a real priority instead of continued delivery. From there, you can find the right mix of techniques to give yourself the best chance possible.