The Path, Not the Person

There is something interesting happening in the way we think about capability.

For years, organizations have optimized around the idea of finding the best person for the job.

✨The best model.

✨The best expert.

✨The best manager.

✨The most experienced person in the room.

And then we give that person as much responsibility as possible.

It sounds efficient.

Until it isn’t.

Because the question was never really:

“Who is the best person to handle this?”

Perhaps the better question is:

“What is the best path to the outcome?”

Two recent developments make this distinction particularly interesting.

Apple’s leadership transition from Tim Cook to John Ternus is one example.

Cook isn’t simply disappearing. His capabilities, institutional knowledge and relationships still have value. But his role is being repositioned.

At the same time, the thinking behind Microsoft’s HydraFusion approach to AI orchestration points in a surprisingly similar direction: the strongest model doesn’t need to handle every problem. Different tasks can follow different paths depending on complexity, quality requirements and the value of additional computation.

In both cases, the objective isn’t to eliminate capability.

It is to deploy capability where it creates the highest marginal value.

And that changes the way I think about organizational design.

Don’t optimize the worker. Optimize the system.

We often ask: 

How can we make our employees more productive?

But perhaps we should ask something slightly more uncomfortable:

Why are we using our most expensive capability for problems that don’t require it?

If every decision requires senior approval, senior people become bottlenecks.

If every exception goes directly to management, management becomes an operational queue.

If every problem is sent to the most sophisticated system available, cost increases without necessarily increasing value.

And if the organization depends on one person to solve everything important, that isn’t necessarily a sign of exceptional leadership.

It may be a sign of poor system design.

Expertise should enter the process deliberately.

This is where process design becomes much more interesting.

A well-designed system doesn’t try to eliminate expertise.

It determines when expertise is actually needed.

A simple problem should have a simple path.

A complex problem should have a more sophisticated path.

An unusual problem should trigger escalation.

A high-impact decision may require independent review.

And when the normal path fails, the system should already know what happens next.

That means designing for: generation → evaluation → escalation → resolution.

Rather than simply:employee → task.

The distinction is subtle.

The consequences aren’t.

Apple and AI are asking the same organizational question.

At first glance, Tim Cook’s transition and AI model orchestration have almost nothing in common.

One is corporate governance.

The other is artificial intelligence.

But underneath them sits the same question:

How do we allocate scarce capability without wasting it or creating dependency?

Cook’s experience doesn’t become less valuable because he is no longer CEO.

A powerful AI model doesn’t become less valuable because it isn’t used for every task.

The capability remains.

The allocation changes.

And perhaps that is one of the defining challenges of organizations entering the next decade.

Not finding more capability.

Learning how to orchestrate the capability we already have.

From automation to intelligent allocation

This is also why I find the conversation around AI increasingly interesting from an organizational perspective.

The first wave of automation asked:

What can we automate?

The next question was:

What can AI do?

Perhaps the more mature question is:

What should AI do, what should humans do, and when should each enter the process?

And that question extends far beyond AI.

🧐It applies to clients.

🧐To portfolios.

🧐To teams.

🧐To managers.

🧐To operational functions.

🧐To governance.

Even to delegation.

The principle is remarkably consistent:

Don’t give every problem to the strongest capability available.

Give each problem the appropriate capability for its complexity, risk and expected value.

Then create a mechanism for escalation when the initial path isn’t enough.

The operating model hidden underneath

This creates a very different way of looking at process design.

Instead of starting with:

Who owns this?

Start with:

What decision is being made?

Then:

How complex is it?

What level of expertise does it require?

What is the cost of that expertise?

What happens when the standard path fails?

Who has the authority to intervene?

Who evaluates the outcome?

Now we’re no longer simply designing workflows.

We’re designing an operating system for capability.

And that is where governance, delegation, resource allocation and process design start to converge.

The real optimization

Maybe the future organization isn’t the one with the most talented people.

Maybe it is the one that knows exactly when each talented person should be involved.

The goal isn’t maximum utilization.

It is optimal utilization.

Not every problem deserves the same amount of intelligence.

Not every decision deserves the same amount of authority.

Not every exception deserves the same amount of escalation.

And not every situation requires the person with the highest title, the deepest expertise or the most powerful model.

Sometimes the smartest thing a system can do is not use its strongest capability.

Because intelligence isn’t only about knowing how to solve a problem.

It is also about knowing which capability should solve it, when, and why.

Optimize the path.

Not just the person.

And perhaps, ultimately:

Don’t build organizations around heroes.

Build systems that know when they need one. 

Dejo esto aqui, para que no se te olvide, ni a ti, ni a mi.🐾💕 

Cheers, Loba Rosé🥂

Esta historia vive en: "Y me sentí"…

Un recopilado de experiencias, emociones y observaciones que ayudaron, directa o indirectamente, a formar Kuraigana.

Entrar a “Y me sentí…” →