The CIO Who Still Needs the Java

Years ago, in a large and technically complex organization, any disruption — an application issue, an external service, the infrastructure, a vendor, it didn't much matter which — set off the same ritual: open a bridge, and progressively pull in everyone who might conceivably have something to do with the service. It was not unusual to end up with fifty or sixty people on the call. Fifty-eight of them in silence. Two actually troubleshooting. And almost always, it was those same two who worked out what had happened and brought the service back.

The praise that followed was genuine. Great responsiveness. Great expertise. Great problem-solving. All of it true. But over time I started asking a different question: why does it take sixty people in a war room to let two people solve the problem? And a harder one underneath it — why are we so good at celebrating the fix, and so uninterested in asking why our operating model keeps producing the need for heroics in the first place?

Fifty-eight people in silence, two doing the work

Sometimes the paradox was almost too neat. An application would break. Someone would step in, know every detail of the system, find the defect, and save the day. The praise was deserved. Then you'd notice that the person knew the system that well partly because they had built part of it themselves — a lot of custom development, a lot of one-off logic, a lot of exceptions that had started as a specific business request and quietly become permanent fixtures of the architecture. We were at real risk of rewarding the heroism needed to resolve a complexity we had helped create.

I've come to think of this pattern as leadership's gravity problem. The higher you rise in an organization, the more your contribution should shift — from doing the work yourself to building the system the work happens in. But under pressure, there's a pull back down: toward the level where you're comfortable, where you built your credibility, where progress is immediate and visible. Firefighting feels like contribution. Slowly coaching someone through their own mistake can feel like doing nothing at all.

The CIO who still needs the Java

This pull reaches further up the organization than people usually admit. I once worked with someone I'd now call a CIO analyst — fully capable of diving into the detail of a custom Java fix, the specific application, the specific bug. There's nothing wrong with a CIO who understands the technology; if anything, I prefer leaders who are technically credible. The problem starts when the technical detail becomes the main place a senior leader goes looking for their own value.

A CIO can know the technology. The problem starts when he still needs it to feel useful.

Because the real job of a CIO is not to become the sixty-first person on the bridge. It's to ask why the bridge needs sixty people at all. Why isn't ownership clear? Why doesn't the support model route the issue quickly to the two people who can actually fix it? Why do we carry this many dependencies? Why does the same category of incident keep coming back? Why have we produced so many exceptions? Why does knowledge of the system still live mainly inside a handful of people's heads?

Demand management is not request-taking

Part of the answer, in that organization, traced back to how demand was managed. The function responsible for shaping demand — and, nominally, for a role in digital transformation — sat inside HR. Where a function sits on the org chart is rarely the real problem. The real problem is whether it has the competence the function actually requires.

Demand management is not taking a request, formalizing it, assigning it a priority, and handing it to technology. That's request management. Real demand management has to be able to challenge the demand itself: what is the actual business problem? Do we genuinely need a new solution? Do we already have a capability that covers it? Is this consistent with our architecture? Are we quietly introducing another exception? What will it cost to run? Who maintains it in five years? Which part of the system are we making more complex to solve today's local problem?

Without that capability, "internal consulting" risks becoming a strange phrase — a function that gathers the need and produces analysis and documents, without the technological, architectural and operational depth to genuinely question the solution being requested. And digital transformation risks becoming the systematic digitization of exceptions. There's a problem? A new report. Need a different view? Another report. Then a dashboard. Then another, because a different team wants almost the same data, just slightly different. Each object can be useful on its own. The problem shows up in the sum: a growing constellation of reports, local logic, different sources, ownership nobody quite owns, and small technology products that nobody ever decided, at the system level, to build. The local request gets resolved. The structure that keeps generating that request is left exactly as it was.

The same gap shows up in documentation and in how knowledge travels through people rather than through systems — a pattern I've written about elsewhere on this blog. It's the same root cause wearing a different costume: a system that isn't explicit enough always ends up depending on the people who "know."

Leadership is not only technical

And then there's a dimension I've come to think matters more than any of the above. A senior leader can know Java, architecture and applications perfectly, and still forget that leadership also means emotional intelligence, respect, and some awareness of your own impact on other people.

I remember one Sunday, around lunchtime. My phone rang — the CIO. No incident. No emergency. No critical service down. Just a question. I answered, we talked it through, the call ended. My wife, sitting next to me, looked at me and asked: "Didn't he even thank you for calling you on a Sunday?" I honestly hadn't noticed. She had.

That stayed with me, because emotional intelligence isn't the soft part of leadership. It is leadership. If your position gives you the power to interrupt someone's Sunday for a question, part of leading well is knowing when not to use it.

One root, many symptoms

None of these things look related at first glance. The sixty-person war room. The hero who saves the application. The custom code written for every new request. Demand that quietly becomes request-taking. The proliferation of dashboards. Documentation that mostly lives in people's heads. The senior leader who keeps diving back into operational detail. Too little attention to the human cost of a decision. But they share a root: an organization that can be extremely good at handling events, and considerably less mature at redesigning the system that keeps producing them.

I sometimes find myself, today, looking from the outside at organizations I once knew from the inside. If I buy a premium product and the quality isn't what I expected, or the price goes up while the perceived quality seems to drift, I'm obviously not drawing a straight line back to some IT war room or a Power BI dashboard — that would be absurd. But a broader thought does come to mind: what a customer sees at the end of the chain is usually the result of hundreds of decisions, standards, behaviors and leadership habits that customer will never see. Technology, process, organization, people and customer experience aren't separate worlds. They're parts of the same system.

Organizations genuinely need exceptional people who can resolve an incident. They need, even more, leaders who can build systems in which incidents, exceptions and heroics gradually become less necessary. Putting out a fire well is a skill. Building an organization that catches fire less and less often — that's leadership.