The CIO Used to Keep the Lights On. Now What?

Something shifted in what organizations expect from the CIO role, and the shift happened faster than most organizations were ready for. A decade ago, the CIO's job was legible: keep the infrastructure running, manage the vendors, deliver projects on time and under budget, and stay out of the news. That was success. The CIO who appeared in executive conversations mainly when something broke or when a major purchase needed approval. The CIO who measured themselves in uptime percentages and helpdesk ticket resolution times.

That version of the job still exists in some organizations, but it is increasingly treated as a failure mode rather than an acceptable operating model. The expectation in most industries now is that the CIO is a business strategy partner, not an infrastructure manager. That they are present in discussions about market positioning, product development, and competitive strategy, not just about system reliability. That they speak the language of business outcomes rather than technical specifications. The gap between where the role started and where it is expected to be is significant, and most organizations have not worked through what that gap actually requires.

I wrote about the Upper Echelons angle in an earlier post, and it is directly relevant here. Hambrick and Mason (1984) argued that executive characteristics, including background, education, tenure, and functional experience, shape how they interpret strategic situations and what decisions they favor. I could not find Hambrick and Mason in my local study materials, so I want to be careful with the specifics, but the intuition maps cleanly onto what I observe about CIO effectiveness. A CIO who spent twenty years in IT infrastructure, who built their career on technical mastery and operational reliability, carries a particular cognitive frame into strategic conversations. They are trained to think about risk, about what can go wrong, about dependencies and failure modes. That is exactly the right frame for running data centers. It is not always the right frame for evaluating whether to build a new digital product or restructure the business model around a platform.

This is not a competence critique. The infrastructure CIO is often more technically skilled than the business-oriented CIO. The issue is what the Upper Echelons argument predicts: different backgrounds produce different strategic orientations, and the strategic orientation that produced success in one context is not automatically the right one for a different context. The CIO who excels at IT governance and vendor management may systematically underweight offensive digital investments because their cognitive frame is optimized for risk minimization rather than opportunity pursuit. They are not wrong about the risks. They are incomplete about the opportunities.

The emergence of the Chief Digital Officer created a problem that organizations have been working through with varying degrees of success. The CDO was invented partly as a workaround for this cognitive frame mismatch. If the CIO could not carry the digital transformation mandate, create a new role with a new title and a different background profile. Hire someone who came from consulting, or from a digital-native business, or from a product development background, and give them the innovation agenda. The CIO continues running operations. The CDO chases transformation.

The problem with this arrangement is that it tends to create two competing power centers with overlapping mandates and unclear boundaries. The CIO controls the infrastructure that the CDO's initiatives run on. The CDO controls the transformation budget that IT would otherwise have argued for. Their incentives are not aligned. The CIO has operational reasons to resist fast-moving CDO initiatives that introduce new security exposures or infrastructure dependencies without following established governance processes. The CDO has strategic reasons to route around IT governance processes that were designed for a different pace of change. Both of them are right in their own frame. Neither frame is complete.

The organizations that have navigated this most cleanly seem to have resolved it through one of two paths. Some clarified the CDO mandate as genuinely complementary to the CIO mandate, by defining CDO scope as customer-facing digital products and experiences while CIO scope covers internal systems and infrastructure, with explicit integration points and joint governance. Others absorbed the digital transformation mandate back into the CIO role by appointing a CIO whose background and orientation matched the expanded role requirements, which sometimes meant replacing the incumbent. Neither path is comfortable. The dual-role model requires more coordination than most organizations budget for. The CIO replacement model carries the talent and institutional knowledge risks that come with any senior leadership change.

There is a specific challenge for technically trained leaders that I think is underappreciated. Building credibility in boardrooms requires a different vocabulary and a different mode of argument than building credibility in engineering organizations. Technical leaders are trained to be precise, to qualify claims with caveats, to acknowledge what they do not know. These are virtues in engineering contexts. In boardrooms, they can read as uncertainty or lack of conviction. Business leaders who have spent careers making arguments to boards often communicate with a confidence and directness that is not always epistemically warranted but is organizationally effective. The CIO who explains that the new AI initiative might deliver X percent productivity improvement with these assumptions and this confidence interval is giving a technically accurate answer. The CDO who says "this will transform how we compete in the next three years" is giving a useful boardroom answer. Both are describing the same project. One of them sounds like leadership and one sounds like analysis.

I do not think the solution is for technical leaders to abandon epistemic honesty. But I think the gap between how technical leaders communicate and what boardrooms respond to is real, and closing it requires deliberate work. The CIOs who have made the transition tend to be the ones who learned to translate technical specificity into business narrative, not the ones who abandoned specificity for empty confidence. The translation is the skill. It takes time to develop, and organizations that expect it automatically because someone has a CIO title are going to be consistently disappointed.

The question that bothers me is whether the background and experience pipeline that produces most CIOs systematically underproduces people with that translation skill, and whether the organizational response, creating new C-suite roles to compensate, actually solves the problem or just redistributes it.