In this guest post, Luke Conley delves into keys you should consider when putting together your knowledge transfer plans as your product develops in the market. Read on for part 1 of 2 in his series.
Here’s a question: why do ATMs feel like they’re stuck in the 1980s? In the age of Apple Pay, crypto whales, and contactless transfers, shouldn’t we have swooping, beeping techno-terminals with 4k screens and digital assistants? Why can’t I use one with my phone? Why is the connection so slow? With $210 billion in investments poured into the FinTech space in 2021 alone, you would think that some enterprising Stanford dropout would have pounced on this.
The simple answer, unfortunately, is that it’s impossible. ATMs, like the majority of global financial infrastructure, run on a language called COBOL (”Common Business-Oriented Language”), invented in 1959 — one of the first high-level languages to build on Grace Hopper’s creation of the compiler. The famed computer scientist Edsger Dijkstra wasn’t a fan — “the use of COBOL cripples the mind,” he wrote. “Its teaching should, therefore, be regarded as a criminal offence.” But that didn’t stop COBOL from taking over the finance world — with some adverse effects. As Treasury Secretary Janet Yellen recently lamented to Congress, the IRS “is operating with technology from the 1960s that is archaic and no longer taught in any school in the country.” Refactoring the existing system is so complex and arcane an undertaking as to be functionally undoable.
The result is a serious knowledge bottleneck. There are working COBOL engineers in the field today who are so advanced in age that they’re on supplemental oxygen; they can’t stop working — in fact, they can’t die — because they’re the only ones who know what the code does.
It’s never good to keep everything in one person’s head. Let’s talk about knowledge transfer plans.
What this article will get you
- Suggestions for key tactics for making knowledge transfer frictionless
- A checklist of questions to answer when facilitating knowledge transfer in your organization
- A knowledge transfer plan template and suggested tools to help your organization smooth the transition
Three key points for Knowledge Transfer
You’re busy. Your team’s busy. Everybody’s busy. To fit in important institutional initiatives that, while definitely best practices, don’t necessarily reflect your output at the end of the quarter can feel like a drag — but it doesn’t have to. Knowledge transfer is the movement of necessary information throughout an organization; getting data out of one head and into many. It may happen as part of an outgoing transition or more proactively as an institutional push, but regardless of what motivates you, you’re likely to see tremendous results. Here are three key points to remember when you’re launching a knowledge transfer initiative:
Leverage network effects
A widely-cited 2008 article in the Engineering Management Journal (here’s a free PDF) made an interesting high-level discovery about knowledge transfer projects: the benefit to organizations is increased when knowledge transfer happens not just within projects, but between them.
This shouldn’t be too surprising: network effects are a well-documented driver of exponentially positive outcomes. But it presents a key opportunity. Let’s say you’re a VP of Product at a Series B startup who has never really gotten the traction you need to create a product-led organization — departmental heads naturally have their own impressions of what’s best for the company and how to get there. Understandable, but less than ideal.
I recently found myself in a similar situation as a consulting product manager for a youngish startup that had recently raised a significant round. Its sole product manager was leaving the company, and pretty much all of the edge cases, weird bugs, and stray suggestions about the next 6 months of roadmap lived solely in her head. We had a week to get it documented.
In addition to the usual documentation, we also spent some time speaking with adjacent departments like customer support and L&D to see what their current unmet needs were and where they’d like to see greater collaboration with Product. “We’re doing a documentation push,” we said, “and we’d like to know if there’s anything we can do to make your life easier.” It was a one-two punch: as we were seeking input from other teams, we also set ourselves up to disseminate product knowledge through the organization.
It went extremely well. Not only did we send off the outgoing product manager with the beginnings of a whole new approach to continuous documentation, but we planted the seeds for deeper relationships throughout the organization, creating the kinds of productive informal connections that lead to bottom-up collaboration and synchronicity between teams.
Many > few. Don’t forget about the network.
Use shared time with intention
Whether you’re launching a new company initiative involving multiple departments or facilitating a download from an outgoing teammate, the delicate balance of deep work time vs constructive collaboration is a perennial concern.
In our situation, this shared ground for a plan of attack was crucial. Our outgoing product manager’s last week also happened to be a stretch of time I had scheduled to travel to an entirely different timezone, with some PTO on the books when I would be unplugged. It just wouldn’t work to rely on ad hoc zoom rooms and late-night Slack pings; we had to be intentional.
After a brief exchange, we ended up with an agreed-upon calendar for the hand-off that would cover all of our bases while allowing ample time for both individual focus and collaboration:
Friday, 3pm EST: Luke publishes a Notion doc with specific open questions from Engineering and Product leadership and ICs on what needs to get into the backlog and the user documentation.
Monday, 9-11am EST: Luke and Amanda pair on recording screenshare videos to document the existing workflow in production and beta. We’ll use this time to open tickets for any new bugs we find and facilitate tacit knowledge transfer between outgoing and future PMs.
Tuesday, Wednesday: Luke on PTO, Amanda will use this time to write tickets, fill out the backlog with initiatives discovered in the last 3 months of user interviews, and transfer the next 6 months of roadmap from a spreadsheet on her local machine to a shared Notion workspace accessible to the whole department.
Thursday, 12pm EST: Final sync, last round of open questions. Luke presents the finalized knowledge transfer to Product leadership at 3pm.
Friday: Amanda’s farewell party!
If we had left this process to chance or whim, we would have been screwed. By creating alignment around our intentions for how we would use our last week of overlap, we facilitated a productive agreement that allowed everyone to focus free of distractions while remaining confident that we were aligned and ready to get it done.
Time scheduled without intention is time wasted. When collaborating, make it count.
Remember we’re all human beings
While it’s great to have a proactive knowledge-sharing effort within your organization, it’s often the case that documentation brain dumps happen when someone is leaving the organization. All good things come to an end – and exit periods can be fraught with varied emotions, competing requests, one eye turned towards the next thing, and questions about what might have been done to retain people. It’s a charged time.
The end of a job can clarify intentions about what matters most in career, and for many, the answer is people. The outgoing product manager I mentioned above cared more than anything about supporting the engineers she had worked with so closely since joining the company — in our case, extraordinarily hardworking developers balancing the precious normalcy of a day job with extreme uncertainty and violence in their home country of Ukraine. Not an easy situation.
As Maya Angelou said, “people will forget what you said, they will forget what you did, but they will never forget how you made them feel.” Supporting outgoing coworkers is a chance to put others first and support a teammate on their road to what’s coming. We all have priorities in corporate initiatives, but sometimes the path to truly successful collaboration emerges from the soft approach. Ultimately, we ended our documentation push with a heartfelt goodbye to the Kyiv development team that reflected years of hard work and mutual respect — and it closed that chapter for the company in the most meaningful way we had available to us.
So there they are, three keys to successful knowledge transfer. Of course, you need a place to put all that institutional wisdom, and an organization-wide process for getting to it. In the next section, we’ll offer an example of a knowledge transfer plan template — one you can copy and paste to send out today. Plus, we’ll examine three of the most popular knowledge-based solutions, and how to get the most out of them.
Good luck with your knowledge transfer push! See you next time.
While you wait for the next part…access more great content on Mind the Product
- Discovery in an agile world – Anthony Marter on The Product Experience
- A case study – how to end cooperation with a software house or contractor
- The Heartbeat of Product by Nate Walkingshaw
