How to Enable L1, L2 and L3 Support

Turning a flat, overloaded team into a layered support model that scales, without the org-chart theatre. This is the work I do with engineering teams, usually in places where downtime has a price tag attached.

Every flat team works fine right up until the night it doesn’t. They all find out the same way: an alert fires, three people open the same dashboard, and twenty minutes pass before anyone admits they assumed someone else had it. Nobody owned the incident because, on a flat team, everyone owns everything. Which is the same as no one owning anything.

I’ve seen what an unowned gap actually costs. A client in the financial sector had hit a connectivity fault once before. The vendor shipped a fix, and it got implemented, but only halfway. The missing half was the backup line, which was meant to be configured on our side and never was. A year later the primary connection dropped, the failover everyone assumed existed wasn’t there, and the market-data feed went dark. Traders stopped receiving rates and sat watching trades they couldn’t make. We escalated hard, on our side and the vendor’s, and it still took the vendor walking the connection end to end to notice the backup line had never been set up. Two hours. An eternity in a trading room. Afterwards we ran a proper post-mortem, owned the part that was ours, stood up reactive monitoring on the connection, and started actually testing failover instead of trusting it. The fix from a year earlier had been real. It just was never finished, and nobody owned finishing it.

Seniority becomes the only triage mechanism. Your best engineer becomes the default first responder for everything, their week gets shredded by interruptions a junior with a decent runbook could have closed in ten minutes, and the platform work that would prevent the next page never gets done. Knowledge stays locked in two or three heads, so onboarding crawls and holidays are tense.

Layering the team fixes this, though not for the reason people assume. It’s not about rank. It’s about knowing, before the next 3 AM page, who picks it up and when it leaves their hands.

What the three layers actually do

The labels are old, but the jobs underneath them have moved on. L1 isn’t a phone queue, and L3 isn’t a fancier firefighter.

Tier	Core function	What they own	Escalates when	First target
L1 — First response	Service desk	Triage, containment, runbooks, ticket ownership, comms	Outside the runbook, or response SLA breached	First response ≤ 15 min (P1)
L2 — Platform engineers	Incident management	Diagnosis and fix, runbook upkeep, pipelines, reliability work	Cause is systemic or needs a design change	Fix or workaround ≤ 4 h (P1)
L3 — Architects	Problem management	Root cause, architecture, standards, mentoring	Recurring cause, regulatory impact, or a major incident	Post-mortem / design ≤ 48 h; off the rotation by default

The two mistakes I see most often hide inside that table. The first is treating L1 as a relay that only re-routes tickets. If your first line has no authority to fix anything, you haven’t built support, you’ve added a hop. Give them a real runbook library and let them close the common cases. The second is leaving L3 on the front line. An architect’s job is to make incidents rarer and smaller, not to keep getting paged for the same one. If they’re firefighting every week, that’s a runbook gap wearing a staffing costume.

One more thing worth saying out loud, because it’s where most tiered models quietly fail: not every incident should climb the ladder one rung at a time. For a genuine P1, sequential escalation is just downtime with extra steps. Keep the explicit path for the routine ninety percent. For the majors, pull the right people in together regardless of tier. That’s also, for what it’s worth, where current ITIL thinking has landed.

Incident flow across L1, L2 and L3, with a swarming path for major incidents and a continual-improvement loop back into runbooks

The first 90 days

You can’t declare an L1 team into existence on a Monday. You build the conditions that make one possible, in roughly this order.

Weeks 1–2. Read the last quarter of incidents. Not the dashboards, the actual tickets. Sorted by category and business impact, the picture is always lopsided: a handful of failure modes eat most of the senior time. That list is the whole transformation in miniature; everything after it is just working the list down.

Weeks 3–6. Build the runbook spine. This is where the real work lives, and where most teams have nothing usable. “Check the logs and restart if needed” is not a runbook. It’s a shrug in prose. A runbook names the dashboard, the log line, the exact command, and how you know it worked. Until your top ten failure modes are written down that precisely, you don’t have an L1 layer. You have juniors guessing.

Weeks 5–8. Make routing and SLAs mechanical. With runbooks in place, the escalation matrix lives in the runbook system as a table, not in someone’s memory. On-call policies and ticket timers escalate automatically on breach. This kills the worst habit in incident response: the “give me another ten minutes, I’ve nearly got it” that turns a fifteen-minute handoff into a two-hour outage. The rule I enforce is blunt. Escalate on the clock, not on a hunch.

Weeks 8–12. Protect L3 and close the loop. Recurring causes get pulled out of firefighting and into deliberate root-cause work. A short weekly review lets L1 surface the patterns that are invisible one ticket at a time. That review becomes your improvement backlog, generated for free by the people closest to the failures. By the end of the quarter the change shows up in numbers you can put on a slide: share of incidents closed at L1, time-to-escalate, and the senior hours handed back to actual engineering.

Where to start

Write the runbooks. The tier structure mostly assembles itself around them. And if you can’t yet write down how to handle your top ten alerts, that’s the finding. It’s exactly where we’d begin.

This is the transformation I run: flat, interrupt-driven teams turned into something that gets steadier with each incident instead of more brittle. If that sounds like your team right now, get in touch.

Ein flaches, überlastetes Team in ein gestaffeltes Support-Modell verwandeln, das skaliert. Ohne Organigramm-Theater. Das ist die Arbeit, die ich mit Engineering-Teams mache, meistens dort, wo Ausfallzeiten einen Preisschild tragen.

Jedes flache Team funktioniert gut bis zu der Nacht, in der es das nicht mehr tut. Sie erleben es alle auf die gleiche Art: Ein Alert schlägt an, drei Personen öffnen dasselbe Dashboard, und zwanzig Minuten vergehen, bevor jemand zugibt, dass er davon ausging, die andere Person hätte es. Niemand hat den Incident übernommen, weil in einem flachen Team alle für alles zuständig sind. Was dasselbe ist, als wäre niemand zuständig.

Ich habe selbst erlebt, was eine unbesetzte Lücke kostet. Ein Kunde im Finanzbereich hatte einmal einen Konnektivitätsfehler gehabt. Der Hersteller lieferte einen Fix, der implementiert wurde, aber nur zur Hälfte. Die fehlende Hälfte war die Backup-Leitung, die auf unserer Seite hätte konfiguriert werden müssen und es nie wurde. Ein Jahr später fiel die primäre Verbindung aus. Der Failover, von dem alle ausgingen, existierte nicht, und der Marktdaten-Feed fiel aus. Trader empfingen keine Kurse mehr und starrten auf Trades, die sie nicht ausführen konnten. Wir eskalierten hart, auf unserer Seite und beim Hersteller, und es dauerte trotzdem, bis der Hersteller die Verbindung von Ende zu Ende durchging und feststellte, dass die Backup-Leitung nie eingerichtet worden war. Zwei Stunden. Eine Ewigkeit in einem Handelsraum. Danach führten wir ein sauberes Post-Mortem durch, übernahmen Verantwortung für unseren Teil, richteten reaktives Monitoring auf die Verbindung ein und begannen, den Failover tatsächlich zu testen, anstatt ihm zu vertrauen. Der Fix von einem Jahr zuvor war real gewesen. Er war nur nie fertiggestellt worden, und niemand hatte die Verantwortung übernommen, ihn fertigzustellen.

Seniorität wird zum einzigen Triage-Mechanismus. Der beste Engineer wird zum Standard-Ersthelfer für alles; seine Woche wird durch Unterbrechungen zerstückelt, die ein Junior mit einem vernünftigen Runbook in zehn Minuten hätte schliessen können, und die Plattformarbeit, die den nächsten Alert verhindern würde, kommt nie dran. Das Wissen bleibt in zwei oder drei Köpfen gesperrt, das Onboarding kriecht voran, und Urlaubszeiten sind angespannt.

Das Team zu schichten löst das, allerdings nicht aus dem Grund, den die meisten annehmen. Es geht nicht um Dienstgrad. Es geht darum, vor dem nächsten 3-Uhr-Alert zu wissen, wer ihn aufnimmt und wann er die Hände wechselt.

Was die drei Schichten wirklich tun

Die Bezeichnungen sind alt, aber die Aufgaben darunter haben sich weiterentwickelt. L1 ist keine Telefon-Warteschlange, und L3 ist kein besserer Feuerwehrmann.

Stufe	Kernfunktion	Verantwortung	Eskaliert wenn	Erstes Ziel
L1 — Erstreaktion	Service Desk	Triage, Eindämmung, Runbooks, Ticket-Verantwortung, Kommunikation	Ausserhalb des Runbooks oder SLA verletzt	Erstreaktion ≤ 15 Min (P1)
L2 — Platform Engineers	Incident Management	Diagnose und Lösung, Runbook-Pflege, Pipelines, Reliability-Arbeit	Ursache ist systemisch oder erfordert eine Design-Änderung	Fix oder Workaround ≤ 4 h (P1)
L3 — Architekten	Problem Management	Ursachenanalyse, Architektur, Standards, Mentoring	Wiederkehrende Ursache, regulatorische Auswirkung oder Major Incident	Post-Mortem / Design ≤ 48 h; standardmässig nicht in der Rotation

Die zwei häufigsten Fehler verbergen sich in dieser Tabelle. Der erste ist, L1 als reine Weiterleitungsstelle zu behandeln. Wenn die erste Linie keine Befugnis hat, irgendetwas zu beheben, hat man keinen Support aufgebaut, sondern einen zusätzlichen Hop. Gib ihnen eine echte Runbook-Bibliothek und lass sie die gängigen Fälle schliessen. Der zweite Fehler ist, L3 an der Front zu belassen. Die Aufgabe eines Architekten ist es, Incidents seltener und kleiner zu machen, nicht, für den gleichen Incident immer wieder gerufen zu werden. Wenn sie jede Woche Brände löschen, ist das eine Runbook-Lücke im Personalverkleidung.

Noch etwas, das laut gesagt werden muss, weil es der Punkt ist, an dem die meisten gestaffelten Modelle still scheitern: Nicht jeder Incident sollte die Leiter Sprosse für Sprosse hochklettern. Bei einem echten P1 ist sequenzielle Eskalation nur Ausfallzeit mit zusätzlichen Schritten. Behalte den expliziten Pfad für die routinemässigen neunzig Prozent. Bei den grossen Fällen ziehst du die richtigen Personen gemeinsam ein, unabhängig von der Stufe. Das ist auch, nebenbei bemerkt, wo das aktuelle ITIL-Denken gelandet ist.

Incident-Fluss über L1, L2 und L3, mit einem Swarming-Pfad für Major Incidents und einer kontinuierlichen Verbesserungsschleife zurück zu den Runbooks

Die ersten 90 Tage

Man kann ein L1-Team nicht an einem Montag herbeierklären. Man baut die Voraussetzungen, die eines möglich machen, in ungefähr dieser Reihenfolge.

Wochen 1–2. Das letzte Quartal an Incidents lesen. Nicht die Dashboards, die eigentlichen Tickets. Sortiert nach Kategorie und Business-Impact ist das Bild immer unausgewogen: eine Handvoll Fehlermuster fressen den Grossteil der Senior-Zeit. Diese Liste ist die gesamte Transformation im Kleinformat; alles danach ist nur, sie abzuarbeiten.

Wochen 3–6. Das Runbook-Gerüst aufbauen. Hier liegt die eigentliche Arbeit, und hier haben die meisten Teams nichts Brauchbares. «Logs prüfen und bei Bedarf neu starten» ist kein Runbook. Es ist ein Schulterzucken in Prosa. Ein Runbook nennt das Dashboard, die Log-Zeile, den genauen Befehl und wie man weiss, dass es funktioniert hat. Solange die zehn häufigsten Fehlermodi nicht so präzise aufgeschrieben sind, gibt es keine L1-Schicht. Es gibt nur Junioren, die raten.

Wochen 5–8. Routing und SLAs mechanisieren. Mit Runbooks an Ort und Stelle lebt die Eskalationsmatrix im Runbook-System als Tabelle, nicht im Gedächtnis von jemandem. On-Call-Richtlinien und Ticket-Timer eskalieren automatisch bei Verletzung. Das tötet die schlimmste Gewohnheit in der Incident-Reaktion: das «Gib mir noch zehn Minuten, ich hab's fast», das aus einem 15-minütigen Übergabe einen zweistündigen Ausfall macht. Die Regel, die ich durchsetze, ist direkt. Eskaliere nach der Uhr, nicht nach dem Gefühl.

Wochen 8–12. L3 schützen und den Kreis schliessen. Wiederkehrende Ursachen werden aus dem Feuerwehreinsatz herausgelöst und in gezielte Ursachenarbeit überführt. Ein kurzes wöchentliches Review lässt L1 die Muster sichtbar machen, die Ticket für Ticket unsichtbar sind. Dieses Review wird zum Verbesserungs-Backlog, kostenlos generiert von den Personen, die den Fehlern am nächsten sind. Am Ende des Quartals zeigt sich die Veränderung in Zahlen: Anteil der bei L1 geschlossenen Incidents, Time-to-Escalate und die Senior-Stunden, die wieder echter Ingenieurarbeit zufliessen.

Wo anfangen

Runbooks schreiben. Die Stufenstruktur baut sich meist von selbst darum herum auf. Und wenn man die zehn häufigsten Alerts noch nicht aufschreiben kann, das ist der Befund. Genau dort würden wir beginnen.

Das ist die Transformation, die ich durchführe: flache, interrupt-getriebene Teams, die mit jedem Incident stabiler werden, statt fragiler. Wenn das nach dem eigenen Team klingt, nehmt Kontakt auf.