Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Solved Her Team's Knowledge Silos with Internal Podcasts
Transcript
- Lucas: There is a CTO at a 300-person fintech in New York who noticed something that probably sounds familiar: her senior engineers were answering the same questions over and over in Slack. New hires, product managers, even engineers from other teams — all asking things like 'Why did we choose Postgres for that service?' or 'What actually happened during the outage last quarter?' Luna: Right, the classic knowledge silo problem. But I'm guessing she didn't solve it with a wiki. Lucas: She tried a wiki. She tried architecture decision records. She even tried recording video walkthroughs. None of it stuck. People didn't read the docs, and the videos were too long to produce. So she did something that sounded weird at first: she launched an internal podcast. Luna: An internal podcast? Like, for the company only? Lucas: Exactly. Once a week, fifteen minutes max, one of her senior engineers sits down with her and explains one thing — a recent architecture change, a postmortem, a new pattern they're adopting. No slides, no screen share. Just a conversation. And she publishes it to a private feed that the whole engineering org can subscribe to. Luna: Okay, I have so many questions. First: how much time did that take to produce? Because I can already hear managers saying 'We don't have time for that.' Lucas: She told me it costs about two hours of someone's time per episode. One hour for the senior engineer to record, one hour for a junior engineer to edit and publish. And she cycles through different senior engineers, so no one person carries the load. Luna: Two hours a week. That's not nothing, but compared to the time lost from people asking the same questions over and over, it's probably a net positive. Lucas: That's exactly how she framed it. She measured the drop in Slack questions about topics that had been covered in an episode. Within three months, questions about those topics dropped by about forty percent. And onboarding time for new engineers fell by roughly thirty percent. Luna: Thirty percent? That's huge. What's the secret? Why does audio work better than a written doc? Lucas: She thinks it's about two things. First, audio carries tone and context that written words don't. When a senior engineer says 'We chose this database because...' you can hear the nuance — the hesitation, the confidence, the trade-off they're still uneasy about. That tacit knowledge gets lost in a doc. Luna: And second? Lucas: Passive consumption. People can listen while commuting, walking between meetings, or doing chores. They don't have to block out time to read a five-page RFC. The CTO told me that within the first month, over half the engineering team had listened to at least one episode. That's a consumption rate no wiki ever achieved. Luna: Honestly, this reminds me of something I read about how the best way to transfer complex knowledge is through storytelling, not documentation. And a podcast is basically structured storytelling. Lucas: Exactly. She gives the guests a simple structure: start with the problem, explain the options you considered, say why you chose what you did, and then reflect on whether it worked. No script, just a loose outline. That keeps episodes tight and authentic. Luna: I wonder if this only works at a certain scale. Like, at a ten-person startup, everyone already knows everything. At a thousand-person company, you might need something more formal. But three hundred seems like a sweet spot. Lucas: She actually thinks it scales both ways. In a smaller company, the podcast can serve as a record of decisions for when you do grow. In a larger company, you can have multiple feeds—one for platform engineering, one for data, one for frontend. The format is cheap enough that you can spin up a new feed in an afternoon. Luna: So let's talk about the format more. Fifteen minutes, no slides. What about editing? Do they cut out the ums and ahs? Lucas: They do light editing — remove long pauses, coughs, tangents that go nowhere. But they keep the conversational feel. The CTO said the first episode was over-edited and sounded robotic. So they pulled back. Now they leave in a little bit of thinking aloud, because that's where the real insight often comes out. Luna: That makes sense. If it's too polished, it loses the authenticity that makes audio valuable in the first place. Lucas: Right. And they also do something clever: each episode starts with a one-sentence summary written by the guest. So if you're short on time, you can read that sentence in Slack and decide if the full episode is worth your fifteen minutes. Luna: Oh, that's smart. Lowers the barrier to entry. Instead of 'I have to listen to fifteen minutes to find out if it's relevant,' it's 'I can decide in five seconds.' Lucas: Yeah. And she also told me that the act of preparing for the podcast has been valuable for the senior engineers themselves. They have to articulate their reasoning clearly, which sometimes exposes gaps in their own thinking. One engineer realized mid-recording that the team had never actually documented why they chose a particular caching layer. Luna: That's a nice side effect. It's almost like a lightweight architecture review baked into the process. Lucas: If today's tech conversation gave you something usable, you know what keeps this show ad-free and independent. It's listener support — the simplest kind. If this episode was worth a coffee to you, that's the link: buy me a coffee dot com slash fexingo. Luna: Yeah, it genuinely makes a difference. Even a small contribution helps us keep bringing conversations like this one. Lucas: So back to the internal podcast: what about measuring impact beyond just Slack question counts? The CTO tracks something she calls 'knowledge reach' — the number of people who listen to an episode divided by the number of people who should have that knowledge. For example, after an episode about a new service mesh, she checks how many of the engineers who work on services actually listened. Luna: That's a solid metric. And it's actionable — if you see low reach for a critical topic, you know you need to promote it differently. Lucas: Exactly. They also run a quarterly survey asking engineers to rate their understanding of key architectural decisions. The score has gone up consistently since the podcast started. And the number of people who say they feel 'in the loop' about what other teams are doing jumped from 35 percent to 68 percent in one year. Luna: That's a massive improvement. I want to push back on one thing though: doesn't this add to the 'yet another tool' burden? Engineers are already drowning in Slack, email, Notion, Jira, meetings... Lucas: Fair question. The CTO's answer is that it replaces other forms of knowledge sharing rather than adding to them. She actually reduced the number of all-hands meetings and tech talks because the podcast covered the same ground more efficiently. And because it's async and on-demand, it doesn't interrupt anyone's flow. Luna: So it's not an extra thing — it's a substitute for less effective things. I can get behind that. Lucas: Yeah. And she also emphasizes that the podcast isn't mandatory. No one has to listen. But because the episodes are short and relevant, most people choose to. It's pull-based knowledge sharing, not push. Luna: What's the biggest mistake she sees teams make when they try to copy this? Lucas: Making episodes too long, and trying to be too comprehensive. She says the best episodes answer exactly one question. If you try to cover 'everything about our microservices architecture' in one episode, no one will finish it. But fifteen minutes on 'why we use gRPC instead of REST for this specific service' — that gets listened to. Luna: Narrow scope, high relevance. That's a good rule for any kind of documentation, really. Lucas: Absolutely. And she also warns against having only the CTO host every episode. The whole point is to surface voices from across the org. She hosts the first few to set the tone, then rotates to engineering managers, staff engineers, even sometimes product managers when the topic overlaps. Luna: That builds a culture of teaching and learning, not just broadcasting from the top. I like that. Lucas: Yeah. The CTO told me her ultimate goal is that the podcast becomes redundant — that the knowledge flows so well through other channels that you don't need it anymore. But so far, that hasn't happened. Every time they stop for a few weeks, the Slack questions creep back up. Luna: So maybe it's a permanent part of the communication stack at that company. And that's okay. Lucas: I think so. It's cheap, it's effective, and it builds a habit of storytelling around technical decisions. For teams struggling with silos, it's worth a try.