Late one evening in the tiny village of Cong in the west of Ireland I was enjoying a glass of Green Spot with Damian Costello.
We were talking about why so many technology projects fail - and why the failures are so predictable. Damian has spent thirty years consulting in complex systems.
His point was simple: you cannot, for any sustained period, defy the reality of the system you're operating in.
Human nature, economics, politics, organisational inertia - these forces don't care how clever your solution is.
I live in a small surfing village on the Atlantic coast, and Damian used a metaphor I loved: leadership is like surfing.
You cannot impose your will on the ocean.
You have to read the currents and move with them.
The currents he meant were technological, social, political and economic. They included what people believe, what they're afraid of, what they're motivated by.
And if you try to push against all of that because you think your solution is clever enough to override reality - you might get lucky for a while. But eventually, the system wins.
The Three Circles
Damian drew a Venn diagram on a napkin with 3 overlapping circles:
Leadership. People. Technology.
Most technology work happens in the non-overlapping part of the technology circle. People try to solve problems by looking only at the tech.
They're good at what they do - but they can't affect real change because they're ignoring the other two circles entirely.
If you want to influence a system, you need to own all three.
- Authentic engagement with leadership - what the business could and should be aiming for.
- Understanding people - their motivations, their resistance, what they're actually afraid of.
- Only then does the technology piece fall into place.
When you get all three right, the solution almost falls out on its own.
Solutions are rarely the problem. The problem is the politics, the misaligned motivations, the conditions that were never set up properly in the first place.
The Fragility
This is where I pushed back a little.
These systems are inherently fragile.
You can build a proof of concept that looks amazing. It does exactly what you want. Everyone's excited. And then you try to take it to production - and suddenly it's far more complex than anyone expected.
Credentials expire. Authorisations don't transfer. The person who set up the integration leaves. The API changes. One system thinks the user has access; another system disagrees. What worked perfectly in the demo environment falls apart in production.
This gap is almost impossible to explain to the people who control the budgets.
Damian agreed, but his point was that the people who formulate budgets don't see that level of granularity.
It's filtered through their vendors. And their own internal people have been taught to think the same way.
You can't rely on your own team to be objective - because they've been trained by the same system that's selling to you.
This explains something I've seen repeatedly: organisations where the internal technology team genuinely can't see the problem, because they've been conditioned to see through vendor-shaped lenses.
The "Dentist Rule"
Damian told me his number one lesson from thirty years of consulting: never answer a question you haven't been asked.
The key is figuring out how to get them to ask the right question in the first place.
He used this analogy: you're the best dentist in town, walking down the street. A parent is coming toward you with their child, and you can see the child's teeth are a disaster. If you walk up and say so - unsolicited - you're the one who's going to have the problem.
Then we take the same dentist.
But if that parent walks into your clinic and says, "We're worried about her teeth - what can we do?" - now you're trusted. Now you can help.
The difference isn't politeness vs. impoliteness.
It's their awareness of and readiness to discuss the issue.
What This Looks Like in Practice
A few months before that conversation, I'd been working with a blood testing lab.
They have highly trained scientists running critical diagnostic tests. Their expertise mattered. Their time was expensive.
And they were spending hours every day typing handwritten data into spreadsheets.
When I asked why, the answer was familiar: "That's how the system works."
The changes I suggested we make were narrow and surgical. Smart data capture with a tiny custom solution. Automated validation with another.
Processing time dropped by 92% per sample. The lab gained 12x more capacity without hiring anyone. And the highly trained scientists were able to spend more time on science.
The investment for that initial build was miniscule - only €2,500, and their first-year savings exceeded €250,000.
Those numbers only made sense after the inefficiency became visible. Before that, everyone assumed complexity was inevitable.
They'd been told - by vendors, by their own systems, by years of accumulated habit - that this was just how it worked.
They were wrong about which parts of reality were fixed and which parts were just… never questioned.
That project was on my mind when Damian and I talked.
What This Means for Leaders
If you're leading a team through AI adoption, you're probably feeling two things at once.
- First: pressure to move fast. Everyone's talking about AI. Competitors are making claims. Your board wants a strategy.
- Second: suspicion that something's off. The pilots don't scale. The integrations break. The ROI projections feel optimistic. Your own team seems confident, but you're not sure they're seeing the full picture.
The currents, the fragility and the conditioning - the vendor-led thinking that makes it hard for anyone inside the system to see clearly - are all real.
The way through is to step back and see all three circles: what leadership is trying to achieve, what people are motivated by, and only then - what the technology can do.
As Damian put it in Cong: "Someone needs to stand with the client and say, 'We're on your side. We're going to add value. And we're going to be honest about what's actually happening.'"
I'd be glad to hear from you. I'm at [email protected]
Damian's point matters most for trust, which I took further in who gets the time AI saves. The project version of it is ROI before code.