Der Raid wiped. Zum vierten Mal. Und im Chat passiert danach immer dasselbe: Alle zeigen nach unten in der Gruppe. Niemand zeigt auf sich selbst.
Zwei Navy-SEAL-Offiziere, ein Häuserkampf in Ramadi, und ein Führungsprinzip, das seither in jedem Leadership-Regal steht: Extreme Ownership von Jocko Willink und Leif Babin. Die These ist unbequem: Es gibt keine schlechten Teams. Es gibt nur schlechte Leader.
In dieser Folge übersetze ich die Laws of Combat aus dem Buch in das, was passiert, wenn eure Raid-Gruppe – oder euer Sprint – zum wiederholten Mal scheitert.
Was diese Folge behandelt:
-
Extreme Ownership & No Bad Teams – warum die volle Verantwortung beim Leader liegt, und warum das keine Einbahnstraße ist: Der Leader erklärt, bis der Plan sitzt, jeder Einzelne fragt nach, bis das Warum sitzt
-
Believe & Check the Ego – warum gute Absichten der richtige Ausgangspunkt sind, auch wenn man sich das Vertrauen dafür manchmal erst erarbeiten muss
-
360-Grad-Feedback und Achtsamkeit – zwei Werkzeuge, um den eigenen blinden Fleck sichtbar zu machen: nach innen die eigene Ego-Reaktion erkennen, nach außen die Reaktionen anderer lesen lernen
-
Die vier Laws of Combat – Cover and Move, Simple, Prioritize and Execute, Decentralized Command, und wie Simon Sineks „Start with Why“ auf Decentralized Command trifft
-
Discipline Equals Freedom und die Dichotomie der Führung – warum jedes Prinzip aus dem Buch, übertrieben, ins Gegenteil kippt
Quellen & Buchempfehlungen:
Co-op Mode – Gaming trifft Leadership. Für alle, die Teams bauen, nicht nur Prozesse verwalten.
Mehr von Georg:
https://hofmann-freiburg.de
Auf LinkedIn vernetzen:
https://www.linkedin.com/georghofmann-digitalleadership
Der Raid wiped. Zum vierten Mal. Und im Chat passiert danach immer dasselbe: Alle zeigen nach unten in der Gruppe. Niemand zeigt auf sich selbst.
Zwei Navy-SEAL-Offiziere, ein Häuserkampf in Ramadi, und ein Führungsprinzip, das seither in jedem Leadership-Regal steht: Extreme Ownership von Jocko Willink und Leif Babin. Die These ist unbequem: Es gibt keine schlechten Teams. Es gibt nur schlechte Leader.
In dieser Folge übersetze ich die Laws of Combat aus dem Buch in das, was passiert, wenn eure Raid-Gruppe – oder euer Sprint – zum wiederholten Mal scheitert.
Was diese Folge behandelt:
-
Extreme Ownership & No Bad Teams – warum die volle Verantwortung beim Leader liegt, und warum das keine Einbahnstraße ist: Der Leader erklärt, bis der Plan sitzt, jeder Einzelne fragt nach, bis das Warum sitzt
-
Believe & Check the Ego – warum gute Absichten der richtige Ausgangspunkt sind, auch wenn man sich das Vertrauen dafür manchmal erst erarbeiten muss
-
360-Grad-Feedback und Achtsamkeit – zwei Werkzeuge, um den eigenen blinden Fleck sichtbar zu machen: nach innen die eigene Ego-Reaktion erkennen, nach außen die Reaktionen anderer lesen lernen
-
Die vier Laws of Combat – Cover and Move, Simple, Prioritize and Execute, Decentralized Command, und wie Simon Sineks „Start with Why“ auf Decentralized Command trifft
-
Discipline Equals Freedom und die Dichotomie der Führung – warum jedes Prinzip aus dem Buch, übertrieben, ins Gegenteil kippt
Quellen & Buchempfehlungen:
Co-op Mode – Gaming trifft Leadership. Für alle, die Teams bauen, nicht nur Prozesse verwalten.
Mehr von Georg:
https://hofmann-freiburg.de
Auf LinkedIn vernetzen:
https://www.linkedin.com/in/georghofmann-digitalleadership
Zwei Entwicklerinnen an einer Aufgabe – doppelter Aufwand. So lautet der häufigste Einwand gegen Pair Programming. Es ist die falsche Rechnung.
Pair Programming reduziert die Fehlerrate um bis zu 40 Prozent. Es erhöht den Bus Factor eines Teams. Es verteilt Wissen, ohne dass dafür ein Meeting nötig ist. Und es erzeugt Code, dem zwei Personen gefolgt sind – nicht einer, der hofft, dass es schon stimmt.
In dieser Folge geht es um Pair Programming als das, was es ist: das reinste Co-op-Erlebnis, das die Softwareentwicklung zu bieten hat.
Was diese Folge behandelt:
-
Driver und Navigator – warum der Rollentausch der eigentliche Lernmoment ist, nicht das gemeinsame Tippen
-
Die Psychologie der geteilten Tastatur – Tunnelblick, kognitiver Load und warum jemand daneben sitzen die Fokus-Mechanik verändert
-
Wissenstransfer statt Silos – wie jedes Pair den Bus Factor erhöht und warum das kein Zufall ist
-
Senior plus Junior – warum das „Warum“ wichtiger ist als das „Was“, und was der Junior den Senior lehrt
-
Und die ehrliche Seite: wann Pair Programming nicht funktioniert – und warum man es nie als Pflicht einführen sollte
Quellen & Buchempfehlungen:
Co-op Mode – Gaming trifft Leadership. Für alle, die Teams bauen, nicht nur Prozesse verwalten.
Mehr von Georg:
https://hofmann-freiburg.de
Auf LinkedIn vernetzen:
https://www.linkedin.com/georghofmann-digitalleadership
Zwei Entwicklerinnen an einer Aufgabe – doppelter Aufwand. So lautet der häufigste Einwand gegen Pair Programming. Es ist die falsche Rechnung.
Pair Programming reduziert die Fehlerrate um bis zu 40 Prozent. Es erhöht den Bus Factor eines Teams. Es verteilt Wissen, ohne dass dafür ein Meeting nötig ist. Und es erzeugt Code, dem zwei Personen gefolgt sind – nicht einer, der hofft, dass es schon stimmt.
In dieser Folge geht es um Pair Programming als das, was es ist: das reinste Co-op-Erlebnis, das die Softwareentwicklung zu bieten hat.
Was diese Folge behandelt:
-
Driver und Navigator – warum der Rollentausch der eigentliche Lernmoment ist, nicht das gemeinsame Tippen
-
Die Psychologie der geteilten Tastatur – Tunnelblick, kognitiver Load und warum jemand daneben sitzen die Fokus-Mechanik verändert
-
Wissenstransfer statt Silos – wie jedes Pair den Bus Factor erhöht und warum das kein Zufall ist
-
Senior plus Junior – warum das „Warum“ wichtiger ist als das „Was“, und was der Junior den Senior lehrt
-
Und die ehrliche Seite: wann Pair Programming nicht funktioniert – und warum man es nie als Pflicht einführen sollte
Quellen & Buchempfehlungen:
Co-op Mode – Gaming trifft Leadership. Für alle, die Teams bauen, nicht nur Prozesse verwalten.
Mehr von Georg:
https://hofmann-freiburg.de
Auf LinkedIn vernetzen:
https://www.linkedin.com/in/georghofmann-digitalleadership
Zwei Entwicklerinnen an einer Aufgabe – doppelter Aufwand. So lautet der häufigste Einwand gegen Pair Programming. Es ist die falsche Rechnung.
Pair Programming reduziert die Fehlerrate um bis zu 40 Prozent. Es erhöht den Bus Factor eines Teams. Es verteilt Wissen, ohne dass dafür ein Meeting nötig ist. Und es erzeugt Code, dem zwei Personen gefolgt sind – nicht einer, der hofft, dass es schon stimmt.
In dieser Folge geht es um Pair Programming als das, was es ist: das reinste Co-op-Erlebnis, das die Softwareentwicklung zu bieten hat.
Was diese Folge behandelt:
-
Driver und Navigator – warum der Rollentausch der eigentliche Lernmoment ist, nicht das gemeinsame Tippen
-
Die Psychologie der geteilten Tastatur – Tunnelblick, kognitiver Load und warum jemand daneben sitzen die Fokus-Mechanik verändert
-
Wissenstransfer statt Silos – wie jedes Pair den Bus Factor erhöht und warum das kein Zufall ist
-
Senior plus Junior – warum das „Warum“ wichtiger ist als das „Was“, und was der Junior den Senior lehrt
-
Und die ehrliche Seite: wann Pair Programming nicht funktioniert – und warum man es nie als Pflicht einführen sollte
Quellen & Buchempfehlungen:
Co-op Mode – Gaming trifft Leadership. Für alle, die Teams bauen, nicht nur Prozesse verwalten.
Mehr von Georg:
https://hofmann-freiburg.de
Auf LinkedIn vernetzen:
https://www.linkedin.com/in/georghofmann-digitalleadership
