Transfer learning (and transferring your learnings)

Today I learned about transfer learning as a machine learning principle. I liked the concept so much that I immediately applied a mental map about this in my own head to how it might relate to job transitions in the business world.

Before I share that with you, here’s my novice primer on transfer learning for context:

In essence, transfer learning is when you collect and analyze enough data to build a machine learning model that serves one purpose, but you can apply it another way. We were discussing this concept in relationship to BERT, Google’s machine learning model that’s been open sourced for general use AI and natural language processing (NLP).

While Google started with a general problem — “How can we contextualize information about the English language so that answering questions is easier?” — now it’s easy for anyone to add something specific on top of it. For instance: “How can we make it easier to ask and answer questions all about indoor carpets and rugs?”

If you were to ask a very specific question about a particular rug in the general NLP model today, you likely wouldn’t get a super specific answer. But, like an ever-growing game of improv, you can “yes and” that original model, dumping in tons of data about rugs and carpets, in addition to catalogues from stores, the way they are cleaned, how you value them, and how you make them. Over time, you’ve made a general model into a specific one. Ta da!

It’s called transfer learning because you’re essentially transferring the model from one use case to the next. You can apply this in a million different ways. But none of it would be possible if you weren’t starting with some shareable model that’s broadly accessible to begin with.

I thought about this principle related to the business world in an area I think about a lot: Talent management.

Consider this: One of the toughest parts about growing any organization is the knowledge transfer that needs to take place. Suddenly, ideas that were in the minds of one person need to be in the brains of a three-person co-founding team. Then into the brains of the first 10 employees. Then 100. Then who knows how many.

For each person that leaves an organization, there’s an immediate gap to fill, a hole that is empty until somebody else comes along to plug it up. And at that moment, what happens to the “data dump” of somebody’s brain about their job, their responsibilities, and their projects?

Suffice it to say that you can’t simply download your brain and upload it into the new person’s hard drive.

Organizations that fail to effectively share knowledge throughout each subsequent wave of succession will never scale effectively. There’s a learning transfer problem that needs to be solved every time we make a change in personnel or team at a business. So how do you do this?

When you leave a job, it’s not good enough to make a list of all of the things you did and link to where everything lives. I learned this the hard way when I left my previous company. I thought it would be good enough to share my mental data-dump with everyone around me when I left. So I spent three weeks tracing every project I worked on for four years, cleaning up the pieces, putting them in obvious places, and then notifying everybody about where it all lived.

It pains me to admit this, but that exercise was a complete waste of time.

People don’t learn the same way machines do. If they haven’t been a part of the process, they haven’t internalized or learned it themselves yet. And if they haven’t internalized it, then whatever you built will live and die with you. You haven’t transferred your learning. You’ve just memorialized it in a display case. That’s a very different thing.

Wouldn’t it be nice if we could figure out a more seamless way to do this as humans in the workforce? To transfer our learnings?

Turns out, we have. It’s called teamwork and collaboration.

I think too often we look at teams and ask, “What is everybody’s job to do?” And too infrequently we ask, “What can everyone learn from each other?” They are both true, of course. Everyone has a job to do and everyone can learn from each other. But if we ask these two questions all the time — at the start of a new project, in the midst of a goal-setting exercise, at a debrief session over drinks — then we’re always thinking about how to best use the smart brains of the people around us. We’re priming ourselves to always be asking: “What do they know that I don’t? How can we work better together?”

With this mindset in mind, over time, when one person on that team leaves, my guess would be that the team could recoup and recover from that loss a bit more easily. They not only would know the exact role that absent person played, but the kinds of questions they asked, the ways they evaluated information, and the frameworks they used to make decisions.

It’s this stuff, the squishy intangible stuff that doesn’t quite fit nicely on a Google Doc or Trello Board, that the team collective can infuse and pass along to the next person. That’s how transfer learning happens in business.

There are a lot of things to like about open source projects and platforms. For one, it means you never have to start from scratch if you don’t want to. Second, it helps us collectively advance further than we may have been able to do individually. And third, it forms a community of collaboration around an idea that catalyzes even more energy and momentum toward that project.

But there’s a fourth thing I like about open source, too: That ideas are free. And the more you put out there, the more you can take back and apply in a new way.

Originally published at Dry Erase.