Commentary: Six Rules for CIO SurvivalBy John Parkinson | Posted 08-17-2006
Commentary: Six Rules for CIO Survival
Last week I wrote about the evolving challenges of CIO educationand the need to figure out what a career path towards the CIO role might look like. This week I want to touch on the kinds of "survival strategies" that, at a high level, I think all technology executives must embrace and cultivate.
I've been developing this list over a long time, both from my own experiences as a CIO (now a decade in the past, thankfully) and as an observer of, and advisor to, many CIOs since then. In many cases, I have seen organizations who ignore these rules wind up with major technical and business problemsand the CIOs who ignore them do so at their peril.
First Rule: Minimize the number of irrevocable decisions you make. An irrevocable decision is one you can't afford to undo easily or in a hurry, so needing to undo it will get you into a lot of trouble. Many organizations make such decisions all the time and without sufficient thought as to the consequences. Platform technology choices fall into this category, as do strategic supplier relationships and, often, organizational models, especially the relationship model with the business. Anything to do with explicit "cultural change" belongs here. And then there is outsourcing . . .
Irrevocable decisions aren't intrinsically bad, but they do carry specific risks that should be addressed during the decision-making process and afterwards. And once made, specific attention needs to be paid to continuing risk management, if only so you have sufficient warning if things start to go wrong and a "revoke" becomes inevitable.
Rules Two and Three
Second Rule: Minimize the number of essential competencies within the IT department required for success. This one is even more widely ignored than the first rule. Developing a sustainable competency, whether it be in a new technology, a design approach or a business architecture, is more complex and takes longer than many organizations think. A "competency pool" is a dynamic construct and needs to be carefully managed to account for such factors as:
Doing all this for even one essential competency is challenging. Doing it well for many competencies is almost impossible. And in extreme cases, organizations require so many different "essential" competencies that they can't possibly create competency pools that are big enough to be self-sustaining over time, no matter how well managed they are. In such a circumstance, one or more essential competencies will always be lacking and the risk of failure will be high.
There is a common trap hidden here. Organizations often assume that because they have people who are smart at one (or several) things, their people are smart at everything. This is the "renaissance person" trap. There are indeed people who are smart at everything and you are truly fortunate if any such people work for you. But there are very few of them. They are hard (and expensive) to keep, and there aren't enough of them for everyone's needs. So this approach is guaranteed to fail sooner or later.
Third Rule: Don't make success dependent on competencies you don't have and can't get. Organizations routinely embark on new programs assuming that they can either acquire the resources they need in the market or create the competencies internally. There is little evidence that either approach is easy or guaranteed. Few organizations seem to take into account how scarce some skills are, especially skills associated with new technologies or with technologies for which there is a significant spike in demand, increasing scarcity (and causing attrition if any of your people have any of those capabilities) and inflating costs.
And few organizations are set up to provide timely and effective internal training. Relying on vendor partners can be equally problematic. Training often isn't their core business, and they too have resource constraints, especially if they are small and their products are new or innovative. If you decide to go for new competencies, be prepared to make a (perhaps significant) investment in recruiting and/or internal training. Remember that a lot of your vendors spend much more time and resources training their support staff than you probably invest in your own peopleeven when they will have to play critical roles in making your new technology work effectively.
Rules Four, Five and
Fourth Rule: If you've made an irrevocable decision, make it pay off fast. This buys you some wiggle room if you have to change your mind later. In fact, a focus on realizing benefits early is almost always a good idea in technology because (even today) things change so fast. If you have to wait years for the technology to pay back, it's highly likely that, by then, there will be a much more cost effective way to do what you need, and your choice will look foolish. You can also get trapped in a technological "fashion" (remember Steve Jobs's NEXT) or in adopting an emerging technology that evolves away from your expectations (virtualization is a good current candidate). This will matter less if the ROI is already in the bank.
By the way, this is a survival rule, not a success rule. If you made a poor decision but it worked out well financially you should survive the disruption caused by the "revocation." But it's not likely that anyone will thank you.
Fifth Rule: Buy insurance (and maybe some reinsurance too). Insurance comes in several forms. One form that's easy to acquire is the adoption of broadly supported industry standards. Such standards give you some insulation from individual vendors and offer a place to switch to if a selected technology supplier fails or a strategic relationship turns adversarial. Broad standards tend to have one or more major "anchor" vendors and a rich "ecosystem" of aligned ISVs. SIs and VARs, so you should have plenty of tactical options as well as a rational basis for your "strategic" selections. You'll also probably have plenty of company in any misery that does surface, so you won't look like you missed obvious warning signs.
Another useful form of insurance is the "plus one release" planning model. Always assume that the feature (or capacity or cost level) you need will be one release later than the vendor promises. You will sometimes be pleasantly surprised and occasionally acutely disappointed, but the majority of the time you will look prescient.
And finally, remember that you only need insurance when something bad happens. Having insurance doesn't stop bad things from happening; it just gives you the tools to survive and recover from the bad outcomes. The actual recovery process will still usually be unpleasant.
Sixth Rule: Expect to be surprised. Even if you do everything right and make all the decisions you have control over correctly, things can still go wrong. The future is inherently uncertain and there are plenty of things you can't control that can derail your carefully thought-out plans. So it makes sense to stay (a) alert and (b) agile. This is especially true if you have made some (carefully considered and insured) big bets that can't easily be undone. Even though you can't really anticipate surprises, you can pay attention, by implementing competitive intelligence and technology trend monitoring programs that let you peer a little way into the future. If you pay attention to what the signals tell you, you can often detect the early stages of a surprise in time to adjust course. That's the agility requirement.
And you never know. Not every surprise brings bad news. Some of the surprises you detect might even make life better, and your ability to incorporate them quickly and easily into your plans will make you look smart. And that's much better than merely surviving.