My Podcast Episode Guide

I host two podcasts, The IT Guy Show and the Fedora Podcast, and the thing nobody tells you when you start is that the recording is maybe a quarter of the work. The other three quarters is everything around it, and if you do not have a system for that, every episode becomes a scramble. The thing that holds it together for me is a document I call the episode guide. Let me walk through how an episode actually comes together, from the first message to a guest to the final export.

It starts with booking, and booking is where most of the quality of an episode is already decided. When I reach out to a guest, I am not just asking if they will come on, I am already thinking about why this specific person on this specific topic makes an episode worth someone’s time. A good guest booking has a clear reason to exist. James Harmison on bootc worked because he had been living in bootc for years and could talk about what it actually looks like in production, not just in theory. Once a guest says yes, I get a time on the calendar and I send them a short note about what we will cover, so they are not walking in cold. Nothing kills momentum like a guest who thought this was going to be a different conversation.

Then I build the episode guide, which is the heart of the whole workflow. It is a single document per episode, and I use the same template for every one so I am never reinventing the shape. At the top is a metadata block that holds all the logistics in one place: the date aired, the host and guest stream links, the YouTube link once it exists, who the host and guests are, who is producing, and for the more technical episodes, the lab operator and lab source. Under that is an abstract, a few sentences that force me to say in plain language what this episode is actually about before I go any further. If I cannot write the abstract, the episode is not focused enough yet.

Below the logistics is the part that does the real work, which is the agenda. Not a script, because a scripted podcast is a boring podcast, but a set of landmarks. It opens with a hook, the thing that earns the listener’s next thirty seconds, and a slot for the intro video. Then come the introductions, where I have three standard questions I ask almost every guest: who are you, what do you do, and what do you do for fun. That last one matters more than it looks, because it relaxes the guest and reminds the audience there is a person here, not a press release. After the introductions I lay out three or four main areas I want to make sure we hit, with a couple of specific questions under each, phrased as things I am actually curious about, because genuine curiosity is what makes an interview feel alive. And it ends with a closing, which in my template is close to a fixed script: the like and subscribe ask, a teaser for what is next, and a sign-off I deliver on behalf of the guest and myself. Having that closing pre-written means I never fumble the ending, which is the part hosts most often botch when they are tired.

One section of my template I would not run a show without is Topics to Avoid. It is exactly what it sounds like, a short list of things not to bring up: a subject the guest asked to steer clear of, a rabbit hole I know eats twenty minutes and goes nowhere, a piece of news that is not mine to break. Writing those down before we record keeps me from wandering into a landmine live, and it is a small courtesy to the guest that pays for itself the first time it saves an awkward moment. There is also a block of episode keywords in the template, the tags and terms the episode should be discoverable by, which I fill in so the show notes and the eventual companion post are already pointed in the right SEO direction.

The reason the guide is a set of landmarks and not a script is that the best moments in any episode are the ones I did not plan. A guest says something surprising and I want to chase it. The guide is there so that when I follow a tangent, I know how to find my way back to the thread and I have not forgotten the three things I promised the audience we would cover. It is a map, not a set of rails. I keep it open on a second screen while we record and I check things off as we go.

The guide also does double duty as my production notes. As we record, I jot timestamps next to anything I know I will want later: a great quote, a moment that needs a trim, a spot where the audio got weird. When I get to editing, those notes turn a two-hour hunt into a targeted pass. I am not relistening to the whole episode trying to remember where the good part was. I wrote it down while it was happening.

Production itself is the least interesting part to write about but the part that eats the most time. I clean up the audio, cut the dead air and the tangents that went nowhere, and make sure the levels are sane so nobody has to ride their volume knob. For the video versions I sync things up and cut to whoever is talking. None of this is glamorous and all of it matters, because an audience will forgive a slightly rough conversation but they will not forgive audio that is painful to listen to.

The last thing the episode guide gives me is a head start on everything that comes after the episode. Because I have the topic, the outline, and the timestamped quotes all in one place, writing the companion blog post and the show notes is not a separate research project. It is right there. That is a whole workflow of its own, and one I will write about separately, but it starts here, in the same document I built before I ever hit record.

The system is not complicated, and that is the point. One document per episode, built before you record, updated while you record, and mined after you record. It turns a chaotic process into a repeatable one, and repeatable is what lets you keep publishing without burning out.