Your Manager Has Six Reports Because Management Stopped Thinking in 1933

Rod Liddle, the British columnist and former editor of Radio 4's Today programme, died last week, aged 66. He wrote with mischief, nerve and a magnificent lack of reverence for respectable opinion. He offended a great many people, often deliberately, and half the fun was waiting to see who would splutter next. This piece is a tribute to him. The tone is tongue-in-cheek; the argument is not.

One engineer and one designer are rebuilding an application end to end. A year ago, I would have assembled two teams of six around the same outcome, not because twelve people were required to type the code, but because the work crossed enough boundaries to require them. They are now doing it with some AI and almost no ceremony. There is not a Jira ticket in sight, so I have been unable to establish whether the work officially exists.

It is magnificent. As VP Engineering, I shall eventually receive some credit for creating the conditions in which it happened, having contributed chiefly by not preventing it.

What changed was not merely the speed of delivery. Many of the dependencies that once demanded a team can now be crossed by one engineer. The org chart should probably notice.

Meanwhile, elsewhere in the company, several highly paid adults are rearranging an organisation chart with the grave concentration of air traffic controllers. Unlike air traffic controllers, they can move every object on the screen without landing anything. The basic unit is reassuringly familiar: six engineers in a box and a manager above them.

Accumulate enough boxes and we add managers to manage the managers, each layer farther from the work and more urgently in need of an update about it. Small teams work because six people can know what they own and notice when nobody owns it. Then comes the sleight of hand: because six people can build together, six must also be the number one manager can support.

How many people should build together and how many people one manager can support are different questions. The modern corporation answered both with six and went on an away day to discuss agility. AI is now ruining this pleasing symmetry: delivery teams can shrink while management spans grow.

The Strange Afterlife of the Number Six

The number has a pedigree, which saves everybody the inconvenience of asking whether it was ever true. Six was management folklore before it acquired a formula. In 1933, the consultant V. A. Graicunas tried to explain why spans should remain narrow by counting every possible relationship among a manager and their reports. Four reports produced 44 possible relationships, five produced 100 and six produced 222.

This was mathematics in the sense that the multiplication was correct. Everything interesting had been assumed. Graicunas counted every possible grouping as though it occurred, mattered equally and demanded the manager's attention. He then borrowed an argument about how many digits a person could remember, apparently on the basis that an engineer and the number seven impose comparable cognitive demands.

Graicunas did not even recommend six for interlocking, non-routine work. He preferred four, with five as the maximum. His work was republished in 1937, after which Lyndall Urwick helped turn the surrounding idea into the familiar rule of five or six. By 1946, Herbert Simon had identified the joke: a narrow span creates more layers, although fewer layers were simultaneously held to be another sacred principle of efficient administration. Management had produced two commandments which contradicted each other and called both science.

The commandment has proved remarkably durable. Gallup's 2026 research found that the average American management span had risen to 12.1, yet the median remained five or six; two-thirds of managers still had fewer than ten reports. Gallup does not prove that modern companies inherited six from Graicunas, only that an unproven number can enjoy a longer corporate career than most of the people subjected to it.

Graicunas worried chiefly about coordination, and software engineering once supplied it by the bucket. Frontend needed backend, backend needed infrastructure, infrastructure needed security and security had raised a ticket with the database team. The Engineering Manager found where the work had become lodged and poked it with a stick.

Coordination was expensive, so we coordinated through hierarchy.

Long before generative AI, research across eight countries found that technologies which lowered the cost of acquiring information were associated with greater autonomy and wider managerial spans. Technologies that merely made communication cheaper had the opposite effect because decisions became easier to refer upwards. Slack, it turns out, is not self-government.

Engineering then spent twenty years lowering the cost of acquiring information. Platforms made infrastructure self-service, observability exposed running systems, and documentation and code search made knowledge discoverable without first locating its custodian.

The Machine Knows Where the Bodies Are Buried. It Put Some of Them There

AI has accelerated the change, although everybody remains hypnotised by how quickly it writes code. Typing faster is not the interesting part. Wandering further is.

Direct evidence that generative AI will flatten hierarchies remains early, and pretending otherwise would turn prediction into consultancy. The coordination mechanism is clearer. In a 2026 field experiment involving 791 professionals at Procter & Gamble, individuals using AI matched the performance of two-person teams without it, while producing work that crossed functional boundaries more successfully. Product innovation is not software engineering and a two-person team is not an org chart. It is nevertheless an inconveniently exact preview of what happens when one person can reach expertise that previously required another.

A frontend engineer can investigate a backend service without first locating its author. A backend engineer can revisit an unfamiliar UI framework. Either can trace a call, decipher a deployment file, read the logs or produce a plausible test before disturbing its custodian.

The useful measure is not the code produced, much of which the world could cheerfully do without. Count how often the engineer must stop and find another person before work can continue.

AI is frequently wrong and has the confidence of a man in a pub who has confused three newspaper stories. DORA calls AI an amplifier: sound systems gain leverage, while disordered ones create disorder more efficiently.

In a strong system, AI also reduces the cost of being wrong. An engineer can test a hypothesis, inspect the failure and abandon a bad approach before the old process has found the correct specialist and a mutually convenient hour. The danger is not being wrong briefly. It is committing the mistake without review or feedback.

Faster coding can disappear into slow testing, security queues, review and deployment, which DORA calls downstream disorder. A faster engineer merely reaches the queue earlier.

An engineer can now carry a change further before asking for help. Specialists remain valuable, but we can consult them when judgement is needed rather than whenever an unfamiliar file appears. The economics changed. The org chart was attending a workshop.

Here is the peculiar bit. We entrust engineers with production systems, customer data and tools capable of generating code across the stack, then arrange them in groups of six because a seventh apparently creates an intolerable shortage of adult supervision. We call them autonomous until the org chart is opened.

Managers will object that with twenty reports they could not know what everybody was doing. Good. Nobody should know what twenty engineers are doing in enough detail to interfere with all of them.

Please Conduct Your Brilliant Leadership Somewhere People Can Find It

Wider spans fail when leaders hide useful judgement in private rooms. Engineering leaders, myself included, ask engineers to take ownership and then schedule a fortnightly meeting to watch them do it.

My diary contains councils, forums, steering committees, weeklies, monthlies, bi-weeklies, check-ins, connects, syncs and, my favourite, the quick sync. These are ten names for the same event.

If one level of engineering leadership explains a trade-off to the next, which explains it to the next, the organisation calls this a cascade. A cascade is the daftest communication method devised since whispering across a crowded pub: each layer repeats what it thinks it heard, removes anything alarming and adds a deadline.

I am often asked to cascade messages to my teams, despite the company possessing email distribution lists and public Slack channels. Apparently these technologies remain experimental, whereas asking eighteen managers to produce eighteen versions of the truth is considered reassuringly mature.

The cascade concludes with an alignment meeting, where thirty people attend so that two may discover they disagree. The other twenty-eight serve as human read receipts. A sync is alignment shortened to fit the calendar. A forum has acquired columns and imagines itself ancient Rome. None produces a decision.

The steering committee is grander: the people furthest from the wheel meet monthly to ask why the vehicle has not arrived. Naturally it requires a pre-steer, where the same people agree what they will pretend to decide at the real meeting. The quick sync is especially useful because the word "quick" relieves the organiser of preparing anything. If discussion threatens to produce a decision, somebody sensibly proposes taking it offline, where it can no longer endanger the meeting.

Put the reasoning where people can find it. The person making a decision should explain it once, in public, rather than feed each layer a private version to misunderstand.

A personal conversation may serve one person; its reasoning can serve twenty. This does not mean discussing Sheila's performance rating in #engineering-general. Pay, illness, conflict and performance belong in private. If it is not private, do not hide it merely because arranging a meeting feels more managerial.

Written reasoning can be challenged, corrected, searched and reused; new colleagues inherit the history and AI can retrieve something more useful than the title of a vanished Teams call. Writing demands preparation and an actual thought. A meeting lets you arrive with neither, think aloud at everybody else's expense and call it collaboration.

AI has made words cheap, not good. Brutal editing matters more, not less. Write the decision, expose the reasoning and cut until no reader needs the meeting.

The Holy Half-Hour, Every Tuesday Until One of Us Dies

Private management time is the principal argument for narrow spans. It is therefore worth examining how casually we spend it.

A meeting without an agenda is a hostage situation with a calendar invitation. Making it recurring merely books the next abduction.

The weekly 1:1 began as a useful idea and became a sacrament. At half past ten every Tuesday, two adults present themselves before Outlook because one clicked "recurring" eighteen months ago. Everything is fine. The blocker belongs to another team, which is apparently barking mad, so make the MR yourself. No, nobody knows when the progression window will open.

Twenty reports at thirty minutes each consume ten hours before preparation, hiring and reviews. Therefore, we say, twenty reports are impossible. Perhaps twenty adults do not require the same appointment every week.

A new engineer or somebody struggling may need several conversations a week. An experienced engineer receiving continuous feedback may not need the same half-hour until retirement or acquisition, whichever comes first. Attention should follow need. That requires the manager to notice when somebody needs help; Outlook can reserve half an hour, but it cannot care.

Formal check-ins still matter. Twenty reports, once a quarter, means eighty conversations a year: a little over one and a half a week, plus preparation and follow-up.

Corporate wisdom insists that all twenty occur in the same two-week "check-in window." Managers abandon useful activity, paste evidence into boxes and receive reminders in ever more accusatory shades of amber, each threatening loss of privileges and a report to the governor. Eventually the dashboard turns green, proving not that anybody developed but that everybody complied.

Calibration and reward may need a common window. Development does not. Stagger the conversations and the manufactured crisis disappears.

None of this works if the manager also carries a normal sprint commitment. Gallup's span research found lower engagement among managers who spent more than 40 per cent of their time on individual-contributor work, with the association becoming stronger as spans grew. Twenty reports and six tickets is not a modern hybrid. It is one job done badly and another done after dinner.

This is not an argument for pure-play managers. Every Engineering Manager should still do engineering: review, pair, investigate incidents, prototype and improve tools. They should remain off the critical path. Their technical work should improve delivery; delivery should not depend on it.

The Blessed Line Manager, Into Whom the Organisation Pours Everything It Forgot to Design

Autonomous adults still need support. It does not follow that every form of support must be bundled into a designated supervisor for each six of them.

The line manager has become the organisational lost-property office. Anything without an obvious home gets handed in: architecture, delivery, recruitment, coaching, motivation, administration, compensation, career planning and the emotional consequences of whatever senior leadership announced on Thursday. No wonder the span remains six. We designed a job too swollen to support seven people and mistook the resulting breathlessness for a law of nature.

Take the bundle apart. Much of what engineers seek from old-fashioned line management can be provided elsewhere: coaching, guidance, feedback and a second opinion. Principals can offer technical judgement, Product can supply direction and peers can provide feedback. Even Centres of Excellence, whose name suggests white coats and a small particle accelerator, can spread standards, coaching and difficult review without acquiring reports. Splendid. But if they become another gate or ticket queue, we have replaced the blessed line manager with a committee and called the extra waiting time excellence.

The org chart is not a plumbing diagram through which wisdom must flow downhill. Principal Engineers can coach. Peers can coach. A graduate engineer who has just discovered why the build keeps failing can coach the CTO. Human Resources need not launch a reverse-mentoring programme first.

Wanting to develop people is admirable. Wanting them formally placed beneath you before development can begin is something else. If the coaching requires a title, perhaps it was authority you wanted.

Feedback is a gift, according to Human Resources. So is a dead pheasant. The value depends on who gives it, whether you wanted it and what precisely you are expected to do with it now. It does not become wiser because the person delivering it also controls your pay.

Plenty remains for the manager: performance, reward, fairness, retention, capability, succession, conflict and change. Somebody must notice when one excellent engineer is carrying everybody else. The role moves from routing daily work to guarding the health of the system around it.

Routing work is seductive. It is visible, fills the calendar and provides the pleasant sensation of being indispensable. Judgement is harder. It leaves fewer meetings behind.

If a manager's value disappears when engineers coordinate themselves, the span was never the problem.

A Team of One, Which Is Considerably Less Lonely Than It Sounds

The same fall in coordination cost that permits wider management spans is changing the delivery team itself. The six-person team is a community, but it is also a container for dependencies: frontend, backend, testing and infrastructure sat together because an outcome required all of them.

AI weakens those boundaries. One engineer can cross the codebase, create tests, investigate infrastructure and carry a bounded outcome towards production. Review and specialist judgement remain necessary. Five permanently assigned people may not.

My prediction is that engineering will converge towards teams of one: one engineer becoming a viable unit of delivery, not an isolated unit of organisation. This will emerge first where platforms are mature, systems understandable and risks bounded.

Before Enterprise Architecture calls an emergency meeting, no, this is not an argument for leaving one exhausted engineer alone with a payment system and an on-call telephone. Safety, continuity, review and collective ownership remain. Product sets the outcome, a Principal challenges the architecture, security reviews the dangerous bit and peers find what was missed. Collaboration happens when useful, not because six chairs share a heading.

One engineer may deliver the change, but others must be able to understand, review and operate it. Otherwise a team of one is merely a bus factor with a laptop. Work proceeding on several fronts and systems requiring an on-call rota may still need a stable group. If every engineer queues for the same Principal, security specialist and platform engineer, we have merely rebuilt the old team badly in Slack.

This is why leadership must become visible. Smaller units work only when context and judgement travel freely. Otherwise we have removed the coordinators and left everybody else to rediscover the same facts alone.

When the Work Changes, the Org Chart Should Admit It

Twenty will not become the new six. A wider span is not achieved by typing twenty into Workday. It is earned by making ordinary work less dependent on the manager.

Deleting alternate boxes from PowerPoint creates no autonomy. If decisions still climb the hierarchy, deployments still require favours and every difficult question joins a specialist queue, the old dependencies remain. The diagram has merely stopped mentioning them.

Nor should anyone sack the middle layer and buy everybody an AI licence, the sort of transformation which begins with a burning platform and ends with a consultancy partner's new kitchen. Remove managers before redistributing coordination, coaching and technical leadership and none of that work disappears. It becomes nobody's job until it becomes everybody's crisis.

Where engineers own outcomes, platforms remove dependencies and Principals lead technically, the org chart should admit it. Putting a manager and five permanent specialists around every change is not autonomy. It is supervision with better branding.

We built teams because expertise had to be gathered in one place, and hierarchies because work had to pass through somebody who could see the whole. Neither premise is as true as it was. Engineers still need direction, standards, challenge, colleagues and care; they do not need all of it routed through the same manager.

The engineer will finish the application. I shall eventually present it as evidence that our operating model is working, which is how executives convert somebody else's achievement into strategy.

We reduced the cost of coordination. It would be peculiar if the only thing left unchanged were the organisation designed to manage it.