The Technology Is Not the Hard Part. The System Change Is.
Why established organizations keep adopting new technology without changing anything that matters.
I spent the first twenty years of my working life inside large and medium-sized companies trying to build new businesses. Not maintain them. Not optimize them. Build new ones, from inside organizations that were already successful at something else.
I was good at finding the opportunity. I was persistent about making the case. And I kept running into the same wall, dressed in different clothes depending on the company. Internal friction that had nothing to do with whether the idea was sound. Decision rights that sat with people who had no interest in the outcome. Pilots that went well and then quietly disappeared. C-level executives who used the language of transformation in every presentation and then protected their position in every actual decision. Endless alignment meetings that produced nothing but the next alignment meeting.
Eventually I stopped trying to innovate inside established organizations and went to work with startups instead. Not because startups are perfect. They have their own dysfunction. But the dependencies are different. The resistance is different. When something needs to change, it can actually change.
What I did not expect was that leaving the corporate world would give me a cleaner view of it. Because once I was on the outside - as a founder, as a consultant, as someone trying to sell something genuinely new to established companies - I could see the pattern more clearly than I ever could from the inside.
The problem is not that established organizations lack ideas, ambition, or access to good technology. The problem is that they were built to extend what already works, and that structural fact shapes everything that happens inside them, including how they respond to technology that genuinely requires something to change.
How the system was built and why it works the way it does
A mature company has added people to teams, teams to departments, departments to business units, and reporting lines to manage the growing complexity. It has standardized how work moves from top to bottom, how information moves from bottom to top, and how market signals are collected, filtered, translated, approved, and turned into action. It has created processes for everything that can be repeated, documented responsibilities, defined handovers, installed governance routines, and built dashboards.
This is not stupidity. For the core business, this logic is genuinely useful. A company that cannot repeat what works has no business. Standardization reduces variation, creates reliability, makes scale possible, and allows leaders to compare performance across teams and markets. The current business needs control, and control requires structure.
The problem starts when the same system is asked to create the next business. O’Reilly and Tushman’s research on organizational ambidexterity, one of the most cited bodies of work in organizational theory, describes the tension precisely: exploitation - the mode established companies are built for - is about efficiency, control, certainty, and variance reduction. Exploration - what building a new business requires - is about search, discovery, autonomy, and embracing variation. The two modes require conflicting structures, resources, and decision rights inside the same organization. The research shows that the dominant logic of the established business consistently crowds out the conditions exploration needs to function.
Exploration does not behave like execution. A new business model is not a process improvement with a nicer name. It starts with uncertainty. You do not yet know whether the customer cares, whether the problem is painful enough, whether willingness to pay exists, or which assumption will break first. That makes exploration deeply uncomfortable for organizations built around predictability. So they apply the same governance to uncertainty that they apply to certainty. They ask for business cases before the business is understood. They ask for alignment before the evidence exists. They ask for scalability before there is proof of demand. Then everyone wonders why reinvention feels slow, political, and strangely performative.
And when the system still cannot process ambiguity on its own, the answer is usually another meeting. Meetings are not the work in these organizations. They are the repair mechanism for a system that cannot handle what it was not designed to handle.
Where AI makes the contradiction impossible to ignore
I see many companies framing AI through the easiest available question: where can we replace human workload with automated work? That is a valid question. It is also a narrow one. Using AI to summarize documents, draft emails, search internal knowledge, support customer service, or generate reports can be genuinely useful. It reduces workload. It improves speed. It removes low-value effort from people’s day. There is nothing wrong with any of that.
But task automation is not reinvention. It is the easiest form of adoption precisely because it does not disturb the system. The same team stays responsible. The same process stays in place. The same decision rights remain untouched. The same customer promise remains unchanged. The work becomes faster or cheaper, but the underlying logic keeps running.
The harder question is different: what part of the system has to change for this technology to matter beyond efficiency?
That is where things become uncomfortable. Because once AI is no longer used only as a productivity layer, it starts asking harder questions that the system would prefer not to answer. Why does this approval step still make sense? Why does the customer wait three days for something that could be resolved in three minutes? Why is the business model still priced around effort if effort is no longer the scarce resource? Why does expertise sit in one role when the system could distribute it differently?
At that point, AI is no longer just a tool. It becomes a challenge to the operating model and to the people whose authority depends on the operating model staying the way it is.
Three levels of adoption, and why most companies stop at the first
I find it useful to distinguish between three levels of what actually happens when a company adopts new technology, because conflating them is how organizations convince themselves they are transforming when they are not.
