When I was in college there was a big IBM 360 in the basement of the physics building. Back then it was pretty easy to get computer time. All you had to do was show up any time after midnight. We were allowed to code in two languages—FORTRAN or COBOL. Both were high level languages and neither  offered the opportunity to be creative.

It was a good way to get your feet wet in computing, but it wasn't challenging. I certainly understood the business value of a mainframe and batch processing (to perform boring repetitive tasks), but I also understood that I would probably stay away from IT until the technology caught up with the needs of business.

The only bright spot in my mainframe encounter was finally being allowed to code in assembler. Actually tweaking bits and bytes as I moved them around from register to register was exciting. This was an opportunity to truly create something from nothing. Coding assembly language to make the sprawling behemoth on the raised floor actually do something at my command was pretty cool. Plus, it seemed much closer to the things Claude Shannon and Alan Turing were talking about than using some high level compiler that someone else put together. Unfortunately, I was stuck in batch mode and that sealed my fate for the next few years.

That drive to make a dumb machine do something is part of the geek spark that I look for when hiring. I don't care if you are a wizard with Excel or that you created a Website with some WYSIWYG editor or that you are an expert in some application. I want to work with people who are as comfortable using Notepad to edit HTML as they are running a power shell script.

There is a world of difference between the IT guy who brings in three vendors to pitch their server monitoring software and the IT guy who writes a script to gather all the basic monitoring stats that we can use until we finally purchase some off-the-shelf software to do that same thing. I am not suggesting that we write all of our applications in house or that everyone in IT needs to be some kind of über geek. What I am suggesting is that people who truly understand technology are the only ones qualified to make rational technology decisions.

Outsourcing

I did some work for a large organization a few years ago. They had recently made a decision to outsource all of their IT. I mean everything—not just hardware and data centers and networking. They got rid of all of their technology people and replaced them with contractors of one sort or another. The contractors were managed by managers who had little or no technical chops.

The CIO came from a business background, not technology. The reason given for divesting themselves of IT was that it was not a core competency. They believed their core competency was making and selling widgets—not IT. Never mind that they had an IT organization that spanned the globe and serviced tens of thousands of employees on every continent and sub-continent and countries I never heard of.

So they hired another large company to manage their IT. When I first heard about the decision I didn't get it. Something was missing. It took me a while but I finally had my "aha" moment. The issue wasn't the core competency in IT…it was the core competency in outsourcing.

The global firm for which I was working already had competent IT people all over the globe. What they didn't have was a less expensive offshore IT model. Their current IT employees were well compensated—whether they lived in the US or Azerbaijan. By divesting themselves of their IT staff they were able to switch to a less expensive model entirely managed by their new IT partner.

Bad Choice

So how did that work out? Not well. With no real technologists on staff everything was a black box and they were totally dependent on vendors and consultants to configure and maintain their infrastructure and the software and systems that ran on that infrastructure. I don't know about you but when I am on a crisis call because a system is down I don't want to be at the mercy of a vendor whose only motivation is preserving the account. I want someone who is concerned with preserving the business—and who understands the technology.

One incident that happened when I was with that organization typifies the sort of problems one runs into when the people running the technology don't understand the technology. Early, on a Monday morning, an engineering group from offshore pushed a software update to all of a certain type of server. This was not a security patch or a hot fix…it was an update. This was accomplished without any testing, without notifying the application teams, and apparently without any forethought at all.

The result was an application that was hard down at start of business (on the east coast) Monday morning. It took 24 hours of scrambling to restore that application. And you know who took the hit on that one? The application team.

I know that is an extreme example and I am sure your organization has safeguards in place to prevent that sort of thing from happening. Nevertheless, most IT outages are change related and are the result of some human error—sometimes an error in judgment and sometimes an error caused by laziness or incompetency.

Just Because

There are a lot of places within an IT organization for non-creative thinkers. There is a substantial amount of IT work that is just as boring and repetitive as the old mainframe batch jobs. In fact, most IT tasks are maddeningly repetitive. But each of those mundane tasks needs to follow a procedure that was created by individuals or teams who truly understand the technology.

How many times have you questioned why something is done a particular way and the answer is: "We've always done it that way."

Wen you hear that answer you need to act immediately to bring fresh talent into the group or light a fire under any semi-intelligent people in the group. I don't like to hear that our new system will be available as soon as we can get the consultants in to configure it. That is a recipe for failure. An internal team should be configuring it, with assistance from the vendor if necessary.

Not

IT staffs are not created equal nor do they work equally. You see it all the time. There are those who come in early and work late. It's not because they are slow and inefficient, but because they love what they are doing and need the extra time to work on the cool stuff in addition to the endless meetings and mindless tasks they are required to perform.

There are also the staffers who show up right at 9 a.m. and dash out the door at 5 p.m., telling everyone how busy they are. These are also the ones you see at every non-compulsory company function and meeting throughout the year. And that's fine. I don't suggest you need to cull the herd (although that really isn't a bad idea). I am suggesting that you keep track of your über geeks and make sure they are assigned to useful, creative tasks. The corporate toads just putting in their hours are a financial drain on the organization but have little chance of doing significant harm because they have more than likely already reached their Peter Principal level.

Senior Management

The third type of IT staffer is the scary one. These are people who totally get the corporate thing. They attend the right seminars and career-building sessions. They always have something to say in meetings even if what they say is totally obvious or meaningless. They understand how to market themselves—and in the corporate world that name recognition is more important than competence. Kind of like the adage that bad publicity is better than no publicity.

They have their careers well planned out—punching all the right buttons along the way. They have probably switched organizations a couple of times…each move resulting in a higher level of responsibility.

These are the ones on the way to the upper echelons of management. There is nothing inherently wrong with corporate climbers. Someone has to do the "managing" and I'm fine with that. What does scare me is that these decision-makers don't always understand the technology or the repercussions of the decisions they make, but they think they understand. And that is why we need checks and balances in corporate IT.

We need to have a substantial body of individuals who understand technology with the power to approve, recommend or reject bad technology decisions. Most organizations have some sort of review process in place with various boards to make these recommendations. The trick is to empower the review boards to make meaningful decisions and recommendations.

Business should never drive technology. Business needs should drive technology. And that should be a defined process whereby business prepares a basic requirements-document, IT first learns and understands the business process, and then makes appropriate recommendations for implementation of a technology solution to the business requirements.

Two-way Street

At the same time, IT has to be attuned to the needs of business. There is a reason the business has fallen into the habit of seeking out and listening to third-party vendors and consulting firms. That reason is probably because IT has been unresponsive to their needs.

This is where you need to put your techno-savvy folks to work. It makes no sense to force a talented individual into mundane tasks or endless rounds of meetings. Keep your best technology people engaged in researching and designing new ways to solve business needs. Make certain that extreme geeks have a career path.

Working in technology for the love of technology doesn't mean that they want to work for less money than the career guys. Don't risk losing them to an organization that understands their value. You do need them. Find a good place for them and feed and nurture them.

Consider using smart outsourcing and offshoring some of those repetitive or mundane tasks. Take the money saved and build a better core IT staff. And leave the corporate climbers alone. Let them run the show…or at least let them think they run it.

Please address comments, complaints, and suggestions to the author at [email protected].