Why Good Managers Build Systems, Not Dependency

W. Edwards Deming spent decades making an argument that managers still resist, usually while agreeing with it out loud. His claim, put bluntly in Out of the Crisis, was that the overwhelming majority of problems in an organization belong to the system rather than to the people working inside it. He put the split at roughly 94 percent system and 6 percent special cause, and he meant it as a management instruction, not a statistic to quote in a deck. If most of what goes wrong is structural, then most of what a manager does about individuals is aimed at the wrong target.

Which raises an uncomfortable question for anyone who is good at their job. If your team performs well because you are personally excellent at unblocking it, what have you actually built?

What the Research Shows

The Manager Effect Is Real, Which Is Exactly the Risk

Gallup’s finding that managers account for at least 70 percent of the variance in team engagement, which we covered here, is normally read as a case for developing managers. Read it the other way and it is a warning. A single role that explains that much variance is a single point of failure. When the manager is good, the team is good. When the manager is on holiday, tired, or distracted by a reorganisation, the team is whatever the absence of that person makes it.

Deming’s answer to that is not to care less about managers. It is to change what the manager spends their attention on: the conditions the work happens in rather than the individual instances of work.

Dependency Looks Identical to Engagement From the Inside

This is the part that keeps the problem alive. A manager whose team routes everything through them experiences that as being trusted, needed and close to the work. The calendar is full of people who want their input. Nothing about the daily experience feels like a design flaw. It feels like being good at the job.

The signal that separates the two is not how busy you are. It is what happens to throughput when you are unavailable, and most managers never run that test deliberately.

Systems Beat Intentions Because They Persist

The practical case for systems is unglamorous: they work when nobody is thinking about them. A documented escalation path resolves a question at 11pm on a Friday. A remembered preference does not, because the person who remembers it is asleep. Every norm that lives only in a manager’s head has an availability requirement attached, and that requirement is invisible until it is not met.

A manager whose team routes everything through them experiences that as being trusted. Nothing about it feels like a design flaw. It feels like being good at the job.

Why This Matters for Teams

Dependency is expensive in ways that do not appear on any dashboard.

It caps the team at the manager’s throughput. Every decision that must pass through one person inherits that person’s queue, and the queue does not scale. Teams grow, decisions multiply, and the constraint stays exactly where it was.

It degrades the decisions themselves. A manager deciding twelve things a day is not weighing the ninth one carefully, whatever they believe about their own judgment. We wrote about the underlying mechanism in decision fatigue on cross-functional teams. Centralised decision-making does not just slow throughput. It quietly lowers quality at the tail of the day.

And it stunts the people. Someone who has never owned a decision end to end has not practised the part that is hard, which is living with the consequences of a call they made. You cannot develop that by watching someone else do it, and no amount of shadowing substitutes for having been wrong once and having had to fix it.

There is a version of this that looks like generosity and is not. Protecting the team from a hard decision, absorbing the ambiguity yourself, shielding them from a difficult stakeholder. It feels like care. Done repeatedly it produces a team that cannot do those things, which is not a gift.

The Gap the Data Reveals

Deming’s insight is widely quoted and thinly applied, and the reason is that “build systems” is not actionable at the scale a manager works at. It sounds like an instruction to redesign the organisation, which nobody has the authority to do from a middle position on a Tuesday.

The gap is that most of the systems that matter to a team are small, local and entirely within a manager’s gift. Not org design. A written rule about which decisions need approval and which do not. A standing time when priorities get re-ranked so people stop asking individually. A default for what happens when two things collide, so nobody has to come and ask.

The second gap is that systems get proposed as a replacement for judgment, which is why experienced managers resist them. A rule that tries to cover every case becomes bureaucracy, and everyone has worked somewhere that happened. The useful framing is narrower: systems handle the recurring cases so that judgment is available for the genuinely novel ones. You are not automating your job. You are clearing the routine out of it so the interesting 6 percent gets your full attention.

What to Build, Concretely

Start From Your Escalation Log

For one month, write down what people bring you. Not the time it took, just the category. The list sorts itself: most teams find that three or four categories account for most of the interruptions. Those categories are your build queue. Everything arriving once is fine and should stay a conversation.

This is the step people skip, and skipping it produces systems for problems nobody had. Build from the log, not from a template.

Write the Decision Rule, Not the Decision

When the same question keeps arriving, resist answering it again. Answer the class of question instead. “Anything under two thousand pounds and reversible, you decide. Over that or hard to undo, bring it to me.” That single sentence removes a recurring interruption permanently, and it is more useful to the team than fifty individually correct answers, because it teaches them where the boundary is.

Make the Default Explicit

Most escalations are not requests for a decision. They are requests for permission to use the obvious answer. Name the default and the traffic stops: when a client asks for something outside scope, the default is no and here is who can override it. People escalate because they are unsure whether the obvious thing is allowed, not because it is hard.

Put the Rhythm Where the Questions Are

If priorities shift midweek and people ask individually, the answer is not a better answer. It is a scheduled slot where re-ranking happens in front of everyone. We covered the mechanics in setting expectations when priorities shift midweek and in the weekly accountability rhythm. A cadence converts a stream of interruptions into one meeting, and the meeting is cheaper.

Test It by Leaving

Take a week off without a handover document. Whatever breaks is the thing you have not built yet, and you will learn more from that than from any amount of reflection about whether your team is empowered. Run it annually. The failures move as the team changes.

Deming’s 94 percent was never a claim that people do not matter. It was a claim about where a manager’s leverage sits. Fixing the instance helps once. Fixing the condition that produced it helps every time it would have recurred, including on the days you are not there. The managers worth working for are not the ones who solve everything brought to them. They are the ones who, over a year, are brought less.

Related Reading

• What Is a Team Operating System? The Five Systems Every High-Performing Team Needs
• How Great Managers Create Clarity Without Micromanaging
• Sustainable Pace Is a System, Not a Mindset
• The Leadership Communication Stack: Four Systems Every Manager Needs
• Gallup’s Manager Research: Why Managers Account for 70% of Engagement Variance