Wenn alles brennt: Vom Priorisieren zum Triagieren

Montagmorgen, 8:47 Uhr. Das Ticketsystem zeigt 14 offene P1-Tickets. Drei Kunden eskalieren gleichzeitig. Ein Deployment von Freitag hat einen kritischen Fehler in die Produktion gebracht. Das Monitoring schlägt an, weil ein Drittsystem nicht mehr antwortet. Und im Slack-Channel fragt jemand, ob das Feature für den Messe-Auftritt nächste Woche noch rechtzeitig fertig wird.

Willkommen im Alltag vieler Entwicklungsteams. Irgendwann an diesem Morgen passiert etwas Entscheidendes: Das Team hört auf zu priorisieren – und beginnt zu triagieren.

Priorisierung: Das normale System

In einem gesunden Team gibt es eine klare Abstufung. P1 bedeutet: sofort handeln, alles andere wartet. P2 heißt: wichtig, hat eine Deadline, wird als Nächstes bearbeitet. P3 steht für: relevant, aber ohne festen Zeitdruck.

Dieses System funktioniert, solange die Verteilung stimmt. Ein paar P1-Tickets pro Woche sind normal. Sie unterbrechen den Arbeitsfluss, aber das Team kann sie einordnen, abarbeiten und danach weiterarbeiten. Die Prioritäten geben Struktur. Sie beantworten die Frage: Was ist gerade am wichtigsten?

Problematisch wird es, wenn diese Frage keine brauchbare Antwort mehr liefert – weil fast alles gleich wichtig ist.

Triage: Ein Begriff aus der Notfallmedizin

Der Begriff Triage stammt aus der Katastrophenmedizin. Wenn nach einem Unglück mehr Verletzte eingeliefert werden, als behandelt werden können, sortieren Ärzte nicht mehr nach Schwere der Verletzung allein. Sie entscheiden: Wem kann mit den vorhandenen Mitteln am effektivsten geholfen werden? Wer hat auch ohne Behandlung eine Chance? Und – das ist der harte Teil – wem kann man nicht mehr helfen, selbst wenn man es wollte?

Es geht nicht um Fairness. Es geht um Schadensbegrenzung.

In der Softwareentwicklung bedeutet Triage: Das Team kann nicht mehr alles liefern, was wichtig ist. Es reicht nicht, Aufgaben zu sortieren. Es muss entschieden werden, was aktiv nicht gemacht wird – obwohl es eigentlich gemacht werden müsste.

Die Symptome des Absturzes

Der Übergang von Priorisierung zu Triage passiert selten über Nacht. Er schleicht sich ein. Typische Anzeichen:

• Fast alle Tickets sind P1. Wenn alles kritisch ist, ist nichts mehr priorisiert. Die Kategorie verliert ihre Bedeutung.
• Ständiges Firefighting ohne echten Abschluss. Tickets werden bearbeitet, aber nie wirklich gelöst. Workarounds stapeln sich, echte Fixes werden verschoben.
• Technische Schulden und Architektur verschwinden vom Radar. Niemand spricht mehr über Refactoring oder Systemverbesserungen. Dafür ist keine Zeit – und die wird auch nicht kommen.
• Psychische Belastung und Burnout. Entwickler arbeiten nicht mehr an Lösungen, sondern an Schadensbegrenzung. Das Gefühl, nie fertig zu werden, wird zum Dauerzustand. Motivation erodiert.

Warum mehr Personal nicht hilft

Die naheliegende Reaktion: mehr Leute einstellen. Schnell skalieren. Kapazität aufbauen.

In der Theorie klingt das logisch. In der Praxis macht es die Situation kurzfristig oft schlimmer. Neue Mitarbeiter brauchen Onboarding. Onboarding kostet Zeit – die Zeit der erfahrenen Entwickler, die gerade im Krisenmodus arbeiten. Größere Teams brauchen mehr Abstimmung, mehr Kommunikation, mehr Meetings. Die Koordinationskosten steigen überproportional.

Frederick Brooks hat das vor über 50 Jahren formuliert: „Adding manpower to a late software project makes it later.“ Es ist immer noch wahr.

Das heißt nicht, dass Wachstum falsch ist. Aber es ist keine Notfallmaßnahme. Es ist eine strategische Entscheidung, die Monate braucht, um zu wirken.

Der Weg heraus: Radikale Ehrlichkeit

Wenn ein Team im Triage-Modus steckt, gibt es nur einen Weg heraus: Führungskräfte müssen radikal ehrlich sein. Gegenüber dem Team, gegenüber Stakeholdern, gegenüber sich selbst.

Das bedeutet konkret:

• Klare Prioritäten setzen. Nicht fünf Dinge gleichzeitig als „Top-Priorität“ deklarieren. Eine Sache ist die wichtigste. Der Rest wartet.
• Mut zu unpopulären Entscheidungen. Projekte stoppen. Features streichen. Kunden sagen, dass ein Termin nicht gehalten wird. Das ist unbequem, aber notwendig.
• Schutzräume schaffen. Das Team braucht Zeit, die nicht durch Tickets getrieben wird. Zeit für echte Fixes statt Workarounds. Zeit, um technische Schulden abzubauen.
• Transparent kommunizieren. Wenn die Situation ernst ist, muss das ausgesprochen werden. Nicht als Schuldzuweisung, sondern als gemeinsame Standortbestimmung.

Führung zeigt sich nicht darin, allem zuzustimmen. Führung zeigt sich darin, Nein zu sagen – rechtzeitig und begründet.

Krise ist normal. Dauerkrise nicht.

Jedes Team erlebt Phasen, in denen es eng wird. Ein kritischer Release, ein unerwarteter Ausfall, ein Quartal mit zu vielen parallelen Anforderungen. Das gehört dazu. Kurzfristige Triage ist ein legitimes Werkzeug.

Aber wenn Triage zum Normalzustand wird, verliert das Team die Kontrolle. Nicht sofort, aber stetig. Erst über die Qualität. Dann über die Roadmap. Und irgendwann über die Motivation der Menschen, die jeden Tag versuchen, das Unmögliche möglich zu machen.

Der Moment, in dem Priorisierung nicht mehr reicht, ist der Moment, in dem Führung gefragt ist. Nicht als Management-Buzzword, sondern als konkrete Handlung: entscheiden, kommunizieren, schützen.