This blog post was originally published at the RJJ Software blog. The original post (without gifs) can be found here
The cover image for this post is by CoWomen over at Unsplash
For those who don't know, I'm the host of The .NET Core Podcast. I'm also a "serial podcast producer" (in the words of my friend James Studdart), as I've started a number of them throughout the years. Some of them are about technology, some are about video games, some are about the business of writing software, and some are just fun to produce.
You can see a list of all the shows I’ve been involved in at my podchaser profile page - which includes this wonderful statistic:
Anyway, none of that is the reason why I wanted to write this blog post. I wanted to talk about the 10 things that I've learned from running a tech podcast for two years.
Number 1 - You're Playing The Long Game
Some podcasts can achieve instant success, and that's fantastic. Usually, these shows have a very specific niche, an engrossing host team, or a large team of folks behind them.
Unless you are lucky enough to have those things, then you're likely going to be playing the long game. This is because it will likely take time for your show to gain traction - and that's partially because there are so many other people out there creating shows on everything. Seriously, almost any topic you can think of has several established podcasts with engaged audiences and a legion of not so well established podcasts.
With that being said, you shouldn't let what I've said stop you from starting the podcast of your dreams. But you should know that it may take a while to gain traction.
Number 2 - Ignore the Stats at the Start
It's incredibly exciting to jump over to your podcast host's website and take a look at the numbers going up. I'm not going to lie that I used to do this daily. The problem with that is, that podcasts are an on-demand type of media: folks will listen whenever it suits them.
Because of this, you will have days where it feels like almost no one will be listening to your show. This is because of the very ad-hoc nature of podcast consumption. Imagine the situation: you only listen to your favourite show when you're driving to work, and you suddenly no longer need to drive to work - let's say that there's a public holiday. Well, you're not going to be listening to your favourite show.
And that's where Number 3 comes in:
Number 3 - There's no "Perfect Day" to Release
I've seen this question come up a lot, usually from folks just starting out or from folks reaching out to me to up their game. I'll tell you what I tell them:
There's no perfect day to release an episode of your show, just a day which is perfect for you.
Let's face it when we start a new project we go through a "Honeymoon phase" of sorts: we want to keep working on it as much as possible and get as much content out there for people to see and consume. The problem with that is that it's not sustainable.
Imagine that you get super excited about a podcast that you're creating and decide to release 4 episodes a week. That's fine right now because you've likely budgeted your time out to give you time to experiment. But what happens in 6 months, when you're suddenly moving to another state? What about 12 months, when the enthusiasm starts to wear thing? What if the unthinkable happens and you get ill? What if - and I hope it doesn't happen to you - you have some tragic news? Can you keep that release cadence up?
The only perfect release day which matters is the release day that you can fit into your schedule. If you can't fit it into your schedule, then it's not a perfect release day.
Number 4 - Automate All The Things
At the start of every episode of The .NET Core Podcast, I say:
let's sit back, open up a terminal, type in
dotnet new podcastand let the show begin
with the sound of me typing the command dotnet new podcast into my terminal. The reason for this is because I do that when starting a new episode.
I have a small .NET application for scaffolding all of the files I need to create a new episode. It creates a markdown file for show notes, adds an entry into my calendar, sets up a planning document, and opens a new email in my email client.
And that's just the recording side of it.
I also have an automated deployment pipeline for releasing the episodes. Each episode is released at 12:30 (UK time) on Friday afternoons, and the website for the show is built on using the Hugo static site engine. so I have a GitHub action which rebuilds the site at midday (again, UK time), ahead of the release of that week's episode. My episodes are also set to auto-release at 12:30 and to link back to the show notes address.
So the pre-production is automated, and the release is automated. I just have to deal with production, editing, and post-production.
Number 5 - Know Your Tooling
This goes without saying, regardless of whether you are working with audio, crafting code, writing unit tests, or writing prose. Once you know your tooling, you'll be both more efficient and be able to do things you previously thought not possible.
For a lot of folks who are new to podcasting and working with audio, this will mean learning both the audio production and editing tools and learning about the physics of audio. But don't be put off by the fact that you have to learn something new, you can pick it up as you go along.
For some, this might mean heading over to Udemy (or some other video-based training site), grabbing a course on Audition, Garage Band, or similar, and sitting through several hours of someone talking you through the tooling. For others, this might mean recording something and figuring it out as they go.
Let me just say that both of those strategies are fine because we all learn differently. Picking it up as you go along is just as valid as learning everything ahead of time.
Number 6 - The "Anti-Umm" Thing
Don't waste your time with this. It will sound unnatural, and there will likely be imperceptible audio spikes which cause issues when bouncing/rendering the audio. Everyone can tell when you cut out some umms and errs, so just don't do it.
Plus, it takes a very long time to do (see Number 8)
Number 7 - You'll Get Better At It With Time
Unless you have years of experience doing podcast production under your belt, you're going to start with something good enough and get better with time.
What I mean by "good enough" is not that it will be bad in any way, shape, or form. I just mean that because you don't have the experience, you won't spot things that you could have done to make the quality better, the edit faster, or the post-production tighter.
It's the same with anything in life: you want to get good at swimming? Go out and swim a lot, as you approach that magical 10,000 hours of deliberate practice, you'll start seeing improvements.
So don't sweat it, if you start slow or look back on where you started and cringe.
Number 8 - It Takes Time
Unless you hire an editor
one of the services that RJJ offers is podcast editing
then you can expect to spend a lot of time editing. The rule of thumb that I throw around is:
for every 30 minutes of recorded audio, you're looking at 60 minutes of editing time at the very least
The emphasis here is the important part. When you start, you'll likely be slower because you might still be learning the tooling. You'll get faster as you get better, but it will still likely take about double the length of the recorded audio. This is because you'll likely start picking up other tips and techniques, meaning that you spend even more time getting everything edited together.
And that doesn't count the time you'll be spending planning episodes, writing them, reaching out to and scheduling guests, getting promotional pieces done, shouting up about it on social media sites, and answering listener feedback.
There's a reason why folks like Joe Rogan have a team of people around him. He turns up to the studio with a list of topics, sits down in front of the mic, starts talking when the audio engineer clears him, and leaves when the recording is done. His team handle everything else.
Number 9 - Have a Pre-Release Checklist
You've recorded the audio, edited it down, post-produced it, sourced a sponsor, added the ad-read, and even uploaded the mp3 file to be released. But have you done everything?
That's where a pre-release checklist comes in. This allows you to doublecheck that you've done everything. What if you release an episode which was meant to have some ad-copy in there, but it's somehow missing from the episode? Well, you're likely going to have a very upset sponsor calling you up as soon as they find out - and they'll find out as soon as the episode goes live.
This is where having a pre-release checklist is vital, and having a step on there with "listen to the episode in it's entirety before releasing". The emphasis here is super important. What if the bounce/render failed partway through? What if the audio suddenly becomes super loud at the halfway mark? You don't want your listeners or sponsors to have to report that to you.
Number 10 - Don't Release Until It's Approved
Part of the process for getting your podcast out there is telling Apple about it. It's a step which goes back to the iTunes days - it's since been renames Apple Music. Here's what you need to do:
- Tell Apple Podcasts (used to be called iTunes) that your show exists
- Wait for them to approve it
- Wait for them to approve it
- ...
- Wait for them to approve it
- It will appear in Apple Podcasts
If your podcast isn't in Apple Podcasts, then the majority of people won't have a chance at hearing it. This is because the majority of the podcast aggregators pull their podcast feeds directly from Apple Podcasts - whether they should or not is up for debate.
So if your podcast isn't on there, then it won't be anywhere. And if you've ever released an app to the Apple App Store, you'll know that there's a period where the folks at Cupertino need to do some checking and vetting of your show. If you don't follow Apple's guidelines to the letter, then your show won't be accepted, and you'll have a bad time.
As such, it's worth waiting until your podcast has been accepted by Apple before you start the media campaigns. You don't want potential listeners to flock to their podcatchers (the term for podcast consumption apps) only to struggle to find your podcast because Apple denied the show.
Summary
Those are some of the things that I've picked up over the first two years of producing, hosting, editing, dogsboddying, and promoting The .NET Core Podcast. I have so much more advice to give, but I'd rather not keep you all day.
Are you involved in creating a podcast? I'd love to hear some of your top tips? If you're not involved in one, are you considering it? Let me know in the comments.
One last thing: I've put a course together on getting into podcasting. If you liked this article, and are considering getting into podcasting, or if you already have a podcast and are looking to up your game (as it were), then I'd recommend enrolling today.
Latest comments (2)
This is a great article Jamie! It's easy to see why a lot of podcasts struggle to get going, or have inconsistent releases, since there's so much that goes into it. Thanks for all the work that you've done in this space. I enjoy every one of your podcasts!
Thanks Devin.