Technische Führung: Eine Aufgabe hat einen Verantwortlichen. Die Zusage gehört dem Team.

Ammar Najjar · Veröffentlicht am 31. Oktober 2026 · 4 Min. Lesezeitleadership

KI-generiertes Bild

Vor Kurzem habe ich erlebt, dass zwei Arbeitspakete fast zwei Wochen lang unangetastet blieben, obwohl beide klare Deadlines hatten.

An der Arbeit selbst hatte sich nichts Besonderes verändert. Die Anforderungen waren gleich geblieben, keine externe Abhängigkeit blockierte den Start, und das Team hatte genug Informationen, um loszulegen. Der Entwickler, der am stärksten mit den Themen verbunden war, war lediglich einen Teil dieser Zeit nicht verfügbar.

Zunächst wirkte das wie ein Kapazitätsproblem. Jemand fehlt, also verzögert sich die Arbeit. Je länger ich darüber nachdachte, desto deutlicher wurde jedoch ein anderes Problem. Meine Interpretation war, dass wir das Commitment so behandelt hatten, als könnte es nur mit der zugeordneten Person vorankommen.

Das Problem zu sehen, reicht nicht

Das fällt leicht nicht auf, weil das Modell meistens funktioniert. Ein Ticket wird zugeordnet, der Entwickler arbeitet daran, und das Team sieht Fortschritt. Die Schwäche wird erst sichtbar, wenn etwas den erwarteten Ablauf unterbricht: Krankheit, ungeplante Produktionsarbeit, eine unterschätzte Aufgabe oder eine Abhängigkeit, die plötzlich länger dauert.

Ich trenne inzwischen zwei Dinge, die früher ineinander verschwammen. Das erste ist die Ownership der Umsetzung, die der Assignee trägt: das Problem gut verstehen, die Arbeit vorantreiben und die täglichen Entscheidungen treffen. Das zweite ist die Awareness im Team: relevante Arbeit, die nicht mehr auf ihre Deadline zugeht, zu bemerken. Diese Awareness hat Bedeutung, aber wenn sie abstrakt allen gehört, fühlt sich vielleicht niemand dafür zuständig, sie in eine Entscheidung zu verwandeln.

Ein gemeinsamer Punkt der Neuverhandlung

Eine dritte Verantwortung entsteht, sobald der aktuelle Auslieferungsplan nicht mehr tragfähig ist: Jemand muss sicherstellen, dass die Awareness in eine Entscheidung überführt wird.

Ich betrachte ein Risiko für eine Deadline zunehmend als gemeinsamen Anlass, den Auslieferungsplan erneut zu prüfen. Wenn zeitkritische Arbeit nicht mehr vorankommt, sollte das Team überdenken, ob der aktuelle Auslieferungsplan noch glaubwürdig ist. Das ist derselbe Zug, den ich bei späten Restriktionen als Test einer Entscheidung beschrieben habe: Neue Information trifft ein, und statt die Entscheidung dem Schwung zu überlassen, prüft das Team sie an den Kriterien, die den aktuellen Plan ergeben haben. Hier ist das Kriterium schlicht die Zeit, und die Neuverhandlung gehört in die normale Planung und tägliche Abstimmung, besonders wenn die ursprüngliche Person nicht weiterarbeiten kann.

KI-generiertes Bild

Das entscheidende Signal ist nicht, dass jemand fehlt. Es ist, dass das Team relevante Arbeit auf eine Deadline zulaufen sieht, ohne dass jemand entscheidet, ob sich der Auslieferungsplan ändern muss. Die Lücke zeigt sich, wenn alle das Risiko sehen, aber niemand die Entscheidung über das Weitere trägt.

Warten sollte eine Entscheidung sein

Die Antwort muss nicht immer eine Neuzuordnung sein. Arbeit zwischen Entwicklern zu verschieben hat Kosten. Kontext muss aufgebaut, bisherige Überlegungen müssen übertragen und möglicherweise andere Arbeit unterbrochen werden. Manchmal ist Warten weiterhin die beste Entscheidung.

Das Team sollte sagen können: Wir wissen, dass diese Arbeit pausiert. Wir kennen die Deadline. Wir haben die Optionen geprüft und akzeptieren angesichts der Abwägungen bewusst das Risiko. Das ist etwas anderes, als später festzustellen, dass alle davon ausgegangen sind, die ursprüngliche Person werde irgendwann zurückkommen und einfach weitermachen. Lencioni vollzieht den gleichen Schritt in Die 5 Dysfunctions of a Team: In dysfunktionalen Teams werden Entscheidungen getroffen und danach stillschweigend untergraben, verschoben oder neu verhandelt. Engagement wird erst echt, wenn jemand bereit ist, die Entscheidung weiterzutragen, auch wenn sie nicht seine bevorzugte Option war.

Die Frage, die ich heute stelle

Eine kleine Praxis, die ich hilfreich finde, ist, eine Frage explizit zu machen, sobald zeitkritische Arbeit nicht mehr vorankommt:

Wer trägt jetzt die Entscheidung darüber, was mit dieser Arbeit passiert?

Das sollte eine benannte Person sein, ob nun der Tech Lead oder jemand anderes, den das Team für diesen Punkt ausdrücklich benennt. Diese Person muss die Arbeit nicht selbst umsetzen. Es ist derselbe Ownership-Instinkt, den ich bereits in diesem Beitrag über die Ownership einer Entscheidung beschrieben habe, nur hier auf eine Deadline angewandt. Ihre Verantwortung besteht darin, sicherzustellen, dass das Team bewusst zwischen Warten, Neuzuordnung, Scope-Reduktion, Verschiebung eines anderen Commitments oder einer neuen Deadline entscheidet, bevor die Zeit die Entscheidung übernimmt. Änderungen außerhalb der Entscheidungsbefugnis des Teams brauchen die Zustimmung der Personen, die die betroffene Priorität oder Zusage verantworten.

Wenn eine Person in deinem Team nicht verfügbar wird: Welcher Mechanismus verhindert, dass auch ihre wichtige Arbeit still mit ihr ausfällt?