The danger of the finished answer

When the finished answer becomes the problem

AI produced an excellent communication plan for a client in minutes. It was clear, comprehensive and difficult to fault.

That’s when my heart sank.

The problem was that it looked finished.

It can be tempting to rush towards the end, towards the answer, and yes, I’ve done it too. It feels quicker and more efficient, particularly when AI can produce something in minutes that might previously have taken days.

The problem is what happens next.

When you share the finished plan with the team, whose plan is it? Their plan or your plan? And which are they most likely to adopt?

My lesson – the wrong starting point

About 20 years ago, I was responsible for a complex migration for a large bank.

We had 120 business-critical applications that needed to be migrated over a single weekend. The runbook contained almost 1,000 interdependent tasks, and around 15 couriers would be carrying data tapes between different locations throughout the night.

The first versions of the runbook were created largely by one person, me.

I had built up a fair amount of knowledge by that point and taken separate input from lots of people, so technically the plan was pretty solid.

As I presented it, I noticed the delivery teams were focusing all their energy on showing me everything that was wrong with it.

I could feel myself getting defensive. Luckily, I caught it.

I put the plan aside and started whiteboarding with the people responsible for delivering it. We used big Post-its, worked through the dependencies and challenged the assumptions using their language.

It took time. Some of the conversations became involved and messy. People saw different risks and understood different parts of the migration.

That was exactly the point.

The separate pieces of knowledge we needed were not sitting in one person’s head. They were distributed across the group.

The moment it became their runbook

As we developed the plan together, I noticed something changing.

People began referring to it as their runbook. They took responsibility for updating their own parts and worked directly with one another when those changes affected other teams.

That shift in language might sound small, but it represented something much bigger.

They were no longer reacting to somebody else’s answer. They understood how the plan had been created, where their contribution fitted and how their work connected with everyone else’s.

The final runbook was undoubtedly better, but the improvement to the document was only part of the value. The process was also developing the team that would be responsible for using it.

We were building shared understanding, working relationships and confidence in one another. By the time we reached the migration weekend, the runbook was no longer something I needed to persuade people to follow. It reflected decisions they had helped make and contingencies they had helped think through.

They had invested part of themselves in it.

Why contribution changes ownership

There is a useful idea in organisational research called psychological ownership.

It describes the feeling that something is “mine” or “ours”, even when there is no legal ownership involved. The research suggests that this feeling develops through three broad routes: having some control over the thing, understanding it intimately and investing your own effort or ideas in it.

Our work on the runbook created all three.

People had genuine influence over the plan. They developed a detailed understanding of how it worked. They invested their knowledge and judgement in making it stronger.

Psychological ownership is not just a pleasant feeling. Field research has linked it with organisational commitment and the willingness to contribute beyond basic requirements, although it would be too simplistic to claim that ownership automatically guarantees better performance. Research involving more than 800 employees found positive relationships with several employee attitudes and behaviours, while also showing that the connection with performance is more nuanced.

This matters because participation is sometimes treated as a communication technique. Leaders create the plan and then involve people to help them understand or accept it.

That is different from giving people a meaningful opportunity to shape the work.

Being consulted after the important thinking has finished does not create the same experience as contributing while assumptions are still open to challenge and the answer can still change.

The plan was also building the team

Ownership was only one part of what happened.

The conversations around the runbook helped us develop a shared understanding of the migration. People could see beyond their individual tasks and understand how decisions in one area might affect another.

Researchers sometimes describe this as a shared mental model: a sufficiently common understanding of the work, the relationships between its parts and how the team will respond.

A meta-analysis of shared team mental models found positive relationships with team processes and performance. Separate research drawing on 72 studies also connected information sharing with team performance, cohesion, decision satisfaction and the integration of knowledge.

That does not mean everyone needs to know everything or agree about every detail. Our team contained different areas of expertise, responsibilities and perspectives. The value came from understanding enough of the whole to coordinate our different contributions.

We were also developing confidence in our ability to succeed together.

Research describes this as collective efficacy: a group’s belief that it can organise and carry out the actions required to achieve something. A meta-analysis covering more than 6,000 groups found a meaningful relationship between collective efficacy and group performance, with stronger relationships where the work was more interdependent.

Our migration was intensely interdependent. No team could succeed independently of the others. We needed the whole system to work.

What happened when a tape was corrupted

During the migration weekend, one of the data tapes was corrupted.

I was concerned when I first heard. I remained responsible for the overall migration and understood the potential consequences.

Fortunately, the team had already planned for that possibility. A separate backup tape was travelling with another courier and the contingency had been invoked.

In most cases, I was simply notified about decisions that had been taken at the level where they made the most sense. Other people were brought in when their part of the migration was affected.

The backup tape arrived a little later, but the delay was not on the critical path. Once we confirmed that the second tape was fine, we were able to recover and continue.

The team did not need to wait for me to invent the response. They understood the plan, knew the contingency and had the confidence to act while keeping the wider migration informed.

That was the real value of the process we had been through.

They had not merely helped write a better runbook. Together, we had developed the judgement, shared understanding and relationships needed to use it when reality departed from the plan.

Leadership did not disappear

Co-creation did not remove the need for leadership.

We communicated closely throughout the weekend. Some decisions were taken locally and others came back through me when the wider implications required it. My role was to hold the whole picture and make sure the different parts continued moving together.

I felt like the conductor of an incredibly talented orchestra.

A conductor does not play every instrument. The role is to help talented people coordinate their contributions towards something none of them could produce alone.

The talent was in them, not me.

By that weekend, the team was far stronger than the individuals within it. It was also a lot of fun to be part of. We were messaging one another throughout the night, dealing with problems and moving together towards a shared outcome.

The runbook mattered, of course. But the process through which we created it had also created something that could never be captured fully in the document.

It had helped us become a team.

What should AI accelerate?

AI makes the temptation to rush towards a finished answer far more powerful.

It can produce an impressive plan before the people responsible for delivering it have properly explored the problem together. The plan may be clear, comprehensive and technically strong, while the understanding and ownership needed to implement it remain weak.

This is not an argument against using AI to create plans.

AI can help frame the problem, surface questions, test assumptions, organise emerging ideas and capture what a group has developed. It can identify gaps, trace dependencies and help keep a complex plan current.

Used in that way, it can strengthen the collaborative process.

The leadership judgement lies in deciding which work simply needs to be produced and which work people need to experience together.

Before asking AI for a finished answer, it may help to consider:

• Will delivery depend on people exercising judgement together?
• Do different teams hold knowledge that needs to be combined?
• Could important assumptions or dependencies remain hidden without discussion?
• Will people need to adapt the plan when reality changes?
• Does success depend on people taking responsibility for keeping the plan current?
• Is developing shared understanding part of the outcome?

If the answer to several of these questions is yes, the process is doing more than producing an artefact. It is helping to create the conditions for successful delivery.

That does not mean everyone needs to contribute to every sentence or that every decision should be made collectively. Involvement without purpose quickly becomes frustrating. Leaders still need to provide direction, define decision authority and recognise when speed matters.

The aim is not participation for its own sake. It is to involve people where their experience, understanding and ownership will materially affect the outcome.

AI can then do what it does exceptionally well, helping the group think, organise and move faster without taking away the experience through which they become capable of moving together.

Before you ask for the finished answer

AI can help us reach an answer faster.

Sometimes, that is exactly what we need.

At other times, the conversations, disagreements and shared problem-solving that happen on the way to the answer are part of the work. They build understanding, ownership, confidence and the ability to respond together when the plan meets reality.

Our job as leaders is to recognise the difference.

Think about your latest transformation plan. Did people help create it, or were they asked to approve somebody else’s answer?