Kevin Isenberg
Programm, Governance

Steuerung ohne Weisungsbefugnis

By Kevin Isenberg

August 3, 2026 · 2 Min. Lesezeit

Zeige Zusammenfassung Teile den Beitrag Beitrag drucken

Kein einziges Team in meinem aktuellen Programm berichtet mir. Mehrere sitzen in derselben Organisation, nur unter anderer Leitung. Der Rest gehört zu Partnerorganisationen, in drei verschiedenen Ländern.

Das ist keine Ausnahmesituation. Es ist der Normalzustand von Programmarbeit ab einer gewissen Größe — und das meiste, was dazu geraten wird, greift zu kurz.

Eskalation ist ein Beleg, kein Mechanismus

Wenn man nicht anweisen kann, ist der erste Reflex, einen Weg zu jemandem zu bauen, der es kann. Eskalationsmatrizen. Sponsorentermine. Ein RACI mit dem eigenen Namen in der A-Spalte.

Das ist alles sinnvoll zu haben. Es ist nur nichts, worauf man sich verlassen sollte.

Eine Eskalation ist ein Beleg — der Nachweis, dass man etwas angesprochen hat. Wenn man sie braucht, ist der Preis meist schon bezahlt: die Verzögerung ist eingetreten, die Abhängigkeit gerissen, und man verhandelt nicht mehr über Reihenfolge, sondern darüber, wer es trägt.

Eskalation skaliert außerdem schlecht. Drei-, viermal geht das, dann ist man derjenige, der eskaliert — und Leute fangen an, einen zu umgehen. Der Mechanismus, der Ausrichtung schaffen sollte, wird still zum Grund, warum man Dinge nicht mehr früh erfährt.

Was tatsächlich gewirkt hat: Nachvollziehbarkeit

Was Teams über drei nationale Clouds hinweg ausgerichtet hat, war weder Weisungsbefugnis noch Eskalation. Es war, die Logik von Entscheidungen so sichtbar zu machen, dass Menschen sie vorhersagen konnten.

Zwei Mechanismen haben den Großteil der Arbeit gemacht.

Priorisierungskriterien, schriftlich. Keine Prioritätenliste — die Regeln, nach denen etwas Priorität bekommt. Der Unterschied wiegt schwerer, als er klingt. Eine Liste lädt zum Streit über Platzierungen ein. Kriterien heben die Diskussion eine Ebene höher, nämlich auf die Frage, ob die Kriterien richtig sind — und die führt man einmal und nutzt sie danach wieder. Teams, die sich über Ergebnisse uneinig waren, konnten sich über den Maßstab einigen.

Freigabepunkte mit expliziten Bedingungen. „Fertig” ist sonst eine Meinung, und Meinungen halten einer Prüfung nicht stand. Ein Freigabepunkt, der benennt, was wahr sein muss und wer es bestätigt, macht Betriebsreife zu etwas, das auch jemand prüfen kann, der nicht im Raum war.

Beides braucht keine Weisungsbefugnis. Beides braucht, dass man Dinge aufschreibt und sich zuerst selbst daran hält — sichtbar, auch wenn die Antwort für einen selbst unbequem ist.

Regulatorische Grenzen sind organisatorisch, bevor sie technisch werden

Die Programme, in denen ich arbeite, laufen unter Auflagen dazu, wo Daten liegen und wer sie berühren darf. Es ist verlockend, das als Engineering-Problem zu behandeln: Kontrolle bauen, Kontrolle nachweisen, fertig.

In der Praxis ist die Kontrolle selten das Schwierige. Schwierig ist die Einigung darüber, wer sie verantwortet, wer ihre Wirksamkeit nachweist und wer nachts geweckt wird, wenn sie versagt. Das sind organisatorische Fragen im technischen Kostüm. Beantwortet man sie spät, bekommt man eine Kontrolle, die technisch existiert und betrieblich nicht.

Deshalb ist „die Verantwortlichkeiten klären wir später” in regulierten Vorhaben teurer als anderswo. Später heißt praktisch: nachdem ein Audit gefragt hat.

Der unbequeme Teil

Steuerung über Nachvollziehbarkeit startet langsamer. Kriterien zu schreiben, die einer Prüfung standhalten, dauert länger, als eine Entscheidung zu verkünden — und es gibt am Anfang eine Strecke, auf der eine Ansage offensichtlich schneller wäre. Diese Strecke ist real, und man muss sie aushalten.

Es zahlt sich aus, weil es sich verzinst. Eine Entscheidung, die man trifft, ist eine Entscheidung wert. Eine Regel, die Menschen ohne einen anwenden können, ist jede Entscheidung wert, die sie danach selbst treffen — und in einem Programm, das übergeben werden soll, war genau das immer das Ziel: nicht im Raum zu sein.