A Completely Rational Life Decision
Let me paint you a picture. It's a perfectly good stretch of days off. The sun is out. A beach exists somewhere. And what did I do? I spent two personal leave days attending the Spain Innovation Summit instead of going on holiday.
Truly, the stuff of legend.
Look, I'm not going to tell you it was the best possible use of those days. I'm also not going to tell you I wasted them. The truth, as it so often is, sits somewhere in the uncomfortable middle: I came back slightly tired, mildly overstimulated, and with a notebook full of ideas that I've been chewing on ever since.
So here's my honest debrief from two days spent thinking about innovation, AI, and why most companies are still fumbling both of them.
Innovation Is Not a Vibe, It's About Reducing Uncertainty
The first mental model that stuck with me reframes what innovation actually is. We tend to romanticize it, the eureka moment, the disruptive leap, the genius founder sketching the future on a napkin. But the more grounded definition offered at the summit was much more useful in practice:
Innovation is the systematic effort to reduce uncertainty.
Not eliminate it, that's impossible, and anyone who promises you otherwise is selling something. But reduce it, deliberately, with each experiment, each prototype, each small bet you place. That reframing matters because it turns innovation from a mysterious art form into something you can actually manage.
And managing it requires understanding what kind of engine you need at any given moment.
The Two Engines Every Company Needs Running Simultaneously
Here's the uncomfortable truth about mature organizations: the same thing that makes them good at what they do today is exactly what prevents them from being good at what they'll need to do tomorrow.
The exploitation engine is the one that pays the bills. It optimizes existing processes, serves existing customers, and scales what already works. It is very good at saying no to anything that doesn't fit the current playbook, because that's literally its job.
The exploration engine is the one that keeps the company alive in five years. It runs experiments, tolerates failure, and looks for asymmetric bets. It is very good at saying yes to things that don't yet have a proven ROI, because that's also its job.
The trap most companies fall into is thinking these two engines can share the same driver. They can't. They run on different fuels, reward different behaviors, and measure success on completely different timescales. Companies that figure out how to run both simultaneously, without letting one strangle the other, are what strategists call ambidextrous organizations. They're rare. They're also the ones that tend to outlast everyone else.
Three Modes of Innovation (and When to Use Each)
- Optimize the existing: Incremental improvements to your current core. Faster, cheaper, less broken. Not glamorous, but it funds everything else. Most companies are only doing this and calling it innovation.
- Expand: Take what's working and push it into adjacent markets, customer segments, or geographies. Lower risk than starting from scratch, higher upside than standing still. This is where most growth actually happens.
- Explore: True bets on uncertain futures. New business models, new categories, new technologies. High failure rate by design. The key is not to bet the company on a single exploration, you run many small ones and see what survives.
Copy With Style, and Other Honest Advice
One of the more refreshingly candid pieces of advice: start by copying with style.
It sounds almost too simple, but the logic is solid. Before you can truly innovate, you need to understand the landscape well enough to know what's already been solved. Copying what works, adapting it, adding your context, your brand, your specific customer insight, is a legitimate and often underrated starting point.
The adjacent point was equally useful: move one square at a time. The matrix that captures this goes from improving your current business → adjacent growth → transformational bet. Each step to the right multiplies both potential upside and potential failure. Jumping straight from the first square to the third without building the muscle in between is how well-funded companies make spectacular, expensive mistakes.
There's a certain humility required to accept that "let's do what they did, but better and for our customers" is a valid innovation strategy. Most leadership teams are too proud to say it out loud. The ones who do tend to move faster.
The Hardest Part Isn't the Technology, Jorge Blasco on People
Jorge Blasco gave what was, for me, the most grounding talk of the event. Not because it was the most technically sophisticated, but because it was the most honest about where transformation actually breaks down.
The central argument: people are simultaneously the most critical and the most underestimated variable in any innovation effort.
We spend enormous amounts of time debating which AI tool to buy, which cloud vendor to pick, which architecture to implement. And then we hand the result to a team that wasn't involved in designing it, doesn't understand why it's changing their workflow, and has every incentive to quietly route around it. The technology works perfectly in demos and fails quietly in production, not because of bugs, but because of humans.
Blasco's point wasn't that people are the problem. It's that they're the solution, and they're only the solution if you treat them that way from the start.
The skills gap is real but teachable. What's much harder to develop in someone who doesn't already have it is the right attitude toward change.
Blasco broke this down into concrete traits that distinguish people who become engines of innovation from people who become sources of organizational friction:
- Proactivity: Not waiting to be told where the problems are. Seeing friction, naming it, and proposing solutions before it becomes someone else's crisis.
- Intellectual curiosity: The genuine desire to understand how things work, and how they could work better. This isn't a personality type, it's a practice. But it needs to be cultivated, not assumed.
- Tolerance for ambiguity: Innovation, by definition, involves working on things that don't have clear answers yet. People who need certainty before they act are genuinely less useful in exploratory contexts, not because they're bad, but because they're mis-deployed.
- Willingness to experiment and fail small: The organizations that innovate fastest are the ones where people feel safe trying things that might not work. That safety doesn't come from policy documents. It comes from how leadership actually reacts when something fails.
The uncomfortable implication: if the people you work with doesn't have these traits, no tool, no AI platform, and no transformation roadmap will save you. You fix the culture first, or you fix it forever.
The summit framed this topic in a way that I think is genuinely underused in how we talk about AI transformation. Most discussions operate on two levels: the software (the models, the apps, the platforms) and the hardware (the infrastructure, the compute, the cloud). These are the levels that vendors talk about, that procurement teams evaluate, and that IT roadmaps are built around.
But there's a third level that determines whether the first two matter at all: wetware.
Wetware is the biological layer, the humans. Their cognitive models, their habits, their mental frameworks, their willingness to change how they think about their work. It's the hardest layer to upgrade and the one that gets the least investment in most transformation programs.
Here's the pattern that plays out constantly: a company buys excellent software, runs it on solid hardware, and then discovers that the wetware, the people, haven't changed how they operate at all. They use the new tools to do the old things in slightly different ways. The transformation stalls not because the technology failed, but because the humans weren't actually part of the redesign.
True transformation requires all three layers evolving together. Upgrade the software without upgrading the wetware and you get expensive shelfware. Upgrade the wetware without the software and you get capable people stuck with inadequate tools. The organizations that get it right treat human development and technological deployment as a single, integrated program, not two separate workstreams that happen to share a budget line.
Innovation-oriented people are often harder to work with than execution-oriented ones. They push back on constraints. They get bored of repetitive work quickly. They have strong opinions about the direction of things. In a pure exploitation environment, these traits are liabilities. In an exploration environment, they're your most valuable assets.
The job of leadership in an ambidextrous organization is knowing which mode you're in at any given moment, and matching your management approach to it. Applying execution management to exploration teams kills innovation. Applying exploration management to execution teams creates chaos. Both are expensive mistakes that happen constantly.
The conclusion: Working with people who are capable of innovation isn't a nice-to-have. It's the prerequisite for everything else on this list.
Applying AI to the Enterprise, The Three Pillars
The second major thread of the summit moved from innovation theory into something more concrete: how do you actually integrate AI into a business without making a mess of it?
The framework that structured most of this discussion rests on three interdependent pillars, and the word interdependent matters, because the single biggest mistake organizations make is treating them as independent:
The three pillars of real AI transformation
| Pillar | What it means | Where most companies fail |
|---|---|---|
| People | The humans who will use, interpret, and be changed by the AI systems. Their skills, mindset, and buy-in determine whether the tools get used or ignored. | Treating this as a training problem. It's a cultural and organizational design problem. You can't train your way out of the wrong incentive structure. |
| Processes | The workflows, decision points, and information flows that AI will touch. The design of these determines whether AI adds value or just adds noise. | Digitizing broken processes. If a process is bad, making it faster with AI makes it fail faster. Transformation means redesigning, not just automating. |
| Technology | The models, platforms, infrastructure, and integrations that make AI capabilities available in the right places at the right time. | Buying the technology first and figuring out the use cases later. The tool should follow the problem, not the other way around. |
This Is Not a Headcount Reduction Story
Let's address the elephant in the room, because it came up repeatedly: AI transformation is not a euphemism for firing people.
Or at least, it shouldn't be, and the organizations treating it that way are almost certainly doing it wrong.
The logic here is straightforward once you think it through. If you implement AI primarily to reduce headcount, you're optimizing for cost reduction in the short term while hollowing out the organizational capacity you'll need to adapt in the medium term. You're trading future optionality for current savings. That's a trade that looks great in a quarterly presentation and looks terrible in five years.
The more productive framing, and the one that aligns with what Jorge Blasco said about people: AI should free your people from low-value work so they can do more high-value work. The goal isn't fewer people, it's better-deployed people. People who spend less time copying data between systems and more time making decisions. Less time formatting reports and more time interpreting them. Less time chasing approvals and more time designing better workflows.
The organizations that get this right don't announce AI initiatives alongside redundancy rounds. They announce them alongside upskilling programs and role redesigns.
The Process Problem, Why "Just Add AI" Doesn't Work
This was one of the most important points of the summit, and it's worth dwelling on because it's where the most money gets wasted.
The instinct, when faced with a slow or painful process, is to put AI on top of it. Automate the steps. Add a chatbot. Run an LLM over the inputs. And sometimes that helps, but very often, it doesn't. Because the problem wasn't the speed of the process. The problem was the design of the process.
A bad process, digitized, is a digital bad process. It's now just failing faster, at scale, with fancier error messages.
Real process transformation means asking harder questions before touching any technology:
- Why does this process exist in its current form? Usually the answer involves a historical constraint that no longer applies.
- What decisions is this process actually enabling, and do those decisions need to be made this way? Often the answer is no.
- Where is information being entered multiple times, translated between systems manually, or lost in handoffs? These are the actual pain points, and they're usually not where people think they are.
- What would this process look like if we designed it from scratch today? Almost always radically different from the current version.
Only after working through these questions does it make sense to ask which AI capabilities would make the redesigned process better. The technology comes last, not first.
When Data Becomes Feedback Instead of a Mirror
One of the cleanest insights of the event: most organizations use data as a mirror, they look at it to understand what already happened. The real transformation happens when data becomes feedback, it tells you what to do next.
This is not a subtle distinction. A mirror shows you the past. Feedback shapes the future. The difference in how you design systems around each use case is enormous.
A data system built to be a mirror produces reports. It tells you last quarter's revenue, last month's churn rate, last week's production throughput. It's useful for understanding history and presenting in meetings.
A data system built to give feedback does something different. It watches the present, detects deviations from expected patterns, and surfaces the right information to the right person at the right moment, early enough to actually act on it. It doesn't wait to be queried. It speaks up when it has something to say.
The practical shape of this feedback system was captured in four verbs: Alert, Ask, Recommend, Correct. An AI-powered process doesn't just report, it notices when something is off and flags it (Alert), asks clarifying questions when it needs context (Ask), proposes a course of action based on available data (Recommend), and adjusts automatically within defined parameters when the answer is clear (Correct).
The Anatomy Metaphor, or: Are You Using AI as a Crutch?
The most memorable framing of the entire summit came in the form of an anatomy metaphor, and it's one I've been using in conversations ever since.
The question it answers is deceptively simple: what kind of relationship does your organization have with AI right now?
Most companies, if they're being honest, are using AI as a crutch. A crutch is useful. A crutch genuinely helps you move when you otherwise couldn't. But a crutch doesn't change how you walk, it compensates for something that isn't working, it doesn't transform how you move through the world. You're still fundamentally operating the same way; you just have something to lean on.
The alternative, the goal, is AI as an exoskeleton. An exoskeleton doesn't compensate for weakness. It amplifies capability. It lets you carry more, move faster, maintain precision over longer periods. You're still the one driving it, your brain, your judgment, your intent, but the ceiling of what you can accomplish is completely different.
Most AI deployments today are crutches dressed up in exoskeleton marketing. The difference isn't in the technology. It's in the depth of integration and the willingness to actually redesign how work gets done around the capability.
Extending the metaphor: if AI is the exoskeleton, what does it actually augment? The answer maps surprisingly well onto human anatomy. Each biological system has a functional equivalent in an AI-augmented organization, and understanding these mappings helps clarify which capabilities you're actually building when you invest in AI.
The brain, the one thing that is always human, is judgment and criteria. AI can inform decisions, surface options, flag risks, and model outcomes. It cannot and should not replace the human act of deciding. Organizations that forget this end up with automated systems making consequential choices with no one accountable for the outcome.
| Biological system | Organizational function | AI capability that maps to it |
|---|---|---|
| 🧠 Brain (judgment) | Strategic decision-making, ethical reasoning, contextual interpretation | Always human. AI informs, humans decide. |
| ⚡ Nervous system | Information flow between processes, departments, and systems in real time | Integration layers, event-driven architectures, real-time data pipelines that connect what used to be isolated silos |
| 👁️ Senses | Early detection of signals, anomalies, opportunities, threats, before they become obvious | Monitoring systems, anomaly detection, predictive alerting that catches problems when they're still cheap to fix |
| 🧬 Memory | Accumulated organizational context: what was tried, what worked, what customers said, what the data showed | Knowledge bases, retrieval-augmented generation, institutional memory that grows more accessible over time instead of less |
| 💪 Muscle | Execution capacity, the ability to coordinate and complete tasks at scale with minimal friction | Workflow automation, agentic AI systems that can take multi-step actions, orchestration layers that reduce operational drag |
| ⚙️ Reflexes | Operational feedback, fast, automatic responses to known deviations that don't need human review every time | Automated corrective actions within defined guardrails, closed-loop quality systems, real-time process adjustments |
| 🦴 Skeleton | Governance, traceability, compliance, the structure that makes everything else auditable and trustworthy | Audit logs, explainability layers, data lineage tracking, model monitoring, the boring stuff that makes the exciting stuff safe to deploy |
So, Was It Worth Two Days of Leave?
Grudgingly: yes.
Not because any single idea was revelatory. Most of what was said at the Spain Innovation Summit I had encountered in some form before, in papers, in conversations, in the slow accumulation of pattern recognition that comes from working in this space. But there's something valuable about hearing ideas spoken aloud, in context, by people who are dealing with the same organizational realities you are.
The things I'm carrying forward:
Innovation is a discipline, not a personality trait. It can be managed, structured, and systematically improved, but only if you're honest about which engine you're running at any given time, and whether your people are actually equipped to run it.
The three pillars aren't decoration. People, processes, and technology fail independently all the time. The rare thing, the actually hard thing, is getting all three moving in the same direction simultaneously. Most transformation programs pick one and hope for the best.
The crutch vs. exoskeleton distinction is the most useful diagnostic I've found for evaluating AI implementations. Ask yourself, honestly: is this making us fundamentally more capable, or is it just making a broken thing slightly less painful? The answer determines whether you're building something durable or buying yourself six months of runway before the same problems resurface.
And the brain is always human. Judgment, criteria, accountability, these don't get delegated to a model. The exoskeleton amplifies. The human decides. Lose that distinction and you don't have an AI strategy, you have a liability.
Would I skip vacation again for this? Ask me next year when I've actually had a holiday.