How Leaders Should Think About AI

Most senior leaders learned to evaluate technology during the enterprise software era. They learned how to assess vendors, run pilots, calculate ROI, and measure success. Those lessons worked. But AI systems behave differently, and forcing them into the old framework produces predictable disappointments.

‍

Here are the differences that matter most.

AI is probabilistic

Traditional software does what you tell it. If a payroll system calculates a paycheck wrong, that's a bug. Someone wrote a line of code incorrectly. You find it, fix it, and the system never makes that mistake again.

‍

AI produces outputs based on patterns learned from data, and those outputs carry uncertainty. The same question asked twice may yield different answers. A system that summarizes documents well most of the time will occasionally produce something odd. That is a property of the technology, not a defect you can engineer away.

‍

So the deployment question changes. In software, it was usually binary: does it work or not? With AI, it becomes: how well does it work, under what conditions, and what happens when it doesn't?

‍

Organizations that understand this design workflows with humans in specific places. They sort decisions by whether they can tolerate occasional error. They measure performance as a distribution rather than pass or fail.

‍

Organizations that miss this either deploy AI where errors are catastrophic, or reject it entirely for not being perfect and forgo the value available where imperfection is fine.

‍

Consider an AI that drafts customer emails versus one that approves loan applications. Both may be equally accurate. The consequences of error are wildly different. A leader thinking in software terms sees two applications of the same tool. A leader thinking properly about AI sees two risk profiles that need different governance.

Capabilities are discovered, not specified

When you commission traditional software, you write requirements, engineers build to them, and you test whether the result matches. You can estimate cost and timeline with reasonable confidence.

‍

AI inverts this. You often don't know what a system can do until you build it and try. A team may find that a model handles a task nobody anticipated, or fails at something simpler than what it already solved.

‍

This means AI initiatives should be structured more like research programs than construction projects. Demanding a detailed business case with projected returns before approving work doesn't fit — you can't forecast returns on capabilities you haven't mapped.

‍

The alternative is a portfolio: fund many small experiments with clear kill criteria, expect most to fail, scale the ones that show promise, and budget the cost of learning as a real cost.

‍

This is uncomfortable for leaders trained in capital allocation discipline. It feels like abandoning rigor. It's applying the rigor that fits. Venture investors don't evaluate seed-stage companies with discounted cash flow models, because the tool doesn't fit the problem.

The advantage compounds through use

Traditional software improves through releases. A vendor ships version four, you install it, you have new features. Improvement is episodic and comes from outside.

‍

AI systems improve through use — through accumulated feedback and refinement against your specific context. The data your organization generates while using the system becomes an input to making it more useful for you.

‍

That changes the strategic calculus. In traditional software, early adoption offered modest advantages. You got features sooner, but a competitor who adopted two years later caught up quickly by buying the same product.

With AI, an organization running these systems for two years has accumulated data, learned what works, built internal expertise, and reshaped its processes. A competitor starting today buys the same underlying models but not the two years of learning. That gap is harder to close.

‍

This is the strongest argument for moving now without a perfect business case. Not because current tools are extraordinary, but because the learning curve is real, and starting later means finishing later.

AI changes what the work is

Traditional software mostly automated existing processes. You had a manual invoice process, you bought software, the same process ran faster with fewer errors. The work stayed recognizably the same.

‍

AI changes the task itself. When drafting is nearly free, a writer's work shifts toward judgment about what should be written and whether the output is good. When analysis is nearly free, an analyst's work shifts toward asking better questions and interpreting results in context.

‍

So the productivity gains often don't appear if you drop the technology into existing workflows. They come from redesigning the workflow around the new capability, which is harder and takes longer.

‍

Factories electrified in the early twentieth century saw modest gains at first, because they swapped steam engines for electric motors while keeping a layout designed around a central power source. The large gains came decades later, when factories were redesigned around distributed power. The technology arrived long before the organizational imagination to use it well.

‍

We are in a similar moment. The leaders who capture the most value won't be the ones who buy the best tools but the ones who rethink how work is organized around what the tools make possible.

Users need judgment, not training

When you deploy traditional software, you train people to use it. Click here, enter this, generate that report. Competence is procedural and teachable in a workshop.

‍

AI asks more. Because outputs are probabilistic and quality varies, people need judgment about when to trust the system, how to verify its work, and when to override it. That develops through experience and can't be transmitted in a training module.

‍

Rolling out AI is less like installing a system and more like introducing a new colleague whose strengths and weaknesses the team has to learn. It benefits enormously from environments where people can experiment without being punished for failed attempts.

‍

Organizations with punitive cultures around error will struggle. If people are afraid to try things that might not work, they won't develop the judgment that makes AI useful. They'll avoid the tools or use them mechanically, without the discernment that makes them valuable.

What to do

Separate exploration from deployment. Give teams room to experiment at low stakes, and reserve heavier governance for systems that touch customers or make consequential decisions. Applying deployment rigor to exploration kills learning. Applying exploration looseness to deployment creates risk.

‍

Invest in understanding rather than tools.

The tools will change. Your organization's grasp of where AI helps, where it fails, and how your work could be restructured is durable — and it lives in people.

‍

Be honest about time horizons.

‍Transforming how work is done takes years. Leaders who promise dramatic results in two quarters set their organizations up for disillusionment and premature abandonment.

‍

Pay attention to the boring parts.

Data quality, access, and governance are unglamorous but determine what's possible. Many AI initiatives fail not because the models are inadequate but because the organization can't get clean data to them.

‍

Resist both extremes.

The technology is neither a magic solution nor a passing enthusiasm. Leaders who hold both truths at once will navigate better than those who pick a side.

‍

The hardest part of leadership during technological change isn't making decisions about technology. It's recognizing when your existing frameworks have stopped fitting. That means acknowledging that hard-won expertise is partially obsolete, operating with less certainty than you'd prefer, and being willing to look somewhat foolish while learning.

‍