NASA's Lost Technology Teaches Us a Lesson About Knowledge Transfer

One of my secret joys is reading conspiracy theories. In another post, I may explain more about why I find them so fascinating, but I read one this morning talking about how NASA lost the technology to go to the moon. I had to look it up because it actually sounded plausible. Sadly...it turned out to be true.

However, the conspiracy suggested that we never made it to the moon and, therefore, can't lose technology that we never had. But I find the actual implication of why NASA no longer has this technology even more deeply unnerving: maintaining organizational knowledge is incredibly difficult.

We've lost lots of technologies over the years, in all fields. Imagine trying to rebuild Ford's Model-T. You can't just pick up some molds, look up a few specifications, and slap together a system that'll produce that car without rebuilding the whole thing from scratch - essential re-inventing the technology. And most importantly, none of the people who developed that technology exist in the organization today.

This is what happened with NASA. The Apollo Guidance Computer (AGC) that made the moon landing possible no longer works with newer systems. So what do you do, try to update it? Go back and future-proof it? Develop entirely new tech? No matter what you do, the effort will be costly.

In the mad-dash to achieve space travel, there was a flurry of development where everyone was moving singularly forward - rather than slowing down to record the steps. Add in countless vendors and subcontractors with their own approaches and IP, and you have something incredibly difficult to track and translate to new-hires.

This begs the question: how do you transfer corporate knowledge to the next generation of workers? How can you diminish the impact of losing a seasoned employee? There's no end to potential solutions, but I want to highlight three key areas that I constantly see overlooked in companies with complex, organizational dynamics.

1. Define the Employee Journey that includes mentorship.

As much as we want employees to stay with us forever, the reality is that they will leave for many reasons: poor culture fit, more attractive options with a competitor, or even accidental illness or death. The best case scenario would be that they retire happily after years of fruitful, enjoyable service.

The issue is that employers rarely plan for an employee's exit - no matter the cause. Because they don't think about it, there isn't a plan for how to handle that knowledge transfer.

If an employee is set to retire in two years, when should I have him or her work with my new hires so they can pick up some of that insight and experience? What's that mentorship program look like? If I decide to include mentorship at the time I get news of the retirement, it's already too late.

My suggestion is to take time filling out your ideal Employee Journey map. It's just like your Customer Journey, but it describes the entire lifecycle of the people you hire - from onboarding to promotions to termination (pleasant or not).

My second suggestion within this bullet is to include mentorship as a given expectation in your organization. Hire people who enjoy it or have experience mentoring, and reward people for cascading essential knowledge to teammates.

2. Create a Corporate Mythology on each project.

Much like stories from tribes with strong oral tradition, your company has a rich lore. Stories make it easy to share complex information with employees in ways that feel natural. You're not training them on your history, but they readily pick it up key highlights through the tales you tell each other.

You likely have sales stories and default responses when handing customer objections, so why not do the same for your company's values, project wins, or product origin stories?

Even with nuanced technological processes, you can still attach narratives that summarize what the project problem was and what the team did to overcome it. That way, at a glance, readers can determine if the technological solution fits what they need to do.

I recommend collecting stories and compiling them into a Wiki or online document. These can be user stories or journeys that describe your customer avatars. Include in these documents the major decisions points and the rationale behind the final determination. Why did you choose this solution over another, and what was the positive outcome? What do you wish you did differently or would do if you had time to rework the project?

If you're worried about documentation ownership slipping when people get busy, then assign a person who has the task of managing follow-up. While it may seem like an expensive job function, it will pay off as you bring on new people that can rapidly get up to speed on your approaches. You should have an active log of each project. An added bonus is that this habit makes it easier to track progress while you're going through complex projects with overlapping milestones.

The point of these stories isn't to include entire code snippets or list out detailed processes, but instead convey the emotional or psychological effect of key decisions. For example, one of my company stories is about a time we delivered a video that our client hated. I share it with others because it illustrates a lot of the nuance we encounter when trying to educate clients about approaches that seem counterintuitive. The end product was great and it made that company an astronomical amount of money, but we weren't called back a second time. That's the risk you take as a consultant, especially when tasked with giving a client what they need instead of what they want. I don't regret our decision, and want my partners to adopt the same philosophy.

(If you feel intimidated with creating corporate stories, check out Sage Academy's online course that walks you through the process.)

3. Embrace newer iterations.

Not everything that's lost is a detriment. The past can teach us a lot, but we also don't need to stay there. The Model-T was a death trap. We have far safer and more efficient car technology now, so there isn't a reason to go back and build them.

One common pitfall I see companies fall into is that they don't review older approaches through the lens of improvement. I think this exercise is an essential part of the creative process: make connections between old solutions and new problems, as well as old problems to new solutions.

In the first case, it may be worthwhile to reinvest energy and resources to revitalize the technology. For example, e-ink technology was discovered a long time ago, but it didn't have a direct application at the time. So people sat on it until it was useful. Old solution, new problem.

In the second case, you find new opportunities to fix things others have slept on. What problems still linger that, because tech hasn't changed, remains stagnant? Back to the automobile, the basic design hasn't changed since the late 1800s. We still use combustion engines, and more than half the energy they use gets converted into heat. The design is due for a major overhaul.

Sometimes, there are technological improvements that, when used in conjunction with your solution, reach new heights. For example, there's a scene in Star Trek IV: The Voyage Home where the team gives instructions to a plexiglass company for creating a high-stress, thin-walled tank. It was deemed ridiculous at the time, but we now have transparent aluminum due to improvements in polymer technology.

Finally, embracing a "version 2.0" of your past solutions allows for upsells, new opportunities in different markets, and repackaging improvements as new features.

Conclusion

I hope you found this useful. There's obviously a lot more I could cover, but these three can have direct and immediate improvements on how information is transferred and preserved.

How are you maintaining essential knowledge within your organization and what are you doing to transmit it to newcomers at your company? Do you have any key tips to share with those that may be struggling to do this? Please share your ideas in the comments below.