This is the ninth excerpt from the first book in the Defen series: The Board Member's IT Brief.
In choosing a CIO, the cardinal rule is to pick someone whose skills align with the technology you have or want.
Management processes form a critical piece of your information architecture and bringing in the wrong skills is tantamount to dropping an 1890s steam engineer in the pilot's seat of 747 while in flight.
Do it, and one of two things will happen: either someone internal to the IT organization will act as the real CIO, turning your exciting new hire into an opportunity blocking figurehead; or mistakes will be made, and conflicts created, that inevitably cause your systems costs to increase while bringing down systems reliability and user productivity.
One client of mine, a 650 bed acute care hospital, installed a comprehensive hospital management system built on Unix with smart displays (21" NCD X-terminals like this one), and got it properly deployed and pretty much "shook down" using two technical staff provided by the primary application developer.
At the end of the installation period the system was getting rave reviews from users -and then the hospital hired a competitor's CIO whose systems experience had started with Burroughs and finished with a System 390.
When he found the hospital had taken the vendor's advice and budgeted for only seven full time IT staff, he requisitioned more money and started a hiring binge - but only for people who looked and thought like him - and correspondingly didn't have a clue about Unix or smart display technology.
A year later, he had 45+ staffers, a new, more formal, IT steering committee, a service level agreement, a printed disaster recovery plan, and logical reasons for everything, but nothing actually worked reliably anymore.
According to his staff the vendor was uncooperative, the technology had proven inadequate, and user management was biased against the project.
In reality, users were up in arms, budgets were out of control, data was being lost, PCs and off budget IT support staff were proliferating like lice, and the primary application vendor was threatening legal action to collect fee hold backs and terminate the relationship.
What had happened? He did what he knew how to do: exactly what he'd done before: the right thing for an information architecture built around a System 360; and totally the wrong thing for Unix. And, worse, he knew he was absolutely right - and spent more money to hire name brand consultants to tell the board so, even as he destroyed the information systems at the heart of the institution's ability to do its job.
Rule zero: Align your CIO with the technology or suffer the consequences
Basically the hospital had bought a perfectly balanced machine, and then nicely sabotaged it by replacing a critical component, the CIO, with one drawn from an incompatible competitor's inventory. - an action, and a predictable result, no different from what a long distance trucking company might get if it hired a dispatcher from a big city cab company to head freight assembly and customer service.
What happened at the hospital amounts to a horror story, but it's not unusual - and the worst thing about this kind of thing is that the cause is not generally recognized in time to prevent a total systems meltdown.
The reason for that, I think (and part of the reason for this book) is that most senior executives simply don't have the knowledge, or the trusted outside information sources, needed for them to call a halt early on in the process.
Instead they usually start out as victims of escalating commitment to the CIO hiring decision and end so overwhelmed by the CIO's knowledge, confidence, and consultants that they question their own judgment and agree to have the CIO hire more name brand consultants, who also share his background, his loyalties, his myopia, and thus his opinions, to tell the board that he's right, and that the system he inherited in working order, was wrong.
My client never fully recovered, and before this mess ended most of the original members of the steering committee had agreed that the software decision, organizational structures, and controls they had put in place the first time hadn't been adequate - nicely blaming themselves for the wrong mistake.
Notice, furthermore, that this kind of thing isn't an artifact of a specific technology: it's a consequence of the fact that technologies and skills are tightly related, and that what's right for one usually isn't right for another. If they'd had a zSeries/Windows environment this guy would have served them well; conversely if they'd hired a Unix guy this meltdown would not have happened.
The bottom line is simple: when hiring a CIO, remember that he'll either be an obstacle for the real CIO or the primary definer of the "management methods and processes" that go into operating your corporate information architecture. Fail to match this component to your hardware and software, and you will create a disconnect that cannot be patched over and usually brings the systems operation to grinding halt.
There is a significant proviso: it's technology that counts, not its application. You can no more put a CIO from one community in charge of another than you can expect a teamster to fly a jet - but you can safely cross both organizational and industry experience boundaries in hiring.
The business context is part of your information architecture, but it's the one component on which your other senior executives are experts. As a result the information asymmetries that leave them powerless to rein in a CIO whose expertise is contra indicative for the technology environment, don't exist. Since the CIO is supposed to deliver IT services, not use them, this means that he'll learn what he has to about your business from the experts in place - and that means that industry experience is nice to have in a candidate, but should be far down the list of decision criteria.
---
Some notes: