The CIO role in the Unix Enterprise

The CIO role in the Unix Enterprise

Summary: There's really not much to running a Unix system in the enterprise: as CIO all you need to do is create your own mini-me s in user departments, continually beat back the wintel/dp bigots, avoid the invisibility that comes with success, and recruit others willing to sacrifice their careers for professional success.


Organizationally a fully implemented and operating Unix/Smart display architecture presents as a small office of the CIO, two or more operational clusters running the actual infrastructure, and people embedded in user groups or departments who manage the application software running on that infrastructure.

From a long term perspective CIO stability and willingness to do as little as possible are the critical managerial success factors because the system as a whole is very much like Unix itself: something that works until brought down by an idiot with root access -or in the organizational context, a senior executive with hiring control over the CIO role.

At the day to day working level, however, the CIO job consists of keeping the outside forces seeking to destroy the system at bay while ensuring that his own people have the skills, authority, and resources needed to evolve the system as user needs and technology change.

This sounds simple enough, but you'll face three long term issues in actually doing this:

  1. auditors are trained to Wintel/DP expectations - today's CoBIT requirements are functionally identical to the 1920s data center operational standards they're derived from, and correspondingly counter-productive when applied to science based computing.

    In the Unix organization, for example, you have to empower your user side people to make software changes as needed by their users, but because you don't want accumulating changes leading to chaos you have to ensure that these decision makers have the judgment needed to know where the limits on individual action are and thus both when to say no, and when to invoke organization or division wide co-ordination and/or rethinking. As a CIO you achieve that first by hiring good people but organizationally by cross training them through job rotation, by encouraging them to form ad-hoc teams as they wish, and by assigning every staffer one or more long term personal responsibilities while allowing them to trade execution on those responsibilities among themselves.

    In doing this you violate every IT audit expectation on role separation, on formal planning and execution processes, on change documentation, on data and application ownership, on reporting hierarchies, and so on and so on.

    Functionally, almost nothing you do right as a Unix CIO will pass a traditional IT audit because the auditor's expectations are based on something close to the opposite of what you do -basically, an auditor trained to see short swords and machine guns as indistinguishable weapons and then sent out to review the Legion isn't going to sign off on a ranger team.

    In theory you should be able to have your senior management address this with the audit partner, but in practice it's often easier, if seriously less honest, to recognize that data processing audits are driven entirely from paper records, never reality - so showing them the paperwork they expect to see: things like your SLA, your DRP, and your unique staff assignment and certifications file, works. You'll need to brief your CEO and senior management team in to get the paperwork in place, but the bottom line is that you're dealing with audit juniors who have few clues, no judgment role, and no career path based on exercising judgment - so a simple mouse click certifying that your application librarian maintains a prioritized license recovery plan trumps any amount of demonstration or logic even if all of the ideas and assumptions involved are completely foreign to your environment.

  2. a properly implemented and run Unix/Smart display system has near zero visibility in the enterprise. The thing works - and therefore there are no IT crisis meetings facilitating face time with senior management, there's no continual user pressure on technology change, and that whole smarter-than-you separation between IT and users you get with PC support simply isn't there. Instead you're like the guy who fixes the phones: nobody knows who he is or appreciates what he does because phones, of course, run on centralized Unix switches and nearly always work.

    If we had a metric based on positive interactions between IT and non IT people, the Unix architecture organization would come out far ahead - but those interactions are mostly with users and user group level managers: not the senior people who vet your budget or hire your successors, and so two bad things come out of this:

    • you, your people, and your budget become safe targets for newly arriving senior managers eager to make bones with their colleagues - and because the Unix users won't care about systems while the Wintel/DP bigots never stop whining the resentments you build in beating these back will eventually force you to move on; and,

    • when you or one of your staff want to move on, it's the size of your organization and budget, not it's successes or effectiveness, that will dominate other people's perceptions of the resume. Basically head hunters and others will automatically consider a guy spending five million a year to achieve squat superior to the guy spending a million a year to give a comparably sized organization a major competitive advantage.

    Personally I've never found a way to beat this.

  3. and, number three, finding, training, and keeping good staff can be very difficult.

    The basic problem here is that you need people who can take on every role in the IT organization - including yours - and then motivate them to stay long enough to truly contribute value to the organization. Unfortunately the smart ones are both the ones you want to keep and the ones most likely to move-on once they know the job and understand their own value to other employers.

    Strategies that generally seem to work include telling them right up front that they'll get a much wider range of experience much faster with you than with traditional IT employers and should therefore plan on taking over somewhere else in about five years; sponsoring some open source projects; paying for additional education; rotating IT staff through practicums as user managers; and, giving them paid leave to teach at local colleges and universities.

    Strategies that sometimes work (but often backfire) include setting formal IT performance and satisfaction metrics with senior management and tying IT bonus monies to the achievement of those goals; keeping a couple of training FTE slots on the organizational chart; and, simply trying to out bid the other guy to retain particularly valued staffers.

    And, of course, strategies that are sure to fail include accepting mediocrity in exchange for stability, creating team rivalries, and trying to keep people in the dark about the value of the skills they learn in your organization.

So what's really the bottom line on the CIO job? You need to set a clear direction, motivate your people, train most of them to take over your job, and then generally underplay the role to do as little as possible while maintaining some kind of positive profile with senior managers - most of whom think IT trivial and you a mere geek from the wrong side of the social divide.

Nothing to it. Really.

Topics: Software, Banking, CXO, Open Source, Operating Systems, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It is everyone else's fault

    You sound like a real tea party express minion. Blame everyone else - especially established authorities - regardless of their merits.<br><br>Every conclusion have been decided in advance. Now you just need to put a spin on reality to make it look like your foregone conclusion looks correct (in your eyes).<br><br>Rudy, Unix had it's chance. It was too expensive and Windows was the disruptive technology to shake up the landscape.<br><br>Old-time Unix'es are the dinosaurs. The future belongs to Windows (desktop and servers) and to Unix's agile nephew, Linux (on servers). On mobile it is iOS, Linux (until that fails as well) and Windows.<br><br>Live with it. Instead of blaming everyone and their mother.
    • Uh, would you mind elaborating just a little bit?

      "Every conclusion have been decided in advance."
      How do you know this?

      "Unix had it's chance. It was too expensive and Windows was the disruptive technology to shake up the landscape."
      Examples? (and, by the way, BSD is free)

      "The future belongs to Windows (desktop and servers) and to Unix's agile nephew, Linux (on servers). On mobile it is iOS, Linux (until that fails as well) and Windows."
      You're contradicting yourself -- exactly how can the future belong to Linux when it is going to "[fail] as well"?
    • You only get one?

      "Rudy, Unix had it's chance."

      Only get one? Of course not.

      Arguments for the Unix/Smart displays in some environments are compelling. Murph has made a good case. His points about the challenges are accurate: auditor knowledge, MSCE bleating, Budget largess, Finding and retaining staff.

      "Every conclusion have been decided in advance"

      Are you talking about Murph?
      Richard Flude
  • water!!........

    sparkle farkle
  • A Unix/Smart display system has near zero visibility

    A true statement as a Unix/Smart display system has a near zero deployment, so you cannot see what is not there.
    Tim Cook
  • A conservative is a conservative is a conservative

    Murphy didn't build a museum for the future, he built it to house the past. Inside it he visits strange parallel universes where Unix actually stayed around, Sun still exists and they never heard of object oriented code. <br><br>In these strange worlds Rudy is a consultant. No matter that the world outside the museum has changed beyoind his recognition, he only knows one thing and he's sticking to it. I suspect his clients live in these universes too, as we've never been able to track one down in the real world. In fact, if you have or have ever been a client of Rudy de Haas, please post here and let us know your experiences - pitchforks and torches should be left at the door. <img border="0" src="" alt="wink"><br><br>Rudy is the ultimate conservative. Essentially if it's not working, just don't fix it and the peak of computer development was in the early 1990s.<br><br>I think it's time to take down the billboard outside the museum Rudy and close the doors - luckily you don't have to worry about the Windows. I know, I know, it's not you out of step - it's the rest of the world.
    • How about actual comments on the post, not the poster?

      @tonymcs@... <br><br>For someone who swore times and times again to never, ever read "Rudy"'s blog again,you've been awfully busy posting non-replies...<br><br>Oh well!!!
      • RE: The CIO role in the Unix Enterprise


        Everyone is capable of redemption ;-)
      • How about actual comments on the post, not the poster?

        How about it? You never make any valuable comments in the first place.
        I come here to read it for laughs, and I'm sure that is a factor for Tony too.
        Rudy is stuck in the past desperately clinging to life. His blogs always make me laugh with how out of touch he is.
  • Complete fantasy, from a lying fantasist

    There is nothing related to reality here. Rudy has never done what he's talking about, he's never implemented a system like he talks about, he's never seen one in operation. It's something he likes to pontificate about. It's not real.
    • RE: The CIO role in the Unix Enterprise


      Woppela! You forgot to mention he doesn't eat three carrots a day...
  • RE: The CIO role in the Unix Enterprise

    @Blah Well he did manage to fill out the application.What a Great guy an good story. I Understood it but i just couldn't get into it. Paul Murphy is way more geeky then me "lol" the funny thing is i am a fbsd user