Introduction
Over the course of this series, I have discussed lifecycle gaps, complexity, capabilities, AI, aftermarket learning, value flows and decision making.
Most of those topics were presented as observations.
Patterns I have seen repeatedly. Problems I have encountered across organizations. Lessons that emerged from successful and unsuccessful transformations.
But perhaps it is time to acknowledge something.
None of these ideas appeared in a conference room. None of them emerged from a framework. And none of them started as a theory.
They emerged from experience.
From spending years moving between engineering, sales, service, digitalization initiatives, architecture discussions and executive conversations.
Looking back, I realize that the way I think about transformation today is very different from how I thought about it when I started my career.
And that evolution may be one of the reasons I write this series at all.
I Started With Technology
Like many people in engineering and product development, I began by focusing on technology.
The questions felt obvious.
How do we improve engineering? How do we structure product information? How do we manage complexity? How do we select the right system? How do we improve development efficiency?
These were important questions. And in many cases they still are.
But over time I started noticing something that confused me.
The most difficult business problems rarely behaved like technology problems.
A new system often improved part of the situation. Yet somehow the underlying challenge remained.
At first I assumed the implementation had failed.
Later I started suspecting that the diagnosis had failed.
Those are very different explanations.
The Organizations Were Full of Smart People
One observation repeatedly challenged my assumptions.
Most organizations were filled with highly capable people.
The engineers were smart. The sales teams were smart. The service organizations were smart. The management teams were smart.
Yet the organization still struggled.
This was important. Because it forced me to stop blaming competence.
If intelligent people across multiple departments are all working hard and still encountering the same frustrations, the problem is probably not individual capability.
The problem is more likely systemic.
That realization fundamentally changed how I look at transformation.
The Space Between Functions
One of the biggest lessons I learned was where many problems actually live.
Not inside functions. Between them.
Engineering knew things that sales needed. Sales knew things that service needed. Service learned things engineering needed.
Information flowed. But often not effectively.
The organization was full of knowledge. Yet critical insights struggled to move.
What fascinated me was that every function could be performing reasonably well. And the company could still underperform.
The weakness often existed in the connections. Not the components.
That observation eventually became the foundation for what I later started calling the Product Lifecycle Gap.
I Stopped Looking for Silver Bullets
During the early years, I was probably as susceptible as anyone else to the promise of the next solution.
The next platform. The next architecture. The next methodology. The next transformation framework.
Over time, however, reality became difficult to ignore.
I saw organizations succeed with imperfect technology. I saw organizations struggle with excellent technology. I saw expensive programs deliver modest results. I saw surprisingly small initiatives create enormous impact.
The common factor was rarely the tool itself.
It was usually how well the organization understood the problem it was trying to solve.
That realization made me much less interested in solutions. And much more interested in diagnosis.
The Power of Better Questions
If there is one thing that has changed most dramatically over my career, it is the questions I ask.
Earlier in my career I often asked:
- Which system should we implement?
- Which process should we improve?
- Which technology should we choose?
Today I am more likely to ask:
- Which capability are we trying to build?
- Which decision are we trying to improve?
- Where is value being lost?
- What information is missing?
- Which assumptions are we making?
- What happens elsewhere in the lifecycle if we change this?
The interesting thing is that better questions often create better answers long before any technology discussion begins.
Transformation Is Mostly About Learning
Another lesson took me much longer to understand.
I used to think transformation was primarily about change.
Now I increasingly think it is about learning.
Organizations do not become successful because they change once. They become successful because they learn continuously.
Every change eventually becomes outdated. Every system eventually becomes old. Every process eventually needs adaptation.
Learning is what allows organizations to keep moving.
When I look at the companies that consistently outperform their peers, I often see one common characteristic.
They learn faster.
Not because they are smarter. Because they are better at converting experience into decisions.
Why I Became Interested in Capabilities
For many years I focused heavily on systems.
PLM. Configuration management. Engineering IT. Product structures. Architecture.
Those areas remain important. But eventually my attention shifted.
I became more interested in what organizations were capable of doing.
Two companies might own similar technologies. Yet produce radically different outcomes.
Why?
The answer was usually not hidden inside the software. The answer was hidden inside capability.
One organization had developed a stronger ability to make decisions, coordinate activities, manage complexity, learn from experience and govern product knowledge.
Technology enabled those capabilities. But the capabilities themselves created the value.
Why AI Reinforced These Beliefs
The arrival of AI has only strengthened many of these observations.
Initially, the discussion centered around data, models, algorithms and platforms.
Over time the conversation started resembling earlier transformation waves.
The same assumption appeared again.
If we introduce enough technology, performance will improve.
Yet AI continues revealing the same reality.
Organizations struggle less because they lack information. They struggle because context, ownership, accountability and decision logic are often unclear.
AI did not create those issues. It simply made them easier to see.
Which is one reason I find AI fascinating. It exposes organizational thinking. Not just technology.
Transformation Is a Leadership Discipline
Perhaps the biggest shift in my thinking is where I believe transformation actually belongs.
Earlier in my career, I would probably have described transformation as a technology discipline.
Today I see it as a leadership discipline.
Technology matters enormously. But leadership determines:
- What matters
- What gets measured
- What gets prioritized
- What gets funded
- What gets governed
- What gets learned
And ultimately those decisions shape the organization far more than any specific platform.
The best transformations I have witnessed were not technology-led. They were leadership-led.
Technology simply amplified the direction that leadership had already established.
What I Believe Today
After more than two decades in this space, my thinking can probably be summarized fairly simply.
I believe organizations create value through decisions.
Those decisions depend on capabilities. Capabilities depend on information. Information depends on context. Context depends on relationships. And relationships exist across the lifecycle.
Which means most business performance problems are larger than the systems that appear to contain them.
That perspective shapes almost everything I do today.
How I evaluate technology. How I think about transformation. How I approach architecture. How I think about AI. And ultimately, how I think about leadership.
Final Thoughts
When I started my career, I thought understanding technology would be enough.
Today I think technology is only one part of the story.
The more experience I have gained, the more interested I have become in how organizations learn, decide and create value across the entire lifecycle.
Because that is where competitive advantage increasingly emerges.
Not from individual systems. Not from individual departments. Not even from individual decisions.
But from how effectively all of those things work together.
That insight has taken me many years to develop. And it continues to evolve.
Which is perhaps the most important lesson of all.
Transformation is not a destination. It is an ongoing
process of learning how the business actually
works.
And learning, in my experience, is where meaningful transformation always begins.