Bring technology advice and trends to your listeners, with a cutting-edge technology podcast.
Technology-themed shows can be a lot of fun and can be useful to listeners, but keep in mind that this particular audience will be demanding and smart, and you’ll need to be extremely passionate and informed about your topics if you want to pull this off successfully.
While there is no secret formula, I’ve discovered some things in my podcasting career doing technology-oriented shows that have worked for some reason, at least most of the time.
Raw is an odd term, but it’s the one word I think of when I think about the audio shows I do. Technology shows with nontechnical hosts on any medium (TV, radio, and now podcasting) are easy to spot. Usually these shows are hosted by someone who “almost sorta gets it,” but they never sound quite right. Folks in the technology trenches aren’t usually the most polished speakers, but there’s a rawness to what they’re saying that’s genuine and can’t be faked. And just about every subject contains so much minutia that if you’re going to rattle off the benefits of, say, Linux, you better make sure you’ve either spent the last few years banging away at the console or you’re interviewing a Linux expert. This isn’t a top 40 station; it’s a podcast, and it’s meant for a sliver of the population, not for everyone. Your listeners will appreciate the familiar tech-hacker as opposed to the slickster DJ.
You can’t be an expert on everything, but it’s usually pretty easy to spot who is the expert in a specific area of technology. When I want to hit a topic that I think might be interesting to my audience, but I’m not an expert in that topic, I usually try to find some of the experts in the field. This sounds hard, and besides, why would anyone want to talk to a lowly podcaster? Well, I’ve found that book authors promoting their books and bloggers looking to get the word out about subject matter in which they’re experts are usually good candidates. I’ve interviewed [Hack #33] corporate types, but usually you have to get past a few layers of PR or marketing people before you can get to an engineer or developer. The best way to do this is to tell them up front that you’ll be asking some pretty technical questions, and to send over a few sample questions to scare them. It also helps to attend tech conferences—catching someone out in the hallway for a five-minute chat after they just did a killer demo on stage seems to make a good segment.
When I review technology (software, gadgets, or whatever), I generally review only those things I’ve bought or have tried in real-world settings. A good example of this is when I installed an XM Satellite radio in my wife’s car—after installing it, using it for a few weeks, and recording some audio of some of its traffic and “extra” features, I felt I could speak to it in a way that folks could relate to. Why we bought it—the commute times, the technology that makes it work, geographic area, pricing—these are all considerations you usually don’t get from the two-minute tech reviews you see on TV or hear on syndicated radio. After you get a few of these hands-on, real-world reviews of your own gear under your belt, it might be a good time to contact some of the companies that make the products you want to try. Having them listen to how you review a product will help them get an idea of what you have planned. It’s also good to let them know your review might take a while longer than a more superficial review, since you’re actually going to use the product or service in a real-world setting.
Because your audience likely will be more technical than you are, it’s OK to try new recording setups and conferencing methods. If you’re finding that Skype does a better job with five-way recording than recording a phone-based system, that information likely is useful to your audience. Did you get a new mic? Let the audience know—I’ve always felt it was my duty as a technology podcaster to run across the technology minefield for my audience, alerting them of what’s good and what not to step on. While others might have other motives with their podcasts, one of my goals is to grow new tech podcasters—some of your listeners might take a page from your book and start their own podcasts. By opening up the kimono on how and what you do for your show, you’ll be helping this process along.
I’m saying this only because I’ve noticed that it’s the biggest source of complaints. When people download a technology show, they really want the dirt on tech, not some weird Red States versus Blue States debate. Technology is one of the rare topics that many people can be part of and can enjoy. For some reason, "talk radio” and even “talk podcasting” encourage all sorts of heated topics, which is fine; just keep them out of a tech show. With that said, you should talk about the politics of legislation and the laws that affect technology; just leave out the ideology that the politicians often inject.
Tech podcasts are filled with tons of information about a wide variety of topics. Because of this, you’ll need to provide all references in your show notes. I’ve generally found that breaking the show notes into time sections with a one-sentence descriptor, time code, and URL helps a lot. Show notes with a good description also help casual listeners to figure out if they want to listen to your show. In addition, they help the search engines index your content, since it’s going to be a while before search engines are able to index audio. Here’s an example:
|01:30—Google offers new mapping service (and here’s a hack for it…)|
Many people have told me they listen to shows as they’re commuting to work, and that once they arrive at their desk, they check the show notes for something they enjoyed or want to learn more about.
The most common format for podcasts is the venerable MP3 [Hack #18] , but depending on your audience, there might be demand for another format. If your show is Windows-centric—let’s say it’s about Windows Media devices—by all means, supply your podcast in Windows Media Audio (WMA) format. Is your show about open source? Go with the Ogg Vorbis format, but use it in addition to MP3. I try to supply an MP3, WMA, and Ogg file for direct download, as well as via torrent when it’s possible. It’s a little extra work, but there’s nothing better than someone getting the format they really want, right from you.
You can get feedback about your shows in many ways. I usually provide my email, instant messaging, and Skype addresses and encourage folks to send comments, but you also can get feedback in a few other ways. When I first began podcasting, I’d post my audio on my site and send a link to one of the many IRC rooms where my friends hang out. This quick sanity check usually saved me a ton of embarrassment if I goofed on a filename or audio compression, but it also gave me some initial reactions to my shows. I don’t suggest doing this in IRC channels you’re not familiar with or don’t have friends in, since it’s somewhat spammy.
Another way to get feedback and to get some extra content for your show is to use a free voice mail service [Hack #62] . If you use Skype, you’re already set; just tell people to call and leave you a message. I really like k7.com’s service. It’s a free voice mail system that sends you an email with a WAV file attached. You can even request a “vanity number” so that people can dial words. Here’s one of mine: 206-888-MAKE.
This is the most important consideration. I’ve stumbled along, creating technology podcasts for more than a year now, and each show, each email from a listener, makes every new podcast a little bit better. My final tip is to make shows you would want to hear, and talk about things that no one else is talking about. The worst thing in the world, the killer of all great things, is sameness.
Moira Gunn’s TechNation radio show (http://technation.com/) is distributed nationwide through NPR. It also is podcast via Doug Kaye’s IT Conversations (http://itconversations.com/). Moira’s show comprises two or three interviews with people she believes have a keen insight into technology and its impact on society.
Today, she interviews Nobel Prize winners, famous scientists, and the CEOs of multinational corporations. But early on, producers were skeptical as to whether the technology format would work. And Moira, even with her background in engineering and science, initially was overwhelmed by the breadth of the topic. The more technology trendsetters she interviewed, the more she was able to frame their work in a larger context, and to pass that understanding on to her audience.
She prepares for the interviews with a set of around 8 to 20 written questions. For the first question she goes right to the heart of the topic. Follow-on questions provide the background material for her listeners. She likes to let her guest guide the conversation, and she uses her written questions in a random order.
On a good day, she can get everything she needs in 23 minutes or so, but the segment sometimes runs longer, depending on the guest. She admits that not every scientist or engineer makes for a great interview. She gets a couple every season who can’t answer questions or who can’t separate fact from opinion.
The show never lacks for guests. Most are booked several weeks in advance and are sourced from a network of around 140 publicists that Moira has developed over the years. Cutting the final show takes from 3 to 10 days. The finished show is sent as an MP2 file to Doug Kaye, who splits up the segments into individual podcasts for IT Conversations.
Moira wants the show to discuss technology’s impact on our society. So, she stays away from product-pitch segments and late-breaking news. She likes to find questions for the show that the guest might not have heard on his press tour, and she likes to give an outlet to scientists, philosophers, and engineers who would not have the opportunity to reach a wider audience otherwise. From the wide appeal of her show, it’s clear that Moira’s approach is working.
Tim Shadel found that no show written and produced for Java programmers was available for him to listen to during his commute. His Zdot podcast (http://timshadel.com/blog/) afforded him the ability to create content just for engineers. This is not a “for dummies” technical show. It’s in-depth coverage of architectural and technical Java topics. And it’s presented three days a week in 10- to 20-minute installments because that’s just the amount of time that commuters have to listen to the show.
He starts with a Java topic that interests him and writes some notes with some major points highlighted. Then he records the show in a single shot using Audacity [Hack #50] . He edits out the “ahs” and “ums,” and then he drops in the show’s canned intro and outtro [Hack #63] using a multitrack Audacity session [Hack #60] . With a few effects such as gverb [Hack #51] and some noise removal, the show is ready for encoding and uploading to his Word-Press blog [Hack #38] .
Even through some hardships, he has kept doing the podcast because it gives him a way to relate his ideas and experience to other programmers.