Transistor.fm to the rescue

November 18, 2022
Based on my customer service experience, Transistor.fm is truly agile. Not necissarily "Agile", but agile.

I want to make a small plug for Transistor.fm, the company I use to host my podcast, Tiny DevOps.

As I’m working on automating several of my processes related to social media and my podcast, I began investigating Transistor.fm’s API.

You see, for the last year+, I’ve been publishing my podcast episodes via the Transistor.fm web site… then re-entering a significant amount of that data for my web site. Their API sounded like a great way to automate a lot of that, so I could enter the data just once, into my web site, then via their magical API, publish to Transistor.fm.

The only problem? Their API had no way to upload the written transcript of each episode.

So I contacted their support by email. Less than two hours later I got a polite response:

This feature has been considered and will likely form part of a future API project that encompasses a number of features in addition to adding transcripts.

Ah well…. maybe some day.

Then… the very next day:

Hi! We’ve had a few requests for this so we’ve gone ahead and added it to the api. It’s been tacked on to episode creation and updates. Consider yourself the first beta tester. Let us know if this suites your needs, or if you experience any issue with it! Thanks for reaching out about it.

LOL. Wow!

So, great response time, and good customer service. Kudos to you, Transistor.fm.

But what I want to call out here is something else…

I know literally nothing about the internal structure or technology used at Transistor.fm. But… I can make some educated guesses, based on this short interaction.

  1. They don’t batch releases. Either they were able to prioritize, build, and deploy, this small feature independently, or I got extremely lucky with the timing of my request, and happened to contact them a day before their quarterly scheduled release…
  2. They don’t rely on manual regression testing. I’ve never seen a team that relies on manual regression testing with less than 24 hour turnaround.
  3. They aren’t over-committed. When a team is over-committed, pulling in a small feature request from a random, low-teir customer, never gets prioritized.
  4. Their teams are emplowered. Apparently both customer service, and their developers, have the freedom to make choices. Because I’m sure some upper-level manager would not have prioritized this task for little ol’ me.
  5. They don’t use Scrum. If they were using Scrum, the best I might reasonably hope for is “Thanks for your request, we’ll do that next sprint,” followed by up to two weeks of waiting. And honestly, that would have been fine with me, but that’s not what happened.
  6. In short: Transistor.fm is agile. Not necissarily “Agile”, but agile. That is, they can respond quickly to change.
Share this

Related Content

Not every product or change needs a sprint demo

Demos are far from the only way to receive timely feedback.

We found a way that works best for us...

These phrases are designed to end conversations.

My very first (and last?) successful sprint

We didn't call it that then, but looking back, it certainly looked like one.