November 2014 was a frenetic time at Uber. I was on the Launch Operations team and we were activating 10 to 20 new cities every month. My job was to collect and share learnings from every launch to ensure the next launch was even better. We were refining our coveted playbook for using systems and tools in (near) real time. It was brutally hard. Little did I know, I was receiving a best-in-class education on how documentation can scale a generational company.

Knowledge Debt is expensive

‍

‍

After helping to launch Uber in dozens of cities, I came up with a formula that represented the hill we were climbing each day. 

‍

‍

On the Launch Ops team, we measured our Rate of Business Change by the number of new city activations. And we measured our Rate of Knowledge Transfer by the number of process guides added or updated in the launch playbook. 

Our job was to keep the equation balanced. Failure to keep up with business change caused major issues: high passenger wait times, bad driver experience, frustrated teammates, missed revenue targets. I realized later this equation applies to every business. 

I recently hosted an event with 155 knowledge management professionals and learned that most organizations are struggling with Knowledge Debt. 

‍

‍

It’s not surprising. Knowledge Management and Operations teams today have a near-impossible job, keeping up with the Rate of Business Change, managing expanding tool sets, and servicing global remote teams. I asked the group at the event about their top challenges and a few themes emerged:

• Knowledge and operations teams are too small to keep up with the business
• Creating documentation requires hours of tedious work 
• Subject matter experts are too busy to help us with knowledge sharing
• We don’t get feedback from stakeholders so we can’t improve
  ‍

I experienced all of this at Uber, and since then, the landscape for Knowledge and Operations professionals has only gotten more complicated. Equipping the team with the latest best practices was rewarding—but also tedious and sometimes frustrating. It was hard to keep up, and there were a lot of challenges while moving knowledge from idea > process > documentation > successful use within the team. This is the first time I considered the idea of a Knowledge Transfer Pipeline. 

What is a Knowledge Transfer Pipeline?

Over time, I identified and refined all of the steps needed to get knowledge into the hands of my Uber teammates and landed on the following framework to define the Knowledge Transfer Pipeline: Prioritize > Create > Publish > Optimize. 

‍

‍

The exact steps for your company may be a little different, but there are three reasons every company needs a Knowledge Transfer Pipeline:

1. Institutional Knowledge = Intellectual Property.

The internal know-how needed to build products and generate revenue is just as valuable as your patents and code bases. Yet, most companies treat their knowledge casually comparatively. To use knowledge as a competitive differentiator, we have to codify the steps we take to cultivate it. 

2. We can only improve what we measure. 

Once your steps to transfer knowledge are solidified, you can measure efficiency, remove bottlenecks, and increase quality. It also becomes possible to show the impact Knowledge and Operations teams have on programs like new hire training, software rollouts, standard operating procedures, and change management. 

3. Great people can do great things. 

But not if they’re spending their mental energy looking for information to operate tools and perform basic tasks. More up-to-date documentation ensures employees have the knowledge they need to do their jobs. This reduces their cognitive load, allowing your people to do their best work and have a bigger impact on company success.

The 4-Step Knowledge Transfer Pipeline

We used this four-step Knowledge Transfer Pipeline at Uber, and we use it today at Tango: 

Step 1: Prioritize

Collect documentation requests, prioritize according to business goals, and match up documentation needs to the right subject matter experts. 

Questions to get you started: What are our current business goals? What documentation can we provide to impact those goals? Who are the experts for this software or specific process?

Step 2: Create

Capture the step-by-step process, standardize the content, and review it for quality, compliance, and brand guidelines. 

Questions to get you started: What process and tools will the experts use to create this documentation? Who else needs to review to ensure quality and adherence to standards?

Step 3: Publish

Push completed documentation to your knowledge base(s) and notify users. 

Questions to get you started: What format does this documentation need to be in? Which knowledge bases have old versions of this document? Who’s using the old documentation and who needs the new version? 

Step 4: Optimize

Monitor usage of your documentation, collect feedback from users, and iterate to drive greater efficiency and higher stakeholder satisfaction scores. 

Questions to get you started: Who’s using this documentation? How do I know if they’re having success or failure with the process? What changes can we make to improve their experience? 

Once you understand the steps in your pipeline, you can start to measure and remove bottlenecks from each phase.

Remove bottlenecks from your Knowledge Transfer Pipeline

Here are some of the most common bottlenecks you’ll see in your Knowledge Transfer Pipeline—plus solutions to speed up your Rate of Knowledge Transfer.
 

❌ “Our Knowledge Management team is too small to keep up”‍

Impacts: Prioritize, Create, Publish, Optimize

This is the most common bottleneck I hear from knowledge and operations teams—and it has the biggest impact on your Rate of Knowledge Transfer. Your team might never be big enough to keep up with your business so you have to work smarter, not harder.

✅ Scale your team by decentralizing the content creation process and empowering subject matter experts to create documentation themselves. Work with functional department heads to build documentation goals into quarterly KPIs and reward top contributors. Delegating content creation to your experts on the “frontlines” will lead to better content and help you move faster. 
‍

❌ “Our subject matter experts are too busy”‍

Impacts: Create, Optimize

We often focus entirely on the experience of our employees/customers and forget to streamline the experience for our subject matter experts (SMEs). Your SMEs are probably busier than the average team member and creating documentation can feel like a thankless job so there is a reverse incentive structure in place for them to help.

✅ Remove friction from the creation process for SMEs and you’ll attract more experts— which means exponentially more documentation. Catering to them by running screen share sessions, hiring ghostwriters, transcribing videos, and acknowledging them publicly with praise and awards might sound time-consuming. But the more barriers you remove for SMEs, the more SMEs you’ll attract, and the more you’ll be able to scale your knowledge transfer process. 
‍

‍

❌ “It takes too long to create content and get approvals” 

Impacts: Create

For your experts, the hardest part of creating documentation is usually writing and technical skills. Video, for example, is labor intensive and requires specialized editing skills. Long, text-heavy documents require writing skills. Given everyone writes differently and may use different tools to create documentation, lack of standardization is one of the reasons approvals take so long after your initial drafts are ready.  

✅ Scale down your tools and formatting to the minimum viable context needed for your stakeholders to do the job. For most training, a simple, step-by-step how-to guide with a short description, and screenshots is most effective. Your SMEs will save time, and your content will come out more standardized—which will save time on reviews and formatting. And your stakeholders will be happy you got rid of the fluff. 
‍

❌ “People don’t use the documentation we make”

Impacts: Prioritize, Optimize 

An easy way to waste time and slow down your pipeline; create training material that people don’t want.

✅ Help your stakeholders feel invested in the work you do by A) giving them a forum to make requests, B) acknowledging their ideas in writing, C) offering transparency into your priorities and timelines, and D) following up to see if new documentation meets their needs. 

✅ Publish content in context where stakeholders are likely to need it. For example, to help Sales, embed how-to guides about converting leads to opportunities in the Slack channel where they get alerted to new leads. Not only will that save them from looking for what they need and asking you where it is, but it will also ensure they use the most up-to-date versions. This might mean keeping track of even more knowledge bases, but it’s worth it. 

‍

❌ “We have too many different knowledge bases”

Impacts: Publish, Optimize

There are more official and unofficial knowledge repositories today than ever before. You can’t operate as if there is only one official source of truth. And you can’t cut corners when it comes to tracking documentation versions and locations.

✅ Keep a list (could be a spreadsheet) of all of the systems where your people get answers to questions. If your list doesn’t include Slack, MS Teams, Google Drive, OneDrive, or at least one unofficial knowledge base, start over. 😁 If you don’t invest the time upfront to distribute knowledge to all of the places your team looks for answers, you’ll waste even more time on the back end answering the same questions over and over.

‍

❌ “We don’t get any feedback so we can’t improve”

Impacts: Prioritize, Publish, Optimize 

Just like any good product knowledge manager, we have to talk to our stakeholders (internal and external). Regardless of whether your knowledge base provides stats about usage, collecting anecdotal feedback is critical to improving. 

✅ Form a knowledge advisory group and bring them together quarterly to get feedback about what’s working and what’s not. If there are too many processes to discuss, make a list of the most and least used training guides and focus on those. 

The cost of failed knowledge transfer

When we launched Uber into the Tokyo market in March 2017, we deployed a dispatching strategy called “the donut radius.” The idea was that by connecting riders with drivers who are a few minutes away from their location (versus ones that are closest to their location), we could more evenly balance supply and demand. 

Donut dispatch works well in cities like Portland and New Orleans, where regulations limit the number of driver sign-ups. Tokyo initially looked like an ideal match for the donut dispatch radius. But it turns out, unlike Portland and New Orleans, Tokyo riders had better, cheaper transportation alternatives—so they moved on when they had to wait too long for an Uber. 

We learned this when launching Singapore but didn’t transfer the knowledge to the Tokyo team in time. And it cost us: Negative Uber sentiment spread across Japan. Repeat rider percentage was below targets. Low demand caused drivers to cancel, which led to even longer wait times—a vicious cycle that cost the company millions and cost our team credibility. 

Uber became a global sensation. But not in Japan. There are many reasons we didn’t take hold in that market—donut dispatch is only one of them. Yet to this day, I still think about the learnings we left behind and the resulting opportunities we missed.

Manage your knowledge like a product

If the Knowledge Transfer Pipeline looks familiar to you, that’s because I stole the idea—I mean, I was inspired by all of the great Product Management and Software Engineering teams I’ve worked with. The time and energy we invest in standardizing, measuring, and streamlining the product development pipeline are exactly what’s needed for our institutional knowledge. 

As internal knowledge becomes more critical to helping companies innovate and differentiate, I envision a world where Knowledge Debt is an executive board room metric, knowledge is managed like a product, and knowledge managers are celebrated like product managers. I’m starting a community to bring together like-minded people to help build this movement. Join the founder’s list and email me directly to share your ideas and experiences. 

‍