Pablo Dimenza is Senior Managing Director at Omnicom, where he leads the Core Solutions Team, the strategic technology backbone of the group, which is a more interesting job than it sounds on paper. Named to the HotTopics Global CIO 100 in 2026, he has spent over 25 years in technology, starting in consulting where he delivered solutions across telecoms, media, finance, healthcare, and the public sector, before finding that advertising technology offered problems interesting enough to stay for a decade. He speaks on value-driven technology, AI governance and strategic agility, plays padel at an enthusiastic standard, and travels to places with poor mobile coverage by design.
Recently, in an exclusive interview with CIO Magazine, Pablo shared insights into how a career built on “an obstacle removal service with a strategy attached” can outlast technology hype cycles. On AI, he argues it has exposed agile and ITSM as outdated rituals, predicting that real governance won’t come from incumbents but from outside the enterprise software world. He warns that the “best practice” of equating budget with advantage will be obsolete by 2030, since capability is now cheap and talent density wins. His advice to aspiring leaders is to get comfortable being wrong in public, optimize for exposure to hard problems over visibility, and obsess over whether something is worth building before you build it. The following excerpts are taken from the interview.
Hi Pablo. What first drew you into technology 25+ years ago and made you stay for the long haul?
I have a brain wired for logic and am deeply uncomfortable leaving problems unsolved. Technology was the most efficient way I found to feed that particular affliction. You build something, it either works or it does not, and you find out immediately. No ambiguity. No committee. No “let us revisit this next quarter.” Just a result. For someone with my disposition, that is basically therapy.
What I did not expect was how much the field would reward the other half of how I think, the part that gets bored with the known answer and starts looking for a better one somewhere nobody has looked yet. The logical mind is useful for navigating within a system. The interesting work is in questioning whether the system is the right one to begin with. Most people are good at one of those. Very few are comfortable with both. The ones who are tending to cause a disproportionate amount of useful trouble.
What made me stay is simple: I never found the ceiling. Every time I thought I understood how this industry worked, it changed in a way that made my previous understanding look quaint. I expect that to keep happening until I retire, and I am in no hurry to test the theory.
As a Senior Managing Director, Technology Solutions, you set vision, strategy, and execution. What part of that mandate energizes you most when you start your day?
Execution. And I say that fully aware that strategy is the part everyone wants to talk about at conferences.
Strategy is what you do in a room with good coffee, a whiteboard, and no immediate consequences for being wrong. I enjoy it. But enjoyment is not the same as challenge. The real test of whether any of it means anything happens on a Thursday morning when the strategy document is two weeks old, four teams have four different interpretations of what was agreed, and someone needs a decision before lunch. That is the interesting part. That is where technology leadership either quietly proves itself or quietly does not.
I start most days thinking about the one or two decisions that will unblock the most people. Not the most visible decisions. Not the ones that make for good anecdotes at a CIO roundtable. The ones that, if not made, will cause twelve other people to stop moving. After a quarter of a century, I have concluded that the primary job of a technology leader is to be an obstacle removal service with a strategy attached.
Technology cycles are accelerating. How do you see the role of agile and IT service management evolving as AI becomes the default layer?
Let me say something that will not be popular in certain circles: agile, as most organisations practise it, was struggling before AI arrived. The two-week sprint, the daily standup where fifteen people confirm they are still doing what they said yesterday, the velocity chart everyone games. These became rituals organisations performed to feel organised rather than tools that helped them move. AI has not broken agile. It has made it impossible to pretend the current version is fit for purpose.
With agentic AI, the problem becomes structural. An agent does not wait for sprint planning. It acts, triggers downstream processes, and produces consequences at a speed no current governance framework was designed to manage. Applying ITSM thinking to agentic systems is like managing a motorway using the highway code for horse-drawn carriages. Technically still a document about roads. Substantially not the point.
What I find interesting is that the revolution might be so deeply structural that I do not think the solution will come from the people who built the current frameworks. Guy Kawasaki’s point about innovation applies precisely here: the next curve almost never comes from the incumbents on the previous one. They have too much invested in the model they built to be the ones who replace it. My honest expectation is that the new paradigm for governing AI-speed work will emerge from an industry that has nothing to do with enterprise software, and by the time the ITSM vendors catch up, the organisations that figured it out early will have lapped the field.
Best practices are shifting fast. What “best practice” today do you think will feel outdated by 2030?
The belief that large organisations have a structural technology advantage over small ones. For decades, the assumption underlying almost every enterprise technology decision was that scale buys capability. If you had the budget, you got the tools. If you had the tools, you had the edge. That logic is collapsing faster than most large organisations would like to admit.
A two-person startup today has access to AI, cloud infrastructure, and data tooling that would have required a dedicated team and a seven-figure budget five years ago. That barrier has not shrunk. It has essentially disappeared. Enterprise IT spent thirty years treating budget as a moat. The moat is now a puddle. By 2030, capability will be close to free, and what separates organisations will not be who can afford the tools, but who can think more clearly about what to do with them. Which is, inconveniently for most large enterprises, a question of talent density and decision quality rather than purchasing power.
The uncomfortable implication is that the best practices built around technology being scarce and expensive will not merely feel outdated. They will actively disadvantage the organisations still following them while everyone else has moved on. I see both types of organisations from where I sit. The gap is already visible. By 2030, it will be a canyon.
Congratulations on being recognized as one of the 2026 Global CIO 100. Our readers would love to know the secret mantra behind your success.
Thank you, I am delighted. Which makes this an awkward moment to admit I am about to argue with the premise of your question. I do not have a mantra, and I am mildly sceptical of anyone in this industry who does. In my experience, mantras are what people reach for when asked to summarise something that is actually disciplined common sense, because “I consistently ask whether things are worth doing before doing them” does not fit neatly on a slide.
That is, though, genuinely what I do. I am, and colleagues who have worked with me will confirm this without being asked, borderline obsessive about validating that something is worth building before anyone starts building it. Not in a slow, bureaucratic, fourteen-stakeholder-sign-offs way. In a “can someone explain to me in one sentence what problem this solves and for whom” way. That sentence either exists or it does not. You would be startled by how often a six-month project cannot produce it.
The reason this matters more than it sounds is that technology failure is almost never a technical problem. It is three priority problems stacked in a trench coat, pretending to be an engineering issue. The project that runs over budget and under-delivers was usually approved without anyone stopping to check whether the underlying question was right. I have sat in enough post-mortems to know that the question nobody asked at the start is almost always the answer at the end.
The caveat, because I am aware this sounds like a blueprint for never shipping anything, is that I am equally obsessive about speed to market. These are not in conflict. Asking the right question for thirty minutes upfront is what allows you to move fast for the six months that follow. Skipping the question does not save time. It relocates the cost to a point where it is considerably more expensive to absorb.
With a fast-paced, competitive environment, everyone needs a reset. What’s the go-to activity that helps you recharge and gain clarity?
The honest answer is that my most reliable reset is not an activity; it is a person. My daughter is eleven and has recently discovered that she has opinions about everything and that I am no longer automatically right about any of them. This is, I am told, developmentally appropriate. I am finding it character-building in ways no leadership programme has managed to provide. Nothing recalibrates your sense of professional importance faster than losing an argument to someone who cannot yet legally open a bank account.
Then there are my hobbies, which I will list while acknowledging upfront that they sound exactly like the hobbies of a fictional senior technology executive in a magazine profile. I play padel, and I would like it noted that I was playing it in Argentina at university, decades before it became the mandatory sport of every professional with a LinkedIn account. I stopped for twenty years, it became globally fashionable without me, and I have returned at a level best described as committed but no longer dangerous to the opposition. I listen to a great deal of music, spanning a range considerably more interesting than my daughter will acknowledge in public. And I travel, with a strong preference for destinations that require planning to reach and do not have a gift shop in the arrivals hall.
The version of travel I found most restorative was by motorcycle. The logic is simple: when you have only what fits in two panniers and no realistic way to be useful to anyone until the next town with a signal, a quality of thinking becomes available that is not accessible any other way. I keep meaning to get back to it. I have been saying that sentence for longer than I would like to admit, which is either a reflection of how busy things have been or a character flaw I have not fully diagnosed.
Leaders need perspective beyond code and systems. What book, film, or story has shaped how you think about people and collaboration?
I watched WarGames as a child, and it did something very few things have managed before or since: it made computers feel simultaneously dangerous and the most exciting objects in the world. Broderick’s character breaks into a military supercomputer from his bedroom using a home machine and a phone line. To an eleven-year-old in the early eighties, that was not alarming. It was the most compelling advertisement for a career in technology I have ever encountered. Not because I wanted to hack anything, a distinction I feel I should make clearly, but because it showed me that understanding how systems worked gave you access to a world most people could not see. I wanted to be in that world.
What I missed at eleven, and have been coming to terms with ever since, is the other lesson in the film. The one nobody discusses. It is not about the machine. It is about Falken, the man who built it. After a personal catastrophe, he decided the machine’s behaviour was inevitable and walked away. No sabotage, no dramatic exit. He simply stopped considering himself accountable for a system he had designed, moved to an island, and let it keep running without him. The machine was fine with this arrangement. Falken is not a villain. He is something more common and more dangerous: a builder who reclassified his own creation as weather. Something that happens, rather than something he decided.
Which is where I think everyone misreads the film’s famous conclusion. “The only winning move is not to play.” Everyone quotes it. Almost nobody notices that Falken already tried it, years before the story begins, and the crisis nearly happened anyway. Non-participation did not remove him from the game. It removed the one person who understood the system from the room where the system was making decisions. Forty years later, that reading has stopped being film criticism and started being a job description. We are now deploying systems that act autonomously, at scale, with real consequences, and the Falken position, “I built it, what it does next is inevitable”, is quietly becoming a respectable opinion in this industry again. It should not be. Autonomy in the system does not create absence of accountability in the builder. If you designed the system, you have skin in the game whether you acknowledge it or not. Falken’s tragedy is that he believed walking away removed his stake, and the film spends ninety minutes proving him wrong. A 1983 story about a teenager and a supercomputer worked that out before most current AI governance frameworks have.
I also apply that as a hiring criterion. I would rather have someone who cannot stop asking what their work is for, and who considers themselves answerable for what it does, than someone brilliant who stopped asking years ago. The former is occasionally annoying. The latter is eventually expensive.
What is your biggest goal? Where do you see yourself in 5 years from now?
Doing work that is harder than what I am doing now, with people who make me feel like the least impressive person in the room at least some of the time. That is the honest answer. I find rooms where I am definitively the smartest person on the relevant subject both flattering and slightly depressing, because it means the problem has already been solved to the extent that I can see it clearly. The interesting problems are the ones I cannot fully see yet.
More concretely: I want to be leading technology decisions with genuine business consequences at a scale that justifies the effort, and I am increasingly interested in contributing from the board level as well as the executive one. Non-executive board work is an area where technology governance is underpowered. Most boards have learned to ask about cybersecurity, and that is roughly where the digital literacy ends. Someone who has actually run this kind of infrastructure adds something structurally difficult to find elsewhere. That is not a pivot. It is an expansion of where I think I can be useful.
Five years is a long time in this industry, and I have learned not to be too specific about plans that far out. The field has a tendency to reorganise itself around you while you are busy executing the previous plan.
Aspiring professionals often chase tools and titles. What mindset should they build first if they want a 25-year career with impact?
Get comfortable being wrong in public and recovering from it without drama. The professionals I have seen plateau are almost universally the ones who, at some point, decided that protecting the appearance of competence mattered more than developing actual competence. That trade-off looks rational in the short term and is catastrophic over a twenty-five-year horizon.
The ones who go furthest figured out early that “I do not know, let me find out” is a power move, not an admission of weakness. It signals you are more interested in the right answer than in being seen to have the right answer. At senior levels, that distinction is visible to everyone in the room, and it separates people who are genuinely useful from people who are merely impressive.
The other thing I would say, and this is more controversial than it sounds: stop optimising for visibility and start optimising for exposure to hard problems. The high-profile project where everything goes well and everyone gets photographed at the launch is fine. The operational disaster nobody wanted to own, that you volunteered to fix, where you spent six months learning how things actually fail and who actually keeps them running, that is the one that builds a career. Almost everything I know came from the assignments I initially did not want. The ones I was excited about at the start rarely taught me anything I did not already know.