Of course, there are some people for whom a bit of knowledge is actually dangerous. These people (and tech people can and are guilty of this as well) suffer from overconfidence or overestimation of their knowledge. These people are often adept at convincing co-workers that they have most of the answers. This can lead to confusion, poor security, and conflicting company policies in some cases if the person in question is in a high level role.
‘Do you have a wireless access point I can borrow?’
One day a couple of our sales people wandered into the technical office. One of them asked me if I happened to have a wireless access point he could borrow.
I said sure, that I had a couple extra ones sitting on the shelf at home, and I could bring one in for him to use. I was making the assumption that he was asking for it on a personal basis, but just out of curiosity, I asked him what specifically he had in mind.
He explained that they wanted to set up an access point in the sales area so they would have good wireless.
Needless to say, rogue access points in any sane business situation are a no-no. I told him very firmly that it was against company policy, and asked what was wrong with the current wireless network provided by the company. The answer of course was that it was ‘too slow’.
After I let him know we would find any rogue access point that he set up and smash it with a hammer if we did, the matter was settled. I brought it to the attention of my boss, and within a couple days a company-wide reminder about our technology policies was distributed to everyone. Case closed…but it also illustrates how a little bit of knowledge used without consideration could cause issues. We needed to make sure we educated people on why things like this were not a good idea, and everyone needed to make sure they took enough of an interest to understand the reasons why. Looking back at the ‘smash it with a hammer comment’ perhaps I needed to work on my PR skills as well, though I did say it in a friendly manner.
It’s not even that their ideas are bad ones sometimes — it is the fact that people often have the luxury of not considering the bigger picture. Every company or organization and every scenario is different. There may be a good reason that certain things have not been upgraded yet, that certain pieces of software have not been put in place, that certain methods are still in use. The reasons could be technical, they could be regulatory, they could be logistical. They could be company politics. Often and most importantly, they are financial.
‘Why aren’t we running Windows 7 on everything?’
Several years ago when Windows 7 was just a few months in the general public, one of our managers came to us asking if she could be upgraded from WinXP to Windows 7. We explained that she was in an update cycle that would see her computer and OS replaced the next year. She asked why we didn’t just simplify things and upgrade everyone and everything across the board to Windows 7 and be done with it, especially considering the free upgrade path that was offered by Microsoft for a period of time.
I was tempted to give a clever reply. Fortunately I thought about it for a moment and realized that I had an opportunity to give her some legitimate reasons and help her better understand how this particular part of my job worked.
I explained that these things were usually done in stages for budgetary reasons, as well as logistical (only so many staff to roll out so many machines). I also explained that we really did not have enough information yet on how Windows 7 operated with some of our proprietary software — but that we did know for sure that it did not work properly at that point with our radio automation software, which, well…put everything to air on our radio stations. Not the area that you want any uncertainty in with regards to stability. Upgrading our automation software at that point would also be costly and a major project. Wheels within wheels, dependencies. The bigger picture.
Once we talked about it, she understood. She wasn’t exactly happy with the fact that she wasn’t getting upgraded yet, but she understood a little better some of the factors involved, and she now knew that we were testing things behind the scenes.
This is what I believe people new to the field of I.T. and Engineering often have trouble with as well. I know I did. The biggest, the newest, and the fastest are not always the most efficient or the best choice in a given situation. Sometimes mission critical systems need to prioritize stability over being bleeding edge. What seems like the most logical course of action may have many other factors involved that complicate what seems like a straightforward issue.
I am not in any sense advocating that everyone should not be calling their technical support when they have an issue. It can be a fine line, knowing how far to go or when to stop with troubleshooting before calling your support. I am also not in any way advocating that we should not be moving forward with our technology — I am merely saying that a cautious approach is often needed depending on the situation and environment. On a personal level, I can make the decision to upgrade, downgrade, install beta software, whatever I want. If I run into a problem, I am answerable only to myself.
This is in a sense where things need to come full circle for the technical department. We as techs usually have our hands in every other department in our organization supporting their tools, so we too need to take at the very least a mild interest in what others are doing, how they do it, and in the bigger picture. We need to know the ramifications of our own decisions and actions as they relate to the rest of our organization or our clients.
