Credit: CBS Photo Archive/Getty Images
When I was a newbie engineer, our station went off the air due to a problem in its McMartin transmitter. The engineer in charge spent about 15 minutes explaining the theory of this model until I interrupted and said, “How do we fix it?”
Ultimately I isolated the issue to an old tube exciter that was losing frequency lock. The station would wander up and down the FM band until something tripped.
But the memory reminds me that as engineers dealing with off-air situations, we tend to talk to one another in terms that other people at the station probably do not understand.
Let’s say a transmitter is failing intermittently due to a recurring reflected power issue. Perhaps it is caused by a shorting antenna bay, or a combiner failure, or fluid in the coax, or a bad connector. So, fellow engineers, how should we handle this?
Well of course we would test the transmitter into a dummy load, use a framus wigglenator to veebleize the combiner utilizer and exize the googleator.
Right?
To a non-broadcast engineer, our conversation might well sound like the above.
Of course, unlike the technobabble made famous by “Star Trek,” the impressive terminology we use isn’t essentially meaningless. But in many situations it’s useful, even important, to help non-technical colleagues feel that they have a basic understanding. This certainly applies to interactions with your boss.
For this problem, I might tell the station manager, “Ah. There may be some water that has built up over time in the coax cable that goes up the tower. We will take the connector off the bottom and see if any liquid comes out. Then if that’s not it, I will let you know what we will do next.”
This brief explanation — in plain English — gives the person a sense that their engineer is working on the issue in a sensible and timely manner, rather than leaving them to wonder what, if anything, is going on. Your explanation also shows them respect and helps develop a team mindset.
Later, once the station is back on the air, we should communicate in plain terms what the issue was, how we repaired it and what we did to try and keep it from happening again. This will help everyone to sleep better knowing that the issue was addressed fully.
And as Radio World’s John Bisset has written many times, it demonstrates the value of engineering to station management.
Let me know your own experiences in how to communicate effectively with non-engineers, especially in this new era of networking, virtualization, cloud and IP. Drop me a note via Radio World.
By the way I am often tempted to explain how I resolved an issue by saying “I used Magic Purple Dust.” But do as I say, not as I do!
Meanwhile if you are having a particularly hard day and just need a sentence like “I’m detecting a slight field variance in the isotopic electro-ceramic booster,” check out the Technobabble Generator.
RW welcomes your Tech Tips, email us at [email protected].
