Inspections Should Be A Standard For Any New CIO

Todd Michaud runs Power Thinking Media, which helps retailers and restaurants tackle the convergence of social, mobile and retail technologies. He spent nine years delivering technology platforms to more than 10,000 retail locations as VP of IT for Focus and Director of Retail Technology for Dunkin' Brands.

As an IT leader, my least favorite phrase from my business partners is, "Well, can't you just simply…" No matter how someone finishes that sentence, the answer is, "No." The implication being that this person in Operations, Marketing or Finance believes he or she knows a simple way to solve the problem at hand. But it is never that easy. If it was, it would have been done already.

One of the biggest reasons CIOs fail—and, as a result, have such a high turnover rate—is the ghosts of decisions past. Highly complex systems built on a series of shortcuts and workarounds create a minefield of technology booby-traps that make even simple projects overly bloated and complicated. I think it is about time that CIOs start requiring an external audit of the IT environment prior to taking on the new role. Similar to a building inspector letting new home purchasers know about the inner workings of a house, an IT inspector would give new CIOs a clear picture of what they are walking into.

I had this thought after watching Holmes Inspection on HGTV. In the show, Mike Holmes helps homeowners who have purchased a house that develops serious problems, even after having a home inspector tell them everything was okay. Mike is famous for identifying all of the problems with the house, and then "Making it right" (his tagline). He undoes all of the shortcuts taken by the builder or previous contractors and redoes things correctly. I was struck by how awesome it would be to have an IT inspection done before taking on a new role.

In most retail environments, it is never as easy to get something done as it should be, which is frustrating to all those involved. When the systems are built with bailing twine and duct tape, there are too many resources forced to support the systems versus implementing enhancements or deploying new systems. The development activities that do take place require twice as long and are twice as hard as they would be if the environment were "clean."

Just as plumbing and electrical are critical to the operation of a new house, data feeds are important to an enterprise application portfolio. Can a company easily identify the data within a company, which system is authoritative of that data, and which systems it is shared with? Are there monitors, error checking and automated retries built into the systems? Are the database schemas documented and easily available? If the answer to any of these new questions is, "no," then that should be a red flag on the inspection.

The infrastructure of a house (foundation, walls, floors and ceilings) is just like the infrastructure in an enterprise (network, servers, storage and applications). Is the network robust, scalable and highly available? Are the servers virtualized and configured to properly maximize the high-availability tools? Are mission-critical systems clustered and highly available? Do you have solid service-level agreements with third-party providers? Again, if any of the answers are, "no," then a red flag should be raised during the inspection.Although it leaves the housing analogy, two other areas that should be included in an IT inspection are the people and the budget. I would argue that the people are the most important part when taking on a team. Are the people on the team qualified and experienced to do the roles they are currently assigned? (Assuming they are is a grave mistake.) Are there documented and clearly defined roles and responsibilities for each team member? Is the team organized around function and technology expertise or around the team members themselves? (We needed to promote Jim so he didn't leave, but we didn't have an open spot so we made one up.) Will you have the ability to make dramatic changes to the team, or are there sacred cows? (Jim is the CEO's nephew.) All of this should be part of the IT inspection.

Note: Most old-school IT people do not place a lot of importance on the datacenter or, in some cases, the server room. I've seen many people wrongly think that it's just some air conditioning and a bunch of blinking lights (if you've seen one, you've seen them all). However, from my experience, this is one of the best "tells" about an IT team that you can get during an interview. You can learn a lot about a team just by looking at a cabling job in a server room. If the room is sloppy or the cables are strewn, you are most likely looking at a sloppy team. It is a great visual cue as to how tight a ship is run.

Lastly, what about the budget? Even if the company leadership is open and upfront about the problems that you will face in the role, will you have the dollars necessary to correct the situation? I would personally take a guaranteed budget over guaranteed compensation any day of the week. What is the trend of IT spending over the past five years and what, if any, events have impacted it? What percentage of the budget goes toward supporting the existing systems versus new development? As things move to cloud-based services, has the budget progressed, too, by moving traditional capital items to expenses?

I understand that sometimes it is about getting a job and a paycheck and that sometimes it's about feeding your family. But sometimes it's about making that next step in your career. The answer to the questions I have outlined here can easily make the difference between two years on the job and 10 years. Even if you can't get a full third-party audit done of the environment, you should try to get as much of this information as possible yourself during the interview process. Just like buying a new house, don't get seduced by a great brand or a great executive team. Just like a house that is staged to sell, you have to take a much deeper look before you invest yourself in an opportunity.

What do you think? If you disagree (or even, heaven forbid, agree), please comment below or send me a private message. Or check out the Twitter discussion on @todd_michaud.