The Great Tim Ferriss
I was listening to one of my favorite podcasts. It’s not only one of my favorites, but one of the most popular podcasts in the world.
The Tim Ferriss Show is dedicated to featuring world-class guests - people at the top of their field, from a broad and eclectic mix of different fields. The point is to find the elements of greatness and deconstruct the components make for world-class performers.
On Developer On Fire, Prosper Otemuyiwa emphasized being driven by the desire to be world-class. He has come to embody his desire and has truly achieved it. His is an outstanding and amazing story. If you’re not inspired by Prosper, you are probably unreachable. I think of Prosper now when I think world-class.
Another name that comes to mind when thinking of world-class software developers is, of course, David Heinemeier Hansson (DHH). This is so much the case that he has been a guest on the Tim Ferriss show. I take great pleasure in knowing I have a guest in common with Mr. Ferriss. That simple fact makes me feel a bit like I have arrived.
Back to the Point
As I was saying, I was listening to Tim Ferriss and he was doing a little routine he likes to call “drunken dialing.” where he gets social media followers to sign up to receive a phone call from him as he makes several of them to create a show that is a medley of these calls with different people asking him questions. This particular episode was not the first time he has done this.
One of the recipients of the calls from Ferriss was a software developer interested in advice on starting a podcast and on how to get big names in the field on his show. The gist is that he doesn’t have a recognizable name and wants to speak with exceptional people, but doesn’t know how to approach them. The call starts at 01:00:22 and finishes at 01:17:04.
For your convenience, here is the audio, starting at the relevant point.
(I don’t think sharing the audio in this way is a violation of any law or ethics code - I certainly wouldn’t object to somebody wanting to share a portion of a Developer On Fire episode in this way - please let me know if you know better about such things.) (And, of course, if you’re reading this, Tim Ferriss, and you don’t want me doing this, let me know and I’ll stop immediately. I’d also love to talk with you about a great many things - let’s get in touch.)
This is a question I feel I am qualified to address and I agree with parts of Tim’s answer and disagree with other parts.
The name of the call recipient was Eric. No last name is given and I don’t know who he is. Eric, if you’re reading this, please get in contact with me and we can talk further and podcasting and software and life.
Start Small
Tim’s advice was to start with smaller names and work up to the larger-than-life developers. That’s not the approach I took at all to my podcast. I asked some people for interviews with cold emails to total strangers who have recognizable names. I did not limit myself to people I knew, people I saw as approachable, or people I thought were “in my league.” This is, to me, the greatest reason for the success of Developer On Fire. Success can be defined in many ways, but to me, the best thing that has come from the show is the lesson I have learned: If you want something from someone, you must ask them. It’s good and ok to ask and there is no harm in asking anyone for an interview.
I have been surprised how many people have agreed to speak with a stranger. I have been told “no” quite a few times, too. That’s ok - anyone who doesn’t want to speak with me has absolutely no obligation.
There is never a “yes” without an ask, though.
It’s a simple as that. Eric mentioned to Tim that he’d like to speak with DHH. I emailed DHH early in my time with the podcast - so early that I was still describing myself as someone who recently started a podcast, rather than as a podcaster - and it took a while to get a response, but I did get one. He didn’t know me, I did not have a recognizable name, and there was no reason for me to believe he’d be willing to share his time with me. I had heard some people on a podcast once talking about seeing him at an event and not talking to him because he was too unapproachable. I did not expect to get a response at all, but I did. He was happy to do the show and it is still my most downloaded episode.
Thank you, DHH.
Further Advice
Tim gave Eric a few other pointers related to podcasting itself without additional prompting.
They were:
- Record a minimum of six episodes.
- Look for ways you can win even if the project fails.
Recording multiple episodes before shipping is excellent advice. His reasoning was to try to game iTunes to get some attention for the podcast early on. This may or may not really matter and it may or may not fit with your intentions on creating a podcast. I like the advice for other reasons. For one thing, it’s a commitment to give this new pursuit a try before abandoning it, thinking it’s not for you. It’s common to experience the friction of getting started on something and read it as being not a fit rather than an adjustment period. Only with adequate effort, can you really determine which it is. Also, shipping with more than a single episode makes for a nicer listening experience. One episode is not enough to get a taste for whether you like something and it’s nice, as a listener to have a few samples to make a decision on whether to subscribe or not. As with software, focusing on user experience is paramount to making your product worth consuming.
Additionally, if you have multiple episodes recorded, you don’t have to release them all right away. Developers know the pain of facing deadlines. If you commit to a schedule to publishing new episodes, it’s great to have a buffer so you can take a little time away from the microphone or deal with cancelled appointments or guests who don’t show up at the agreed time without compromising your commitment. I always have multiple weeks of Developer On Fire episodes recorded and guests will often wait a month or more between recording and hearing themselves on my feed. Life is much better lived when you’re not scrambling.
The advice for looking for ways you can win even if the project fails is a great way to look at life. One that is easy to overlook. I mentioned in Episode 1 with John Sonmez, my first interview, that even if nobody ever listens to the show, it would still be an exercise worth pursuing. I was right about that. Tim talked about working on verbal ticks and learning patience in waiting for an answer and not jumping in right away when a guest is struggling. This is great advice for teachers. I have found that asking for interviews, putting out something I think is good and finding out if I’m right, and facing people I admire and see as larger than life have all led to a new me much more willing to leave behind (some of) the limitations of comfort and to punch fear in the face.
The Question of Questions
Eric asked Tim for advice on how to formulate questions. This is a point on which I may have learned something. Tim’s advice was to find things about which to ask that the guest is not routinely asked. It’s simple advice and seems obvious with it stated, but it’s also counter-intuitive. It’s obvious to ask the questions that are always asked because we all wonder about a lot of the same things. This is one place where the format of a show like Developer On Fire, with a set of standard questions, makes this something I have done accidentally. At least, I have done it to an extent. My standard questions are crafted to get guests to tell stories and share their experiences and wisdom. In most cases, this is something different than what the guests are asked on other podcasts. At least, I’d like to think so. I’d love to hear what you think. Please comment below and/or join the community to interact.
Podcasting Nuts and Bolts
Tim also recommended hardware and software to use for podcasting. For anyone interested,
He also talked about software for recording and suggested using Skype and ECamm call recorder. Typical advice for new podcasters is to use Call Recorder if you are on a Mac and Pamela for Skype if you are on Windows. I use Pamela as a backup for Zencastr to make sure that in case something goes wrong, I have a secondary recording. My primary recording is done with Zencastr, which Tim also mentioned. It’s cool that he did so. I’m a big fan and interviewed Josh, who created it, while it was still in a free Beta and still very much a story yet to be determined. He’s doing a great thing for interview participants and for himself and I’m happy to see it. When I interviewed Scott Hanselman using Zencastr, he was impressed and started using it for Hanselminutes, too.
Tim also recommended some hardware. If you’re interested in podcasting, screencasting, or something else involving media, you may be interested to know he recommended this microphone. I have not used it. It costs quite a bit less than mine, so would be worth considering. Instead, I use and recommend the Rode Podcaster (which is also recommended by Pluralsight for their authors). Actually, I didn’t just buy the microphone, but the package that also includes a boom arm and shock mount, which is really a must for working at a desk. I have used that microphone for every episode of Developer on Fire except a handful where I accidentally recorded by webcam instead because of misconfiguration of my computer and the one I recorded in person at an event. Tim also mentioned a higher-end mic, popular among podcasters for those that want something more. It’s more expensive than the Rode Podcaster, but not remarkably, so, and may be worth consideration, but I have never used it, so can’t say for certain.