You don’t have to be right. You have to be willing to find out.

I was working through an AI transformation problem recently when I hit a dilemma: how do you work out what needs to change when so much of what you’re doing is genuinely new?  I mean, none of us have been here before.

Organisations everywhere are trying to work out what AI means for their business. They’re identifying use cases, deploying tools and encouraging adoption.

But there is an uncomfortable reality sitting underneath much of this activity. We don’t yet know what good looks like.

We are introducing a fundamentally different way of working while simultaneously trying to understand the behaviours, processes and practices that will allow us to get value from it. And that’s okay.

The problem isn’t that we don’t know. The problem is when we behave as though we do.

Start with the outcome, not the use case

A major pitfall I see in AI transformation is the rush to identify use cases. Where could we use AI? What could we automate? Which tool should we deploy? These can all be useful questions. But they start surprisingly far downstream.

Before the use case comes a more fundamental question:

What are we trying to achieve?

And, perhaps more importantly, why does it matter?

The answer doesn’t have to be complicated. Drive sales. Improve productivity. Reduce costs.

In fact, there is real value in getting it brutally simple. The business outcome becomes the true north, a reference point for everything that follows.

But knowing the outcome is only the tip of the iceberg. It fails to tell us how to achieve it.

If the goal is to drive sales, what actually needs to change? How should AI change the way people sell, make decisions, understand customers or spend their time? What will great AI-enabled selling actually look like?  What will be the experience for the customer?

That’s where things become much less certain.

If the outcome isn’t explicit, we can implement a perfectly reasonable AI use case without ever knowing whether it has made a meaningful difference.

Adoption of what?

This leads quickly to another pitfall that really irks me: our fixation on adoption.  

How many people are using it? How frequently? Which functions have adopted it fastest? And here’s another dashboard. Oh, and even a leaderboard!

Meanwhile, the more important question can remain unanswered: is all this activity actually producing the business outcome?

Because adoption is not the same as transformation.

I keep coming back to a very simple question:

Adopt what?

If AI is genuinely changing the way work gets done, then something beyond technology usage needs to be different. People may need to make decisions differently. Leaders may need to manage differently. Teams may need to share knowledge differently. Existing processes may need to change around the technology.  

We need to understand how the new way of working actually works, and whether it’s producing the outcome we’re after. 

The important question becomes:

If we were achieving the desired outcome exceptionally well, what would we see people doing differently?

That’s a much harder question than measuring logins.

The three behaviours problem

So now we’ve come full circle.  We know what we want to achieve, but we don’t really know what it’s going to look like.  Again, that’s okay. 

Imagine identifying the three critical behaviours most likely to enable the outcome you’re pursuing. 

It sounds simple. It isn’t.  

And here’s the difficulty. The way work is changing is so new that we may not yet know which behaviours matter most.  

So how do we know? We don’t. We make a hypothesis:

If people consistently do these things well, we believe they will materially increase our likelihood of achieving this outcome.

You can pressure-test that hypothesis. Are the behaviours observable? Specific? Within people’s control? Are they genuinely high leverage? Can they be reinforced? Can we measure whether they’re changing?

We can make an informed judgement. But we might be wrong.  Again, that’s okay.

That’s where it gets interesting

The answer isn’t to wait until we know. Nor is it to pretend that we know. It’s to recognise the assumption for what it is.

Choose the best hypothesis you can. Make it explicit. Put it into practice. Pay attention to what happens. Then be willing to find out.

Perhaps one of the behaviours matters enormously and another doesn’t. Perhaps people discover a way of working nobody anticipated. Perhaps your highest-performing teams develop practices that weren’t part of the original transformation plan. Perhaps the technology creates an opportunity that wasn’t visible when the strategy was developed.

These aren’t necessarily deviations from the transformation. They are intelligence generated by it.

Execution should teach us something

This is where I think our conventional idea of execution can sometimes get in the way.

We develop the strategy. We agree the plan. Then we execute it.  We treat it like a neat and tidy process: do this, job done.  Success can start to mean proving that the original plan was right.

But execution changes what we know.

As people put a strategy into practice, they encounter customers, operational realities, edge cases and possibilities that weren’t visible when the plan was developed.  Rather than a linear process, execution creates branches of learning that weren’t visible at the outset.  

AI accelerates this because the technology itself is evolving while organisations are learning how to use it. So the leadership task cannot simply be to keep everyone faithfully executing the original answer.

Leaders need to create a way for what the organisation is learning to come back to the table.

What are we seeing?

What is working?

What isn’t?

Which assumptions are holding?

What have we learned that changes what we should do next?

Then recalibrate. 

Those new branches aren’t a failure of execution. They’re how we discover what we couldn’t know when we started. And that’s how the outcome isn’t just delivered but improved. But only if we’re willing to notice them.

You don’t have to be right

There is a discipline in this. “You don’t have to be right” isn’t permission to be careless.

You still need to think rigorously. Start with the business outcome. Use evidence and experience. Pressure-test your assumptions. Make deliberate choices. Measure what happens.

But don’t confuse a well-reasoned assumption with a fact. Especially when the world is changing faster than our experience can keep up.

Once we stop treating uncertainty as something to eliminate and learn how to include it, we can start paying attention to what it reveals.  The uncertainty you’re navigating may very well be where the opportunity lives.

Perhaps one of the most important capabilities leaders can build in an AI-enabled organisation is the ability to move with pace when certainty isn’t available.

This is what we believe will work. This is why we believe it. And this is how we’re going to find out.

You don’t have to be right.

You have to be willing to find out.

This writing is inspired by my earlier article, Feedback: The Precision of Leadership.