The author is technology coordinator for KUT Public Media.
It’s Monday morning.
The chief engineer is finally on vacation, the first real one in months after all the long days, transmitter visits and late-night troubleshooting. Then it happens.
A studio-to-transmitter link drops. Metadata stops updating to the HD Radio receivers. An automation server starts throwing errors. Operations staff start calling around and run into the same wall every time.
Nobody actually knows how these systems work under the hood.
For a lot of stations, this isn’t hypothetical. It’s closer to real life than most of us want to admit.
Broadcast engineering has always leaned on a few experienced people who carry decades of knowledge around in their heads. That’s valuable, no argument there, but it’s also a risk nobody talks about enough.
Knowledge lives in a person, not in the station. And honestly, the real test of an engineering department isn’t how smooth things run when everyone’s at their desk.
It’s what happens that one day the person who understands a system is gone.
The “only one guy knows” problem
Every station has a few systems that fall into the “only one guy knows how that works” bucket.
Could be a custom audio routing setup, firewall rules quietly holding a remote site together or an automation failover that nobody has touched in years.
Maybe it’s a transmitter setting adjusted once, ages ago, never written down anywhere. Or just a maintenance routine that lives in someone’s head because that’s how it’s always been done, nobody ever wrote it up.
Bit by bit this all turns into “institutional knowledge,” except that’s not really the right word for it. It’s not institutional. It’s personal.
It lives in one person and nowhere else.
But life happens. People go on vacation, get sick, retire, take a job somewhere better or just vanish with barely a week’s notice.
[Related: “Rojith Thomas on the ROI of Reliability”]
When that happens, their knowledge goes with them, and everyone else is left starting from zero.
This is all at a time when the reality is that the industry’s getting older.
Many veteran engineers are heading toward retirement, and stations keep running leaner staffs.
So, preserving knowledge stopped being a nice-to-have a while ago. Now it’s just necessary.
Write it down!
Nobody actually enjoys documentation.
Most engineers would rather go fix the next thing than sit down and write about the last one. It takes time, it takes patience, and by the time you’ve got something working again, writing it up feels like the least important item on the list.
There’s always something else pulling at you.
Still, it’s one of the better investments a station can make. At minimum every facility ought to have solid, current records for:
- Network and IP addressing
- Network diagrams
- Studio and transmitter inventories
- Audio routing and signal flow
- STL and backup STL setups
- Automation architecture
- Remote access steps
- Vendor contacts
- Emergency procedures
Broadcast engineering isn’t just transmitters and consoles anymore and it hasn’t been for a while.
Virtual servers, cloud services, streaming, metadata systems, VPNs and cybersecurity — it’s all part of the job now. And as that gets more complicated, the need for actual documentation just keeps climbing with it.
Documentation doesn’t have to be fancy or expensive either. Draw.io, Visio, Lucidchart, tools like that make it a lot easier to put together network diagrams and signal flow charts without much fuss.
Draw.io, as John Bisset talked about in his Workbench, has caught on with engineers because it’s free, easy enough to figure out, and it saves right into OneDrive, Google Drive, SharePoint or whatever file-storage solution you’re already using.
A diagram that’s actually current can save you hours the next time something goes down at 2 a.m.
Wherever you keep your documentation it needs to be somewhere the right people can access.
A file sitting on an engineer’s laptop isn’t much better than a procedure sitting in his head.
At KUT, we use a shared OneDrive, an internal FTP setup and the Box platform.
We’re working on consolidating the setup, because having documents scattered across three or four places just creates its own mess.
A playbook for the bad days
Good documentation tells you how something was built. Great documentation tells you what to do when it stops working. That’s really the whole point of a runbook.
A runbook is just a step-by-step guide for the common failures and routine maintenance, written plainly enough that someone without a ton of technical background can follow along and keep things stable.
After all, we are not trying to turn operators into engineers here. The goal is to buy enough time until someone who actually knows the system can jump in.
Even experienced engineers do better with something written down to follow during a crisis than trying to remember every step while the phone’s ringing off the hook.
The password problem
Pretty much everything at a station sits behind a login these days. Automation servers, codecs, routers, VPNs, cloud accounts, streaming platforms — there are credentials for all of it.
And yet plenty of plants are still running this off notebooks, sticky notes or somebody’s personal spreadsheet.
That’s a security problem and it’s also just an operational headache waiting to happen.
A decent password manager fixes both problems and keeps a platform locked down and still lets the right people in when it actually counts.
There are many options out there, some free, and it is worth your time to choose a good one instead of grabbing the first offering.
At KUT, we went with 1Password. A forgotten password can take a station off the air just as fast as a blown tube can.
Share what you know
Make knowledge sharing a normal part of your routine, instead of something special.
It doesn’t need to be a formal class. Bring someone else along for a site visit, a system upgrade or even routine maintenance.
A weekly call where people just talk through what they’re working on helps more than you’d think, too.
When someone’s tackling a bigger job, it’s worth having another person shadow them on it. Over time that builds actual familiarity, not just a name on a checklist somewhere.
Some stations rotate responsibilities on purpose for exactly this reason, so nobody ends up being the only person who understands a given system.
We use Asana at KUT to keep track of tickets and how they were resolved so that knowledge doesn’t just disappear once the ticket is closed.
At an old job, I put together a simple internal ERP site for the station chief engineer, which let staff assign weekly and monthly routines, log what got done, leave comments and upload files, all so none of it lived only in somebody’s inbox.
This isn’t about replacing anyone or making people feel expendable. It’s just about not letting expertise get stuck in one head.
Don’t assume. Verify!
Documentation is only as good as it is accurate, and the only real way to know that is to test it.
Every so often, have someone actually run through a routine task using nothing but what’s written down.
Wherever they get stuck or confused, that’s exactly where the documentation’s falling short.
If there’s a bigger change, new gear, a software update or some other network change, that’s your cue to go back through and update the instructions.
Technology doesn’t sit still. Instructions that were accurate three years ago may be wrong now, or at least confusing enough to cause problems.
And the same is true for disaster recovery. Your backups needed to be tested on a recurring schedule, not just on an assumption that they’re fine because they worked once.
Nothing shows you the gaps in your documentation faster than an actual recovery drill going sideways.
Plan beyond today
If anything, experienced engineers matter more now than ever given how complicated many station setups have gotten.
But keeping good documentation is about resilience, plain and simple.
A resilient station keeps serving listeners no matter what’s going on behind the curtain. It handles problems faster, bounces back quicker and doesn’t lose critical knowledge just because one person happens to be out of town.
Radio always runs on reliability. Listeners expect a signal or stream to function when they tune in.
The best engineering departments understand that reliability never was about one irreplaceable person. It comes from planning, documentation, training and people working together instead of hoarding what they know.
So next time your chief engineer heads out on vacation, ask yourself something simple.
If that vacation ran longer than planned, would your radio station be OK?
If you’re not sure, that’s probably your cue.
It might be time to start writing some of this down.
[Do you receive the Radio World SmartBrief newsletter each weekday morning? We invite you to sign up here.]
