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:
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.
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:
Personally I've never found a way to beat this.
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.