I run a lot. Early mornings mostly, before the inbox wakes up. And the longer I do it, the more I notice how much running has taught me about running an IT organization. Not the motivational poster version. The real one, where your legs hurt, the weather is bad, and you still have to show up.
When I joined ALTEN to build the group IS&T function, I inherited something familiar to anyone who has done this job: talented people, all working hard, all working on their own thing. Every business unit had its own projects, its own tooling, its own way of tracking what mattered. Locally, it worked. Globally, it was fifteen countries running fifteen different races and calling it a team.
So the first question wasn’t « which platform do we buy. » It was « what does fit look like for us. » And that question, it turns out, has more to do with training than with technology.
Governance is the training plan, not the medal ceremony
In most companies, governance has a bad reputation, and honestly it earns it. People hear the word and picture a steering committee where forty slides get presented to people who already made up their minds, followed by a status report nobody reads. That is governance as ceremony. It produces the feeling of control without any of the substance.
Real governance is closer to a training plan. It is the boring, repeated, slightly unglamorous structure that lets you perform when it counts. A runner doesn’t improve during the marathon. They improve during the eleven weeks of dull Tuesday intervals nobody posts about. The race just reveals the work.
For a global IT org, that means the value isn’t in the quarterly review. It is in the cadence underneath it: the shared definition of a project, the same risk lens applied everywhere, the same way of saying « this is on track » so the words actually mean something in Paris and in Bangalore and in São Paulo. When I finally had a single 360 view of the full project portfolio, the dashboard wasn’t the achievement. The shared language that made the dashboard possible was.
Standardize the road, not the runner
Here is the tension every global CIO lives with, and the one I get asked about the most. Standardize too little and you get fifteen islands. Standardize too much and you get fifteen frustrated teams quietly building workarounds you will discover two years later during an audit.
The way I think about it: you standardize the road, not the runner.
The road is the stuff that only creates value when it is the same everywhere. Identity. Security baselines. How we classify a risk. How we describe progress. The core of the information system. Nobody in a business unit wakes up excited to reinvent single sign-on, and they shouldn’t have to. That is shared infrastructure, and shared means shared.
The runner is everything close to the business, where local knowledge genuinely wins. A team in one country understands its clients, its regulators, its rhythm better than I ever will from headquarters. My job is not to make them run my way. It is to give them a road that is smooth, safe, and well marked, then get out of the way.
We built the organization as a hub and spoke for exactly this reason. The hub owns the things that have to be coherent. The spokes own the things that have to be close. When someone argues for an exception, the question is simple and a little annoying on purpose: is this a road problem or a runner problem. Most « we’re special » requests quietly resolve themselves once you ask it out loud.
Resilience comes from design, not from heroes
Every IT organization has its heroes. The person who knows where the bodies are buried, who you call at 2am when the thing breaks, who has the whole architecture in their head. We celebrate them. We give them awards. And we should, because they save us.
But if your resilience depends on heroes, you don’t have resilience. You have luck, plus a few exhausted people you are slowly burning out.
Runners learn this the hard way. The injuries don’t come from the hard days. They come from no rest, no structure, doing too much because you felt strong that week. Durability is designed. You build it in with progressive load, with recovery, with form that holds up when you are tired. The same is true for a system serving 300 people across 15 countries. You don’t want the architecture that performs beautifully when everyone is fresh and everything is calm. You want the one that holds its shape on a bad day, during an integration, in the middle of an incident, when the obvious expert happens to be on a plane.
So we design for the bad day. Best of breed where it earns its place, microservices we built ourselves where the market didn’t fit, security woven in rather than bolted on after. Less heroism, more form. It is less dramatic. It is also the only thing that scales.
The part nobody puts on the slide
Here is the wink I’ll allow myself. The single most underrated skill in running a global IT org is the willingness to be a little boring on purpose. To run the same loop. To ask the same dull question. To resist the very seductive pull of the big reorganization that makes everyone feel busy and changes nothing.
The flashy transformations get the conference talks. The ones that actually work look, from the outside, almost uneventful. Quarter after quarter, the same disciplined cadence, the fragmentation slowly going down, the trust slowly going up, until one day you realize the fifteen separate races have quietly become one team that knows how to pace itself.
That is the whole job, really. Not the sprint. The training. You show up, you do the unglamorous work, you protect the people doing it, and you let the results reveal themselves when it counts.
The inbox is awake now. Time to stop writing and go run the loop.
