This blog post was originally posted over at the blog for RJJ Software - here is a link directly to it

A Question About Podcasting

Recently, 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?

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

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 - if I tidied it up a bit, that is. So I've taken some time to do just that, and here it 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

Intro

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

• The Waffling Taylors - fortnightly releases
• The .NET Core Podcast - fortnight releases
• DevOtaku - podfaded, but may be returning
• Ask a Brit - podfaded, but definitely returning

First a little terminology:

• Podfade; when a podcast stops creating new episodes and fades into obscurity
• Host; someone who will host your MP3 files and create an RSS feed for people to consume
• IAB; The Internet 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 it
• Double Ender; when you and a guest have to use some kind of VoIP system have everyone record their audio and splice that together

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?", "Can I somehow make my voice sound like I'm a ghost?"

yes. In Audacity: select a section, reverse it, add an echo, and reverse it again

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

You may also start having ideas about intro and outro music. I'll come to this later, but DO. NOT. USE COPYRIGHTED. MUSIC. If you didn't create it, and you didn't pay someone to create it, don't use it. There's a small group of folks called the RIAA who will likely send you a cease and desist.

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.

emphasis is mine

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 actually 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 want a chat 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 my brother's games room 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 for this, 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 the noise.

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 episodes for The .NET Core Show, I use 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 The Waffling Taylors we have been using lavalier mics which have XLR (rather than USB) connectors, which we plug into a Zoom H6N.

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.

One of the best things about this piece of kit 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 mics 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 laptop/PC, 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.

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 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. 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 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 all of the short cuts for Audacity, and have a solid backup plan, so I'm happy using that. But YMMV (Your Mileage May Vary).

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 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 multiplexed together (that's a fancy way of saying "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 recording then count down from three and all clap together. When you come to edit everything, you can use the spike caused by the spike 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. I've used ZenCastr and SquadCast more than I have done double enders; when they work, they work gloriously. But when there's an issue (I've seen this with ZenCastr more than anything else), nothing is usable. I've had to re-record several interviews that I've done with ZenCastr, and I still have a few that are unusable because I haven't had the chance to re-arrange them.

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.

SquadCast will also ask for video permissions. Video footage will not be used for the recording, as such it is recommended to not share video. Doing so will require more bandwidth, and could potentially affect the recording.

Having headphones, earphones or some other form of audio monitor will ensure that there is no audio feedback from a combination of the speakers that your computer uses and the microphone that you are using.

Also have an FAQ for your guests. This can help with easing them into being on a podcast, should they be new to being interviewed for them.

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) will be on the episode with me
  • If there are guests, reach out to them and arrange a time which suits them best
  • Discuss the episode with them ahead of time, and share as much in the way of notes, 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 the latest episode as of posting this - you'll see that it's more like commentary, filling in gaps, and discussing the episode itself. This is because it's designed more as supplemental material to the show. I could provide a transcription of the episode, but they tend to be a little too frenetic to provide a transcription - which means it would take too long to create one. This means that we're cutting out a large portion of our potential listener base: those with accessibility needs. 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 the latest episode - you'll find a full transcription of the episode. This helps folks with accessibility needs, 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 needs rather than the SEO; as your audience should be your priority.

Advice 6: 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. So 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:

• A: a lot of money for what they do (again, you get what you pay for)
• B: some kind of assurance that there will be a 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 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 (think like pounds and ounces, but for audio) 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 web site. All three offerings will take an input audio file, and apply Dynamic Range Compression to ensure that your 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.

My typical 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 WAV file
• Put the WAV file through Auphonic
  • 96 kbps MP3, Mono

Mini Advice 3: File Sizes

96kbps because the music idents are specifically designed to sound ok at that bit rate; MP3 because you don't want someone downloading a ~600 MB audio file; and Mono because it's conversation with everyone mixed to the centre, so it immediately halves the file size. Here is an example of an episode that I'm working on right now, a WAV version and the MP3 encoded version:

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.

As for actual advice on where to start: be prepared to put a lot of work in. The average episode of The .NET Core Podcast is 45-80 minutes long. But I actually spend about 8 hours working on a single episode.

Recording the episode is one of the easiest parts, as I hit record and my "podcast interview voice comes out". Also, I'm incredibly lucky that I'm an auditory learner so I can speed through the recordings a 1.6 to 2 times faster than normal and still take it all in. You might not be able to do this, but with a little training, you will be able to reach those speeds. I'd still recommend going through the episode again at normal speed, in case you miss something.

The rule of thumb for editing is: every 30 minutes of audio is going to take at least 60 minutes to edit - more if there are lots of issues with the audio. Even though I go through my episodes super quickly, I'm still spending around 90 minutes editing every 30 minutes of audio.

It just takes time.

Advice 7: Growing Your Audience

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

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 year or so. 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. That's the biggest drain, for me.

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 at least before you launch. Most of the other platforms piggy back off of those two (even though Google Podcasts is still very new).

It will be worth looking into Podcasts 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

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 the recent festive holiday period) have much longer wait times. So if you are planning to launch on a specific date, ensure that Apple Podcasts has indexed your podcast way 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 (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 in the search results

Advice 9: Download Numbers - Ignore Them

Don't expect success overnight. For every Joe Rogan Experience, there are 300 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.

Most companies who offer sponsorship and advertising will want to know what your audience size it. 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 a lot of 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 and of the links in the 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 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 aspect.

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

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 host The .NET Core Podcast), but 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.

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 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 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 alike.

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) where I was editing right up until the hours before release of an episode - reading on, 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

A number of podcasts that I listen to aren't available on PocketCasts, so I use the podcast feature of VLC to keep up with those shows.

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

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 conference. 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 show about a specific TV show? It might make sense to release it very soon after each new episode of the TV show. 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 folks will be able to listen to the episode:

• For folks in the far east, it will be late at night so that covers commute times
• For folks in Europe and The UK, it's lunch time into early afternoon
• For folks in the Americas, it's relatively early in the day - again 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

Which takes the ceremony 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 hosts, 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: 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.

I have done this, both The Waffling Taylors and The .NET Core Podcast are owned by my limited company. This same limited company is the one that I use for my development contracting business. This protects me (the individual) in case a guest makes a libellous or incorrect statement on the either of shows, and someone takes issue with it.

The Coding Blocks Podcast is owned by an LLC for tax and accounting reasons (as far as I know). 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 to create content, and it means more people will listen (you will likely tell all of your friends, family, and colleagues 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, 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.

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, and let's talk about it - lets not get into arguments about bit rates though, that doesn't help anyone.