% fortune -ae paul murphy

Using open source smarts to pick change agents

There's a frightening job opening coming up soon - let me summarize the requirements.

Your job will be to lead the integration of fourteen competing IT groups ranging in size from 2,300 employees to eleven people - they've all been operating independently, subject only to the collective guidelines of generations of central IT bureaucrats whose primary agendas have been self-preservation and budget growth - and who collectively implemented that by controlling communications and budgets while vigorously refusing to let any Unix variant or open source software inside the funding tent.

There are two rules:

1. you have to promote from inside; and,

2. you have to agree, up front, that absolutely everything done by anyone in any of the predecessor groups was brilliantly successful.

And, of course, you have a couple of goals:

1. you must stop the complaints about IT. Collectively these groups reach about 70,000 users. Of these about 65,000 have no voice at all; but essentially all of the remainder, whether managers or just local PC gurus, generally claim that nothing they've got IT supported access to now works, can really be trusted, or is more than an externally imposed blight on their working lives;

2. you must cut the collective IT budget by at least 30% (since that was a key premise used to sell the re-org); and,

3. you must find and implement a legally and politically acceptable balance between information usability and information security.

On the face of it, this is hopeless - but there is one strategy that might work: pick the best of the internal people and promote them, pick the worst and assign them jobs or supervisors they'll hate enough to quit, ignore the budget issue, and then let time and best efforts lead to the evolution of a service oriented culture.

It's easy to pick the worst offenders - they're the people in charge, the people who go golfing with consultants, the ones with secure go-to job alternatives with major vendors, and the shrillest advocates for the worst solutions. The rest are cost and performance drags, but given time and strong new leadership you can expect to save some while filtering others out.

But meanwhile you've got maybe 300 people who think of themselves as IT executives; people with standing within the predecessor organizations - and once you sideline of the worst 30 or so pending their resignations, how do you pick the top twenty or so among the remaining 250+ without having the time to really get to know them?

I've got three rules of thumb to suggest:

1. ask user management who they go to for honest advice in dealing with senior IT management;

2. check personnel records for reprimands and other comments relating to the candidate's willingness to side with users and against senior IT management; and,

3. talk to them about attitudes toward, and real knowledge of, standard networking, open source, and Unix.

The right answers, I think, are obvious - and I think their initial ranking as candidates for senior positions in the combined IT operation can be largely based on the extent to which the record verifies that they really do act accordingly.