Decision Maker

Some IT Managers Are Just Fit To Be Certified

Having managers complete an IT-specific leadership course could lead to a more productive and successful team.

• By Don Jones
• 06/04/2014

An often-debated topic in the IT world is the value of certification. Does an MCSE get you a job? Is it worth more money? More respect? But after a few recent customer conversations, I'm starting to believe what we need is certification for IT management. Not process certification such as ISO, but a real look at whether the organization has management practices and philosophies that lead to successful IT.

For example, recently a client asked me to help develop a script that would automatically manage the membership of their workstations' local Adminis­trators group. With a big smile, I said, "You don't need to! Group Policy does that!" They sadly shook their heads. "We can't use Group Policy." I stammered. "But..." "We're just not allowed. We've tried. It's a performance problem." Yes, there's no question that Group Policy can be a performance problem, but you can say that about any technology that hasn't been well planned or well executed. Ethernet switches can cause performance problems, too, but I don't see people rushing to unplug them.

Another client asked for help writing a script that could monitor process performance on remote computers. "Performance counters do that!" I said. "Can't turn on Performance Monitor," I was told. "I Tried. Not allowed." So instead of using the native, built-in, well-engineered code to monitor performance, you're going to write a script that will absolutely have a heavier negative impact to do the same thing? "Yup." Oy, vey.

This is like saying you want to drive a car, but you're not crazy about the accelerator pedal because you've heard it increases global warming. You'd rather cut a hole in the floor pan of the car, put the transmission in neutral, and make like Fred Flintstone. Yeah, you can do that. But the other kids are going to make fun of you.

These attitudes typically come from a massively misinformed management team. In some cases, they've got senior IT people who don't know what they're talking about, and instead spew mistruths that management accepts. In some cases, these attitudes come from years-old information no longer relevant in today's technologies and environments. These organizations should not be making IT decisions, because they're wrong. They're creating their own performance problems, their own security holes, and their own operational nightmares -- and them blaming their administrators, Microsoft, and everyone else for the resulting problems.

I can't help but wonder what would happen if IT people universally refused to work for companies clearly unqualified to manage their own IT investments. I bet many companies would have no choice but to outsource.

How can you tell your organization has adopted outlandish IT management policies? The answer is simple. Anytime you're trying to work around a product's built-in features, or refuse to use the product's native functionality, you might have a problem. The next test is to justify your decision. Is it because the product doesn't deliver a capability in a way that's compatible with your business requirements? For example, if you don't use the native Windows event log auditing because they don't provide the level of detail you need to remain compliant, then you're completely justified in shutting it off and doing something else. But you need to continually revalidate your argument because products change. The event log of today isn't the event log of 10 years ago.

If your reasons for not using a feature stem from performance, security, or manageability reasons, you need to revisit those decisions nearly on an annual basis, as even service packs and patches can change functionality in significant ways.

Here's another test: If you ask your administrators to do something, they offer a native solution, and you tell them they can't use the native solution. Then look at their faces. If they appear gob smacked, you're probably wrong. Revisit, revalidate and reconsider. Ideally, you'll always use technology the way it's meant to be used. Sometimes, you won't, and if you've got valid reasons, then fine. But ask around. See if other organizations have come to the same conclusions as you. If they haven't, then either you're a genius and everyone else is wrong, or it's time to take a good, hard look in the mirror.