Part I: The four hallmarks of an effective CIO

Self-driving cars; thermostats that learn your habits; expert systems that help diagnose and treat cancer; smartphones replacing credit cards…and on and on! Technology is becoming more and more important to organizations, no matter what they make or do. Which means an ever-increasing push to invest more in IT.  As a CEO or Board member, you’re responsible for ensuring that your organization’s IT investment is appropriate: spending enough—but not too much—and spending on the right things. Every organization is different, so there’s no magic formula a consultant can hand you that will tell you if you’re on the right path.

But as a CIO myself, and a Director and advisor to CEOs and Boards, it’s clear to me that having an effective CIO is vital for properly managing your IT investment. CIOs come in many shapes and sizes, and their mandates are quite different depending on the role of IT in your organization. But no matter their style, here’s what I’ve learned over 25 years: effective CIOs must excel in four areas:

1. Alignment
2. Architecture
3. Agility
4. Ability

In Part I of our 4-part series, we’ll examine IT Alignment. Over the next few weeks on the Planet Mainframe blog, we’ll examine IT Architecture, Agility and Ability.

1. Alignment

Alignment means that IT understands and serves the needs of the organization. This sounds so obvious you may wonder why I even mention it: every corporate function exists to serve the needs of the organization. Sales only sells what you make, and finance reports the way the Board (and GAAP) dictates…doesn’t this mean IT does the same?

Perhaps alone among major corporate functions, IT is often poorly aligned with the strategic needs of the organization and thus doesn’t provide the leverage it might. Why is IT poorly aligned with the business? Mostly because you, the CEO and the Board, have left the CIO out of the loop. Former Secretary of State George P. Shultz said it best: “If you want me in on the landing, include me in the takeoff.” CIOs need to be in on whatever landing the Board/CEO have planned.

The #1 reason a CIO is out of the loop is reporting relationship. If you want effective IT, the CIO needs to report to the CEO (or perhaps the COO or President if they operate the organization). Period. There is a symbolic reason for this: it says “IT matters.” I’ve known CEOs who said “Oh, come on—what difference does it make as long as you’re on the team?” When you’re the top dog, you can say things like that. But the rest of the organization can’t really see “who is on the team” except by looking at the org chart.

Even more important than the symbolism is the access.

As a CIO, the most important thing for me to know is what keeps the CEO up at night because THAT’S what I should be focusing on. During my CIO career, I’ve reported to CEOs/Presidents/COOs, CFOs, CAOs, and even a CMO. Some of them have been truly great bosses and been very supportive of IT. But there’s a qualitative difference between reporting to the top person and to a “functional executive”: every functional executive is charged with ensuring their function delivers stellar results, so every functional executive is subtly—or overtly, depending on your incentive scheme—biased towards using IT resources to improve their function. Only the CEO (President/COO) has responsibility for the organization as a whole and can truly balance the competing needs of the various functions.

Another benefit from the right reporting relationship is participation in the organization’s “Executive Committee (ExCo),” or whatever the decision-making group is called. Hearing executive discussion and deliberation is so much more valuable for a CIO than just being told “it was decided that we’re doing ‘x’.” If the choice was between ‘x’ and ‘y,’ perhaps the CIO can do both by approaching the problem differently. And if the choice was do ‘x,’ THEN ‘y,’ and the CIO just gets told “do ‘x,’” there’s a lot of architecture work that might have to be redone unnecessarily. The statement “perspective is worth 20 IQ points” applies very strongly to this sort of decision-making.

There’s a value that comes from a CIO just listening to the business discussion, but that’s not the only one. Don’t forget that the CIO has insight into technology developments the rest of the ExCo might not have, as well as a unique view across every business process from one end of the organization to the other. This insight can help shape decisions that don’t appear IT-related as well as those that do—but only if the CIO is in the room.

There’s another, often overlooked, IT Alignment issue that needs discussion: Board participation. Early in my career as a CIO I was lucky enough to have a CEO boss who arranged for me to attend every Board meeting (as well as Board dinners, etc.). Some CIOs never meet the Board; some get to present an annual “state of IT” show; and others provide regular updates (usually on cybersecurity these days). But the opportunity to be an observer of the Board’s deliberation and decision-making process gave me an insight into issues I NEVER would have gotten any other way.

For the first few meetings I was afraid to speak up, and just answered questions while trying not to embarrass myself. But as our mutual comfort grew I became more of a business participant as well as the “resident techie.” It was a wonderful experience and provided me, through me the entire IT team, with the insight to make rapid progress on an aggressive IT investment plan.

In addition to CIO Alignment, effective IT should have middle-management Alignment. I’ve always been fascinated by the fact that there are but two defined channels between IT and the rest of the organization. The CIO works with senior executives, and the IT “Help Desk” works with front-line team members. But the folks who run the organization day-to-day, the business middle managers, have no forum for collaborating with IT middle managers. This means requests for service have to work up the business chain of command, get “thrown over the fence” to the CIO by a senior business executive, then work their way down the IT chain of command for discussion and action. Or the Help Desk incident reporting mechanism gets used as a way of requesting changes, and change requests get pushed down the business chain of command, reported as bugs to the Help Desk, then pushed up the IT chain of command for discussion and action. How dysfunctional!

I’ve seen two things work to empower middle managers and improve alignment: IT “Account Management” and business/IT Process Committees.

• Account Management is something your sales teams do with existing customers: listen to their issues, communicate with them, make them feel loved. Sometimes I’ve assigned my senior IT executives the dual role of account managers for various business functions, and other times I’ve created dedicated roles to handle this. It works like this: when the IT rep is with the “client,” they speak for IT; when they’re with IT, they speak for the client. If you charge senior IT executives with this responsibility it has other benefits: the “techies” get comfortable selling and listening to business issues and they learn the business. To make this work, it’s important that the organization’s C-level functional executives are onboard, since the IT Account Manager should participate in staff meetings, team building, planning sessions, etc.
• A Process Committee is a group of middle managers that collectively oversees a business process. If you look at most business processes, they tend to cut across departmental/functional boundaries. For example “Billing” may start in sales, move across several operations functions, and end in accounting. Forming teams of business and IT middle managers to talk about the process breaks down barriers—between IT and business as well as among business departments—and speeds up innovation. You’d be surprised to discover that such a group of business managers rarely, if ever, gets together to talk (unless there’s a crisis and they’re 100% focused on fixing something NOW)…and never includes the appropriate IT managers.

There’s an IT organizational nuance embodied in this as well. Most often, IT thinks of itself as responsible for a piece of technology rather than the success of a technology-enabled business process. In the Billing example mentioned previously, IT had a “Manager of [billing system software package].” I asked him what responsibility he had to see that bills went out correctly and on time. His answer “None! That’s not my job.” It’s common, but always a bit surprising, that IT managers rarely see themselves as “connected” to business outcomes. I changed the title to “Manager of Billing Technology” and told him that he was the IT owner of the process, along with several “clients” in the business, and that they were jointly accountable for billing overall. The difference was incredible! Problems that had plagued the business managers for years were fixed in days or weeks, and the overall process improvement was spectacular.  Alignment works!

Some poorly-aligned organizations use an “IT Steering Committee” as a way to pay lip-service to solving structural alignment problems. Such committees are usually composed of senior executives who hear presentations on proposed IT projects and somehow vote on what should be done by IT. While I’m a big fan of IT project portfolio management, Steering Committees are often slow-moving, bureaucratic, politicized time wasters (I’ll address this in more detail in a future column). Even if they had a place in the slow-moving, “systems of record” world of old mainframe IT, Steering Committees mostly slow things down without adding commensurate value in today’s fast-moving world.

So, what happens when an organization lacks IT Alignment? In the old days, when IT was the province of white-coated “scientists” and mainframes were the only game in town, the organization just suffered—sometimes in silence, and other times by complaining to the CEO and getting the “VP of IT” replaced. Since IT has been opened up and democratized, the organization has a “rational” response to poor IT Alignment.

Business functions that aren’t getting appropriate IT service go it alone. They hire their own IT folks (using vague titles to hide the fact from HR and IT), engage outside IT resources (consultants), or sign contracts for “cloud” or SaaS systems specifically intended to circumvent IT. This has the cute name “Shadow IT,” but I think the term “Rogue IT” better describes the “outlaw” nature of the process. A great deal of IT’s job—security, backup/disaster recovery, documentation, change management, regulatory compliance, audits, data quality, interoperability—occurs behind the scenes the client sees. That doesn’t mean these things lack value, just that IT doesn’t always make a big deal about them. Rogue IT is often oblivious to these processes/controls, and systems implemented without IT involvement are usually done, at best, in a slapdash manner—and at worst can expose the entire organization to dire SOX, security and compliance failures. It’s much better for the organization as a whole to add the business unit money earmarked to be spent on Rogue IT to the “official” IT budget and use it to prioritize that business unit’s work. Of course, this assumes that IT is capable of delivering quality work in a timely manner. That is, assuming the IT team has proper Architecture, Agility and Ability.

And next week on Planet Mainframe, we’ll have a closer look at what Architecture in IT is all about.