When engineering managers go, the work they did does not go with them. It lands on engineers or on nobody, unless a named person is given it first. Liz de Moll makes this case in a recent article, and this piece extends one claim from it: flattening an organization removes the owners of its dependencies.
De Moll argues that flattening removes the people who manage dependencies
De Moll starts from the many recent predictions that AI will end engineering management. She accepts that AI can absorb status updates and progress tracking, and argues that those were never the core of the job. In her account the core is setting expectations, coaching, setting priorities, keeping teams aligned, and translating strategy between levels of leadership. She summarizes her position in one line: "Org charts flatten. Dependencies don’t."
Her evidence is her own two parental leaves. Her teams had hand-off documentation, knowledge transfers, and a coverage plan, and nothing major broke. Even so, alignment weakened and expectations blurred, engineers were pulled into coordination tasks, and leaders above the team were drawn into execution details. Colleagues later told her they had not realized how much invisible work she did. She adds that AI raises the stakes, because implementation speeds up while product decisions, testing, security, and rollout do not, so misalignment costs more and leaves less time to coordinate.
Google’s 2002 experiment shows where unowned coordination goes
David Garvin reported in the December 2013 issue of Harvard Business Review that Larry Page and Sergey Brin tried running Google as a flat organization in 2002 by eliminating engineering managers. The aim was to speed up ideas and recreate the collegial atmosphere of graduate school. The experiment lasted only a few months. Too many employees brought routine problems, such as expense reports and interpersonal conflicts, directly to Page, and the founders reversed course. Garvin gives no figures for the experiment.
The useful detail is the direction the work traveled. It did not disappear. It moved to the one person who was still in a position to receive it. De Moll describes the same movement at team scale, where the work moved to engineers and to leaders above the team. In both cases the cost of coordination stayed in the system and fell on people whose time was meant for something else.
The boundary on this evidence is real. It is one company, early in its life, reported in a single secondary account. It shows a pattern. It does not show what happens to a team of eight in 2026. Garvin’s article also reports that in 2008 Google found teams with high-scoring managers had lower turnover, which points in the same direction without settling the question for any other organization.
Name an owner for every manager function before the layer is removed
De Moll concedes that senior engineers and other roles can take on parts of this work. The weak point in most flattening plans is that the redistribution stays implicit. A practical version is an ownership map. List each function the manager performed, using the ones de Moll names: setting expectations, coaching senior and junior engineers through AI-assisted work, setting priorities, aligning dependent teams, translating strategy, setting standards for AI adoption, and covering for absences. Put one name and one backup beside each line, and record how many hours a week the function takes. The name ownership map is mine.
Two tests keep the map honest. First, ask two engineers on different dependent teams who decides when their teams read the strategy differently. If they give different answers, a row is empty. Second, ask the named owner whether the work is happening, because a name on a list is not evidence of effort. De Moll raises exactly the questions that belong on the map: who helps skeptical engineers adopt AI, what counts as meaningful adoption, and where experimentation should give way to reliability.
A flatter structure holds up when dependencies are few and owners are named
The case for fewer managers deserves its strongest form. A team with a stable platform, few cross-team dependencies, and senior engineers who want the coordination work may not need a dedicated manager for every function. De Moll herself says AI may eventually help with judgment-heavy work and may change how many managers organizations need, what the role is called, and who performs it. I have not found a primary study comparing delivery outcomes of flat and managed engineering organizations, so I make no claim about which performs better.
What the map adds is visibility. If a flattening goes ahead, the hours that move to engineers become a visible line in the plan, and they can be weighed against the savings. Without the map, the savings arrive immediately and the cost arrives later as drift in standards, duplicated work, and dependencies that surface late, which is the pattern de Moll describes.
Why This Matters for Engineering Leadership
A decision to remove a management layer produces a visible saving and an invisible cost. Leaders who approve it should ask for the ownership map in the same meeting, with a name beside every function and an estimate of the time it takes. From an AI governance view, accountability needs a person. Someone must be accountable for what counts as meaningful AI adoption, for how senior engineers are supported through the change, and for what happens when two teams interpret one strategy differently. If the answer is that engineers will sort it out, the organization has made an assignment without making it explicit.
FAQ
Does AI remove the need for engineering managers?
AI can absorb status updates and progress tracking. De Moll argues the judgment work of coaching, prioritization, and alignment remains, so the need for someone to own it continues.
What happens to coordination work when a manager layer is removed?
It moves to engineers or senior leaders, or it goes undone. De Moll describes engineers pulled into coordination tasks and leaders drawn into execution details during her leaves. Garvin reports that employees at Google took routine problems to Larry Page after managers were removed in 2002.
What is an ownership map?
It is a list of each function a manager performed with a named person and a backup beside each one. The term is this piece’s proposal, built on the functions de Moll describes.
Can senior engineers take over management work?
Yes. De Moll concedes that senior engineers and other roles can take on parts of this work. The point of this piece is that the assignment should be explicit and sized, because the time comes out of their engineering work.
When is a flatter structure a reasonable choice?
When a team has few cross-team dependencies, and every function on the ownership map has a named person who confirms the work is getting done. This piece does not claim flat structures always fail.