Care and Growth leadership and Organisation

Article by Etsko Schuitema

Ask most people what an organisation is and they will tell you it is its people. The culture, the energy, the capability — all of it lives in the people. That is true enough, and it matters. But it is not what I mean when I use the word.

Remove all the people from an enterprise. Send them home. What remains? The policies. The procedures. The reporting lines. The authorisation levels. The job descriptions. The sign-off matrices. The performance frameworks. The procurement rules. The IT systems that enforce all of the above. This web of mechanisms — this is the organisation. It will be sitting there long after every one of those people has gone, waiting for the next set to walk in and be held by it.

The web is not neutral. Embedded in it is a set of assumptions about people — about whether they can be trusted, about what they are likely to do if left unsupervised, about whether initiative is something to be encouraged or a risk to be managed. You may not have designed these assumptions into the web deliberately. Almost nobody does. Organisations are rarely designed at all. They accumulate.

Each new policy is a response to something that once went wrong. Each new approval level is a scar from a previous incident. Each new report is someone’s anxious attempt to maintain oversight. Over time the accumulation hardens into a structure that feels inevitable — as if it were the natural shape of the enterprise. It is not. It is a fossil of every decision made in the past about whether to trust people or to watch them.

The purpose of this article is to examine the web — what it is for, why it takes the shape it does, and what it would look like if it were designed deliberately around a different set of assumptions.

The Dilemma at the Heart of Every Organisation

There are two forces at work in any collective endeavour, and they pull in opposite directions. Understanding this tension is the key to understanding control — and to understanding why so much control is illegitimate without being irrational.

The first force is initiative. Value is the product of initiative — of the individual seeing what needs to be done and doing it. Every piece of genuine value that has ever been created in an organisation was created by a person who chose to engage: who solved a problem before it became a crisis, who went the extra distance for a client, who improved a process because she could see it was broken. None of that is the product of being told to. It is the product of choosing to. Control does not produce it. Command does not produce it. Surveillance certainly does not produce it. It is the fruit of a human being deciding to give.

If this were the whole picture, the design problem would be simple. You would release people to do whatever they thought was right, and the value would flow. But there is a second force, and it creates a genuine dilemma.

The second force is orchestration. An organisation is a collective. It is supposed to move in a direction. And here is the problem. If every individual simply pursues her own judgement of what needs to be done, without reference to what everyone else is doing, the result is not a collective effort. It is chaos. The initiative of one person collides with the initiative of another. Decisions made in one part of the enterprise contradict decisions made in another. Resources are deployed in conflicting directions. The organisation moves at the same time in every direction, which is to say it moves in no direction at all. Undirected effort is not energy. It is entropy.

For a collective of people to go in the same direction, they cannot go in whatever arbitrary direction each of them individually prefers. Someone has to say: this is where we are going, and not that way. This is what orchestration means. And orchestration, by its very nature, is a control problem. The moment you say “we are all going in this direction,” you have constrained the freedom of each individual to go wherever she might choose. That constraint is a form of control. And it is a legitimate one.

So let me say this plainly, because everything that follows depends on it. Control is not inherently wrong. Some control is not only legitimate — it is necessary. Without it, the enterprise has no direction, and the initiative of its people produces heat without light. The question is never whether to have control. The question is which of your controls are genuinely orchestrating collective effort, and which are merely watching individuals.

These are not the same thing, and conflating them is the error that most organisations make. Orchestrating control says: we are going in this direction; here are the conditions within which you must operate; within those conditions you are free to act. Watching control says: I do not trust you to do this properly, so I am going to check what you did before it goes any further. The first releases initiative within a directed frame. The second suppresses initiative and replaces it with compliance. Both involve constraint, but they produce entirely different organisations. One is like a river bank — it gives the water direction. The other is like a dam wall — it stops the water from moving at all.

Most organisations do not make this distinction. They treat all control as equivalent, and they accumulate watching controls — adding new ones after each incident — in the mistaken belief that they are improving orchestration. They are not. They are reducing initiative while leaving the orchestration problem entirely unsolved. The organisation becomes simultaneously more constrained and less directed. That is the worst of both worlds.

Why the Watching Impulse Always Wins

Understanding why organisations drift toward watching matters, because the drift is not accidental and it is not stupid. It has a logic to it. Unless you understand the logic, you will not be able to resist it.

The logic runs like this. When something goes wrong and people are watching, someone is held responsible. Someone loses their job, their bonus, or their reputation. The pain of that is immediate and visible. When something goes wrong because a control was not in place, it is easy to see that the control was missing and easy to add one. The new control costs something — time, money, morale — but those costs are diffuse and slow. The benefit of the control, by contrast, appears immediately legible: this particular kind of incident cannot happen again.

What you cannot see is the value that was never created. You cannot put a number on the initiative that was killed, the decision that was delayed six weeks by a sign-off process, the problem that was not solved because the person who spotted it had neither the authority nor the confidence to act on it. The watched person learns not to stick her neck out. The compliance system teaches her that the safe move is to escalate, to wait for a signature, to defer to the process. The cost of that learning is enormous. It simply does not appear on any scoreboard.

I have worked with organisations where managers could describe in precise detail every control that existed in their systems — what it cost, what risk it addressed, who had put it there and why. What they could not describe was what it was costing them not to trust their people. That cost is always larger. And it is always invisible until the organisation begins to die from the inside.

There is also a ratchet effect. Controls, once added, are almost never removed. Every incident adds a new one. No incident removes one. Over years and decades this accumulation produces an organisation in which nobody can do anything without a signature, and in which the energy of highly capable people is consumed by processes that treat them as suspects. The organisation has not become more controlled. It has become less capable. Those are different things, and the difference is fatal.

The watching impulse has a surface logic to it. A bee that is watched will work harder, you see. Dr Seuss, of all people, identified exactly why this is wrong:

Oh, the jobs people work at!
Out west, near Hawtch-Hawtch,
There’s a Hawtch-Hawtcher Bee-Watcher.
His job is to watch…
is to keep both his eyes on the lazy town bee.
A bee that is watched will work harder,
you see.
Well… he watched and he watched.
But, in spite of his watch,
that bee didn’t work any harder.
Not mawtch.
So then somebody said,
‘Our old bee watching man
just isn’t bee watching as hard as he can.
He ought to be watched by
another Hawtch-Hawtcher!
The thing that we need
is a Bee-Watcher-Watcher!’
WELL…
The Bee-Watcher-Watcher
watched the Bee-Watcher.
He didn’t watch well.
So another Hawtch-Hawtcher
had to come in as a Watch-Watcher-Watcher!
And today all the Hawtchers
who live in Hawtch-Hawtch are watching on.
Watch-Watcher-Watchering-Watch,
Watch-Watching the Watcher
Who’s watching that bee.
You’re not a Hawtch-Hawtcher.
You’re lucky, you see.

The miserable punchline of this tale is that all of them — the watcher, the watcher-watcher, the watch-watcher-watcher — are living on the honey made by one bee. And the bee is not working any harder for being watched.

At a major bank we worked with, the principle was called “The Four Eyes” — everything done by the person executing a task had to be checked by a second pair of eyes before it could proceed. There were people for whom checking was their entire job. In insurance companies, whole departments of verifiers existed solely to check what whole departments of capturers had entered into the system. And yet a significant percentage of policies were still incorrectly handled. More watching did not produce better outcomes. It produced slower, more expensive, more demoralised ones — because the person at the beginning of the process knew her work was going to be checked, and that knowledge was itself a disincentive to take full ownership of what she did. Why be careful if someone else is going to check anyway? Why exercise judgement if the signature at the top is what actually counts?

This is the perverse harvest of the watching organisation. It does not only fail to produce the compliance it seeks. It actively produces the carelessness it fears. The watcher and the watched are locked in a relationship that diminishes both.

The control logic has within it a dynamic of expansion. The more you control, the less control you have, and the more you need to control. It is a trap. And the way out is not less control. It is control aimed at the right thing.

When Can You Trust Someone to Take Initiative?

The question is not whether to trust the people who report to you. The question is when. Trust without condition is not trust — it is abdication. And abdication, dressed up as empowerment, is one of the more common ways leaders avoid the difficulty of actually developing people. The answer to the when question has two parts.

The first is competence. The person who reports to you can be trusted to act autonomously when he has the means and the ability to do what is required of him. Means are the resources, the authority, the tools, and the access he needs to execute the decision well. Ability is the skill and knowledge. Without both, removing the control is not empowerment. It is exposure. If someone makes a mistake because she did not have the means or ability to succeed, the fault is not hers. The control was removed before it was safe to do so, and the person responsible for that removal is the person who held the authority.

This is why the suspension of control must be incremental. You remove one control at a time, in the direction of smallest to largest risk. Before removing each one, you identify what means and ability are required for the person to exercise that control safely, and you ensure they are in place. The process sounds slow. It is not. Done with discipline and genuine attention to the person’s development, it produces capability at a pace that watching never achieves — because the person is actually learning to decide, rather than learning to wait for a signature.

The second condition is intent. The person can be trusted to act autonomously when she understands the why. Not only the what of her task — the instruction, the target, the procedure — but the purpose behind it. What is this task for? Who does it serve? Why does it matter? And beyond the task, what is the organisation itself trying to do in the world? What is the direction in which everyone is going, and what is this person’s contribution to getting there?

We call this the benevolent intent of the task and the person. When a person understands both the intent of her specific task and the broader intent of the enterprise, something shifts. She no longer needs the control, because she has internalised the direction. She knows where she is going and why. Her judgement becomes a better instrument of orchestration than any approval matrix you can design — because her judgement is informed by purpose, not merely by procedure. The control that remains is not distrust. It is the structural condition that makes her initiative coherent with the initiative of everyone around her.

When both conditions are met — competence and intent — the question of watching dissolves. What remains is genuine orchestration: the minimum conditions required to ensure that her initiative joins the collective effort rather than colliding with it. The organisation becomes a place where people can be trusted, because the conditions for trust have been deliberately built.

If initiative is what we are trying to release, and orchestration is what we are trying to preserve, then the organisation must be designed to hold both. That is the experiment.

Most organisations are not designed at all, as I noted at the outset. They accumulate. To design deliberately — to examine with honesty and rigour whether each element of the web is orchestrating or watching — is genuinely unusual. Most leaders have never done it. Most organisations have never attempted it. And yet the logic is not complex. The two instruments of organisation are structure and system.

Structure describes the layout of the spaces in which autonomous action happens. System describes the flow of information and tasks between those spaces. Both must be deliberately shaped if the organisation is to maximise collaborative initiative rather than suppress it.

What Good Structure Looks Like

Think of each space in the structure as a sandbox — a defined territory within which the person who occupies it has the freedom to take initiative and add value. The sandbox has edges. Those edges define the limits of the person’s authority and accountability — the boundary conditions of the orchestration. Within those edges, she operates freely. The job of the leader is not to fill the sandbox for her. The job is to ensure the sandbox is as large as her competence and intent allow, and to expand it incrementally as both grow.

Most organisations do not design their sandboxes deliberately. The structure accumulates, and so do its distortions. Roles overlap. Accountabilities are shared between two people, which in practice means they belong to neither. Handovers multiply, and with each one something is lost. Functions that should be close to the work drift away from it, absorbed into centralised departments that serve themselves as readily as they serve the line. The result is an organisation in which nobody is quite sure who is responsible for what, and in which energy that should go into the work goes instead into managing the complexity of the structure itself.

Deliberate structure follows five rules. These were developed by Christian Schumacher — son of E.F. Schumacher of Small is Beautiful fame — through what he called Work Structuring, a methodology he applied in the chemical industry, including at ICI, in the 1990s. The rules are worth knowing precisely because they are not obvious, and because most organisations violate most of them most of the time.

1. Build around the work, not the people: The structure should reflect the logic of the work to be done, not the strengths and limitations of the individuals currently doing it. When the structure is built around people, it shifts every time those people shift. When it is built around the work, it has integrity independent of who occupies the roles. This sounds obvious. It is almost universally ignored. Ask yourself honestly how many roles in your organisation exist because a particular person needed to be accommodated, rather than because the work demanded them. The answer, in most organisations, is embarrassing.
2. Minimise handovers: Every time a task crosses a boundary between two sandboxes, something is lost — context, continuity, accountability. The person receiving the task arrives at it without the history of the person who initiated it. Gaps form at every boundary crossing, and things fall into them. The fewer handovers a process requires, the more value is preserved. The aim is not to eliminate all specialisation. It is to ensure that specialisation is genuinely justified by the nature of the work, and not by organisational habit or the comfort of familiar departmental boundaries.
3. Optimise spans of control: A span that is too narrow produces a manager with nothing meaningful to manage and a direct report with no room to develop judgement. She is checked so frequently and so closely that she cannot grow. A span that is too wide produces a manager who can only manage by exception — who is in contact with each person so rarely that development is impossible and accountability is nominal. The right span depends on the complexity and interdependency of the work. It cannot be determined by benchmark or industry average. It must be found by asking what the work actually requires.
4. Produce unique accountabilities: If two people are accountable for the same outcome, nobody is. Good structure ensures that each sandbox has one, and only one, owner. When something goes wrong, there must be an unambiguous answer to the question: whose was this? The moment that question has two legitimate answers, both will be wrong. Shared accountability is the structural form of avoided responsibility.
5. Balance core and support correctly: The bees are the people who make, sell, or deliver — the people whose work constitutes the enterprise’s actual contribution to its clients. Everyone else is support. Support exists to make the work of the bees easier and more effective. It does not exist to check what the bees are doing, to report on them, to manage their compliance, or to justify its own existence by finding deficiencies in their work. When support begins to exist for its own sake — when it becomes a watcher rather than an enabler — the organisation has begun consuming the very honey it was designed to produce.

* * *

What Good System Looks Like

The system describes the flow of information and tasks between the sandboxes. At each boundary crossing there is typically a control point — an authorisation, a signature, a check. The question to ask of every control point is the same one we have been asking throughout this chapter: is this orchestrating, or is it watching?

If it is orchestrating — if the person at this point has information, authority, or judgement that genuinely changes the outcome, and without which the task would go in the wrong direction or cause harm — it earns its place. If it is watching — if it exists because someone once did not trust someone else, because a policy was written in response to an incident ten years ago, because nobody has ever thought to remove it — it does not earn its place. It is overhead. And it is overhead with a particular cost: it teaches the people inside the system that their judgement is not trusted, and over time they stop exercising it. They become, in the fullest sense, watched people: people who do what they are checked to do, and no more.

We call the tortured journey a task makes through a badly designed system a snake. The snake twists and turns through approval after approval, signature after signature, check after check — sometimes travelling back up the hierarchy and down again before a decision of modest importance can finally be executed. I have seen purchasing processes in which a request for a replacement part — a part that everyone in the chain agreed was necessary — required seven signatures before the order could be placed. By the time the part arrived, the machine had been standing idle for six days. The cost of the controls vastly exceeded the cost of the risk they were designed to manage. Nobody had ever done that calculation.

Ask the people in your organisation which processes are snakes. They will tell you immediately. They live inside them every day. They know which controls are genuinely necessary and which exist only because of institutional memory, organisational anxiety, or the simple inertia of a policy that nobody has had the courage to revoke. The fact that they have never been asked this question — in most organisations, they have not been — tells you something important about what the organisation values. If you never ask, the answer is that the controls matter more than the people who are held by them.

The methodology for killing a snake is straightforward, though it requires nerve to apply. Begin by mapping the full journey of the task from initiation to completion — every step, every signature, every check, every person whose desk it crosses. Then ask what the ideal would look like: the shortest defensible path from beginning to end, with every genuinely necessary control preserved. Then identify and remove the controls that carry no genuine risk. These are the redundant signatures, the double-checks of double-checks, the approvals by people who have no information that the person below them does not already have. They can be removed immediately. The fact that they have not been removed is not evidence that they are necessary. It is evidence that nobody has asked.

What remains after that first pass are controls that carry some genuine risk — controls where removing them would mean that a person who currently relies on the check would now be making a decision unaided. For each of these, ask one question: does she have the means and the ability to make this decision well? If yes, remove the control. If no, identify what means and ability are required, build them deliberately, and then remove the control. The process is incremental, as all genuine suspension of control must be. You are not blowing up the system. You are editing it, one step at a time, in the direction of minimum necessary interference.

The aim is not a system with no controls. The aim is a system where every remaining control is earning its place — where its removal would create a real risk of the collective effort losing coherence, direction, or safety. Controls that meet that test are not a problem. They are the legitimate infrastructure of orchestration. Controls that fail that test are not protection. They are the slow strangulation of the initiative the organisation most needs.

So here is the experiment. Design the organisation as if the people in it can be trusted — not naïvely, not unconditionally, but when the conditions of competence and intent have been met. Build the smallest, cleanest structure that gives each person a genuine sandbox of autonomous action. Build the simplest system that moves tasks from initiation to execution with the minimum of controls that are genuinely orchestrating. Treat every watching control as a cost to be justified, not a protection to be assumed.

What you will find is that people who are trusted behave differently from people who are watched. The watched person learns the minimum required to avoid censure. She learns where the eyes are and how to appear compliant in front of them. The trusted person learns what she actually needs to know in order to do the right thing. She learns the work, the purpose, the direction. Those two curricula are not the same, and they produce entirely different kinds of people — which is to say, entirely different kinds of organisations.

The organisation is not the opposite of people. It is the frame within which people either flourish or shrink. Most frames are built by fear and maintained by habit. The experiment is to build one by deliberate design.

Get the frame right, and you will not need watchers. The bees will know what to do.

Reflection: Your Organisation as a Web

Before moving on, take stock of the web you are currently holding. The following questions are not comfortable ones. That is the point.

1. If you removed all the people from your organisation tomorrow, what would the web they left behind reveal about what you actually believe about people — as opposed to what you say you believe?
2. For each significant control in your area of responsibility, ask honestly: is this orchestrating collective effort, or is it watching an individual? If you removed it, what would actually happen?
3. Where in your organisation are there more watchers than bees? What is the ratio, and is it defensible?
4. Think of a control that was added after something went wrong. Has anything been removed to compensate? If not, why not?
5. Pick one process you know is a snake. Map it. How many steps does it have? How many of those steps carry genuine orchestration value? What would need to be true in order to remove the ones that do not?
6. For each direct report, ask yourself: does she have the means and ability to act autonomously in the area she is responsible for? If not, what specifically is missing, and what is your plan to provide it?
7. Is your current structure built around the work or around the people? What would change if you rebuilt it around the work?