Andrew Laudato - Fostering Innovation

Compared to our executive peers, our profession is still in its infancy and only recently gaining respectability. Two of the first people to have the CIO title were Al Zipf of Bank of America, and Max Hopper of Bank of America and American Airlines. “Management's Newest Star: Meet the Chief Information Officer,” declared Business Week magazine in a headline in 1986 2. Just 17 years later, The Harvard Business Review declared the profession dead, in the article “IT Doesn't Matter.” 3

Showing our worth has been a tough sell. We don't bring in revenue, mistakes can be extremely harmful, and what we do seems to take forever. Have you ever taken an introductory programming class, and the goal at the end is to get the words “Hello World” to pop up on the screen? The amount of effort necessary to make this happen is incomprehensible to our non-technical peers. One of the biggest challenges is that what we do is esoteric and more challenging than it looks.

Imagine the case where a company is doing well, so it adds hundreds of people to its staff. The company's growth has created two problems: it needs a more robust people-management solution, and it needs additional parking. The decision is made to build a parking garage and implement new cloud-based human resources (HR) software. Both projects coincidentally cost around $3 million to complete.

The company performs a rigorous ROI process before software projects are approved. The chief people officer (CPO) is adamant that she needs tools for talent acquisition, compensation management, payroll, and employee development. As we know, it's hard to associate a revenue increase with this software. Costs will go up compared to their current business processes using spreadsheets and email as their primary tools. The parking garage doesn't go through the ROI process. Nobody likes to park a mile away and ride a shuttle bus back and forth. It's clearly needed.

The CFO wants estimates. The parking garage estimate is detailed and easy to understand. It includes tangible tasks such as excavation, framing, concrete, and painting. The HR project documentation is riddled with obscure jargon. The CIO is reluctant to give an estimate or a completion date for the HR project, stating that he doesn't even know what the requirements are yet.

The decision is made to complete both the parking garage and the HR software projects. Both projects complete on the same day.

There is a ribbon-cutting for the parking garage, and the employees are thrilled. No training is required since they all know how to park.

The new HR software is having a few problems. It's slow, and some users can't log in. Nobody knows how to use the software. As part of the project, HR implemented new policies for vacation and paid time off (PTO). These new policies frustrate the users, who blame the problems on the new system. The parking garage has a clear and immediate benefit. It will last for years. No doubt everyone thinks, “What a brilliant investment; we should build more of these.” The new HR software generates negativity, and the CEO struggles to understand what she got for her investment.

Is a parking garage more valuable to a company than advanced software to manage people? Of course not. What went wrong? In this example, the HR project was on time and within budget, but it was still considered a failure to some.

When things go wrong in IT, leaders tighten the screws and micromanage. Table 3.2provides a list of IT problems and the corresponding unfortunate responses that often follow.

Table 3.2: Common Unfortunate Responses to IT Problems

During the first week of a new job, we had a planned fire drill. While in the stairwell, I overheard two of my new developers discussing the proper way to record the time spent in the fire drill. When I inquired, it turned out that the team was required to account for every minute of their time. When I asked why, several answers were given: (1) it is necessary for Sarbanes-Oxley (SOX); (2) it's required for accounting; and (3) it's necessary for resource planning. None of these answers are accurate, and all of them are frustrating. There are no SOX rules that say you need to document the time salaried employees spend on a fire drill. There are no accounting rules that say you need to document the time salaried employees spend in a fire drill. Micromanaging time is the surest way to destroy productivity. Yes, you must track the time internal employees spend on capital projects. But time tracking should not be extended to lunch breaks, social activities, and fire drills.

As the rules become stricter, the team slows down, and morale dwindles. When a team is not empowered, discretionary effort is gone. The mentality becomes, “If you treat us like babies, we'll act like babies.”

When morale drops, people will leave. In any economy, top IT talent is highly sought after, and they can find jobs outside of your company. When morale is low, top talent departs, and the downward spiral continues. As IT delivers less and less, more pressure is put on the CIO, and the screws are tightened another turn.

In an act of desperation, the CIO will cut corners. Usually, the first thing to go is quality assurance testing (QA). Testing is the last thing that stands between development and launching a solution that will be accessed by its users to do their jobs. Cutting corners on QA appears to save time and money, and by squeezing testing, you’re merely hoping to still ship a quality solution on time.

This is not a suspenseful story; we all know what comes next. The release is buggy, the users are frustrated by these defects, and the new features create havoc for the customers. Now IT is not just a burden on the bottom line—it is negatively affecting the top line. Fixing these bugs must become the CIO's full-time job, and the dream of being a strategic partner will have to be postponed. Top talent is redeployed to remediation, and the beautiful three-year Gantt chart is quickly turning from yellow to red because you can't move forward when your house is on fire.

At this point, more bad things happen:

The CIO loses his job.

The CEO brings in outside consultants to “fix” the IT Department.

A decision is made to outsource IT.

The chances of an internal candidate becoming the next CIO are slim to none as the internal team is associated with the failures.

The conventional wisdom that you can improve IT by implementing more and more processes and controls is wrong. You may try to combat this by embracing an Agile methodology, but done poorly, Agile can create the same problems. Leaders who micromanage lose their team first and their job second. Trusting and empowering your team is the only way to create an Amazing IT Department.