Starting a Podcast - Our Advice

Two black headphones setup on brown wooden table, using microphone arms. Each microphone has a set of headphones plugged into them, and the microphones are arranged opposite of each other.

The cover image for this post is by Austin Distel

This blog post was written by Jamie. It was original published on the website for The .NET Core Podcast We have reproduced an edited version of it here with permission.


Introduction

Everything you’re about to read is my own personal opinion based on my experiences of running three regular podcasts (and having started a few which have podfaded), namely:

Terminology

Before we start, we need to define some terms. This will help if you aren’t sure what these words and phrases mean, in a podcasting context:

  • Podfade; when a podcast stops creating new episodes and fades into obscurity
  • Podcast Host Service; someone who will host your MP3 files and create an RSS feed for people to consume
    • This is different to the host of a podcast; which is the person (or persons) who host the show you are listening to
  • IAB; The Interactive Advertising Bureau - they have a standard for measuring a podcast’s success when reporting to advertisers
  • RSS; a way to consume syndicated content on the web. There are many RSS feed readers, and podcasts are just one of the uses of the technology
  • Double Ender; when you and a guest make use of some kind of VoIP system, and have everyone record their own audio, then splice that together during the edit

A Question About Podcasting

A while ago, KaleighS asked a question over at the Blogging Mastermind slack group all about podcasting:

any good articles/sites/(or even podcasts) on getting started podcasting?

- KayleighS

We had a short conversation in a thread, before I did a veritable brain dump of information. Here is the thread:

The spark which fuelled this blog post
The spark which fuelled this blog post

Note: I’ve blurred the avatar that KaleighS uses because I didn’t want to somehow dox them

I read back through the brain dump and thought that parts of it could be useful; but only if I tidied it up a bit. So I’ve taken some time to do just that, and here is my advice for budding podcasters:

TL;DR

  • It’s challenging, but rewarding
  • Stick to the cadence that you set
  • Don’t look for sponsors right away
  • Don’t focus on the download numbers, focus on quality
  • You get what you pay for

Advice 1: Have a Solid Idea

My first piece of advice is that you should have a really solid idea. If it’s not solid, then the show wont really be fully formed before people start listening, and if the show isn’t fully formed then people will stop listening (people are fickle).

After that, take some time to record a few demo episodes. You’ll get a feel for just how long a planned, structured show takes to produce. You’ll also start to get a feel for what the show will be - the first 5 to 10 episodes that you record won’t reflect the final material because you’ll still be figuring out what goes where.

This is because, whilst the idea is still forming in your head, you will want to try new things out. “What does this filter do?”, “how do I make it sound like I’m talking through a phone?”, “Where can I license sound effects from?” , “Can I somehow make my voice sound like I’m a ghost?”, etc.

You might even come up with new segments whilst you are figuring out how to use the technology that you have. As Steve Jobs said:

Stay hungry; stay foolish.

- Steve Jobs

You may also start having ideas about intro and outro music. DO. NOT. USE. COPYRIGHTED. MUSIC. If you didn’t create it, or you didn’t pay someone directly to create it and give you the license to use it, then don’t use it. There’s an industry body called the RIAA who will likely send you a cease and desist if you do use some music without permission.

There’s a caveat in that you can use a copyrighted piece through “Fair use”, but it’s a grey area and definitely does NOT cover intros, outros, and segment music.

Check with a legal advisor, and do you own due diligence. Fair use may not be viable in your country, or in a country where you listeners are based.

Mini Advice 1: Music

Whatever you do, DO. NOT. USE. COPYRIGHTED. MUSIC. Even a second is enough to get on the bad side of the RIAA. The RIAA represents all of the music industry types across the world. From their about page:

The Recording Industry Association of America® (RIAA) is the trade organization that supports and promotes the creative and financial vitality of the major music companies. Its members comprise the most vibrant record industry in the world, investing in great artists to help them reach their potential and connect to their fans. Nearly 85% of all legitimate recorded music produced and sold in the United States is created, manufactured or distributed by RIAA members.

we’ve added emphasis here

If you want to have music in your show, then have it composed for you. I’ve used folks on Fiverr for this in the past, and I’ve received the full license from them. For the tiny sum of $11 (US) I was able to have someone compose a piece of music to my liking, but also to transfer all ownership rights to me.

Whether you go down the route of Fiverr or not, ensure that you legally own the music that you put into your show. Otherwise the RIAA will be in touch with you.

Advice 2: On Recording - Hardware

You can start with as little as the microphone in your laptop. Examples from my own past are:

  • 53 Games in 63 Minutes which was recorded in Mark’s office with the mic built into my Mac Air - and it really sounds like it.
  • .NET to The Core! the first time I was interviewed for a show. I used my Mac Air microphone array, and we connected over Skype

When you are ready to increase the production value and sound quality of your podcast, I would recommend buying an external microphone. Laptop microphones are OK to get started with, but they aren’t the best. Take a look into the differences between Condenser and Dynamic mics: Condensers tend to be louder, but pick up a LOT of background noise; whereas Dynamic mics are quieter, but don’t pick up as much background noise.

there are caveats involved in this generalisation, though

You don’t have to spend a huge amount of money on a mic, as you’re just starting out. But know that you get what you pay for. For the majority of the early episodes for The .NET Core Podcast, I used a Blue Yeti mic. This a condenser mic which plugs directly into USB, and most apps will detect it without any issues. For the newer episodes of both The .NET Core Podcast and The Waffling Taylors we have been using Samson Q2Us which have XLR and USB connectors, which we plug into Zoom H6N recorders.

The H6N is a hardware recorder, which means we no longer need a computer to record, and can do recordings “in the field” - which is what we did for our episodes at EGX. This means we can take the hardware recorder, a number of mics, and set up shop wherever we want.

The Zoom H6n
The Zoom H6n

One of the best things about this recorder is that we can plug four mics into it, and still use the two mics at the top of the device (in the image, they are the silver protrusions at the top of the device), for a combined 6 mics. Each mic is recorded on it’s own track, so it makes editing really easy.

On top of that, you can also use it as an input device for your computer, so those 6 mics can be recorded (on your laptop/PC) with yet more mics. I wouldn’t recommend it, but if you desperately need to have 7 mics, it’s a quick win - if you can get your head around JACK, that is.

Regardless, know that you don’t have to jump to this level of equipment at the start, but setting aside some money for buying hardware (and eventually editing software) will help.

Advice 3: On Recording - Software

Recording episodes can be incredibly easy or fraught with difficulty.

If you have Apple hardware, like a Mac laptop or Apple computer, then you have access to a piece of software called GarageBand for free. This can be used to get you started. It’s simple to pick up, but can be difficult to master. The first episode of The Waffling Taylors was recorded using GarageBand and the mic built into my Mac Air. All of which was free - after the cost of the laptop.

There are hundreds of products on the market for recording audio using a PC, laptop or Apple device. I use Audacity, mainly because it’s free (remember: you get what you pay for). It’s relatively bug free, and works wonderfully. But when it crashes, whatever you were working on likely cannot be recovered.

I’ve heard a lot of talk about Reaper and Davinci Resolve. These are paid products, as is the Creative Cloud. All of these products have the ability to record and edit audio. I’d recommend taking a look at demos of them on YouTube, and trying out any free trials of them to see which sits with you best. Reaper is definitely at the pro end of the audio and music production spectrum, so expect to see a lot of features that you are never going to use.

I’ve learned a lot of the shortcut key bindings for Audacity, and have a solid backup plan, so I’m happy using that. But YMMV (your mileage may vary).

My recording set up is actually this:

  • Record my audio using the H6n; this is my primary source for my audio
  • Record everyone’s audio using the VoIP software we use; ZenCastr and SquadCast both have “record within the browser” functionality
  • Record my audio with Audacity; as a second backup to both my H6n and the VoIP software

I always use the H6n source audio, but if the H6n recording somehow messes up, then I fall back on the VoIP software recording, and if that somehow messes up then I can fall back on the local Audacity recording.

Note to Windows users: unless you use something like JACK, you can only record one audio source at a time.

I always ask remote guests to record their audio as a backup (called a “Double Ender”), and would recommend that you do the same.

Advice 4: On Recording - Remote

There will come a time when you need to record part of your podcast remotely. This will likely be because you and a guest (or your co-hosts) cannot be in the same physical location at the same time.

There are a lot of services which strive to help you with this. As I’ve said already: you get what you pay for. I’ve found that free services like Google Hangouts, Skype, and similar can be incredibly flaky. If you have to use these tools, ensure that you do a double ender.

A double ender consists of each person recording their own audio and sending it to you to be edited together. If you have to do a double ender, ensure that you have a sync signal. The most common way to do this is to have everyone start recording then count down from three and all clap once, together. When you come to edit everything, you can use the audio spike caused by the clap to line everything up.

There are products out there which are designed to do all of this for you. Some of them are:

  • ZenCastr
  • Ringr
  • Squadcast

The idea with these apps is that they set up a VoIP call for you, record each person’s audio within the browser cache, and upload them to some central server. In the past, I’ve used ZenCastr and SquadCast; when they work, they work gloriously. But when there’s an issue, nothing is usable.I’ve had to re-record several interviews that I’ve done with these services, and I still have a few that are unusable because I haven’t had the chance to re-arrange them - these cases happened before I started using a hardware recorder.

If you end up using something like ZenCastr or SquadCast, it’s worth pointing out to everyone involved that they should read the FAQ for the service that you choose. They often have limits on the browsers that they support. The following text comes from the FAQ that I send to guests of my show:

One thing to note about SquadCast is that the default UI includes a map with a vague geo-location of all participants. This can be disabled on a per-guest basis by blocking the geo-location services API when it is requested, this will not affect the quality of the recording. However, according to their support channels, using a VPN may cause issues with the recording. If this is likely ot cause an issue, we can arrange another way of performing the interview.

Also have an FAQ for your guests. This can help with easing them into being on a podcast, especially if they have nevver been interviewed for one. You are free to use my Podcast FAQ as a starter, but please check the details of the license if you do.

Advice 5: On Planning

I have a multi-part plan for each episode:

  • Come up with an idea, or set of topics
  • Write out as much as I can think of for each topic
  • Figure out who (if anyone) I would like to invite to be on the episode with me
    • If there are guests, reach out to them and arrange a time which suits them best
      • After all, I’m asking them to give up some of their time for me
    • Discuss the episode with them ahead of time, and share as much as I can, so that they’re not “going in blind”
  • Actually record the episode
  • Edit and post-produce the episode
  • Either:
    • Provide show notes commenting on the episode (ala Waffling Taylors)
    • Provide a full transcription of the episode (ala The .NET Core Show)
Mini Advice 2: Show Notes

If you take a look at the show notes for an episode of The Waffling Taylors - here’s an example episode - you’ll see that it’s more like commentary, filling in gaps, and discussing the episode itself. This is because they are designed more as supplemental material to the show. I could provide a transcription of the episode, but teh discussion tends to be a little too frenetic to provide a transcription - meaning that it would take too long to create one. This means that we’re cutting out a large portion of our potential listener base: those listeners who are hard of hearing, for example. This is something I’m looking to fix in the future.

Whereas, if you take a look at The .NET Core Podcast - again, here’s an example episode - you’ll find a full transcription of the episode. This helps listeners with accessibility requirements, as they can read the transcription rather than listen to the episode. This also has the side benefit of adding “SEO juice”

I really dislike that term

to your show notes site, as it’s now searchable and indexable.

But if you’re going to supply a transcription, do it for those with accessibility requirements rather than the SEO; as your audience should be your priority.

Advice 6: On Editing

I pay an editor to actually edit the shows, that way I don’t spend my evenings and weekends doing it - but I did used to do that. It’s hard to juggle a passion project like a podcast, a full time job, and family commitments. I actually have Mark edit the shows, as he is an audio editor with a lot of experience, and because both The .NET Core Podcast and Waffling Taylors are owned and operated by RJJ.

RJJ Software are available for audio editing and podcast consultation. Reach out and we’ll let you know how we can help

I’d recommend looking into paying an editor to put it all together for you, but only after you’ve got the show off the ground. The reason for this is that a lot of really good editors will want:

  • Paying for what they do (again, you get what you pay for)
  • Some kind of assurance that there will be more than just one episode to work on (they’ve got mouths to feed too)

If you go down the route of being the editor, you’ll need to learn a lot about the tools that you use. You’ll potentially need to learn about the physics of sound, filtering and equalising, noise gates, amplification levels, and things like LUFS.

The last part is pretty easy to learn about. LUFS are the loudness units for audio levels in radio, TV and movies. There’s an industry standard for LUFS for TV and Radio and you’ll want to stick with that. Otherwise your listeners will end up having to increase the volume of your show up and then scramble to reduce the volume when yours ends - from a listeners point of view, that’s horrendous and separates the pros from the flight-by-nights.

You can achieve the LUFS levels by investing in an app called Auphonic. It’s available for both Windows and Mac, and as a Sofwtare-as-a-Service. All three offerings will take an input audio file, and apply Dynamic Range Compression to ensure that the resulting episode is within the LUFS range. I leave all of my episodes at -16 LUFS, as that’s the standard for Podcasts and Mobile phone calls.

The old work flow for editing an episode of The .NET Core Podcast is this:

  • Obtain all tracks from an interview recording
  • Feed them all into Audacity
  • Line them up
  • Go through the recording, tweaking things
    • Removing any long sliences
    • Removing any flubs (I often fall over my words)
    • Removing any parts where someone mentions that they’d like to try again
      • Perhaps the person speaking flubbed, or need to refer to notes
    • Remove any gaps for taking a sip of water
  • Add an intro and outro
  • Add short musical indents at key places
  • Add any ad reads (if approprite)
  • Export as a single WAV file
  • Put the WAV file through Auphonic
    • 96 kbps MP3, Mono

The workflow changed in late 2019, and the episode quality has improved because of it

Mini Advice 3: File Sizes

I settled on 96kbps because the music idents used in my shows are specifically designed to sound OK at that bit rate. I chose MP3 because you don’t want listeners to have to download an audio file in the range of 600 MB. And I chose Mono because my shows are conversations where everyone mixed to the centre channel, so that immediately halves the file size. Here is an example of an episode which was edited using the above workflow, I’m showing both WAV and MP3 versions of the edited episode:

The smaller the file, the less time it will take to download
The smaller the file, the less time it will take to download

Your listeners will thank you for the smaller file sizes, and your host will thank you for saving them on bandwidth.

If your show has a lot of music - maybe it’s a music review show or similar - you’ll want to look at a higher bit rate. Because my shows are mostly speech, they can be encoded at a lower bit rate and still sound good.

Advice 7: Growing Your Audience

Getting and maintaining an audience is the hardest part. Just like blogging, it requires a lot of effort from you.

When you start, you’ll be shouting into the void. This is because there are so many other content creators out there offering the same stuff - and podcasting has had a lot of positive press in the past few years, with celebrities getting into the arena and mult-million dollar deals on the line. Once you’ve managed to differentiate yourself from the other creators, you’ll need to try and stay ahead of them by innovating quicker or offering something that they don’t.

After that, you’ll need to try and get some kind of back and forth going with your listeners. Your podcast host will give you vague numbers for your subscriber levels - these are based on download levels, but are not accurate. Whilst it’s great to see the numbers go up, don’t create the show specifically for that because as soon as those numbers drop, so will your motivation to create the show along with your morale surrounding it.

Focus on quality over quantity.

Advice 8: Show Launch

I launched all of my shows, with a single episode each, whilst working full time. Others will tell you to have a number of episodes ready to go before you launch. It’s really up to you.

If you have a specific date in mind for a public launch (maybe you have something planned for social media outreach) ensure that Apple Podcasts (formerly iTunes) and Google Podcasts have discovered your show before you launch. All of the other platforms (such as Overcast, PocketCasts, Podcast Addict, etc.) piggy back off of those two services, and if your show isn’t at least in Apple Podcasts then it wont show up anywhere else.

there’s a caveat hear for apps like Antenna, where the user can supply a link to the RSS feed. But the majority of listeners will use other apps and services

It can take up to a month for both Apple Podcasts and Google Podcasts to discover and index your show, so it’s vital that you do this before you start any advertising campaigns or social outreach - otherwise, your potential listeners won’t be able to subscribe to your show.

It will be worth looking into Podcast Connect and creating an account before you plan to release your show. This is one of the ways that you can submit you show to Apple Podcasts (your host will likely have a way to post to Apple Podcasts for you), it’s also a way to get some stats on your show from Apple.

some stats for The .NET Core Podcast from Podcast Connect - taken in January of 2019
some stats for The .NET Core Podcast from Podcast Connect - taken in January of 2019

Podcast Connect have guidelines on how long it might take for your show to be indexed by them - as they do some kind of vetting process before allowing a show onto their system. The indexing time can change from month to month, and some periods (like festive holiday periods) have much longer wait times. So if you are planning to launch on a specific date, ensure that Apple Podcasts has indexed your podcast in advance of that, because there is no way to speed up the process.

The easiest way to get onto Google Podcasts is to let Google do it for you. This will mean that you’ll need a website for your podcast - which I’d recommend anyway, that way you can have long form show notes. So you might need to approach a web developer in order to help you do it (again YMMV), as there are specific tags that you need to include so that the Google bot can discover your show.

One of the neat positives to this is that you can have Google display the episodes in search results, and will let folks listen to the episode right there in the search results.

clicking on one of those play buttons will play the episode from within the search results, meaning listeners don’t have to go anywhere else in order to listen
clicking on one of those play buttons will play the episode from within the search results, meaning listeners don’t have to go anywhere else in order to listen

Advice 9: Download Numbers - Ignore Them

Don’t expect success overnight. For every Joe Rogan Experience, there are 3,000 other shows recorded in basements. For every McElroy trio, there are hundreds of other wannabe comedians who haven’t been given air time. Keep working at your show, keep producing high quality content, and keep telling people about it; only then will the people come.

When companies do come to your door asking about sponsorship (or when you go to them), they will likely want to know what your audience size is. But this is a difficult metric to measure. Podcasts use RSS feeds. Here is the RSS feed for The Waffling Taylors. As you can see, you can just load it in your browser, and play the episodes there.

Even if you listen in Apple Podcasts (or some other app), you don’t have to sign-in in order to listen to an episode. My previous screen shot showed that you can listen within a Google results page. So how do they measure your audience? Total downloads.

It’s that simple. The amount of time that one of your episodes has been downloaded, for the first 30 days after it was released. SOME hosts count unique downloads by IP address and User Agents, but not all of them do. Which leads to some confusion with this metric.

The problem with that, is that podcasts are ad-hoc: you can listen when you like. I’ve found podcasts which are 2 or 3 years old, and gone back to the start listening from the beginning. Doing that (which some folks do, if this history of the show is important) doesn’t add to their audience from a sponsorship point of view, but it does make their audience larger.

On top of that, streaming an episode (clicking play on one of the links in the Google search result screenshot, above) will only count as a listen after the first 30 seconds has been played. Anything less than that, doesn’t count as a listen.

On top of THAT, the potential sponsors could ask to see proof that you’re actually getting as many listens as you claim. It could just be one person listening to your show on repeat (or a group of people in a building, using VPNs, to play your episodes without listening to them) for all they know.

Some podcast hosts will give you access to a bunch of stats about your listeners. These are (usually) anonymised stats collected from useragent and IP addresses. All webhosts have access to this data for the websites that they serve, and a podcast feed is no different in this respect.

Here’s a rough idea of the worldwide listener stats for The Waffling Taylors:

It turns out that The Waffling Taylors is more popular in the US than in the UK, and has a cult following in Japan and Australia - image taken Jan 1st, 2019
It turns out that The Waffling Taylors is more popular in the US than in the UK, and has a cult following in Japan and Australia - image taken Jan 1st, 2019

All of this can be faked with someone who has access to a global VPN, as they can connect to a node in one country, download an episode of your show, then change to another node and repeat. In fact, this is what a lot of folks who offer to boost your download stats (on sites like Fiverr and the like) are actually doing. Whilst it will increase that number, it doesn’t actually grow your audience. Again, that download number is just a number, and shouldn’t be your goal.

Advice 10: Sponsorship

When it comes time to actually look for sponsors, take a look at some of the ad networks. But do your due dilligence. Look for reviews of them by folks who are actually using them. Most of the ad networks will include testimonials on their site, but do some background checking to ensure that they are still using the network. The quote may be old or fabricated, so look into it. Also familiarise yourself with the IAB. Look into things like their podcast measurement guidelines. Your potential sponsors will know this stuff and will be looking for specific numbers, so make sure that you have them to hand (or know where to look to find them).

Some hosts will only give you access to IAB numbers if you pay them extra. LibSyn does this (they and the podcast host service The .NET Core Podcast), and their stats breakdown is amazing and totally worth paying for. Without the IAB numbers, many sponsors simply won’t be interested.

If you go directly to a potential sponsor - rather than using a network - be ready to sell your podcast as a platform to get their message out. You want to go for the hard sell here, why should this company put their ad on your podcast? Is it even relevant to the subject matter? If your podcast is about submarine engineering and you are approaching Casper, they might pass. What can your show bring to their brand? Do you have those numbers to hand?

Another thing to know is that a lot of sponsors will only be looking for shows which release episodes very frequently - one sponsor I approached said that they where only interested in shows which released new episodes every day.

One way to simplify getting information out to potential sponsors (and to journalists, if you would like them to cover your show) is to have a press kit page. This page can list download numbers, listener stats, and details about the show, the hosts and some example art work. Take a look at the press kit page for The .NET Core Podast for an example.

Advice 11: Release Cadence

It can be super exciting to release your first episode, and you may want to release the next episode right away. But you need to think about the longevity of your show.

If you release two episodes a week now, will you be able to keep that cadence up in 6 months time? What about in a year? What about if you get sick? You need to set a cadence that you can stick to in a year’s time.

When I started The .NET Core Podcast, I was releasing episodes every week. But that was impossible to maintain. I was editing episodes during my lunch break at work, during my commutes to and from work, and into the evenings on most days - and once or twice on the weekends. I dropped the release cadence to fortnightly and built up a backlog of episodes to fall back on, and I’m much more relaxed now.

Mini Advice 4: Backlogs

Before I created a single episode for The .NET Core Podcast, I had a markdown file with ideas for the first 15 episodes. Each of these ideas was fully fleshed out. This helped me to see what the longevity of the show would be. I had a clear topic for each episode, and I spent time writing them, cross referencing them with blog posts that I had written, blog posts written by friends, or official documentation. These 15 episode drafts became monologues about aspects of .NET Core that I thought would be interesting to listeners - either new to .NET and seasoned veterans.

Looking at the released episodes for the show, I have only released 9 of these monologues so far. Which means that I still have 6 episodes that I can turn around very quickly, should I find myself without any episodes ready to go.

in fact in writing this blog post, I came up with 5 more monologues

The key is to have a stable of episodes that you can fall back on. I’ve been in a situation (early on in my podcasting journey) where I was editing right up until the hours before release of an episode - if you keep reading, you’ll be able to guess what time I stopped editing that episode. The key to never ending up in that situation is to have a bank of episode ideas ready to go.


Once you’ve set your cadence STICK. TO. IT.

The majority of podcast listeners have subscribed to around 10-15 shows. As such, they actively look for new episodes. Just like how a lot of people without YouTube accounts use YouTube: they’ll search for their favourite shows, and if there isn’t a new episode they’ll move onto something else, if there’s no new episode then they’ll stop watching altogether.

I’m a bit of a “power listener” as I have a lot of shows that I subscribe to

just some of the shows I subscribe to, as shown in PocketCasts - taken in Jan 2019
just some of the shows I subscribe to, as shown in PocketCasts - taken in Jan 2019

A number of podcasts that I listen to aren’t available on PocketCasts, as such I have recently moved to using [Antenna])(https://antennapod.org/) and gpodder.net for all of my subscriptions.

So called “power listeners” are folks who listen to podcasts the majority of the time. They don’t tend to listen to music. They listen to podcasts when doing menial tasks (commuting, chores, etc.), and some (including me) listen when they work. I’m an auditory learner so can usually both work & listen - and take it all in.

A lot of your audience will NOT be those listeners. As such there will be peaks and troughs in your listenership (those download numbers that you can’t trust). The majority of your listeners will likely listen during their commute and when doing chores, and that’s it. Because of that, you should expect to see dips in listenership during holiday seasons, and times when folks aren’t working (Labour day, etc.). This is because they’ll be doing what you (likely) are doing: spending time with family.

So don’t be put off with occasional dips in download numbers.

The two peaks here are episode releases, but the trough afterward is the 2019 festive season
The two peaks here are episode releases, but the trough afterward is the 2019 festive season

Advice 12: When To Release Episodes

Whenever fits your schedule.

Don’t set yourself up for failure by releasing episodes when it’s hard to. You still need to edit, upload, release, and publicise the episodes. So you need to factor in time to do that. Fit it in around your schedule.

I’d recommend taking a look at your monthly calendar and finding multiple days which work; and remember you need to be able to do this every time you release and episode. Once you’ve found a number of days which work with your schedule, have a think about your subject matter. Is it evergreen? Is it related to a real-time event?

Most of the episodes for my shows are evergreen, so I release them on a day which suits me. But the EGX episodes of The Waffling Taylors went out at the end of each day of that event. This was super tiring, as we’d recorded hours of content which needed to be whittled down to 90 minutes, edited together, and released AFTER a full day at a gaming conference… for four days in a row.

It was not easy.

Is your podcast about a specific TV show? It might make sense to release it very soon after each new episode of the TV show has aired. Is it about a series of ongoing movies (still being released to theatres)? Is it possible to release your episodes during the lead up to the release of the new movie? If so, people will organically find your show when they are searching for the subject.

I chose Fridays at 1230 GMT because I’m usually on my lunch hour at that time, and can quickly sign into my podcast hosts to ensure that the episodes have gone out. I also have all of the tweets/posts/statuses (stati?) for them ready to go just before that. On top of that, it’s a time during the day where most listeners will be able to listen to the episode:

  • For listeners in the far east, it will be late at night so that covers commute times
  • For listeners in Europe and The UK, it’s lunch time into early afternoon
  • For listeners in the Americas, it’s relatively early in the day - more commute times

Again, YMMV and do what works for you.

Advice 13: Automate What You Can

I’ve partially automated the entire process. I have a .NET Core application that I can run which:

  • Creates a SquadCast recording session
  • Creates the Audacity Project on disk
  • Creates an empty show notes file

This takes the ceremony out of getting everything set up. I’m also looking into whether I can automate that with an IFTT connected to the calendly for the show.

Once an episode has been uploaded to my podcast host service, I set up a another IFTT job to do the social stuff, release the show notes, and email folks for me (usually the guests, and my editor). It isn’t hugely difficult to get this all set up, it just means reading a bit of documentation and getting your head around how it all works.

Advice 14: Share The Load

If you are going to have co-hosts, make sure that you divide the lion’s share of the responsibilities for the show between you. Otherwise, you’ll end up doing it all and they’ll take all of the credit. You don’t want to be working until the wee hours of the morning, wondering if you’ll ever see sunlight again, slaving over getting the next episode out, for your co-hosts to take all the credit and claim all the glory. It’s just not fair.

A friend of mine (who has a very successful, weekly show) has gone as far as to draw up a contract between him and his co-hosts. I don’t suggest going this far, but it can help. Especially if co-hosts end up not pulling their weight, or want to leave the show (neither of which have happened to this friend): you then have a legal document saying whether the IP is shared between you and the co-hosts, and whether they should expect to receive a share of any sponsorship or profits after they have left.

For a number of reasons (copyright, legal protection, sponsorship, taxes, and sharing the load), it might be worth looking into setting up some kind of legal entity which owns the show. Seek legal and accounting advice on this, as this will differ per state and country.

as an example, the Coding Blocks Podcast is owned by an LLC. This helps the three hosts keep an eye on spending (they each put money into the LLC, and that is spent on things relating to the podcast), and it helps with taxes due to sponsorship. However, they are based in the Atlanta, GA area and this may be a requirement based on local laws.

Again, due diligence.

Advice 15: Guests & Promotion

Look for other shows in your niche, and approach the hosts about potentially being on their show as a guest. A lot of shows will happily do this, because it makes it easier for them to create content, and it means more people will listen (you will likely tell all of your friends, family, colleagues, and listeners about your appearance). It also works in your favour, because it gets your name out to people who are very likely to be interested in your show. And you can return the favour and have them on your show, doubling down on the guest spot potential.

Before I even started The .NET Core Podcast, I was on a number of shows talking about .NET Core (Cynical Developer, Productivity in Tech, etc.). This meant that when I launched my show, the hosts of those shows were willing to shout out about it, and place a link on shows notes for the episodes I was in.

I would also look into Facebook, Twitter, and LinkedIn groups with a lot of users in your niche. Before you start blindly posting links to your episodes, check with the admins of those groups as to whether that’s permitted - some groups will want to foster a conversation rather than turn into a link farm. Each group will be different, so check with the admins and make sure that your posts follow those guidelines.

I haven’t looked into other social networking sites and services (such as Instagram and Pintrest), as I didn’t see how they were relevant to the podcasts that I create. But they might be relevant to yours, so I’d recommend doing some research.

In Closing

So that’s 15 peices of advice for budding podcasters. Do you agree with everything here? Is there something you would have added? Do you disagree with anything in the list? Let’s chat in the comments, or get in touch over on Twitter or via our contact page, and let’s talk about it - lets not get into arguments about bit rates though, that doesn’t help anyone.