leadership
Notizen zur Führung von Engineering-Teams: Autonomie, Ownership, Accountability und andere zu guten Entscheidungen befähigen.
9 Artikel
Technische Führung: Eine Aufgabe hat einen Verantwortlichen. Die Zusage gehört dem Team.

Zusammenfassung Wenn zeitkritische Arbeit nicht vorankommt, muss jemand anders als der nicht verfügbare Assignee ausdrücklich die Entscheidung darüber tragen, was als Nächstes passiert.
Vor Kurzem habe ich erlebt, dass zwei Arbeitspakete fast zwei Wochen lang unangetastet blieben, obwohl beide klare Deadlines hatten.
Weiterlesen →Technische Führung: Späte Rahmenbedingungen sind ein Test für die Entscheidung

Zusammenfassung Prüfe eine späte Rahmenbedingung an den Gründen für die bevorzugte Option. Bewerte betroffene Kriterien neu und nutze die übrigen Überlegungen weiter.
Vor Kurzem war ich an einer Planungsentscheidung beteiligt, bei der zwei vernünftige Optionen zur Auswahl standen. Wir hatten praktische Rahmenbedingungen verglichen, betrachtet, wer teilnehmen konnte, Kosten und organisatorischen Aufwand abgewogen und nach und nach eine Präferenz entwickelt. Die Entscheidung war noch nicht endgültig, aber die Diskussion hatte bereits genug Eigendynamik entwickelt, dass sie sich fast abgeschlossen anfühlte.
Weiterlesen →Technische Führung: Eine Einladung schafft nur dann Ownership, wenn man sie wirklich ablehnen kann

Zusammenfassung Eine Einladung von einer Führungskraft kann aus einer Möglichkeit Compliance machen. Direkt sagen, ob sie erwartet oder freiwillig ist, und eine Absage gelten lassen.
Als das passierte, hatte ich begonnen, einige unserer wiederkehrenden technischen Gespräche für Menschen zu öffnen, die sonst nur das Ergebnis erhalten hätten. Der Grund ist der, den ich in Ownership beginnt vor der Entscheidung beschrieben habe: Ich wollte, dass Kolleginnen und Kollegen diesen Kontext direkt aufbauen, statt ihn immer über mich zu erhalten.
Weiterlesen →Technische Führung: Ownership beginnt vor der Entscheidung

Zusammenfassung Lade Menschen, die ähnliche Entscheidungen treffen werden, in relevante Gespräche ein. Halte Zusammenfassungen weiter verfügbar und verstehe mehr Selbstständigkeit als Ziel.
Eine Zeit lang habe ich Informationsfluss vor allem als Kommunikationsproblem betrachtet. Wenn in einer Architektur-, Betriebs- oder bereichsübergreifenden Diskussion etwas Wichtiges passiert ist, wollte ich sicherstellen, dass die relevanten Personen anschließend davon erfahren. Ich habe Entscheidungen zusammengefasst, Links geteilt und Notizen dort abgelegt, wo sie später auffindbar waren. Das hat Transparenz geschaffen, gleichzeitig wurde mir mit der Zeit eine Grenze dieses Ansatzes deutlich.
Weiterlesen →Technische Führung: Eine gute Impact Story braucht trotzdem eine messbare Richtung

Zusammenfassung Trennt lokalen Nutzen von erwarteter Bewegung. Fragt, was sich am Ergebnis ändern soll, und entscheidet mit offenen Augen, wenn die Antwort Lernen oder Risikoreduktion lautet.
Vor einer Planungsrunde fiel mir auf, dass ein Teil der benötigten Daten fehlte. Es gab bereits ein übergeordnetes Geschäftsziel, aber im Dashboard war nur schwer erkennbar, welchen Beitrag unser eigenes Produkt dazu leistete. Vor der Diskussion habe ich gemeinsam mit einem Kollegen eine Aufschlüsselung nach Kanälen ergänzt, die den Anteil unseres Produkts sichtbar machte. Sobald diese Sicht vorhanden war, konnten wir den aktuellen Stand direkt betrachten und fragen, wie jede geplante Initiative ihn verändern sollte.
Weiterlesen →Technische Führung: Aus einer Meinungsverschiedenheit eine testbare Entscheidung machen

Zusammenfassung Lange Debatte durch einen kleinen Spike ersetzen: erst die Kriterien vereinbaren, dann die Belege gemeinsam prüfen, dann entscheiden.
Vor Kurzem war ich in einer technischen Diskussion, die sich zunehmend um denselben Punkt drehte. Wir überlegten, wie wir einen Teil einer Frontend-Anwendung strukturieren sollten, und hatten zwei Ansätze, für die es jeweils gute Argumente gab. Der eine versprach eine klarere Trennung und eine konsistentere Struktur. Beim anderen stand die Sorge im Raum, dass wir diese Struktur mit zusätzlicher Indirektion bezahlen und spätere Änderungen dadurch schwerer nachvollziehbar machen würden.
Weiterlesen →Technische Führung: Trenne die Praxis von dem Problem, das sie lösen soll

Zusammenfassung Benennt zuerst Problem, Ergebnis und Rahmenbedingungen. Dann wird die vorgeschlagene Praxis eine Möglichkeit unter mehreren, und das Team kann das Problem behalten, auch wenn es die Lösung verwirft.
In einem Teamgespräch ging es darum, ob wir Test-driven Development einführen sollten. Die Diskussion hätte leicht in den üblichen Austausch über TDD übergehen können: Vorteile, zusätzlicher Aufwand und die Frage, ob diese Arbeitsweise zum Team passt.
Weiterlesen →Technische Führung: Wenn die Entscheidung nicht mehr bei euch liegt

Zusammenfassung Helft, das Problem zu klären, und tretet dann zurück: Bringt Entscheider und Betroffene direkt zusammen, statt die Entscheidung hin und her zu tragen.
Eine Situation, die ich erlebt habe, sieht so aus: Jemand bringt mir eine Anfrage, für die eine Ausnahme nötig ist, und diese Ausnahme kann nur gewähren, wer die Entscheidung verantwortet. Mein erster Impuls war früher, die Anfrage selbst weiterzutragen, den Kontext zu erklären, die Antwort zurückzubringen und die Rückfragen dazwischen zu übernehmen. Besser bewährt hat sich, die Anfrage gemeinsam zu schärfen und die betroffene Person dann direkt mit der entscheidungsbefugten Person zusammenzubringen, sodass die Begründung der Antwort aus erster Hand kommt statt über meine Nacherzählung.
Weiterlesen →Technische Führung: Gib Autonomie einen zeitlichen Rahmen

Zusammenfassung Autonomie funktioniert, wenn das Team den Ansatz trägt und die Führungskraft das Ergebnis, die festen Rahmenbedingungen und den Review-Zeitpunkt explizit macht.
In einer Diskussion über ein operatives Problem hatte das Team mehrere sinnvolle Möglichkeiten, damit 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. Ich wollte dem Team Raum für eigene Entscheidungen geben, gleichzeitig blieb eine wichtige Frage unbeantwortet: Wann würden wir eigentlich wissen, ob dieser Ansatz gut genug funktioniert?
Weiterlesen →