L1/L2/L3 at Scale: Where the Tiered Support Model Breaks

The first time I built a support function, the tiered model felt like a gift. L1 takes the call, resets the password, follows the runbook. L2 picks up what L1 can't solve. L3 — the engineers — handle the gnarly stuff that needs a code change or a deep system dig. Clean. Legible. Easy to explain to a board.

And for a long time, it works. With one product, one codebase, and forty engineers, the tiered model is genuinely the right answer. Tickets flow up. Each tier filters out what it can handle and passes the rest along. The escalation path is a straight line.

Then you cross some invisible threshold — somewhere around 150 engineers, a dozen teams, several products sharing infrastructure — and the model quietly stops working. Not with a bang. With a slow accumulation of stuck tickets, finger-pointing, and a tier-3 queue that nobody wants to look at.

I've watched this happen more than once. The painful part is that nobody decides to break it. The org just grows past the point where "up" is a meaningful direction, and the tiered model keeps insisting that it isn't.

Why "up" stops being a direction

The whole tiered model rests on one assumption: that a harder problem lives at a higher tier. L1 is shallow, L3 is deep, and escalation means handing the ticket to someone who knows more.

That assumption holds when there is one system to know. It falls apart the moment knowledge stops being vertical and starts being horizontal.

At scale, the hard part of a ticket usually isn't depth. It's location. The customer's checkout is failing — is that the payments team, the cart team, the identity team whose token expired, or the platform team whose rate limiter is throttling the lot? None of those is "more senior" than the others. They're sideways from each other. L3 doesn't know the answer because there is no single L3 who owns the whole path.

So the engineer at "tier 3" becomes a router. They spend their day figuring out which of nine teams owns the broken thing, then re-assigning the ticket. That's not depth. That's a switchboard. And it's a miserable job that burns out your best people fast.

This is the core break: the tiered model optimises for escalation when the real problem is routing. Up versus down is the wrong axis once ownership is distributed across teams.

The three ways it actually breaks

When I'm assessing a support org that's straining, I look for three specific failure patterns. They almost always show up together.

The escalation bottleneck

Everything funnels toward a small number of senior engineers because they're the only ones who understand how the systems connect. The org calls them L3. In practice they're a human dependency graph.

The symptom is easy to spot: ask who can resolve a cross-system incident and you get three names. Those three are in every war room, every escalation, every "quick question" on Slack. Their calendars are wrecked. They can't ship anything because they're the load-bearing wall for support.

This isn't a staffing problem you can hire your way out of, because the bottleneck is knowledge concentration, not headcount. You can add five more L3s and the same three names still get pulled into everything, because the new people don't have the cross-system context — and the tiered model gives them no structured way to acquire it.

Tier 3 becomes a graveyard

The second pattern is the dead queue. Tickets that don't have an obvious owner get escalated to L3 "to investigate," and then they sit. Nobody is accountable for closing them because nobody is sure they belong to them.

I've opened tier-3 queues and found tickets aging past ninety days. Not because they were impossible — because each was a hot potato. Every team that touched it had a plausible reason it wasn't theirs. The ticket bounced until it stopped bouncing, and then it just decayed in the queue.

A graveyard queue is the single clearest signal that escalation has replaced ownership. When "escalate to L3" means "make it someone else's ambiguity," you've lost.

Ownership ambiguity at the seams

The third break is the one that does the real damage, because it's where customers actually get hurt. Most painful enterprise incidents don't live inside one team's system. They live at the seams between systems — the integration, the shared queue, the contract between two services.

The tiered model has nothing to say about seams. It assumes every ticket has a tier. But a seam belongs to two teams, which in practice means it belongs to neither. So the incident sits in the gap while both teams wait for the other to move.

If you want to know where your support org will fail, map your team boundaries and look at what falls between them. That's where the tiered model is silent, and that's where things rot.

What replaces it

The fix isn't a better escalation matrix. It's accepting that at scale, support is a routing-and-ownership problem, and routing tickets sideways to the team that owns the code beats routing them up to a generalist who doesn't.

Three patterns do this. They're not mutually exclusive — most mature orgs run a blend — but each has a distinct shape and a distinct cost.

Embedded support

You put support capability inside the product teams. Instead of a central tier-3 queue that all teams escalate into, each team owns the support load for what it builds. Tickets route to the owning team, not up a ladder.

This is the cleanest answer to ownership ambiguity. The team that wrote the code answers for the code. No routing switchboard, no graveyard queue, because the owner is unambiguous.

The cost is real, though. Embedded support taxes your product teams' velocity directly — every hour on support is an hour not shipping features. If you don't budget for it explicitly, support work loses every prioritisation fight against the roadmap, and the embedded model silently rots into "we'll get to it." You have to protect the capacity, usually with a rotation so one person carries support each week and the rest stay heads-down.

Reach for embedded support when teams have clear, stable ownership of well-bounded services and the support load per team is steady enough to plan around. It's the default for a mature you-build-it-you-run-it org.

Swarming

Swarming throws out tiers entirely for a class of problems. Instead of escalating a complex ticket up a chain, you pull the right people together — across teams — to solve it collaboratively, in one room or one channel, then disband.

This is the direct answer to the seam problem and the cross-system incident. Nobody routes the ticket through nine teams. The people who collectively own the path swarm it, fix it, and capture what they learned. It's fast, and it spreads context — which slowly dismantles the escalation bottleneck, because more people see the cross-system picture each time.

The cost is coordination. Swarming is expensive per incident — you're pulling multiple people off their work simultaneously. Do it for everything and you'll grind the org to a halt with constant context-switching. It also needs real discipline: someone has to own the swarm, drive it to resolution, and make sure the learning gets written down. Without that, a swarm is just a crowded, expensive call.

Reach for swarming when the problem is genuinely cross-system, high-impact, and doesn't have a single obvious owner — the exact case the tiered model handles worst. Reserve it for those. Don't swarm a password reset.

You-build-it-you-run-it

The strongest pattern, and the hardest to install, is full operational ownership: the team that builds a service runs it in production, carries its pager, and answers for its support. There is no separate tier to escalate to, because running the thing is part of building it.

This is what actually kills the bottleneck and the graveyard for good. There's no central L3 to overload, because operational knowledge sits with the people who hold the code. Feedback is tight — the team that gets woken up at 3am has a direct, personal incentive to fix the flaky thing properly rather than paper over it.

The cost is the steepest of the three, and it's mostly cultural and structural. You-build-it-you-run-it only works if teams have genuine ownership — real boundaries, real autonomy, and the authority to fix their own systems. Bolt operational responsibility onto teams that don't control their own dependencies and you've just handed them a pager for problems they can't solve. That's worse than the tiered model, not better.

It also doesn't scale down. You still need a human front door — someone to take the customer's first contact, triage, and route. You-build-it-you-run-it replaces tier 3, not tier 1.

Reach for you-build-it-you-run-it when you have, or are willing to build, teams with real end-to-end ownership and the organisational maturity to support it. It's a destination, not a quick fix.

The thread running through all three

If you've read anything on team topologies, the through-line here will be familiar: support follows ownership, and ownership follows team boundaries. The tiered model breaks at scale precisely because it ignores this. It treats support as a separate vertical hierarchy bolted onto an org whose real structure is horizontal.

Every replacement pattern is, underneath, the same move — push the support responsibility to wherever the ownership actually lives, and stop pretending a generic "higher tier" can stand in for the team that wrote the code.

Which is also why you can't fix support in isolation. If your team boundaries are a mess — blurry ownership, shared services nobody owns, services that span five teams — no support model will save you. The tiered model hid that mess by funneling everything to a few heroes. Embedded support, swarming, and you-build-it-you-run-it all expose it, because they demand clear ownership to function. That exposure is a feature. It tells you where the real work is.

The bottom line

The L1/L2/L3 model isn't wrong. It's just scoped. It works for one product, one codebase, and a small enough org that "escalate up" points at a real person who can actually help.

Cross into enterprise scale and the axis flips. Tickets need to go sideways, to the teams that own the systems — not up, to generalists who become routers and then bottlenecks. The warning signs are concrete: three names in every war room, a tier-3 queue full of ninety-day-old hot potatoes, incidents rotting in the seams between teams.

When you see those, don't reach for a better escalation matrix. Reach for the pattern that matches your reality. Embedded support if your teams own clean services. Swarming for the genuinely cross-system fires. You-build-it-you-run-it if you're ready to make ownership real.

And before any of it, look hard at your team boundaries. That's the thing the tiered model was hiding. Fix that, and the right support model mostly falls out of it on its own.