Meta Tried 50 Engineers per Manager. Six Months Later It Asked for Managers Back.

The Experiment Meta Quietly Walked Back

In March 2026, Meta set up a new Applied AI engineering organisation with a striking design choice: up to 50 employees per manager, according to an internal memo reported by The Wall Street Journal. Fortune pointed out that this was double the 25-to-1 ratio usually treated as the outer limit of a workable span of control. It was also five times Meta's own rule. In the 2023 "Year of Efficiency" post, Mark Zuckerberg wrote that in general Meta did not want managers to have more than 10 direct reports, because managing each person was "very important".

Six months later the direction reversed. In September, Fortune, citing Business Insider, reported that Meta was asking individual contributors in the division whether they would move into manager roles. The division had absorbed roughly 7,000 reassigned employees during the year, some of them former managers, and Wired had reported frustration with the rollout. Meta did not explain the change and did not respond to requests for comment.

Nobody outside Meta knows exactly why the company changed course, and one reversal does not prove that wide spans always fail. But the episode is the clearest public test yet of the idea behind two years of management cuts across the technology industry: that AI agents would take over enough coordination work for one person to lead a team of fifty. That idea has been a popular theme on LinkedIn and in engineering-leadership circles all year, and the evidence for it is weaker than the org charts suggest.

For a CTO or VP of Engineering, the useful question is not whether Meta got it right. It is how much management your engineering organisation actually needs now that a large share of its code is written by agents, and where the work of the managers you removed has gone.

How the Great Flattening Happened

The forecast came first. In October 2024, Gartner predicted that through 2026, 20% of organisations would use AI to flatten their structures, eliminating more than half of their current middle management positions, on the reasoning that AI could take over scheduling, reporting and performance monitoring. The large technology companies then moved faster than most.

In September 2024, Andy Jassy asked every Amazon senior-leadership organisation to raise its ratio of individual contributors to managers by at least 15% by the end of the first quarter of 2025, citing pre-meetings and long chains of managers reviewing topics before anything moved. In August 2025, a Google executive told an all-hands meeting that the company had 35% fewer managers of small teams than a year earlier, with many of them staying on as individual contributors.

In 2026 the justification shifted from bureaucracy to AI explicitly. In May, Coinbase announced a 14% workforce cut and a flatter structure with "five layers max below CEO/COO", replacing "pure managers" with player-coaches and organising work around AI-native pods. Brian Armstrong's summary was blunt: "Layers slow things down and create coordination tax." The same month, Meta cut about 8,000 roles, and Fortune reported that the cuts disproportionately hit managers.

The cumulative effect shows up in the averages. Gallup's January 2026 analysis found that the average number of people reporting to a manager rose from 10.9 in 2024 to 12.1 in 2025, nearly 50% higher than when Gallup first measured it in 2013. The median has stayed at about five to six, which means the increase is concentrated: the share of managers with 25 or more direct reports jumped two points in a single year, to 13%.

The Work AI Was Supposed to Absorb, and the Work It Created

The case for flattening is not foolish. A real share of traditional management work was information relay: status reports, roll-up meetings, chasing updates, translating between teams. AI tools are genuinely good at summarising tickets, drafting updates and answering "where is this?" questions. If that were the whole job, wider spans would be easy.

In engineering it never was the whole job, and AI has increased the parts it cannot do. Faros AI's telemetry study of more than 10,000 developers across 1,255 teams found that teams with high AI adoption merged 98% more pull requests, with pull requests 154% larger on average, while review time rose 91%. It found no significant improvement at company level. Faros's 2026 follow-up across 22,000 developers reported bugs per developer up 54% and 31% more pull requests merging without any review.

Those numbers describe a management problem as much as a tooling problem. Someone has to decide which agent-generated changes deserve deep review, set the standards reviewers apply, notice when a team starts rubber-stamping, and coach the engineer whose output doubled while their understanding of the system thinned. Those are judgement calls about people and risk, and they used to be spread across a layer of managers and tech leads that many organisations have just removed.

So the work did not vanish. It moved. Some went to the remaining managers, some to senior engineers who now review far more code than they write, and some went undone, which is the version that shows up later as incidents and attrition.

What the Span-of-Control Data Actually Says

There is no single correct number of direct reports, and Gallup is careful to say so. Its central finding is that "manager talent trumps span of control": highly capable managers keep engagement high even on very large teams. The trouble is that most organisations did not flatten by selecting their most capable managers for wider spans. They flattened through layoffs and reorganisations and gave whoever remained more people.

The more important Gallup finding for engineering is about workload. 97% of managers also carry individual-contributor duties, with a median of 40% of their time spent on that work. For managers below that threshold, engagement holds up reasonably well. For managers above it, engagement falls as span widens. That describes the player-coach model precisely: a tech lead manager who writes and reviews code and also has twelve or fifteen direct reports is in the group whose engagement is most exposed to growing spans. Gallup also found that rising spans hurt remote and hybrid managers most, which covers most engineering teams.

Other data points the same way. Quantum Workplace's study of more than 20,000 managers found manager engagement peaked at eight to nine direct reports and declined beyond that. A June 2026 LeadDev analysis cited data from more than 200 companies showing that managers with 15 or more direct reports scored 20% lower on team engagement than those with seven or fewer, and summarised the industry's situation in one line: "The flattening is happening through layoffs and reorgs, not deliberate design."

Meanwhile, the player-coach expectation is growing. LeadDev's Engineering Leadership Report 2026 found that the share of engineering managers doing more hands-on technical work rose from 20% in 2025 to 35% in 2026. More hands-on work and more direct reports at the same time is exactly the combination the engagement data warns about.

Where the Cost Shows Up

The first place is the top. Korn Ferry's 2025 Workforce Survey of more than 15,000 professionals found that 41% of employees said their organisation had cut management layers, and 37% said they felt directionless as a result. Senior executives absorbed the displaced work: 43% of them said they doubted their ability to fulfil their responsibilities. In an engineering organisation, that looks like a VP of Engineering approving architecture decisions at 11pm because nobody between them and the teams has the authority to.

The second is the review queue. When the person who used to triage pull requests, set review norms and protect senior engineers' focus time is gone, review becomes whoever-is-available work. Senior engineers end up as the bottleneck for every agent-generated change, and the incentive to approve rather than read grows with the queue. We described the mechanics in our piece on the merge bottleneck of agent fleets and the verification capacity gap. Flattening makes both worse, because it removes the people whose job was to manage that capacity.

The third is development. Feedback is the part of management that AI handles least well, and Gallup's numbers on it are stark: employees who strongly agreed they got meaningful feedback were about 70% engaged, against roughly 25% for those who did not, and only 16% described their last conversation with a manager as extremely meaningful. A manager with twenty reports and a coding quota cannot hold weekly conversations of that quality. The engineers who pay most are juniors and mid-level developers, the group already exposed to AI-driven skill atrophy.

The fourth is the slowest to appear: accountability. When an agent-written change causes an incident, someone has to own the decision that let it ship. In a flat organisation with fuzzy ownership, the answer is often nobody in particular, and that is how the same class of incident repeats.

What a Workable Span Looks Like in an Agent-Heavy Team

The answer is not to rebuild the 2021 org chart. Some layers really were relay stations, and removing them was right. The goal is to size management to the work that remains, which in an AI-assisted engineering team is mostly judgement: review standards, technical direction, feedback and ownership.

Start by separating two roles that flattening tends to merge. Technical leadership (architecture, review standards, deciding what agents may do unsupervised) and people leadership (feedback, growth, performance, hiring) can sit in one person on a small team, but they compete for the same hours as a team grows. James Stanier's argument, quoted by LeadDev on Meta's experiment, is that at very wide spans "the manager can no longer be the communication hub", so accountability has to move to clearly named directly responsible individuals and communication has to become asynchronous. That works only if those individuals are named, empowered and given time for it.

Then size spans to the load rather than to a target ratio. A manager whose team produces a high volume of agent-generated pull requests in a business-critical system needs a narrower span than one leading a stable team on a mature product. The table below is a practical starting point, not a rule.

Why External Teams Make the Problem Better or Worse

Flattened organisations still need capacity, and many fill it with contractors or outsourced developers. This is where the span problem can quietly double. If you add six external engineers who report directly to an in-house engineering manager already leading ten people, you have just created a span of sixteen, with the extra cost of time zones, onboarding and a different company's working norms. The vendor's invoice looks fine, but your manager's week does not.

The alternative is to add capacity that comes with its own leadership. A dedicated development team with its own team lead handles day-to-day coordination, code review standards, one-to-ones and the first line of technical judgement, while your engineering leadership owns product direction and architecture. Your manager gains one counterpart rather than six direct reports. That is the difference between staff augmentation that widens your spans and a team that relieves them, a distinction we covered in our comparison of the two models.

When you evaluate a partner, ask who reviews the team's agent-generated code before it reaches yours, who gives the engineers feedback and handles performance, how many engineers each of their leads is responsible for, and how they escalate a disagreement about a technical decision. A partner that cannot answer those questions is selling headcount, and the management work will land back on your side.

How Stepto Structures Teams So They Don't Add to Your Span

At Stepto, every dedicated team we put together includes a lead who owns day-to-day delivery, review standards and the professional development of the engineers on it. Our leads keep spans small enough to read the code the team ships, including the code our engineers write with AI agents, and to hold real one-to-one conversations every week. Your engineering manager works with one accountable counterpart rather than managing each of our developers individually.

We also make the split between technical and people leadership explicit from the first week. Architecture and product decisions stay with you. The review discipline, onboarding, coaching and continuity of the team stay with us, so that a flattening on your side does not quietly turn into an extra dozen direct reports for one of your managers.

Our engineers work from Serbia on Central European time, which gives full working-day overlap with European clients and a solid daily window with US East Coast teams. Decisions that need a conversation happen the same day, not after an overnight handoff. If your organisation has flattened and your remaining managers are carrying more than they should, we can look at where a dedicated team with its own lead would take load off rather than add to it.