Enterprise delivery does not grow by building more, it grows sideways. Around each person making the thing, the organisation adds others to manage the client, hold the margin, run the timesheets, own the P&L, and coordinate the coordination. Every one of those roles is real work, and most of the people are good at it, but each sits a layer further from the thing being built. Stack enough of those layers and you get a lasagna: administration over administration, and at the very bottom, doing the actual building, one engineer holding the only node in the whole structure that is still connected to reality.

Two managers, built to fight

The first two layers are the honest ones, because at least their conflict is by design. They are the same job pointed in opposite directions:

  • The service delivery manager guards the contract. They face the client, they own the SLAs, and their instinct is to over-deliver: expedite the timeline, pull in another body, bypass the process, anything that protects the renewal. They are the client's advocate inside your own organisation.
  • The operations manager guards the machine. They face the business, they own utilisation and margin, and their instinct is to constrain: standardise the process, hold the budget, refuse the ad-hoc demand that burns the baseline or the people.

One wants to spend to keep the client, the other wants to save to keep the business, and the friction between them is not a bug, it is the control system. The engineer sits in the exact middle of it. The SDM escalates a fire, the OM allocates the cheapest warm body to smother it, and the technical lead is the only person in the room trying to make the alert actually stop firing.

The SDM wants the client off their back today. The OM wants the fix to cost nothing. Neither of them wants the bug gone.

Every layer is a lossy compressor

Then the org chart keeps growing, and each new layer is added for a reason that sounds like help: someone to own the people, someone to own the numbers, someone to own the cross-team coordination. What you are actually installing is another stage of lossy compression, broken telephone with an org chart. Every language has its own name for the game, telefonul fără fir, Chinese whispers, a message passed down a line until it comes back as something nobody said.

And the distortion is not innocent noise on a wire. Plenty of forces decide what survives each hop, and no list of them is ever complete. A few of the stronger ones:

  • Power dynamics: nobody passes a message up neutrally. Bad news gets softened at each step, because no one wants to hand the person who controls their budget a crisis, so a real problem sounds smaller the higher it climbs. Orders travelling back down get more rigid instead.
  • Incentives: every retelling bends toward the teller's own scorecard, the SDM's toward a quiet client, the OM's toward margin.
  • Tribal knowledge: the sharpest detail lives unwritten, in one team's heads, and unwritten context is exactly what a summary cannot carry, so it goes first.
  • Translation loss: four layers can mean four vocabularies, and the nuance falls into the gaps between them.

And those are only the ones with names. Add time pressure, risk aversion, plain fatigue, and whatever else you have watched happen in a status meeting.

A systemic infrastructure problem starts as a precise technical fact at the terminal. It travels up: the engineer renders it for the team manager, who renders it for the unit manager, who renders it for the SDM, who renders it for the client. Every hop drops resolution. By the time it lands, "we are paging on connection-pool exhaustion under a retry storm" has become "the team is on it and we expect improvement next sprint." The reality did not survive the trip.

The same loss runs the other way. The reason the work matters, the business why, the real constraint the client actually cares about, is whispered back down through the same layers and reaches the engineer as a ticket with a deadline and no context. Two layers in either direction is enough. The people at the top can no longer say what is being built or how, and the person at the bottom can no longer say why.

Worse than broken telephone

Broken telephone is the gentle name for it. The honest one is the human centipede: a chain of people stitched mouth to gut, each one feeding on whatever the segment ahead has already digested, none of them able to detach. The engineer is sewn to the very end of it. By the time the client's intent reaches that last mouth it has been through every gut in the company, and what lands is not the meal, it is what four prior digestions left of it.

Each layer feeds on the digested version handed down by the one ahead and passes its own waste along. The engineer is stitched to the end of the line, and eats last.

This is the same failure as a metric. A manager is an aggregate of the layer below them, and an aggregate is non-invertible: you cannot reconstruct the territory from the summary, no matter how many summaries you stack on top of each other. It is monitoring is not understanding, run through the org chart instead of a dashboard.

We only described the bottom

And in a real multinational there is not one stack, there are two, crossing. The local one is the account: your delivery manager, your unit, the people who can at least see the actual client and the actual system. The global one is the corporation: regional leadership, the practice and competency leads, the shared-services functions, the people who own a portfolio and a standard and a margin spread across every account at once.

In a matrix you report into both, and they want opposite things. The local layer wants this client served; the global layer wants this client to look like every other client, so the process can be standardised and the margin defended across the whole region. The technical fact is now compressed up two different ladders, in two different vocabularies, and the engineer is the only person standing where they cross.

And the part described so far is only the bottom of the lasagna. Everything up to the SDM is the local delivery organisation, the layers still close enough to smell the actual work. Above them the same shape repeats at global scale, and the stack roughly doubles.

A global account director owns the client across regions, a global practice lead owns the margin across accounts, then a regional vice-president, a divisional P&L, the C-suite, the board, and finally the shareholders. Every one is another sheet, another veto, another digestion of a fact that started at a terminal. The engineer is not near the middle of this structure; they are at the bottom of a tower roughly twice as tall as the org chart they were ever shown.

Three things the lasagna kills

Outcome engineering dies first. When responsibility is sliced this thin, nobody is paid to fix the root cause. The SDM is rewarded for the client going quiet, the OM for the quarter coming in on budget, and the engineer, the only one who could actually end the problem, is told to manage its symptoms so the other two hit their numbers. You get a permanent cycle of patching and never architecting, because the durable fix always costs more this quarter than the patch does.

Then the engineer becomes a gateway. In a deep stack the technical lead spends most of the day translating technical truth into administrative metrics: the same fact, reformatted for five audiences who each speak a different dialect of dashboard. You stop being an engineer and become an API between the systems and the business layer, and an API is not where anyone wanted to spend a career.

This is the quiet driver of talent drain. The people who can actually build resilient systems did not sign up to broadcast status on five frequencies.

And nobody owns the failure. When everyone holds a slice of the process, accountability for the whole evaporates. A service degrades and the blame routes in a perfect circle: the SDM blames the OM for starving the team, the OM blames the tech lead for inefficiency, and the tech lead points at the technical debt the business spent two years refusing to fund. Six owners, zero accountability. The structure that was sold as control quietly removed it.

And that void is not a malfunction, it is the product. A bureaucracy optimises for exactly this: every layer is, among other things, a place for accountability to be set down and never picked up, because the one thing each layer can reliably do is make sure the failure belongs to someone else. The diffusion of responsibility is not what goes wrong with the lasagna. It is what the lasagna is for. Hannah Arendt called the result the rule by Nobody, an organisation arranged so that no human being can be found at the other end of any decision.

None of them build, fix, or run the systems. All of them hold a veto over how the work gets done.

The consensus trap

There is a final tax, and it lands on exactly the decisions that matter most. Put six layers around a technical choice and you no longer make an engineering decision, you make a consensus decision, and consensus in a large organisation always settles on the lowest-risk, highest-friction path. The architecture that wins is the one nobody can object to, which is rarely the one that is correct.

Deploying a single binary starts to require three weeks of alignment with people who have never read the code it replaces. The engineers who wanted to run high-concurrency systems, ship autonomous agents, or hold a real zero-trust boundary do not fight this for long. They leave, because you cannot out-work a structure whose default answer is a meeting.

This is not an argument against tiers

It is tempting to read all of this as "delete the managers," and that is the wrong lesson. Every army that ever scaled past a few hundred did it with tiers, with sergeants holding a handful each and trusted to decide. Tiers are how you beat the span-of-control limit; without them, one person at the top drowns.

The lasagna is not tiers. It is the corruption of tiers. A sergeant decides and is accountable for the call; a middle manager holds a veto and is accountable for nothing. The army layer pushes authority down to where the situation is met; the corporate layer pulls authority up and leaves the situation unmet.

One is a chain of command. The other is a chain of custody for blame. The number of layers was never the disease. Layers that hold power without holding the outcome are.

A sergeant decides and owns it. A middle manager vetoes and owns nothing. That is the whole difference.

The same trap from every chair

It is tempting to read all this as the engineer's grievance, but the lasagna does the same thing to everyone sitting in it. Each chair feels like the only one still connected to reality, and each is partly right.

  • The SDM is fighting their own company to serve the client, and gets "the team is on it" instead of a straight answer.
  • The OM sees costs they cannot interrogate, with no way to tell real engineering from gold-plating.
  • The client pays into a black box and watches their intent dissolve before it reaches anyone who builds.
  • The board decides on a dashboard digested five times over, and gets the rule by Nobody from the top: it can find neither the territory nor anyone to hold to account.

Everyone owns a sliver of the truth: the engineer knows how the system behaves, the client knows what is needed, the OM knows what it costs. The lasagna's real crime is not that it starves the engineer. It is that no chair can see the others' slivers, so no one assembles the whole, and each walks away certain that everyone else is the problem.

Everyone in the lasagna is sure they are the last sane person in it. They cannot all be right, and the structure is built so they never find out.

Nobody here is the villain

None of this is a complaint about managers. Every person in the stack is competent and doing exactly the job they were handed: the SDM really is protecting the client, the OM really is protecting the business, the unit manager really is protecting the P&L. The pathology is emergent. It lives in the wiring, not in the people.

Which is why you cannot fix it by replacing anyone. Put a better person in the seat and they inherit the same incentives and the same lossy channel, and within a quarter they behave the same way. That is the tell that you are looking at a mechanism, not a personnel problem. So you attack the mechanism: you change what each layer is wired to, not who sits in it, and you do it without firing a soul.

You cannot fix a mechanism by swapping the people inside it. The next person in the seat inherits the same incentives and the same lossy channel.

Insulating the engineering cell

You cannot fix this by being more diligent inside it, and you will not get a clean boundary either, because the lasagna pushes in from every side. Priorities mutate mid-sprint when someone upstream remembers something. The stack is often mandated by a global function that has never run your workload, so you build on tooling you would not have chosen. And the blindness runs both ways: the engineers cannot see the big picture, and the people setting direction cannot see the ground truth.

So the goal is not a wall. It is to shrink how much of that mess has to pass through a single human translator, and to make each end a little less blind to the other. A few moves that help, none of them a cure:

  • Automate the interface, both ways. Stop hand-translating reality for management: instrument the systems so the dashboards expose the exact utilisation, SLA, and cost numbers the OM and SDM need, straight from the source of truth. Then run the same pipe in reverse, so the business context, the why and the real constraint, reaches the team without being whispered down through five layers. The engineer should not be the translation pipeline in either direction.
  • Give the technical track real parity. A principal engineer has to sit at the same height as a unit manager, with the authority to refuse and not merely to advise. If technical judgement is permanently subordinate to people-management judgement, the architecture is decided by administrative convenience every time, and your strongest builders correctly read that as the signal to go.
  • Make the outcome so decisive there is nothing to manage. When management asks for "more visibility," they usually mean more meetings. Counter it by engineering the problem out of existence so the symptom never reaches them. A fleet that remediates its own drift, a zero-trust boundary that holds without a human in the loop, a system that simply does not page, leaves the coordination layer with nothing left to coordinate.
  • Feed it loose fitness functions, not tight ones. Expose the outcome, is the service up, is the client renewing, is the margin holding, and stay silent on the method. The moment you instrument the individual instead of the result, you force every person to manufacture a legible reason to exist, Goodhart's law does the rest, and you have rebuilt the lasagna inside a dashboard. Measure the team, never the people inside the layers.

The lasagna grows because every layer can justify itself locally: each manager really is solving a real local problem. It only looks absurd from the bottom, from the one seat that can see the whole stack at once and is too buried under it to be heard. The fix is not to climb the stack. It is to make the part of the organisation that touches reality small, sovereign, and loud enough that the layers above have to listen to the system instead of to each other.

Enterprise delivery grows sideways: around the people building the thing, an organisation stacks others to manage the client, hold the margin, and coordinate the coordination. Every role is real work, but each sits a layer further from the thing being built, and stack enough of them and you get a lasagna, with the one role still connected to reality, in the typical IT-delivery case the engineer, at the bottom.

Every layer is a lossy compressor

Each layer is added to "help", and each is another round of broken telephone. A precise fact at the terminal is re-rendered at every hop until "connection-pool exhaustion under a retry storm" reaches the top as "the team is on it", and the reason the work matters is whispered back down until it lands as a ticket with a deadline and no context.

The loss runs both ways, and no short list of why is complete: bad news is softened at every step up, because nobody wants to hand their boss a crisis, so a real problem reaches the top sounding minor; incentives bend each retelling toward the teller's scorecard; and the tribal knowledge nobody wrote down drops first.

A sergeant decides and owns the call. A middle manager holds a veto and owns nothing. That is the whole difference.

What it kills

  • Outcome engineering. Nobody is paid to fix root cause, so you patch forever and never architect.
  • The engineer's job. The one who touches reality becomes an API between the systems and the business, and the people who can build leave.
  • Accountability. Everyone owns a slice, so nobody owns the failure and the blame routes in a circle. That void is not the bug, it is what the lasagna is for.

None of this is an argument against tiers, but against their corruption: armies scaled on sergeants trusted to decide and own the call, while the lasagna hands a layer a veto and no outcome. And it traps everyone, not just the bottom: every chair feels like the only sane one, each holds a real sliver of the truth, and no chair can see the others'.

The fix is a smaller, sovereign cell

You cannot fix it from inside, and you cannot fully wall it off either: priorities mutate, the stack is mandated from above, both ends are half-blind. The goal is narrower, shrink how much routes through one human translator and make each end less blind to the other. Automate the interface both ways (ground truth up, context down), give the technical track real parity with the authority to refuse, engineer the problem out until there is nothing left to coordinate, and measure the team on loose outcomes, never the individual, or Goodhart rebuilds the lasagna in a dashboard.


Sources