Archive
Logs
Now that is a boring title, eh? Why logs? Why write about logs? No, there will be no examples of logs, but if you do any sort of troubleshooting it is good to read them logs. I know many of us do not really read these things to deeply, but over the years I have solved many issues just by reading the logs.
Today is a good example of the “win” when it comes to logs. The traffic department had shown discrepancies and missed spots during a portion of the day. Everyone gets up in arms when spots are missed. I also notice that fingers get pointed. Long story short, I first checked the logs to verify the report of a system restart. Found that. The next confusion was why did the spots not run. Using the logs I verified contact closures being recorded proving the system was working just fine. Back to the logs and I found that someone left the system in manual mode. No more finger pointing now, eh?
This sound simple, but it can be tedious work. As you know details are always lacking when people report a problem. Doing the detective work means really reading and finding the clues within the logs. Today was WideOrbit. If you ever looked at their radio automation log you know how much detail (and fluff) is in there. With a little patience and time you learn what is important to you and what is not. From there you use what you find to get to the solution, and in my case it was not technical issue. Someone decided to restart the system and forgot to change to automatic mode.
I comb through many different logs based on what I am working on. SAS, Dante, WideOrbit, NexGen, Nautel, and the list goes on. All have logs, and many are very useful. Granted some are not as useful as others, but for the most part they are good to getting the job done. Take the time to read the logs when you troubleshoot. It may take time to decipher, but the more you do it, the easier it becomes. After which you can then tell the manufacturer they have an issue, provide a copy of the log as supporting evidence, and see how fast they respond to your support request.
Cheers!
Pursued….
It is not everyday one gets called by a headhunter. It makes you feel good. It also means that there are those out there looking, and in particular, they are looking at you. For what, you are not sure until they dig. I received three calls on this one. What I did discover is the limitations of what us Chief Engineers in radio face: People Management.
That is correct. Due to the size of most engineering staffs, we do not get to manage people that often. I spin it as managing people that even remotely touch the equipment we service and whom we deal with everyday. Even so, this does not rate to well. Here, I have one assistant. One. How does this help get you to that level of five? Ten? I would like to hear from you on that one. If you are lucky and work for a bit larger company there is that chance of a market DOE or region; maybe even company wide. It could be a long wait. In any case, it is tough to gain such experience, but we keep trying.
Being in such a position I wonder how does one gain this ability to manage others. Most of my career I have either been a department of one or had one assistant. I have some training under my belt from those career resources provided by the company, though now-a-days few and far between. I have read books like the very popular 7 Habits… and even Ken Blanchard of which the latest I have read is Self Leadership and the One Minute Manager. This one is great for improving your self image and ability to self lead, a necessary “skill” in today’s workforce. Yet, again, book learning does not gain much.
The only area left is how you work with others at your facility. I do not wish to elaborate the strange culture that sprouted here, but let me just say that if anyone asks who the chief engineer is, they will answer with a different name, and from my observation this stems from the technical structure created due to the last GM and CE. In any case, most of us get along quite well with the staff. but it is agreed that we are all not the Type-A people person that some employers seek. Keep up the staff relations, though. It will keep you around.
When it came to project management, I scored high. Extremely high considering the “client” of said headhunter is NOT radio. Also IT or networking skills. Actually it was not the skills as I just mentioned that was the block. Many of us have the skills. Also prized is the ability to keep up and show that you are able to implement new technologies. Even though most stories in the trades makes me roll my eyes, it pays off to glance over them. There are some technologies that we must live with even though they may not be the best. I find that browsing across trades of different, but similar industries helps with innovative thought processes. Definitely keep that up.
In addition, a plus, is writing ability. Whether it be documentation or writing that proposal, it is good to keep up on writing skills. I have written documentation, I have written manuals, and I have written training materials, not because I had to, but because I knew it was important. I have made an easy to access engineering website for us with necessary online forms and some other information; it is getting the staff to read it and use it that is difficult. “You can lead a horse to water, but you cannot make him drink.”
I hope this personal experience helps light some bulbs in your head. You never know, you may get that call. If you do, good luck!
Tech Notes from the Field 