Table of content
KEY TAKEAWAYS
When you hire faster than you can explain, shoulder taps stop scaling and documentation drifts out of date.
Peer-to-peer learning fixes it: a standing weekly session where whoever figured something out teaches it live, with questions.
Run it as a program: a set cadence, a voted topic backlog, no logistics for presenters, and a recording that feeds your people and your AI.
Intro
Recently I spent time with a couple of CEOs of fast-growing companies, somewhere between 100 and 300 people. Each had either just raised hundreds of millions of dollars or was doubling in size. And each of them was looking for the same thing: a program for peer-to-peer learning.
Their reason is easy to recognize. When you bring in a lot of new people, you get chaos. The old timers know everything. The new people don't. So the new people tap the old timers on the shoulder, and then the next new hire taps them again with the same question. Nobody likes to be interrupted for the same question 50 times.
I think these CEOs are right. When you are hiring faster than you can explain, peer-to-peer learning, run as a weekly program, is the most reliable way to keep everyone on the same page. Unlike documentation, it stays current and it answers follow-up questions. And every session leaves behind a record that your people, and your company's AI, can learn from.
Here is why it works, and how to run one.
What is peer-to-peer learning at work?
Peer-to-peer learning at work is when someone who figured something out, a veteran or a new hire, teaches it live to colleagues who can ask questions on the spot. A peer learning program is that habit run on purpose: a standing time, a backlog of topics, and someone else handling the logistics, so the expert only has to show up and share.
You may know it as tech talks, brown bag sessions or lunch and learns. I think of it as the campfire. People sit together, exchange stories and talk about what happened: the judgment calls they made and the insights they had. And they answer each other's questions. Most of that never gets written down, because it lives in people's heads.
Picture an hour or two once a week. Thursday lunchtime, say, with a topic or two. As the company grows there can be more than one: one for engineering, one for sales, one for product. It isn't a one-time event. It runs continuously, until it becomes a cultural standard.
It isn't only for new hires, either. Bringing someone up to speed is one milestone. But in a fast-growing company, people figure things out all the time, and the old timers need to hear it too. AI enablement is the clearest example right now. People try different tools and work out best practices, and the most useful thing they can do is say: let me show you what I figured out.
And it has to be live. A video is linear and static. You don't know how relevant it is, you can't stop it to ask a question, and you don't have access to the actual expert. In a live session you absorb the knowledge, but you also ask, probe and interact with the person who has it. Both of you learn. You still walk away with the recording. It just came out of a dynamic setting.
Why does knowledge break when a company doubles?
Because ad hoc knowledge sharing only works up to a certain size. When you know everyone, you know who knows what. Somewhere past 100 people, that stops working. You don't know everyone anymore, so you don't know whose shoulder to tap. And when you do find the right person, every interruption pulls them out of the zone.
Meanwhile, the knowledge itself is all over the place. Some of it is in Confluence, some in Slack, some in Google Docs and the other apps you use internally. Often it contradicts itself, and you can't tell what is current. Maybe that Confluence page nobody has touched in a while is gold. Maybe it's just old. Maybe it's fairly recent and already out of date.
Onboarding programs help. They are good for covering the basics. But they are somewhat static, and a company that is doubling in size is not. Onboarding gets people up and running. It doesn't keep everyone current, and it doesn't get people sharing what they learn next.
The standard answer is to write everything down. Give an engineer half a day to document how they do things. In practice, that is hard. Writing documentation is a different workflow from the one engineers live in, and the moment a document is done it has to be updated and maintained. It goes stale and drifts from reality, which is why a library is stale the day you finish it.
Even good documentation has a deeper limit. You can't ask it anything, and it isn't connected to its author, who may not even be at the company anymore. It also matters more now than it used to, because documentation is not only for people. It is what your company's AI layer learns from. Documentation is necessary. It just isn't sufficient.
Will busy engineers actually show up to teach?
Yes, as long as you remove the toil. When we were doing this at Twitter, with Twitter University, what surprised me was how open engineers, and technical folks in general, are to sharing their knowledge. They gravitate toward it. What they don't want to deal with is scheduling, reminders, spreadsheets and emails. Take that away and they want to show up, whiteboard something and explain it. They love that.
Teaching is also part of the job. The more senior you are, the less your job is writing code and the more it is helping others be successful. At Twitter we codified this in the engineering ladder: the more senior you were, the more you were expected to mentor, coach, teach and keep the documentation up to date.
And it's a low lift. An hour or two once a week often needs no preparation at all. If I'm an expert on a topic, I can show up and whiteboard it. I don't need to build material or polished slides.
I saw this work at Twitter, and I've seen it at LinkedIn with their tech talks. Many successful organizations run a program like this. For more on the people side, see how to get experts to share their knowledge.
How do you run a peer-to-peer learning program?
The programs that work share a few habits. Here is how I would set one up.
Get leadership to sponsor it. What you are really proposing is a peer learning program sponsored by leadership. Top down is the culture that makes bottom-up sharing possible.
Pick a cadence and keep it. Weekly works well, for example every Thursday at noon. People should know what to expect, so avoid ad hoc scheduling and constant rescheduling. Package it as a program that simply happens. It is the same reason a learning container beats a content library.
Keep a backlog of topics and let people vote. Anyone can throw a topic in and see if it sticks before it gets scheduled. Prune the backlog constantly, and let the highest-rated topics win.
Take the logistics off the presenter. Logistics are the buzzkill. The promise to every presenter should be simple: just show up and share. Walk in, share what you know, answer questions, and off you go.
Hand the microphone to everyone. Juniors and new hires often know the newest tools. Make it normal for anyone to say they are presenting on something next Thursday.
Record every session. Live is easy to miss. Record it, transcribe it and summarize it, so the people who couldn't make it get a readable version.
Feed what it leaves behind into your company's AI. The same transcript can go into your company's AI layer. Because the program repeats every week, your AI keeps learning the latest from the people who know it, and the organization gets smarter automatically.
At first you can stitch this together. A recurring calendar invite, then a spreadsheet for the invite list, then reminders, attendance and somewhere to store the recording. Soon you are running five, six, seven different systems held together with duct tape, and the video ends up in somebody's Google Drive. With a dozen people, that is fine. When the program grows and reporting starts to matter, you need a real system. Building one yourself is easy to start these days. The harder question is who will own and maintain it, on top of their full-time job.
Who should teach, and what's in it for them?
Everyone. Somebody once told me that culture comes from the top, but innovation comes from the bottom up. With AI that is especially true: the people figuring out new tools and practices are often the younger folks and the new hires.
So leadership's job is to create a knowledge sharing culture that gives everyone a microphone. Make it okay to stand up and share. Tap people on the shoulder and ask what they learned this week. It's not that we teach top down. We enable top down, and we teach bottom up.
Then let the social side do its work. When someone announces they're presenting next Thursday, people vote with their time. Two or three might show up, or 20 or 30. The people who put themselves out there get visibility. Someone who was quietly building something in a corner of the company suddenly has a podium and a reputation, almost an internal celebrity status. They can become the expert overnight.
That visibility is good for careers, too. We used to say our job was to get our champions promoted. One champion I think about started out coordinating engineering onboarding and is now at the center of some massively important AI initiatives at her company. I've seen that story play out many times. Leadership notices impact, and helping a whole organization learn is a high-leverage activity.
Where does peer-to-peer learning matter most?
Wherever knowledge changes fast. At McDonald's, not much changes about flipping burgers. You can publish it in a binder and it stays valid for decades. But if you work with AI, or rocket science, you are constantly learning and figuring things out, so you always have something new to share.
It isn't only engineering. A sales team figuring out new ways to go to market, or new plays, has exactly the same need. The more your environment changes and the more innovation it has, the more peer-to-peer learning pays off.
Over time, the gap grows. A company with a peer learning program becomes a learning organization. Someone figures something out and, instead of keeping it to themselves, shares it with everyone. One to many. It doesn't matter if they are junior or senior. And every session leaves behind a knowledge artifact, so not only do your people get smarter, your systems do too. An organization that gets even 1% smarter a week compounds that over time.
Documentation tells you what your company knew. Peer learning is how it keeps learning.
Frequently asked questions
What are the benefits of peer-to-peer learning at work?
It keeps knowledge current as the company changes, lets people ask the expert directly instead of guessing from a stale page, cuts down the same shoulder taps, gives quiet experts visibility, and leaves behind recordings that people who missed a session, and your company's AI, can learn from.
How often should a peer learning session run?
Weekly works well: an hour or two once a week, at a time people can plan around, such as Thursday lunchtime. A cadence everyone understands matters more than the exact day.
Do presenters need to prepare slides?
No. An expert at a whiteboard, explaining how something works and answering questions, is the whole format. Keeping preparation and logistics off presenters is what keeps them coming back.
What if someone misses a session?
Record it. A transcript and a summary give people who couldn't make it a readable version, and the same artifact can feed your company's AI.
Can recorded videos replace live peer learning?
No. A video is linear, and you can't ask it anything. The value of a live session is questioning the expert on the spot. Keep the recording as the artifact, not as a substitute for the session.
Does peer-to-peer learning only work for engineers?
No. Engineers tend to take to it quickly, but it works for any team whose knowledge changes fast, including sales, product and anyone adopting AI.
