Zum Inhalt springen
Auf dieser Seite

Technische Führung: Gib Autonomie einen zeitlichen Rahmen

Technische Führung: Gib Autonomie einen zeitlichen RahmenKI-generiertes Bild

Ich habe festgestellt, dass Freiraum für Entscheidungen schnell unklar werden kann, wenn erwartetes Ergebnis und Zeitpunkt der Überprüfung nur implizit bleiben.

Besonders deutlich wurde mir das in einer Diskussion, in der das Team mehrere sinnvolle Möglichkeiten hatte, mit einem operativen Problem umzugehen. Ich hatte selbst eine bevorzugte Lösung, doch die Gruppe wollte einen anderen Weg ausprobieren. Mein erster Impuls war, die Diskussion offen zu lassen und dem Team Raum zu geben. Dadurch entstand Ownership, gleichzeitig blieb eine wichtige Frage unbeantwortet: Wann würden wir eigentlich wissen, ob dieser Ansatz gut genug funktioniert?

Was fehlte, war ein klarer zeitlicher Rahmen

Sobald wir das erwartete Ergebnis und einen konkreten Zeitpunkt für die Überprüfung festgelegt hatten, wurde die Diskussion einfacher. Das Team konnte seinen eigenen Ansatz ausprobieren, ohne ständig neue Zustimmung einzuholen, und ich musste nicht jede Umsetzungsentscheidung steuern. Wir hatten lediglich vereinbart, welches Ergebnis bis zu einem bestimmten Zeitpunkt sichtbar sein sollte. Damit gab es einen klaren Moment, an dem wir gemeinsam prüfen konnten, ob der Ansatz funktioniert.

Freiheit bei der Umsetzung, Klarheit beim Ergebnis

Seitdem trenne ich bewusster zwischen Freiheit bei der Umsetzung und Klarheit beim Ergebnis. Wenn ein Team selbst entscheiden kann, wie es ein Problem löst, versuche ich vor dem Zurücktreten drei Dinge deutlich zu machen: welches Ergebnis zählt, welche Rahmenbedingungen feststehen und wann wir bewerten, ob der gewählte Weg ausreicht.

Ein gemeinsamer Bezugspunkt

Gerade der zeitliche Rahmen hilft dabei, zwei typische Probleme zu vermeiden. Ohne ihn kann eine Führungskraft zu früh eingreifen, weil die Unsicherheit unangenehm wird. Gleichzeitig kann ein Team zu lange an einem Ansatz festhalten, weil nie festgelegt wurde, wann eine Neubewertung stattfinden soll. Ein klarer Review-Zeitpunkt gibt beiden Seiten einen gemeinsamen Bezugspunkt.

Es muss kein formaler Meilenstein sein

Dafür braucht es keinen formalen Meilenstein. Bei einer kleinen operativen Entscheidung kann das das Ende des Tages sein. Bei einem technischen Experiment vielleicht nach einigen Iterationen. Entscheidend ist, dass das Team weiß, wann das Ergebnis betrachtet wird und welche Hinweise dabei relevant sind.

Ich sehe das inzwischen als eine praktische Möglichkeit, Ownership zu unterstützen und gleichzeitig Accountability sichtbar zu halten. Das Team verantwortet den Ansatz. Die Führungskraft sorgt dafür, dass Ergebnis und Rahmenbedingungen klar genug bleiben, damit das Experiment eine sinnvolle Grenze hat.

Die Frage, die ich heute stelle

Eine Frage, die ich in solchen Situationen inzwischen nutze, lautet:

Wenn wir dem Team erlauben, seinen bevorzugten Ansatz auszuprobieren, wann überprüfen wir das Ergebnis, und was würde uns dazu bringen, den Kurs zu ändern?

Diese kleine Klarstellung schafft oft mehr hilfreiche Autonomie als eine weitere Diskussionsrunde.

Wenn ihr ein Team führt, wie geht ihr mit dieser Spannung zwischen Autonomie und Accountability um? Wenn das Team seinen eigenen Ansatz ausprobieren darf, wie legt ihr den Review-Zeitpunkt fest, und woran erkennt ihr, dass es Zeit für einen Kurswechsel ist? Schreibt eure Gedanken gerne in die Kommentare oder meldet euch direkt bei mir.

Ich lese jede Rückmeldung.