The Efficiency Battle in IT – And When To Fight It

Human nature, at its core, is a rather remarkable thing when it comes to adapting to change.

Most people (especially younger people) will somewhat readily admit that they’re open to change if it’s positive. Socially, it’s generally viewed as a negative thing to not to be accepting or considering of newer, better things as they’re made available.

In actuality, though, almost everyone becomes progressively more closed off to change as they get older in life. For some folks, this happens as early as age 30. For others, it sinks in closer to age 40 or 50. And, for some “mythical unicorn” people (such as the person I’m fighting tooth and nail to become), it just never sinks in at all.

Science has shown that the human mind has a “peak creativity” interval in early life where it’s at its maximum learning potential, then this creativity gradually closes off later in life because the mind naturally gravitates towards things that don’t challenge it as much – similar to the physical concept of why most people don’t want to work out or exercise as much as they get older.

Where am I going with all of this? Well, we’re going to talk about applying some of the efficiency processes and standards in the IT world today – such as ITIL. We’ll also dip a bit into some of the non-IT standards, such as Six Sigma, some of the ISO standards, and simple common sense. The reason we need to precede this conversation with an understanding of human nature’s natural resiliency to change versus age is because it’s the biggest opponent you’re going to fight in the name of efficiency.

And, keep in mind, this applies to us first and foremost.

Even Minor Change for Company Culture is HARD

Years ago, I’d just started a job working for a Fortune 100 company as an IT professional. I’d recently achieved my ITIL certification, and had come off the tail end of a massive documentation and standardization lifecycling project at the IT contract position I’d held prior to coming there – in other words, I was somewhat familiar with identifying inefficiencies and understood that even fixing minor problems in this area could save an organization hundreds of thousands of dollars.

​Within a week of starting the position, I identified several core problems that were placing a significant damper on people’s work, whether or not they realized it at the time:

  • “Face-to-face” conversations among employees for the sake of conveying information were rampant, often occurring three to six times towards different people for the same exact concept that should have been distributed via email – but never was. Getting most people to consistently read their email was an entirely different problem in itself.
  • Documentation for many processes was either non-existent, or access to it was denied to Tier 1/2 non-managerial employees because it had to be “filtered” through management first. It was unclear at the time if this documentation actually existed prior, or if management was simply creating it “on the fly”.
  • Creating KB articles for processes, or even drafting SoP templates, had to be proxied through so many different layers of administration that the approval process would take a minimum of six weeks – assuming, of course, that your article wasn’t rejected or that edits were needed. I was never able to get a single article I drafted approved; everything ended up getting shot down, often with no reason provided as to why.
  • Word-of-mouth “training” had been the norm in the organization for so long, that infighting occurred regularly even between seasoned technicians purely because so many people would attest something to the affect of “Well, I learned it from John, who learned it from Joe, who learned it from Jack – and Jack’s been with the organization for pretty much forever so surely he would know!”.
  • Creating your own tools for increasing your job efficiency, whether they were for parsing data, streamlining alerts, or simply cleaning up old queries, were strictly forbidden unless they underwent a lengthy approval process similar to the one KB articles went through. I’d later find out the reason for this fear of tool creation was that annual turnover was so high for this company that they feared an employee would create a tool that would be heavily relied upon, only to leave or be fired for some reason shortly afterward and leave the tool in a state of disrepair.

​This was rather surprising, considering the nature of the organization and how much money they had at their disposal. I’ll admit, at first I wasn’t sure how to react to this situation; I hadn’t guessed from the job interviews here that this was how internal operations worked.

After breaching the conversation topic with management on a couple of occasions, I was more or less told to be quiet about some of the core issues the organization was looking at in these areas because it would be too devastation to the existing company culture (which was heavily laid-back, mind you). With turnover as high as it was, I later realized that their laid-back nature was likely the primary thing keeping most of their staff there.

They were fighting a dangerous battle with organization implosion, and were striving to control it as best they could – by resorting to functioning like a “mom and pop” shop in many areas instead of functioning like the multinational enterprise that they were.

I only lasted about three months at this job before I gave notice to resign; at the end of the day, it’s not worth sacrificing what you can personally achieve or become just to try and get the experience of saying you worked with a company that large. 

Seniority – In More Ways Than One

While this mentality is gradually becoming more outmoded, many organizations or areas of the country still demonstrate it to great degrees. What am I referring to? Well, the concept of senior staff who’ve been with the company for so long that they’ve made it to the top – regardless of whether or not they deserved the position they’re in.

​I recall a contract position I held some time ago where I was placed under a supervisor who’d been with the organization for 26 years. He was an older gentleman, and often brooded in his corner office (which was conveniently kept locked for most of the workday). I’m still not entirely sure what he did with the majority of his time on the job; it certainly wasn’t spent signing quotes, orders, or vacation approval! (but, I digress)

Specific to our conversation, this individual had a personal policy that he enforced on the entire organization:

We couldn’t use VMWare, or any other virtualization. At all. Why, you ask? Because he didn’t like it​.

As a result, we had a datacenter chocked full of physical servers. Everything in the organization was physical, and was often terrifyingly over-quoted in terms of hardware (imagine a domain controller for a 5,000-person organization having 28 CPU cores and 128GB of RAM!). The temperature in the server room was a constant issue due to nothing being virtualized; having a single A/C unit fail would raise the temperature by roughly a degree every five minutes. And the power usage? Mercy, don’t even get me started.

Thing is, I was terrified to try and say something about the situation because my peers had warned me that our supervisor had on-the-spot fired the last person who tried to stand up to him or expose half of the things he was doing. This individual held the entire IT department as his own “personal North Korea” to the point that he was controlling what information was entering or getting out of the team – and he knew how to break off loose ends.

I didn’t last long at this contract before giving notice, either. While my peers weren’t too bad to work with, management’s constant overhanging shadow in terms of preventing efficiency led me to realize that I’d never become the engineer I wanted to be if I couldn’t get into an environment that challenged me to grow and not stagnate on political semantics and personal preference. (the pay there was pretty bad, too)

Seniority, and the “good ‘ole boy” syndrome at it’s finest, folks – tale as a old as time.

Admitting When We’re Wrong – A Tune We Can All Dance To

Probably the one thing I think everyone reading (or writing) this article can speak to is not hardening yourself to the point that you can never admit that you made a mistake. I’ve jokingly referred to this as several different things to my peers: “salty old man disease”, corporate comeuppance, etc.

Honestly, I think that the best solution to the rut of arrogantly not being able to admit to your shortcomings is just that: make light of it. It’s the spirit of keeping it lighthearted that makes people more open to the idea that we all make mistakes.

A phrase that anyone who’s worked with me before has likely heard me say more than once is:

“At the end of the day, we’re all only human – and we’re all in this together.”

I can recall several individuals I worked with in the past who, in the entire tenure of working with them, never once could bring themselves to admit that they’d made a mistake. In one particular case, this was made incredibly difficult as the individual in question was the Director of Information Systems. Imagine going through a team meeting where he’d make some absurd suggestion (we need to move all this stuff to the Cloud because I read an article saying that we should!), and you couldn’t come even remotely close to suggesting an alternative because he was inherently right, and you were inherently wrong.

In situations where senior leadership exhibits this characteristic, it may be next to impossible to get them to change. They’ve likely done it “their way” for so long, that they may be past the point of being able to turn their train of thought around. Sometimes, the human mind or body gets so stuck in going through the motions that it simply lacks the willpower or circumstance to be able to change. And truthfully, that’s a scary thought – because it can happen to any of us.

Something that I’ve done in multiple jobs before that seems to somewhat help with this mentality is keep a public tally, usually on a dry erase board or something similar, of the times that everyone on the team (including management) are caught messing up. While initially this tends to elicit some aggravation, that aggravation smooths over after a few weeks once people start to notice that they’re not alone in making an inherently dumb decision or two. Most times, it gets to the point where everyone can chuckle about it together.

I recall a situation where myself and my peers had caught my boss messing up in a company staff meeting; he’d been trying to talk “shop” about a networking migration project and had butchered several key terms and concepts to the point that the engineers had to stop him, and then re-relay the information again to get everything correctly conveyed.

A week or so later, he came walking over to the engineering area of IT to ask about a quote we needed approval for, and noticed his name on the “Fail Board”, next to the description of “Part-Time IT Terminology Enthusiast”. While you could see the grimace across his face initially, it slowly eased into a smile as he noticed some of the other content on the Fail Board pertaining to some of our mistakes, which were more prominent than his.

He ended up getting a good laugh out of it. We all got a good laugh out it.

​Why? Because we’re all only human – and we’re all in this together.

If People Don’t Want to Change, They Might Be Forced To

The single largest obstacle you can face in an organizational efficiency effort is people who simply, in lieu of everything you’ve tried to do and in light of all the encouragement they’ve received, won’t change.

​Often, those who refuse to change are those who have the most job security – they’re the senior techs, the managerial staff, those who have been around for so long that they’ve become part of the company “culture” themselves.

In situations like this where senior staff or management wants to fight the majority of the team populace in terms of increasing efficiency, there’s one final mechanic you can attempt, albeit at your own risk and with a tremendous amount of strategy, discretion, and documented evidence:

Privately get enough people on your side for what you’re looking to do, have a private meeting with those people to get everyone on the same page, then present the concept at your next team staff meeting with a member of non-IT top-level management (I’ve used the CFO and/or CEO before, etc.) in attendance. The difference is, present the efficiency project in a transliterated sense as though it’s a train that’s already partially boarded, is for-sure going to leave the station, and you can either choose to get on it to the comfort and friendship of those around you, or you can choose to be left behindYour choice.

Presenting things this way, and forcing those in opposition to see that there’s not only a decent amount of people who want this to happen, but that they’ve thought it through to the point that they can prove the impact it’s going to have, can be enough to turn the tide. Having the CFO or CEO sitting in on the meeting can play a huge part in preventing your boss or senior staff from trying to “play house” with the department in preventing the change, because the CFO/CEO will usually recognize it as a positive thing and raise serious questions towards those in opposition.

I’ve had situations in this meeting where those in opposition will raise the complaint, in an effort to save face, of “Why wasn’t I involved in the drafting of this project?” or “I wish you’d run this past me before you’d brought it up in a staff meeting.”. What they’re trying to do is discredit you in front of leadership as someone who’s trying to “run their own show” and isn’t a team player. To that affect, I’ve responded politely, but firmly, as follows:

“Well, the baselines that we’ve put forward today are convincingly the industry standard. For myself and for others on this team, we’ve come from previous employment, training, or backgrounds where we’ve had exposure to these concepts, and as such, we had a running knowledge of them whereas others in the organization might not have – hence, they were omitted from the initial discussions on this for the sake of keeping the group focused and on point. We’re bringing this up in our meeting today because it’s something we’re convinced will improve the organization, and we’d love to have the buy-in of everyone present to help make it a success.”

I won’t sugarcoat this; be prepared to be written up or even fired if this conversation, or the ones that follow, make a pretty sharp left turn. If your boss is the core dissident, he’s likely recognizing that his position of authority in the company is slipping as a result of this turn of events, and getting you out of the picture is the easiest path to victory for him. That being said, having the CEO on your side can be the biggest deterrent for action being taken against you because it’s too suspicious having someone speak out for agreeable improvement, justly so, then mysteriously get fired three weeks later for “incompetence”. Having a number of documented reports from your coworkers as well as members of other teams about your performance, work ethic, and project completion can give you a second insurance policy in the event that you’re lead to the boss’s office to have “the talk” a few weeks later – threatening a court case, and having a small mountain of evidence to aid your cause can force them to realize that they’re attempting to fight a battle they’re absolutely not going to win.

Last, But Not Least, The “Perfect World” Scenario

Finally, there’s a possibility that no one will oppose your improvement efforts, and everything will go off without a hitch.

ITIL, Six Sigma, and many of the ISO standards provide tremendous value to organizations. For some of the standards, they provide indirect value as opposed to direct value – this includes things such as instituting a recycling policy, renewable energy or energy conservation policy, or a personal fitness program to help employees stay in shape. Whether the standard provides direct value (immediate or short-term front-end financial value), or indirect value (converts to better marketing or PR, which then leads to increased long-term front-end financial value), there’s a net gain to be had for many of these frameworks.

I can vouch from the organizations I’ve worked at that strictly adhered to ITIL versus the organizations that didn’t, that the average tickets per hour (TPH), and average time to resolution (TTR) were substantially improved versus the contrary. ITIL is the industry standard for Service Desk and Managed Service Provider companies, and has been this way for nearly 20 years. Its reputation speaks for itself.

While Six Sigma isn’t a big thing for many American companies but is for many overseas organizations, it provides an extensible system for improving process efficiency. To offer my personal opinion, I believe that America would struggle far less in it’s national debt problem due to outsourcing and the global market if it was able to efficiency-optimize many of its domestic businesses and markets. You see this in organizations such as Amazon and General Electric, but in few organizations outside of this size tier. My opinion; take it for what it’s worth.

At the end of the day, complacency kills workplaces, processes, products, and ultimately people. By and large, complacency leads to nearly every detrimental thing that human nature could possibly have in store for it in the course of an average life.

The best method for avoiding the looming inevitable is to keep your frame of mind in a constant state of learning and advancement. Be open to analyzing change, and evaluate emergent technologies and concepts as they claim the consumer market. And, above all, live long and prosper.

Caleb Huggenberger is a 31 year-old systems engineer, old-school guitar and amplifier builder, and Eastern culture enthusiast. Outside of long work days, he enjoys electronics engineering, cast iron campfire cooking, and homesteading on his acreage in the Indiana countryside.

Leave A Comment (please keep things clean & civil)

Your email address will not be published. Required fields are marked *