Imagine you are building a house. You hire electricians, plumbers, framers, roofers, drywall crews, HVAC technicians, and dozens of other specialists, each skilled at something different. Nearly all of them will arrive with a drill. The electrician may prefer Milwaukee, the plumber DeWalt, the framer Makita, and someone else will show up with Bosch or Ryobi.
As the homeowner, you almost certainly do not care. You care whether the lights turn on, the toilet flushes, the walls are straight, and the roof keeps the rain out. You care that the house is built correctly, on time, and at a reasonable cost. The drill matters to the tradesman. The outcome matters to you.
I think this distinction explains much of what has gone wrong in the conversation about AI inside companies.
AI is the drill
Businesses are spending an extraordinary amount of time debating tools. Which model should we use? Should we standardize on Microsoft or Google? Should employees have ChatGPT, Claude, Gemini, or Copilot? Which agent platform should we choose, and which AI features should we switch on in the software we already own?
These questions are not irrelevant. Tradesmen care about their tools for good reason, because tools differ in capability, cost, limitation, and appropriate use. But consider hiring a general contractor to build your house and spending the first meeting deciding which brand of drill everyone will use. You would eventually ask the obvious question: what exactly are we building?
That is the question businesses need to return to. AI has dramatically changed what can be built, how quickly it can be built, and what it costs. It remains a tool. Nobody needs an AI strategy for the same reason nobody needs a Milwaukee strategy. What they need is a strategy for improving the business, with the appropriate tools following from it.
The trades are not the problem
A house requires plumbers, electricians, framers, roofers, engineers, and architects, each contributing specialized expertise. Business modernization has an equivalent set of trades: software development firms, AI consultancies, change management practices, data consultancies, cloud specialists, cybersecurity firms, process improvement experts, workforce consultants, strategy firms, systems integrators, and managed service providers.
Many of these firms are exceptionally good at what they do. That is not where the difficulty lies. The difficulty is that the homeowner does not want plumbing. The homeowner wants a house. In the same way, businesses do not fundamentally want application development, AI implementation, change management, cloud migration, or data modernization. They want outcomes: onboarding that takes five days instead of thirty, revenue that doubles without headcount doubling, higher manufacturing throughput, better customer retention, less administrative work, a smoothly integrated acquisition, lower operating cost, or a product that reaches market sooner.
Any of those outcomes may require several trades and several tools. Someone has to decide which ones.
Every tradesman sees the house through their trade
The old saying about a hammer and a nail has a consulting version. Ask a software development firm how to modernize your business and it will reasonably discover opportunities involving software. An AI consultancy will find opportunities for AI. A change management firm will see adoption challenges, and a workforce consultancy will see workforce opportunities.
None of them is necessarily wrong. A meaningful modernization effort may well require new technology, redesigned processes, different roles, cleaner data, new skills, and significant organizational change all at once. The customer is nonetheless left holding a difficult problem, which is that nobody is looking at the whole house.
There is also an incentive problem
Suppose a roofing company knocks on your door and offers a free inspection. It may be an outstanding company, and its people may be entirely ethical. Your roof may genuinely need work. Even so, the person deciding whether you need roofing work is also paid when you buy roofing work. Your interests overlap with theirs without being identical. You want the best possible house for a reasonable cost, and they earn their living when customers buy roofs.
Technology consulting has the same structural tension. The application development firm benefits when there is application work to do, the systems integrator when there is implementation work, the change consultancy when there is change work, and the AI consultancy when there are AI projects. This is not an accusation of bad behavior. It is simply how the business model works. A firm's natural incentive is to increase profitable spending on the capabilities it sells, while the customer's incentive is to minimize the resources required to achieve the greatest improvement.
Construction solved a version of this problem long ago, by creating a role that answers to the owner.
Someone has to represent the owner
A general contractor does not need to be the best electrician on the site. They do not install every pipe, manufacture the lumber, or make the drills. Their job is to understand what the owner is trying to build and then determine what work is required, in what sequence, with which capabilities, and with which dependencies. They coordinate the trades, challenge estimates, manage sequencing, surface problems, monitor progress, and make tradeoffs so that one contractor does not create a problem for another. Ultimately they are accountable for turning a collection of specialized activities into the thing the owner wanted.
Most importantly, the general contractor works for the owner.
Businesses increasingly need the equivalent for modernization: someone on their side of the table who asks what the organization is actually trying to improve and what prevents it today. That person asks whether the problem is worth solving and what the smallest intervention would be that meaningfully improves it. They ask whether technology is required at all, or whether the process could simply be eliminated instead of automated. They weigh whether to build, buy, redesign, outsource, or stop doing something, and which specialized capabilities are needed, in what order, and at what reasonable cost. After the work is complete they ask whether it produced the outcome that was expected, and then what should be improved next.
Why businesses did not need this before
Modernization has historically been episodic. An organization implemented the ERP, migrated to the cloud, replaced the CRM, launched a digital transformation program, or integrated an acquisition. These projects were large, expensive, and relatively infrequent. A sponsor was named, a team formed, consultants arrived, governance was established, and eventually the project ended and everyone moved on.
Modernization was treated as an initiative rather than an ongoing organizational capability, and that is one reason ownership became so fragmented. When everyone owns modernization, in practice no one does. IT owns one initiative and operations another. Sales buys a tool, finance automates a workflow, HR launches a program, and individual employees now build their own AI tools and agents. Each decision can be perfectly rational in isolation, but no one is managing the portfolio. For a long time that was tolerable, because construction projects were rare enough that a portfolio barely existed.
What happens when construction becomes dramatically cheaper
Suppose building suddenly became faster and cheaper. You would not only build houses. You would build a park bench, remodel a bathroom, replace a deck, move a wall, add a bedroom, or renovate a floor, and occasionally you would demolish a building and start over.
That is the environment businesses are entering. AI dramatically lowers the cost of changing how work gets done. Improvements that would never have justified a six-month technology project can now happen in days or weeks. A painful reporting process can be automated, a customer service workflow redesigned, an internal knowledge process replaced with an agent, a manual handoff between departments removed, and a small internal application created in a matter of days. Occasionally the right answer will still be a major multimillion-dollar transformation.
The more important change is not that individual projects become easier. It is that the number of economically viable modernization opportunities inside an organization increases substantially. When construction becomes continuous, someone has to manage the construction portfolio.
Modernization can no longer be an initiative
For decades, organizations have treated transformation as something with a beginning and an end. I do not think that model survives the AI era. There will always be another process worth improving, another capability that becomes economically feasible, another bottleneck exposed, another customer expectation that moves, and another layer of Operational Debt that needs attention. The organization is never finished being modernized, so the work becomes continuous.
The management question therefore changes. It is no longer which transformation project to launch, but how the organization continuously decides what to modernize next. That is a different kind of problem and it requires a different kind of ownership.
The Modernization General Contractor
This is how I increasingly think about the role of the Operational Modernization Leader. The organization holds a continuously evolving backlog of opportunities. Some are tiny and some are enormous. Some call for AI, some for software, some for process redesign, some for organizational change, and some for several specialized partners working together. Some require no technology at all.
The leader's job is not to push those opportunities through a preferred solution. It is to represent the interests of the organization: to identify opportunities continuously, understand the current state, and prioritize by business value. From there the leader designs the desired future state, determines the capabilities required, brings in specialists when they are needed, coordinates the work, and measures the result before moving to the next highest-value opportunity.
Discover. Prioritize. Design. Orchestrate. Measure. Repeat.
That is not a transformation project. It is an operating discipline.
Sometimes the best project is no project
The most important difference may be that a Modernization General Contractor should be economically indifferent to the answer. The right response might be to build, buy, automate, redesign, outsource, change the organization, use AI, avoid AI, or do nothing. If a $20,000 process change achieves the same outcome as a proposed $300,000 technology implementation, the $20,000 answer should win. If the organization has no real business problem worth solving, the correct recommendation is not to spend the money.
That recommendation is hard to give when the advisor is paid only if a project follows. It comes naturally when the advisor is paid to represent the owner.
The goal is not more transformation
This is where I think the economic model for modernization needs to change. Success should not be measured by the number of AI projects launched, applications built, consulting hours delivered, or dollars spent on transformation. A better measure is the amount of business improvement produced per dollar of modernization investment.
The specialized trades should be excellent at their trades, and technology companies should keep building better tools. The tradespeople should use whichever drill helps them do their best work, whether that is Milwaukee, Ryobi, DeWalt, Makita, Bosch, or whatever comes next. The homeowner should not have to care very much, because nobody builds a house out of a desire to use a drill.
AI is the drill. The business outcome is the thing being built. In a world where organizations will build more things, more often, with more specialized capabilities than ever before, the most useful question may not be which tool to use. It is who is acting as the General Contractor.