This is the 12th excerpt from the first book in the Defen series: The Board Member's IT Brief.
The biggest problem you will face in hiring a good CIO is that, in systems, failure succeeds and success fails.
In IT: success fails and failure succeeds
It sounds absurd, but it's true. Good systems are invisible and so are the people who make them work - if you work in a traditional office structure you probably have a secretary, and I'll bet she knows who fixes the photo copier, but doesn't know who fixes the phones.
Why? because phones work and copiers fail.
It's the same with information systems. Systems that fail are squeaky wheels whose managers get face time with senior executives. Systems that work don't squeak and are correspondingly invisible to senior people.
A systems executive who wants lots of face time with other senior managers need only keep business applications perennially on the edge of failure - producing frequent crisis meetings in which his social skills let him play the calm and reassuring professional, quietly explaining to the plebes that it always takes more staff and more money just to keep things running.
This grows the IT department, and his resume. It's great for him: he's busy and socially appreciated, but it's bad for the organization.
Basically, visibility earns social credibility and budget increases, while a guy who quietly gets the IT services job done will not be a squeaking wheel, will not be known or appreciated where he is, and won't have a resume showing rapidly increasing budget responsibilities.
Consider these two candidates for CIO at a manufacturing company doing about $800 million in annual business (in 2005):
| Results from Current Employer | Candidate A | Candidate B |
| Annual IT budget | $14,700,000 | $3,200,000 |
| Employees managed | 122 | 24 |
| Users | 1,800 | 2,136 |
| Key Software | MS-Office 11, IE 7.0, custom developed client for SAP, Crystal Reports. 3278 emulation (for existing finance apps.) | StarOffice, Firefox, Sybase, Peoplesoft, Statware, Actuate |
| Largest project managed while there | SAP - $31 Million over 4 years- started on Windows 2000 and now due for rollout on Windows 2003/XP Advanced Server with clustered SQL-Server. | PeopleSoft - $5.8 million over two years- on Solaris with Sybase, IQ, and Actuate. |
| Publications/Presentations | "Achieving Success through accelerated Implementation" - a paper given at the 2003 SAP ERP/SCM professional's conference. | None |
| Out-sourcing Experience | Managing EDS processing contract for current zOS based financial and Mfg. applications. | None |
| Technology | Completed enterprise wide rollout for Windows 2003/XP SP2 Professional with advanced directory services | Four way redundant Sun 6900s with 2000 Sun Rays, 80 Macs; about 56 PCs; |
| Help desk calls for year | About 420,000 | 9,384 |
Only one of these guys is doing the IT job, but success fails, and failure succeeds: the other guy is going to get more offers at higher salaries.
It's sad but true, failure to deliver effective user services is not a career limiting move for the CIO. Far from it, the more he spends, the better and more effective he will generally be seen to be.
The big lie in technology management is that a computer is a computer - i.e. that skills in one environment transfer easily to another. The matching big lie in recruiting is that a dollar is a dollar -i.e. that relative budget size in previous roles tell you something of substance about the quality of services a candidate is likely to provide in your organization.
What really counts is what he did with the dollar, not how many dollars he spent.
So how do you pick someone who'll do the job for you? You'll get your first serious indicator when the discussion turns to compensation. People whose focus is on getting the job done, usually want fair treatment and freedom to innovate. Conversely, those who insist on extracting the last nickel and the last concession on separation aren't likely to demonstrate a different focus while in office.
Rule Two: Buy Techies with Trust and Freedom, not dollars
So the bottom line is simple: figure what's fair in your organization - what your other top people are getting - and offer a comprehensive package based on it. If that's not acceptable, think twice, or even three times before going an extra inch - remember: when the conversation turns to money, you may be seeing the real man for the first time.
Performance bonuses are usually bad news except for interim or contract CIOs brought in to deal with well defined, and well understood, change processes. The reason is that you almost always get more of whatever you measure or "incent" but generally have no good way of predicting just how that will come about.
Incent your CIO to reduce help desk calls, and that's normally what you'll get - reduced user support. Adding balance by considering other factors generally doesn't work either; in fact, the more complex you make the performance measure, the more difficult it becomes to fairly enforce it - balance help desk calls against user complaints, for example, and you write a recipe for technology stagnation because any change, no matter how positive, produces both more help desk calls and more user complaints.
The bottom line is simple: start, and end, with fair; and if that's acceptable, move the conversation forward in terms of the non contractual freedoms you can offer.
Remember: trust and freedom are the currencies that motivate technical people - for many, money is a side issue and span of control a nuisance accepted for the sake of the challenge involved in getting the real job done.
Thus a focus on anything else should be a red light for you: you're hiring the head techie here - not a go between translating geek between the real CIO and some executive committee. If the guy you're talking to focuses on money or control you need to ask yourself what he thinks the job is.
So what can you offer? Ask the candidate, but remember that the reality will depend on your organization and be limited by the tolerance your other senior officers have for what they'll usually see as frills.
For example, one idea I recommend to Unix systems managers with budget responsibility is institutionalized support for goofing off -something, by the way, I've yet to see a senior finance guy support.
The background to this, and it only applies in the Unix world, is that the most effective people are also the least obviously busy - once a new application or technology works, there's nothing for them to do until something changes. In response the right Unix organizational structure gives each individual a clearly defined set of personal responsibilities, but then frees them to work with other team members -on anything they want to- once those responsibilities are met.
Supporting people who want to do things that go beyond the job provided only that there's some user involvement improves the relationship between IT and the business side, motivates your people to keep things that are working, working; and creates powerful social incentives for people to develop cross functional skills - thus uncovering new applications and service opportunities for IT while reducing mistakes, turnover, and job stress for everyone.
That's the real bottom line: for a good IT guy trust and freedom, not dollars, are the currencies in which performance is best rewarded. Make it possible for your CIO to advance his own goals while meeting yours and you've got a recipe for success - as defined by the statement that a good IT infrastructure is essentially invisible to users and managers alike.
---
Some notes: