Why Traditional Team Structures Fail in Complex Environments

And What to do Instead

In the interest of providing multiple means of engaging with this blog, below is the podcast style conversation, using our AI friends Johnny and Joanne who go into each blog post at a deeper level. Or below is the usual written format. For whatever format your current environment affords.

Here’s a scenario you’ve probably witnessed: A team keeps being told they need to “take more ownership” and “be more empowered.” They nod in meetings. Nothing changes. Management gets frustrated. The team stays stuck.

Before assuming this is a culture problem or a capability gap, consider a different explanation: perhaps the team has been designed in a way that makes ownership structurally impossible.

This post comes from my reflections following reading some in-depth OD philosophical debates around flat vs hierarchical structures and the role in managing complexity in organisations.

There’s a principle from cybernetics that rarely makes it into leadership development programmes but should: requisite variety (Ashby, 1956). Simply put, a system can only respond effectively to as much variability as it has options to respond with. A thermostat with just “on” and “off” settings cannot maintain precise temperature control. A team with narrow discretion, fragmented responsibilities, and limited authority cannot adapt to situations that don’t fit prescribed paths—no matter how motivated they are.

The question isn’t whether your people are capable. It’s whether your structures, systems and processes let that capability reach the work.

Where We Locate Complexity

Most organisations default to pushing complexity upward. When something doesn’t fit the standard process, it escalates. When priorities conflict, a manager adjudicates. When work crosses boundaries, coordination happens in meetings above the teams involved.

This was a sensible design choice for a different era. When supply chains were local, customer bases were relatively homogeneous, and markets shifted slowly, the external environment generated low variance. Senior leaders had time to deliberate. The volume of exceptions was manageable. The people at the top often did have the best information because change happened slowly enough for knowledge to percolate up without going stale.

That world for many has gone.

Supply chains now span continents and carry disruption risk that propagates in hours. Customer expectations fragment across segments, channels, and contexts. Regulatory environments shift unpredictably. Competitors emerge from adjacent industries with entirely different playbooks. The variance organisations encounter has multiplied—but many structures still assume the old tempo (Snowden & Boone, 2007).

The consequence: decisions migrate away from the people closest to the situation, who hold the richest contextual information. By the time a decision comes back down, the situation has often shifted—or the nuance has been lost in translation. Teams rationally learn to avoid anything requiring escalation, which narrows their responsiveness further. It becomes safer to check every decision than to act, even when speed matters.

The Fragmentation Problem

Here’s the inconvenient truth about complexity: you cannot remove it, only choose where it lives (Ashby, 1956).

Modern organisations have refined the art of slicing work into specialisms. On paper, this looks like efficiency—experts doing expert things, complexity tamed through division of labour. In practice, it often means no single team holds enough of the picture to resolve anything genuinely complex. The complexity hasn’t been eliminated; it’s been scattered across boundaries where it becomes harder to see and harder to manage.

Consider how many organisational challenges sit simultaneously across HR, finance, operations, technology, and commercial functions. If each function owns only a fragment, who owns the whole? Usually the answer is “a steering committee” or “senior leadership”—which means integration work gets pushed up to people furthest from the operational detail, precisely when the environment demands faster and more contextually informed responses.

This is the hidden cost of specialism without integration: the complexity doesn’t disappear, it just relocates. Sometimes to layers that lack the contextual information to handle it well. Sometimes to the gaps between teams where no one is actively looking. And sometimes into the lived experience of customers or employees who bear the cost of fragmentation that the org chart doesn’t show.

I once worked with a retail organisation where a simple customer refund—something that should have taken minutes—required sign-off from three different teams across two functions. Each checkpoint existed for good reasons: fraud prevention, inventory accuracy, budget control. But no single person could see the whole transaction, and the 48-hour delay cost them far more in customer lifetime value than the fraud risk ever justified. The work had been optimised for internal control, not for the variance customers actually created.

Task Focus vs Outcome Focus

One useful distinction when examining team design: is the team organised around tasks or outcomes?

Task-focused teams receive pre-fragmented work. The “whole situation” has been decomposed elsewhere, and the team handles a slice. This reduces the variety the team needs internally—people can specialise narrowly—but someone else must now integrate across the slices. Coordination costs rise. Ownership becomes ambiguous when things go wrong because accountability is distributed.

Outcome-focused teams own a recognisable whole—a customer journey, a product, a patient pathway. They need more internal variety (broader skills, more authority, richer information flows) but integration happens inside the team rather than across boundaries (Hackman & Oldham, 1976). When something fails, there’s no question who owns it.

Neither approach is inherently right. But the choice has structural consequences that often go unexamined—and the cost of task fragmentation rises sharply as environmental variance increases.

Amazon’s “two-pizza teams” are a well-known example of outcome-focused design. Each team owns a service end-to-end, with authority to deploy changes without coordination meetings. The trade-off? Higher skill requirements within teams and more investment in shared platforms. But the payoff is speed and clarity of ownership (Rossi, 2015). Please note, adding a Pizza to a workshop with a team who still have to report back to a steer-co does not make a team empowered.

Conversely, many traditional enterprises remain organised around functional tasks—”the finance team,” “the operations team”—which works adequately when the work itself is predictable and can be genuinely decomposed. It breaks down when interdependencies are tight and the environment is volatile.

Questions Worth Asking When Designing or Assessing Teams

What is the actual variance this team encounters?
Not the idealised process in the handbook, but the real situations—how much unpredictability, how many exceptions, how much context-dependence? If you’re not sure, ask the team. They know.

Does the team own a whole outcome or a fragment of a process?
If a fragment, where does integration happen—and does that integration point have the information it needs to make good decisions quickly?

When something doesn’t fit the standard path, can the team resolve it internally?
If not, where does it go—and what’s the latency cost? Is that delay adding value or just adding process?

What decisions does the team wait on?
Map them. Are those delays necessary, or artefacts of authority distribution that could be redesigned?

Does the team have the skill mix to handle its variance?
Or does even routine work require pulling in other teams? If so, you’ve created structural dependencies that will slow everything down.

If you mapped all the decisions that shape this team’s outcomes, what proportion can they actually influence?
If it’s less than 50%, don’t be surprised when they don’t feel ownership. You’ve designed them not to.

The Design Question Underneath Everything

Before asking “do people take enough ownership?” it’s worth asking: have we made ownership structurally possible?

Before asking “why don’t teams collaborate better?” it’s worth asking: have we distributed work in ways that make collaboration necessary for every routine task—collaboration that could have been avoided with different boundaries?

Before asking “why is decision-making so slow?” it’s worth asking: have we pushed decisions to layers that lack the information to make them confidently, or the proximity to understand their consequences?

Effective teams aren’t just well-led or well-motivated. They’re well-matched—their internal variety fits the variance they encounter. When that match is poor, no amount of training, exhortation, or culture change will close the gap (Ashby, 1956; Galbraith, 1974).

This is why “empowerment initiatives” so often fail. You cannot empower people out of structural constraints. If the team lacks authority, information, or skill diversity to handle the variance they meet, telling them to be more empowered is like telling someone to be taller. The mismatch isn’t motivational; it’s architectural.

What This Means in Practice

The structures that served us when the world was slower and simpler may now be generating costs we’re misattributing to culture, capability, or commitment.

If your teams routinely escalate decisions, ask: could they make those decisions themselves if we gave them different information or authority? If your coordination overhead is crushing you, ask: have we sliced work so finely that integration costs more than specialisation saves? If your “empowered” teams don’t act empowered, ask: what structural barriers are we not seeing?

Requisite variety suggests that the solution to environmental complexity isn’t better control—it’s distributing the capacity to absorb that complexity to where it’s encountered. That might mean broader roles, different decision rights, or fundamentally rethinking team boundaries. It definitely means being honest about the gap between the variance teams face and the variety they’re equipped to handle.

The good news? This is diagnosable. You can map variance. You can assess variety. You can redesign boundaries. It’s not about changing people; it’s about changing what’s structurally possible for those people.

The alternative is what we see everywhere: talented people trapped in structures that won’t let them be effective, then blamed for outcomes they couldn’t influence. That’s not a culture problem. That’s a design problem masquerading as a people problem.

---

References

Ashby, W.R. (1956). An Introduction to Cybernetics. Chapman & Hall.

Galbraith, J.R. (1974). Organization Design: An Information Processing View. Interfaces, 4(3), 28-36.

Hackman, J.R., & Oldham, G.R. (1976). Motivation through the design of work: Test of a theory. Organizational Behavior and Human Performance, 16(2), 250-279.

Rossi, B. (2015). What is a Two Pizza Team? And How Does it Work? Information Age. https://www.information-age.com/two-pizza-team-123460292/

Snowden, D.J., & Boone, M.E. (2007). A Leader’s Framework for Decision Making. Harvard Business Review, 85(11), 68-76.