By: Michael Privat
There is a toy in my house that explains more about corporate America than most leadership books I have read, and it costs about twelve dollars. Drop a disc at the top of a Plinko board, watch it bounce off peg after peg, and you have no idea which slot it lands in until it gets there. If you are running a team that feels slower every quarter despite hiring more people, I think you will recognize the setup immediately. Your org chart works the same way. You drop an idea in at the top, it bounces from founder to product manager to design to engineering to operations, and by the time it reaches the bottom, gravity and a lot of pegs have decided where it lands. Nobody planned that outcome. The structure did.
I have spent close to three decades building and running engineering organizations, most recently a group of roughly 500 people spread across the US and India, and the pattern shows up everywhere I look. Companies keep hiring their way toward speed and getting the opposite result. They add a layer to fix a communication problem and create two new ones. Then they wonder why the thing that shipped looks nothing like the thing someone actually asked for.
The Board Has Five Bins, and Only One Is Good
Picture that Plinko board again, but label the bins at the bottom the way they actually show up in a sprint retro. Delayed. Over-engineered. Misinterpreted. Scope creep. And, in exactly one slot, implemented as intended.
That last bin is not the goal most companies think it is. It is the lucky bounce. It is the exception a lot of organizations are quietly betting on every time they hand off a project through four or five layers of management, and betting on luck is a strange way to run a business that reports quarterly earnings.
Every other bin has a price tag, even when nobody bothers to calculate it. A misinterpreted requirement means an engineer builds the wrong thing correctly, which is somehow worse than building it wrong. Scope creep is just intent landing in the wrong slot and getting funded anyway because stopping now feels more expensive than finishing. Add up the rework hours, the slipped release dates, and the meetings scheduled purely to re-explain what someone meant three layers up, and you are looking at payroll spent producing outcomes nobody asked for. Richard Hackman, the longtime Harvard professor whose research shaped how organizations think about team dynamics, told Harvard Business Review that the effort required to manage communication links between team members increases almost exponentially as a team grows, which is exactly why he recommended keeping most teams well under ten people (Source: Harvard Business Review, 2009). Every layer you add to an org does the same thing to communication paths, except most companies add layers on purpose and call it structure.
This is also, I think, why small teams keep outperforming teams five times their size on the same problem, and it has nothing to do with headcount cost. Researchers at the University of Chicago analyzed 65 million papers, patents, and software projects and found that smaller teams were consistently the ones introducing genuinely new ideas, while larger teams were better at developing and refining ideas that already existed (Source: Nature, 2019). A four-person team has fewer pegs between the idea and the shipped product. The ball just travels further before anything bends it.
You Cannot Aim a Falling Object, No Matter How Good Your Brief Is
Here is where most leaders go wrong, and I say this having made the mistake myself early in my career. When outcomes start landing in the bad bins, the instinct is to aim harder. Write a sharper brief. Add an alignment meeting. Build a more detailed spec before the idea even drops. None of that works, because a Plinko ball cannot be aimed once it leaves your hand, and neither can an idea once it enters a chain of handoffs. The board does not care how clear your intentions were at the top.
The only lever that actually changes where the ball lands is removing rows, not aiming the drop more carefully.
I want to be specific about what that looks like, because “flatten your org” is the kind of advice that sounds good in a keynote and means nothing on a Tuesday. Removing a row is not the same thing as removing a person. The roles that genuinely need to exist still need to exist. Someone has to own the market problem. Someone has to own the user experience. What changes is the mechanism connecting those people to the work. A peg is a meeting where someone re-explains what they think a decision meant. A funnel is a single artifact, a spec, a set of acceptance criteria, an interface definition, that everyone builds against directly, so no layer in between gets to quietly reinterpret it. The engineer hears the actual requirement from the person who owns the problem, not the fourth-hand version that survived three retellings.
I have been removing rows in my own organization for years, one at a time, slowly enough that the system never goes into shock. Every time, the same thing happens. The roles that were doing real work become more visible, and the overstaffing that used to hide behind “process” stops being a guess and starts being obvious on paper.
The AI Trap Hiding in Plain Sight
This is the part that should worry any leader currently pouring budget into AI tools to “move faster.” A recent MIT analysis of over 300 enterprise AI deployments found that 95 percent of them failed to produce any measurable financial return. The researchers pointed to what they called a learning gap: generic tools that work fine in a demo but never adapt to a company’s actual workflows, retain context from one interaction to the next, or integrate with how the business really runs (Source: Forbes, 2025, reporting on MIT’s GenAI Divide study).
The study does not talk about org charts or approval layers directly, and I want to be honest about that rather than stretch its findings further than they go. But the pattern it describes lines up with something I have watched happen inside real engineering organizations more than once. A team drops a fast new AI tool into a process nobody has questioned in years, the tool speeds up whatever that process already does, and the underlying handoffs, the re-explaining, the reinterpreting at each layer, keep happening exactly as before. The result ships faster and is still wrong in the same way it was wrong before, just with less time to catch it. That connection is my own read on the two problems sitting side by side, not a conclusion MIT’s report reaches on its own.
If you are going to bring AI into your organization, my advice is to bring it in after you have removed the unnecessary rows, not instead of removing them. A tool that speeds up a broken handoff just gets you to the wrong answer faster.
Stop Aiming the Ball, and Start Removing the Rows
Here is what the board actually gets wrong, and it took me years running large teams to see it clearly. The best bin on that Plinko board only promises “implemented as intended.” That is not a win. That is the floor. The outcome I actually want for my organization, something genuinely exceptional shipped on the first pass, is not printed on the board at all, because you do not land there by controlling the drop. You land there by controlling the machine.
Velocity, in the end, is just a measure of how few times an idea gets deflected before it reaches a customer. Margin is what you stop losing on the four bad bins you used to write off as bad luck. Neither one comes from a better brief or a tighter meeting cadence. Both come from a structure with fewer pegs in the way.
If your team feels like it is dropping good ideas into a board rigged against them, the fix is not a sharper aim. Count the rows. Then start removing them.
Michael Privat is a Chief Data and Engineering Officer leading a global team of 500+ engineers. With 25 years in tech, he works with organizations on speed, clarity, and accountability in engineering delivery. His “accountable autonomy” model centers on ownership, discipline, and modern AI-driven workflows inside stalled engineering teams. He writes about engineering leadership on his LinkedIn profile and on his Substack newsletter on high-performing teams.
