Many organisations say they want empowered teams.

They create cross-functional groups.

They appoint Product Owners, Product Managers, Product leads and so on...

They talk about autonomy, ownership and outcomes.

They encourage people to move faster, make decisions closer to the work and act on what they learn.

Yet in many of those same organisations, teams still pause before making meaningful decisions.

They ask whether they are allowed to change scope.

They seek approval before challenging a deadline.

They escalate decisions about technical health.

They wait for someone more senior to confirm whether they can act on new evidence.

The team may be accountable for the outcome, but the authority to shape that outcome still sits somewhere else.

I recently explored this tension in the latest podcast episode of the Organisational Friction Series.

Hopefully you have already listened to the podcast. If not, you can find it here:

https://agileproducthub.com/podcasts

The episode asks a simple question:

Why do teams that are described as empowered still feel the need to ask permission before making meaningful decisions?

The answer is rarely that the team lacks confidence.

It is often that the organisation has taught them that permission is safer.

Empowerment cannot be created by announcing it

A leadership team can declare that teams are empowered.

It can appear in a strategy presentation, an operating model or a town hall message.

But the announcement itself changes very little. Empowerment depends on the conditions around the team.

Teams need clear strategic intent.

They need to understand the outcome they are responsible for and the constraints they must work within.

They need meaningful decision rights.

They need access to the people and expertise required to make safe decisions.

They need boundaries that are understood and stable.

They also need confidence that leadership will support them when a reasonable decision produces an imperfect result.

Without those conditions, the language of empowerment becomes disconnected from the reality of work.

The team may own the backlog, but not the strategic trade-offs that shape it.

It may be measured on customer satisfaction, but be unable to pause feature delivery to address the technical problems affecting customers.

It may be accountable for adoption, but unable to influence pricing, marketing, funding or the customer experience surrounding the product.

That is not usable authority. It is accountability without sufficient influence, and accountability without influence can feel less like empowerment and more like exposure.

Teams learn the real rules through consequences

Most teams do not decide whether they are empowered by reading an organisational chart.

They learn through experience.

A team makes a decision using customer evidence, only for a senior leader to overturn it because a stakeholder objects.

The team learns that local decisions are conditional.

A roadmap is described as flexible, but teams are still judged against the original list of promised features.

The team learns that adapting to evidence carries more risk than following the plan.

A team approaches architecture, security or legal colleagues for early advice.

That conversation unexpectedly becomes a formal approval process.

The team learns that asking for help can create delay.

A leader tells the team to take ownership, but steps in and reclaims control as soon as pressure increases.

The team learns that autonomy is available only while everything is going well.

Each of these moments teaches the organisation something.

The message may never be written down, but it becomes understood:

Making the decision yourself carries risk. Asking for permission distributes that risk.

This is why permission-seeking is often rational.

The team may already know what it believes should happen.

It may already have the relevant evidence and expertise.

But asking a senior leader or governance forum to approve the decision creates protection.

If the decision later proves unpopular, the risk is shared.

Permission becomes less about gaining clarity and more about gaining cover.

When legitimate outcomes collide

Consider a familiar organisational pattern.

Marketing wants to launch a major campaign to support an important revenue target.

Engineering needs the same specialist capacity to complete a critical platform upgrade.

Marketing is protecting growth.

Engineering is protecting operational stability.

Both are acting responsibly.

Neither side is necessarily wrong.

Yet neither can safely concede.

If marketing delays the campaign, it may miss an important commercial target.

If engineering delays the upgrade, it may increase the risk of failure during a high-demand period.

The teams may have enough expertise to understand the options.

What they may lack is a clear strategic boundary.

Has the organisation decided that platform resilience takes precedence in this situation?

Is short-term revenue the dominant concern?

What level of risk is acceptable?

Who owns that trade-off?

When those questions remain unanswered, escalation becomes inevitable.

The issue is not that the teams are unwilling to collaborate.

The wider organisation has handed them competing priorities without providing a way to resolve the conflict.

The decision travels upwards because that is where the authority to absorb the trade-off appears to sit.

The system may be pulling decisions upwards

Permission-seeking rarely comes from one isolated process.

It is usually reinforced by several organisational mechanisms working together.

A strategy may describe the organisation as product-led, while funding remains tied to fixed projects, predetermined scope and annual approval cycles.

Teams are encouraged to learn, but changing direction requires returning to an investment committee.

Governance may exist to manage risk, but operate primarily through late approval gates.

Teams respond by trying to appear certain rather than exposing uncertainty early.

Measurement may be intended to support learning, but become a mechanism for comparison and judgement.

Teams respond by making their reporting safer, their commitments smaller and their decisions more defensible.

Leadership may support autonomy in principle, but centralise control whenever urgency increases.

Teams respond by waiting for direction before the next crisis arrives.

Each mechanism may appear reasonable when viewed alone.

Together, they create an operating system that pulls decisions away from the people closest to the work.

The organisation tells teams to act.

The system teaches them to wait.

Boundaries do not weaken autonomy

One of the most common misunderstandings about empowerment is that it requires fewer boundaries.

In reality, healthy autonomy depends on boundaries that are clear, stable and trusted.

A team needs to know:

• which decisions it can make independently;

• which risks it can accept;

• where alignment is required;

• when specialist expertise must be involved;

• which decisions genuinely require escalation.

Without this clarity, every decision contains hidden risk.

The team cannot tell whether it is acting within its authority or stepping beyond it.

The safest option is therefore to ask.

Clear boundaries create confidence.

They allow people to move quickly because they understand the space in which they can act.

This does not remove governance or leadership.

It changes their role.

Governance can help make risks visible and connect teams to expertise.

Leadership can provide intent, set constraints and resolve genuine strategic conflicts.

Escalation can remain available for decisions that cross product, portfolio or enterprise boundaries.

The aim is not to eliminate escalation.

It is to stop using escalation as a substitute for organisational design.

Healthy empowerment is usable authority

Healthy empowerment does not mean teams can do whatever they want.

It does not mean leaders disappear.

It does not mean every decision should remain local.

It means teams have usable authority inside clear and trusted boundaries.

They understand the outcome.

They have access to the necessary context.

They can make meaningful trade-offs.

They can act on new evidence.

They know when to involve others.

They can raise risk without being punished for creating discomfort.

They can change direction when learning shows the original approach is wrong.

And when they make a reasonable decision that produces an imperfect result, leaders respond with curiosity rather than immediately taking control back.

This is where empowerment becomes real.

It is created through the alignment of strategy, authority, boundaries, funding, governance, measurement and leadership behaviour.

That alignment is one of the conditions for Harmony.

A question worth asking

The next time a decision stalls, resist the urge to ask why the team is not taking more ownership.

Look instead at what the system may have taught them.

Ask: What decision does your team repeatedly ask permission to make, even though it already has the context and accountability to make it?

Then ask: What has the system taught them might happen if they decide without asking?

The answers may reveal that the team does not need another message about empowerment.

It may need clearer intent, safer boundaries and authority it can genuinely use.

#OrganisationalFrictionSeries #ProductManagement #AgileLeadership #ProductOwnership #DigitalTransformation #AgileProductHub