Feb 282012
 

Information technology professionals and users can often feel the burden of the cultural lag in technology on their own back and yes, it can get heavy. The lag keeps you squeezed between reality and its perception, between the scientists and the accountants, between the bleeding edge technology enthusiasts who trust any just announced upcoming technology, and matured managers who trust only proven solutions already in use at similar places. This can be quite an irritating factor for IT engineers and technicians, especially in big organizations where you shouldn’t be allowed to install anything new without extensive testing and approval. This can furthermore often be the cause for a bad reputation of IT departments in big companies, and earn them attributes like inflexible, outdated, arrogant and slow, and you have to take an extra effort to make sure your users understand your limitations and rules before sticking a label on you.

Cultural Lag in Education

Even bigger cultural lag can be felt in education. Technology textbooks have always been behind, but the gap is widening. By the time a course is written and ready to be taught, the field has moved light years ahead. This is why most people with advanced postgraduate degrees aren’t usually found in IT field – by the time they get their degrees, the situation has changed a lot. That’s also why I was never eager to hire people with many certifications unless they had other great credentials and recommendations, because that meant only one thing to me – they specialized in passing tests and certification exams.

Back in college, we were learning about 8086 and 8088 CPUs and their instruction set when Pentiums were already around. It was a good base for further education, but it was also a matter of ridicule by some students. Then, take programming languages: although I never worked as a programmer, I knew C better than most of my college professors (long time ago, I’m rusty now). One exception were assembler and advanced micro processors classes, where we had Dr. Malik, an amazing guy from the opposite side of the world, a computer guru so far away from being an ego maniac that he deserves a monument.

Reality Check

Most of the enthusiasts who tend to despise the inevitably conservative new technology management of big institutions forget that it’s easy to upgrade consumer-end solutions at home and revert if things don’t go well, but once you have to deal with thousands of interconnected users and computers, the risk tends to multiply. Things could easily get out of hand if you allow your users to bring in, connect, install and use whatever they want. Several times in my career I witnessed one single misconfigured laptop or a wireless router brought in from home bring down entire network segments and render hundreds of computers inoperable for anything except word processing. Problems like this can carry a heavy impact on your support calls, staff time and workload management and ultimately your budget and your job, hence the importance of doing the testing in controlled lab environments and locking down your production networks. This has to be well explained to new “technical” users and young staff members who like to run the latest beta version of software, computers, phones and tablets and bring and connect their personal gadgets without approval. The saying, “measure twice, cut once” applies to big IT environments far more than to home users. Even if you are a small business, you cannot afford constantly testing new things, so always remember the saying “If it ain’t broke, don’t fix it”. First focus your resources where your needs (not wants) are, where your returns are maximized and your risks of future impairment minimized.

Beta Testing Ban

If you’re running a big IT shop you should be concerned for the well-being of your network and systems, so you may want to ban any beta testing by regular users and include this into your computer use policy. You may even go as far as banning usage of any unsupported software and hardware. Enterprise environments need to be kept away from any chaotic experiments. In my past there were exceptions and compromises, but we set this general rule and required that every testing be approved by the IT department, just so we knew what was going on and we were able to ask proper questions and assure there were no bad surprises ahead of time. Whenever we thought the test would be too risky for production, we’d replicate the production systems in a lab (or schedule use of an existing test environment). We were always more open to testing desires of our technicians or power users because that would often result in an expert opinion on which to base our further decisions to either avoid the solution, or pursue it to a greater extent if the benefits were obvious. We were very careful not to have end users play with things that can impact both their and our productivity and bring down production systems.

Good Cultural Lag

By controlling and knowing who and when introduces new variables into the system you keep it clean and operational. It takes trust-worthy experts to evaluate feasibility and it’s always better to use staff who are on your team or in your company instead of the big sales blood hounds from an external manufacturer whose only reason for being there is to make commission on your purchase and who very well know how to manipulate and spread FUD against your current solutions and mislead your management into believing their systems are the only feasible way. By slowing down the pace with which new solutions are introduced into your environment, the problematic ones will get to break some other places and disappear into history while you will get to read case studies and know what to expect. Unless you have loads of cash it’s better to be on the leading than the bleeding edge of technology. Whatever edge you choose, remember that regular and good communication to both your users and management about your policies, limitations, priorities and reasoning is always crucial.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)