STfA
Persona Lernpfad

Start Hier:
Tech Lead

Fokus auf Teamdynamik, Entscheidungsprozesse und die Verbindung von Delivery, Lernen und Verantwortung.

Level 1: Grundlagen

0/6 gelesen

Nach diesem Level verstehst du, wie Kommunikationsstrukturen, mentale Modelle und Grenzen das Verhalten deines Teams prägen.

Conway's Law

Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu entwickeln, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.

Warum hier: Der wichtigste Einzelzusammenhang für Tech Leads: Teamstruktur wird Systemstruktur.

Goodhart's Law

Wenn eine Kennzahl zum Ziel wird, verliert sie als Messgröße an Aussagekraft, weil das System beginnt, auf den Proxy statt auf die eigentliche Wirkung zu optimieren.

Warum hier: Erklärt, warum Velocity-Ziele und Bug-Quoten das Verhalten deines Teams verformen.

Mental Models

Mentale Modelle sind tief verankerte Annahmen im Kopf, die bestimmen, welche Systemsignale wir überhaupt wahrnehmen und wie wir Entscheidungen treffen.

Warum hier: Teamkonflikte sind oft Modellkonflikte — wer das sieht, moderiert anders.

Interdependence

Elemente in einem System sind wechselseitig abhängig; man kann keinen Teil isoliert verändern, ohne das Ganze zu beeinflussen.

Warum hier: Zeigt, warum lokale Teamoptimierung das Gesamtsystem verschlechtern kann.

System Boundaries

Systemgrenzen sind rein mentale Linien, die wir ziehen, um zu trennen, was zu unserer Architektur gehört und was angeblich "außerhalb" unserer Kontrolle liegt.

Warum hier: Unklare Grenzen sind die häufigste Wurzel von Reibung zwischen Teams.

Resilience

Resilienz ist die Fähigkeit eines Systems, schädliche Belastungen von außen nicht nur zu überleben, sondern sich zu erholen und seine Struktur zu bewahren.

Warum hier: Verschiebt den Fokus von 'keine Fehler' zu 'schnell erholen' — auch für Teams.

Level 2: Praktiker

0/6 gelesen

Nach diesem Level erkennst du destruktive Teamdynamiken als Systemmuster statt als Charakterfragen.

Kommunikationsabbrüche

Informationssilos und falsch ausgerichtete mentale Modelle führen zu architektonischem Drift und Reibungen im Team.

Warum hier: Das Referenz-Symptom dieses Pfads: Kommunikationsabbrüche als Systemphänomen.

Accidental Adversaries

Teams, die eigentlich zusammenarbeiten wollen, zwingen sich durch egoistische, lokale Optimierungen gegenseitig in den Ruin.

Warum hier: Erklärt, wie kooperationswillige Teams sich unbeabsichtigt gegenseitig blockieren.

Shifting the Burden

Teams lindern kurzfristige Symptome mit Quick Fixes und verlieren dabei zunehmend die Fähigkeit, das strukturelle Architekturproblem zu lösen.

Warum hier: Zeigt, warum Helden-Fixes die strukturelle Lösung dauerhaft verdrängen.

Escalation

Zwei Parteien reagieren aufeinander mit immer stärkeren Maßnahmen, weil jede Seite die andere übertreffen oder absichern möchte.

Warum hier: Das Muster hinter eskalierenden Team-Konflikten und Tool-Kriegen.

Stakeholder Mapping

Ein Werkzeug zur Lokalisierung von organisatorischer Macht und potenziellem Veto-Potenzial gegen Architekturentscheidungen.

Warum hier: Macht sichtbar, wessen Interessen das Teamsystem tatsächlich steuern.

Social Network Analysis

SNA entlarvt die wahre, unsichtbare Architekturklüngelei einer Organisation, indem sie misst, wer mit wem (inoffiziell) spricht und wer isoliert ist.

Warum hier: Zeigt die realen Kommunikationspfade — oft anders als das Org-Chart behauptet.

Level 3: Strategischer Tiefgang

0/5 gelesen

Nach diesem Level veränderst du Entscheidungswege und Verantwortungsstrukturen gezielt, statt Symptome zu moderieren.

Decision Rights Clarification

Die drastische Beseitigung von Unklarheit darüber, wer in der Architektur "Empfehlen", wer "Ein Veto einlegen" und wer "Den Kauf-Button drücken" darf.

Warum hier: Die strukturelle Antwort auf Nebenkanal-Entscheidungen und Rollenunklarheit.

Servant Leadership in System Context

Die Neuerfindung der Führungskraft vom Kontrolleur zum "System-Architekten". Führung, die sich darauf konzentriert, die physikalischen Blockaden der Teams zu sprengen anstatt Budgets zu verwalten.

Warum hier: Verankert Führung als Systemgestaltung statt als Einzelfall-Heldentum.

Moving from Blame to Accountability

Eine kulturelle Intervention, die "Menschliches Versagen" als Ausrede für Produktionsausfälle abschafft und stattdessen das fehlerhafte System-Design verantwortlich macht.

Warum hier: Verändert die Fehlerkultur strukturell — Voraussetzung für ehrliche Diagnosen.

Collaboration Whiteboard Tooling

Digitale Whiteboards für verteilte Teams: Sie ermöglichen gemeinsames Architekturentwerfen und Event Storming über Remote-Grenzen hinweg.

Warum hier: Das Trägermedium für gemeinsames Modellieren mit deinem Team.

Decision Log Tooling

Maschinenlesbare Architekturentscheidungen (ADRs): Sie dokumentieren, warum ein Trade-off gewählt wurde, und halten Entscheidungen auch Jahre später nachvollziehbar.

Warum hier: Hält Entscheidungen und ihre Gründe fest — gegen das Vergessen und Re-Litigieren.