Istartedmycareerasanengineer.
At the time, I expected technology itself to be the interesting part. What ended up being more interesting was everything around it: how organizations make decisions, why good ideas fail to get implemented, how teams build capabilities, and what actually has to change for technology to create value.
That pulled me into consulting, digital transformation, technology, data, and eventually product and AI work.
The progression looks relatively logical in hindsight. It was less deliberate while it was happening.
What stayed consistent was the kind of problem I enjoyed working on.
Problems that were still ambiguous. Problems that crossed functional boundaries. Problems where there was no obvious answer and where understanding the system mattered more than optimizing one isolated part of it.
Over the years, I have worked across transformation strategy, operating models, analytics, digital products, technology capabilities, commercial development, and team leadership.
I have built methodologies and teams, worked through large transformation programs, designed analytical decision systems, and helped develop technology-enabled products.
What I enjoy most is still the point where strategy has to become execution.
A strategy can be perfectly reasonable and still fail once it meets data limitations, incentives, existing systems, organizational politics, user behavior, or simply the reality of how work gets done.
That gap interests me.
It is also why I tend to get involved beyond the recommendation itself.
I want to understand what has to be built, what decisions have to change, what capabilities need to exist, and what would make the solution continue working after the initial project is over.
How I think about technology
I don't see technology as a separate layer of the business.
The interesting questions are usually not:
What can we do with this technology?
They are closer to:
What could we do differently because this technology now exists?
That distinction becomes particularly important with AI.
It is now remarkably easy to build something that looks intelligent.
Building something people can trust, integrate into their work, and continue using is a different problem.
It requires product thinking, workflow design, data, validation, ownership, and often changes to the way the organization operates.
That is the part I find interesting.
Building
I learn best when I am close to implementation.
Sometimes that means designing a product or analytical system. Sometimes it means getting into architecture, workflows, prototypes, or the details of how a capability should operate.
I don't need to be the deepest technical specialist in every room.
I do want to understand a system well enough to ask the right questions, challenge assumptions, and connect technical decisions back to the business problem they are supposed to solve.
Building things is also how I test ideas.
It is easy to have strong opinions when they never have to survive implementation.
What I am interested in now
I spend most of my time thinking about a few connected questions:
- 01How will AI change the way organizations operate?
- 02What does good technology leadership look like when the cost of building software continues to fall?
- 03How do you design organizations that can move from experimentation into repeatable execution?
- 04And how do you build systems that improve decisions rather than simply generate more information?
I don't have final answers to most of those questions.
That is part of why I keep working on them.
Martin CervantesTechnology · AI · Transformation