Insights by Agilicist

CONTACT US

Search

From Organisational Chaos to Clarity

Darren Emery
Jul 28
6 min read

Fixing the Structure Behind the Allocation Paradox

Overhead view of a windy river system next to a clean, structured road, symbolising organisational clarity. — From tangled priorities to aligned teams: fixing structure to fix strategy.

Here’s a familiar scenario:

Your teams are stretched. Your budget’s tight.

And yet somehow, no one can give a straight answer to the question: “Where is all our time going?”

It sounds like a reporting problem. Maybe a few dashboards will sort it out? A spreadsheet, perhaps?

But it’s not a tooling issue. It’s a symptom.

And like all good symptoms, it’s pointing at something deeper, systemic, and uncomfortable:

👉 You don’t have a reporting problem. You have a structure problem.

This is the core of what John Cutler calls the Allocation Paradox:

The harder it is to track where time and capacity are going, the more likely it is that your organisational design - not your reporting system - is the real problem.

And he’s right.

When we walk into organisations trying to modernise how they deliver digital products, we see the same pattern repeat itself.

Teams are pulled in multiple directions, project delivery is reactive, and reporting becomes a rear-view mirror exercise that no one trusts.

First let’s understand why this happens – and then, what we can do to fix it.

The Problem: Why Work Feels Fragmented (and Visibility is a Mess)

Most organisations trying to modernise their product and tech functions look something like this:

Centrally coordinated projects run by programme or delivery leads span multiple teams and departments.
"Delivery" teams exist, but they’re not really product-aligned - more like feature factories churning through requests.
Internal teams (data, infra, security) spend most of their time doing ad hoc support, firefighting, or being tagged into everything.
A handful of product teams may be more focused - but even they get pulled into “just one more initiative” outside their scope.
If you’re lucky, you’ve got a few innovation initiatives pushing into new territory - but they’re often under-resourced and politically fragile.

A diagram of typical team structures seen in mid-large organisations — The Setup in most orgs leads to role confusion, low ownership and coordination overhead.

The result?

Work is primarily reactive.
Teams are busy, but outcomes are unclear.
Priorities shift constantly.
Dependencies multiply.
Nobody owns anything end-to-end.

As Klaus Leopold puts it:

“The biggest inefficiencies in organisations aren’t within teams - they’re between them.”

And when ownership is blurred, reporting becomes nonsense. Allocations feel like guesswork, and leadership is forced to rely on gut feel rather than evidence.

The Shift: From “Busy Teams” to Strategic Team Types

What’s the fix?

It’s not just better tooling or sharper project management.

The real shift happens when you redesign your structure around clearly defined team types with a clear purpose.

Drawing from Team Topologies and OrgTopologies thinking, that means shifting towards:

Stream-aligned teams: Own a specific customer journey or value stream.
Platform teams: Build and maintain shared capabilities designed for self-service and scale.
Enabling teams: Coach, unblock, and improve delivery across other teams.
Complicated subsystem teams: Look after specialised areas with deep technical expertise.

These teams aren’t managed like a rotating cast of developers waiting for the next initiative. They have a reason to exist, a focus, and an outcome to deliver.

diagram showing clear team structures based on Team and OrgTopologies. — When inspired by the right principles, higher-performing orgs look more like this.

When you get this right, three good things happen:

You reduce dependencies, which means teams can move faster without waiting on each other.
You create clarity, which makes allocation reporting far simpler and more meaningful.
You align investment with strategy, not just with operational appeasement.

Step-by-Step: How to Actually Fix the Structure

Here’s how we help organisations move from "fragmented project teams" to "clear value-aligned teams."

1. Diagnose Your Current State (Without Blame)

Begin by mapping how things actually work today:

What types of teams do you have?
Where is work coming from?
Who owns what—and who’s just picking up slack?

You’ll likely find:

Some teams are absorbing support work from everywhere.
Others are juggling five priorities from five stakeholders.
Many teams don’t have a clear boundary, outcome, or customer.

Most teams aren’t dysfunctional - they’re just structurally stretched across too many fronts.

👉 Pro Tip: Use an OrgTopologies lens to categorise team archetypes based on alignment to strategy and delivery coherence. Most orgs will find they’re operating in a “Zone 2” or “Zone 3” pattern - where purpose is unclear and boundaries are loose.

OrgTopologies diagram showing common zones of misalignment in team structures. — Most teams don’t fail because of dysfunction - they’re just stretched across too many fronts

2. Decide What Work Actually Matters

Once you’ve got the mess mapped, the next job is to make some hard calls:

What work is genuinely strategic vs. legacy?
What capabilities should be productised (e.g., data pipelines, auth, infra)?
What work is project scaffolding masking a real product or platform?

This is where people get start to get nervous. “But that project is important to Finance/Legal/Compliance!” Sure.

But important doesn’t mean it should fragment five different teams.

Look at how many people are touching the same ambiguous priority - and decide if that’s really the best use of time.

👉 Dan North calls this “accidental complexity.” Your job is to remove it, not report on it.

3. Build Real Teams, Not Role Collections

A team isn’t just a bucket of individuals. It’s a unit of focus.

So you need to create team structures that can own something end-to-end:

Cross-functional: Product, engineering, design, QA, etc.
Customer-aligned: Clear stakeholder or user base.
Outcome-oriented: A measurable goal or value stream.

If a team’s primary role is to respond to requests from six different departments, it’s not a team - it’s a service desk.

Reframe each group:

What do they own?
Who do they serve?
What outcome are they responsible for?

Use Team Topologies to define the right type - and give them permission to say "no" to everything outside their purpose.

4. Decouple Projects from Teams

This one is where most organisations trip up – they define work as projects that get sliced across teams, instead of problems that teams are equipped to solve.

Then they wonder why nothing delivers on time, why dependencies keep multiplying, and why no one feels accountable.

Cliff Hazell puts it well:

“Don’t put teams on projects. Put problems into teams.”

So instead of orchestrating Project Managers to juggle dependencies across five teams, reframe the challenge: what team structure would eliminate the dependency altogether?

If you need a short-term bridge (e.g., programme-managed project to modernise a legacy subsystem), fine. But make the end state clear: stable, outcome-owning teams.

Think: “Can a single team own it end-to-end?” If not, why not?

5. Fund the System, Not the Work

If your budget process still looks like:

“List of projects > Business cases > Annual approvals,” you’re going to keep getting the same reactive, fragmented delivery.

Instead, move toward team-based funding models:

Fund customer-facing product teams and give them the autonomy to pursue outcomes.
Fund platform/enabling teams as internal product orgs with roadmaps and metrics.
Fund innovation teams through exploration budgets, not rigid plans.

This aligns incentives and gives leadership a far better view of where the money’s going. You no longer need to track every hour to a project code - because you’ve funded the capability, not the activity.