Vier Rollen, Fünf Mächte

[🇬🇧 - Four Roles, Five Powers]

🪑 Der Hut-Stapel: Wenn „flach“ eigentlich „konzentriert“ bedeutet↑

Dienstagmorgen. Markus öffnet eine E-Mail von Lehmann. Die Betreffzeile lautet „Klärung vor Q3-Planung“. Die eigentliche Nachricht ist kürzer, als die Betreffzeile vermuten lässt. Das Leadership-Team erwägt eine flachere Struktur. Headcount unverändert. Die Team-Coach-Rolle würde „in die Funktion des People Lead integriert“. Die Tech-Lead-Rolle würde „auf die Senior-Entwickler*innen verteilt“. Markus bliebe weiterhin People Lead. Er würde zusätzlich Coach. Und damit implizit das einfühlsame, psychologische Sicherheitsnetz für vierzehn Entwickler*innen, deren Jahresbewertungen er im November schreibt.

Markus hält bei der Tech-Lead-Zeile inne. Die stimmt tatsächlich. Technische Entscheidungen auf die Entwickler*innen zu verteilen ist exakt so, wie es funktionieren sollte. Er macht sich eine Notiz. Zwei Sätze später stolpert er über die Coach-Integration, und die Notiz spielt keine Rolle mehr.

Lehmanns nächster Satz lässt Markus mitten im Scrollen innehalten. „Bin neugierig, wie du diese Dimensionen ausbalancieren würdest. Lass es mich bis Freitag wissen.“

Markus blinzelt. Dann liest er ihn nochmal. Und nochmal, langsamer, weil gerade etwas Unerwartetes passiert ist: Lehmann sagt ihm nicht, was passieren wird. Lehmann fragt. Was bedeutet, dass sich hier ausnahmsweise ein Fenster öffnet, in dem die Antwort wirklich zählt. Markus kann sich nicht erinnern, wann dieses Fenster zuletzt offen stand.

Er leitet die E-Mail an Agile Coach Lisa weiter: „Können wir vor Donnerstag reden?“

📚 Fünf Mächte: Warum das Org-Chart über sie schweigt↑

Das Org-Chart benennt die Boxen. Über die Art der Macht, die jede Box trägt, schweigt es - weil das Benennen sie angreifbar macht.

1959 veröffentlichten die Sozialpsychologen John French und Bertram Raven den Aufsatz The Bases of Social Power. Der Text ist kurz. Die Taxonomie ist langlebig. Sie identifizierten fünf klar unterscheidbare Mechanismen, mit denen eine Person eine andere dazu bringt, etwas zu tun:

1. Reward Power. Die Fähigkeit, etwas zu gewähren, das die andere Person haben will. Gehalt, Bonus, Beförderung, eine Kalendereinladung zur Konferenz in Lissabon.
2. Coercive Power. Die Fähigkeit, etwas aufzuerlegen, das die andere Person nicht haben will. Eine schlechte Performance-Bewertung, eine verweigerte Beförderung, eine Abmahnung, ein nicht verlängerter Vertrag.
3. Legitimate Power. Formale Autorität, die im Org-Chart eingebettet ist. Das Recht zu unterzeichnen, freizugeben, zu eskalieren, zu entscheiden. Macht, die existiert, weil die Box auf der Folie es so sagt.
4. Expert Power. Einfluss, der auf Wissen basiert, das die andere Person braucht. Die Architekt*in, die weiß, wo die Tarif-Sonderausnahme im Legacy-System vergraben liegt. Die Senior-Entwickler*in, die den Stack Trace tatsächlich lesen kann.
5. Referent Power. Einfluss, der auf Identifikation, Vertrauen oder persönlicher Wertschätzung basiert. Die Führungskraft, der Menschen folgen, weil sie es wollen, nicht weil sie es müssen.

Das sind keine Persönlichkeitstypen. Das sind Mechanismen. Eine Person kann mehrere Mächte in sich vereinen. Die meisten Manager​*innen versuchen, alle fünf zu vereinen, weil das Org-Chart sich darüber ausschweigt, welche Macht die Rolle eigentlich ausüben soll. Und welche nicht.

Genau dieses Schweigen ist der Punkt, an dem sich erste Risse bilden.

🪞 Das Servant-Leader-Paradox: Warum eine Person nicht alle fünf vereinen kann↑

Das bekannte Bild von Führung will, dass die Führungskraft alles ist. Coach am Vormittag, urteilende Instanz am Nachmittag, fachliches Mentoring zur Mittagspause, kultureller Anker auf dem Offsite, und die Person, die im November entscheidet, wer den Bonus bekommt. Die Führungskraft, die alle fünf Mächte gleichzeitig ausüben soll, ist die eierlegende Wollmilchsau des Org-Charts: vom Lenkungsausschuss entworfen, biologisch unmöglich.

Der Schaden beginnt dort, wo Coercive und Referent aufeinandertreffen. Edmondsons Lebenswerk zur psychologischen Sicherheit dokumentiert über zwei Jahrzehnte hinweg replizierter Studien, dass Teamklimata mit hoher disziplinarischer Sichtbarkeit systematisch weniger Offenheit, weniger Risikobereitschaft und weniger Aufdeckung von Fehlern produzieren.

Der Mechanismus, auf den die Literatur konvergiert, ist denkbar simpel: Menschen offenbaren keine Unwissenheit oder Fehler vor Beobachter*innen, die sie zugleich bewerten. In dem Moment, in dem ein*e Entwickler*in weiß, dass die Person, die „wie läuft’s?" fragt, dieselbe ist, die sie am Freitag um 12 Uhr von 1 bis 5 bewertet, wird die Antwort zur Performance, nicht zum Signal.

Referent Power macht einen stillen Abgang, sobald Coercive Power den Raum betritt.

Den vollständigen Mechanismus mitsamt der zugrunde liegenden Biologie liefert der frühere Text zur psychologischen Sicherheit.

Eine zweite Kollision passiert zwischen Expert und Coercive. Wenn dieselbe Person, die der Entwicklerin sagt, die Tariflogik müsse refactored werden, auch die Person ist, die die Delivery bewertet, hört die Entwicklerin eine Anweisung, keine Diskussion. Expert-Einfluss erfordert die Freiheit zu widersprechen, ohne Konsequenzen. Coercive Power erstickt diese Freiheit. Die Entwicklerin wird zustimmen und dann leise das Sicherste tun, was selten das Beste ist.

Die dritte Kollision ist Niklas Luhmanns Beitrag. In Soziale Systeme (1984) argumentierte Luhmann, dass komplexe Systeme sich nach Funktionen ausdifferenzieren. Ein Team ist selbst ein System. Es kann nicht sauber von Akteuren beobachtet werden, die gleichzeitig Teil seiner operativen Steuerung sind, weil diese Akteure strukturelle blinde Flecken haben, die durch ihre Position in der Hierarchie diktiert werden. Ein*e People Lead berichtet nach oben. Ihre Beobachtungen des Teams sind vorgeprägt durch das, was sie berichten muss. Sie kann das Team strukturell nicht klar sehen. Jemand außerhalb der disziplinarischen Kette muss das Team beobachten, ohne die Verzerrung, die die eigene Position in der Hierarchie unweigerlich erzeugt.

(nb: Die Anwendung auf Berichtshierarchien ist abgeleitet aus Luhmanns Argument der funktionalen Differenzierung; das Konzept ist seins, die Org-Chart-Lesart ist meine.)

Trage alle fünf Hüte, und die Biologie verschwört sich mit der Soziologie, um dich zu einer instabilen Beobachter*in deines eigenen Systems zu machen.

Darunter liegt eine kognitive Schicht. Sweller’s Cognitive Load Theory unterscheidet drei Lasttypen: intrinsisch (die Aufgabe selbst), extrinsisch (wie sie präsentiert wird) und germane – Swellers Begriff für den mentalen Aufwand, neue Denkmuster aufzubauen. Eine Person dazu zu bringen, strategische, operative, individuelle und meta-systemische Perspektiven gleichzeitig zu bedienen, multipliziert die kognitive Last, statt sie zu verringern.

Das mentale Modell, das ein*e Product Owner*in braucht, die in quartalsweisen Marktfenstern denkt, ist strukturell ein anderes als das mentale Modell, das gebraucht wird, um einen Architektur-Trade-off zu diskutieren, was wiederum ein anderes ist als das mentale Modell, das man braucht, um einer erschöpften Entwicklerin in einem 1:1 zuzuhören. Diese Schemata verdrängen sich gegenseitig; das Hin- und Herwechseln verursacht dieselben kognitiven Kosten, die in der Engineering-Welt den Durchsatz zerlegt, nur diesmal angewandt auf das Gehirn, das eigentlich steuern soll.

Wenn du den Auslastungsfetisch gelesen hast, kennt du das Problem schon. Ein Mensch, der vier mentale Modelle jongliert, zahlt Weinbergs Kontextwechselsteuer auf jeder Transition. Die Führungskraft, die alles ist, thrasht - sie arbeitet mit minimaler Produktivität.

🧩 Der Vier-Rollen-Split: Was moderne Organisationen eigentlich tun sollten↑

Die übliche moderne Antwort auf das Alleskönner-Manager-Problem besteht darin, den Führungsjob aufzuteilen. Die Namen variieren je nach Framework. Die saubere Version, die den Kontakt sowohl mit der Soziologie als auch mit der operativen Evidenz übersteht, hat exakt vier Rollen. Eine dieser vier Rollen ist das Team selbst.

• Product Owner. Verantwortet das Was und das Warum. Hält Expert Power über Markt und Kunde sowie eine eingegrenzte Form von Legitimate Power: das Recht, Backlog-Priorität zu setzen und Lieferungen gegen die Geschäftsabsicht abzunehmen oder abzulehnen. Trägt keine formale Autorität über die Personen, die die Arbeit machen.
• People Lead (auch: Engineering Manager, Line Manager). Verantwortet das Wer. Hält Reward, Coercive und eine eingegrenzte Form von Legitimate Power: Headcount-Entscheidungen, formales Performance-Management, Beförderung, Gehaltsbänder und Eskalation entlang der disziplinarischen Kette. Trägt den disziplinarischen Vertrag und sonst nichts.
• Team Coach (Agile Coach, Scrum Master, …). Verantwortet das Wie es fließt. Hält Referent Power und eine eingegrenzte Form von Legitimate Power: das Recht, Prozessverletzungen zu benennen und die Working Agreements des Teams zu moderieren. Trägt keine disziplinarische Autorität und keine Architekturautorität.
• Das Team selbst. Verantwortet das Wie es gebaut wird. Hält Expert Power über das System und eine eingegrenzte Form von Legitimate Power: das Recht, Architekturentscheidungen innerhalb seiner eigenen Domäne zu treffen. Hält diese kollektiv, nicht über eine Tech-Lead-Rolle oberhalb des Teams.

Vier Rollen, fünf Mächte. Die Rechnung geht präzise auf, weil Expert Power über die technische Arbeit der Team-Rolle kollektiv gehört. Die vierte Rolle hält die fünfte Macht.

Genau hier machen die meisten Engineering-Organisationen den Designfehler. Sie teilen den Führungsjob in die ersten drei Rollen auf und führen dann eine vierte individuelle Rolle namens Tech Lead wieder ein, in der Absicht, ihr Expert-Autorität über die technischen Entscheidungen des Teams zu geben. Die Absicht ist nachvollziehbar. Das Ergebnis ist ein strukturelles Anti-Pattern mit vorhersehbaren Konsequenzen.

🚧 Die falsche vierte Rolle: Warum ein*e Tech Lead den Flaschenhals wieder einführt↑

Drei voneinander unabhängige Argumentationslinien führen zur selben Schlussfolgerung: Expert Power aus dem Team herauszuziehen und in einer individuellen Tech-Lead-Rolle zu konzentrieren reduziert die effektive Kapazität des Teams, verlangsamt Architekturentscheidungen und produziert exakt die teaminterne Hierarchie, die der Vier-Rollen-Split eigentlich auflösen sollte.

🏗️ Linie 1 - Conway’s Law: Entscheidungs-Flaschenhälse werden zu Architektur-Flaschenhälsen↑

Conway beobachtete 1968, dass Systeme die Kommunikationsstrukturen der Organisationen spiegeln, die sie bauen. Das Korollar, von der DORA-Forschung in Accelerate explizit gemacht, lautet: Entscheidungs-Flaschenhälse werden zu Architektur-Flaschenhälsen. Ein Team mit einer designierten Tech-Lead-Rolle routet seine Architekturentscheidungen über eine einzige Person.

Das System, das das Team baut, wird mit der Zeit dasselbe Single-Point-of-Decision-Muster zeigen.

Komponenten, die übergreifende Entscheidungen erfordern, warten auf die Aufmerksamkeit der Person in der Tech-Lead-Rolle. Komponenten, zu denen diese Person persönlichen Kontext hat, kommen schneller voran. Die Architektur wächst asymmetrisch entlang der Konturen des Aufmerksamkeitsbudgets einer einzigen Person, und der Durchsatz des Teams ist gedeckelt auf das, was diese eine Person in einer Woche reviewen kann.

🧠 Linie 2 - Kollektive Intelligenz: Konversationelle Gleichheit schlägt individuelle Brillanz↑

Anita Woolley und Kolleg*innen fanden in Science (2010), dass Gruppenleistung bei kognitiven Aufgaben mit sozialer Sensitivität, mit der Gleichverteilung der Redeanteile und mit dem Frauenanteil in der Gruppe korreliert und im Wesentlichen keine Korrelation mit der durchschnittlichen oder maximalen individuellen Intelligenz der Mitglieder zeigt.

Übersetzt in die Engineering-Welt: Die architektonische Entscheidungsqualität eines Teams hängt mehr davon ab, ob alle beitragen können, als davon, ob ein einzelnes Mitglied die klügste Person im Raum ist. Eine Person in der Tech-Lead-Rolle, die als technische Entscheidungsinstanz fungiert, wie brillant auch immer, unterdrückt strukturell genau die gleichmäßige Beteiligung aller, die die Forschung zur kollektiven Intelligenz als den eigentlichen Treiber von Gruppenleistung identifiziert.

🛡️ Linie 3 - Psychologische Sicherheit (lateral): Asymmetrisches Risiko beim Sprechen↑

Das Muster, das Edmondsons Forschung für die Manager-Mitarbeiter-Beziehung beschreibt, hat ein Pendant in kleinerem Maßstab zwischen einer institutionell privilegierten technischen Autorität und dem Rest des Teams. Der Mechanismus ist derselbe, der im früheren Text untersucht wurde: Asymmetrisches Risiko beim Sprechen unterdrückt das kollektive Wissen des Teams.

Die Anwesenheit einer designierten technischen Autorität führt exakt diese Asymmetrie ein. Ein*e Junior-Entwickler*in widerspricht jetzt nicht mehr nur einer Peer-Person, sondern derjenigen, deren technisches Urteil institutionell privilegiert ist. Der Widerspruch bleibt im Kopf des Juniors. Die effektive IQ des Teams sinkt auf den IQ derjenigen, die bereit sind, mit der Tech-Lead-Rolle zu streiten, und das ist eine deutlich kleinere Untermenge als das Team selbst.

📊 Empirischer Zusatz - DORA: Verteilte Architekturautorität korreliert mit High Performance↑

Hochleistungs-Engineering-Organisationen verteilen Architekturautorität auf die Teams. Niedrig-Performance-Organisationen konzentrieren sie in Architekt*innen, Lead Engineers und Tech Leads. Die Korrelation gehört zu den am häufigsten replizierten Befunden in den State-of-DevOps-Reports über fast ein Jahrzehnt Datenlage hinweg.

Senior-Entwickler*innen sind unverzichtbar. Ihre Expertise gehört dem Team als beitragendes Mitglied; eine autoritative Rolle über dem Team ist die falsche Struktur für das, was sie einbringen. Senior-Entwickler*innen, die die technischen Entscheidungen für das Team treffen, produzieren ein Team, das ohne sie keine technischen Entscheidungen mehr treffen kann. Senior-Entwickler*innen, die ihre Argumentation erklären, sie als eine Stimme unter mehreren verteidigen und akzeptieren, bei einer 50:50-Frage überstimmt zu werden, produzieren ein Team, das wächst.

Das erste Muster ist die Tech-Lead-Rolle. Das zweite ist ein*e Senior-Entwickler*in. Das Vokabular zählt, weil die Struktur dem Vokabular folgt.

Der Vier-Rollen-Split, mit dem Team selbst als kollektivem Halter der Expert Power, ist die einzige Konfiguration, die alle drei Bedingungen gleichzeitig erfüllt: Conway’s Law lässt keinen Architektur-Flaschenhals entstehen, kollektive Intelligenz hält die gleichmäßige Beteiligung aller intakt, und psychologische Sicherheit trägt keinen teaminternen Coercive-Schatten von einer privilegierten technischen Rolle.

📐 Das Paradox der flachen Hierarchie: Warum weniger Ebenen mehr Rollentrennung brauchen↑

Das ist die Umkehrung, die die meisten Verfechter*innen flacher Organisationen übersehen. Flache Strukturen eliminieren nicht den Bedarf am Vier-Rollen-Split. Sie sind auf ihn angewiesen.

Eine traditionell steile Hierarchie hat vier oder fünf vertikale Ebenen, und das Management verdünnt die Macht über diese Ebenen: Die Teamleitung trägt etwas Coercive-Autorität, die Abteilungsleitung mehr, der VP den Rest. Die Verdünnung ist nicht beabsichtigt, aber sie verteilt das disziplinarische Gewicht auf genug Rollen, sodass keine einzelne Person das gesamte Bündel trägt. Der Nachteil ist offensichtlich: Informationen brauchen Wochen, um nach oben zu wandern, Entscheidungen brauchen Wochen, um zurück nach unten zu kommen, und die Personen, die der Arbeit am nächsten sind, haben den geringsten Einfluss auf sie.

Eine flache Organisation löst das Informations- und Entscheidungsproblem, indem sie die vertikalen Ebenen kollabiert. C-Suite oben, People Leads in der Mitte, alle anderen auf der operativen Ebene. Drei Ebenen, manchmal zwei. Schneller, reaktionsfähiger, näher an der Arbeit. Aber dieselbe Reward-, Coercive- und Legitimate-Macht, die zuvor über fünf steile Ebenen verteilt war, konzentriert sich jetzt auf zwei oder drei flache. Der People Lead in einer flachen Organisation trägt mehr disziplinarisches Gewicht pro Person als jede​*r Teamleiter​*in in einer steilen Organisation.

Diese Konzentration ist der Preis der Flachheit, und der Vier-Rollen-Split ist das, was verhindert, dass dieser Preis vom Team gezahlt wird. Die Coach-Rolle hält Referent Power ohne disziplinarische Zähne. Das Team hält Expert Power kollektiv, ohne einen internen Autoritätssitz, der zum Flaschenhals würde. Die Product–Owner-Rolle hält Prioritätsentscheidungen ohne formale Seniorität gegenüber den Entwickler*innen. Die laterale Konfiguration ist strukturelle Isolation, keine zusätzlichen Ebenen, und sie ist das, was eine flache Organisation unter Last ehrlich bleiben lässt.

Entferne sie, und Flachheit bedeutet nur noch eine kleinere Anzahl von Personen, die einen größeren Anteil jeder verfügbaren Macht halten, mit weniger strukturellen Kanälen für das Team, sich um sie herumzuroutern.

⚠️ Die Mathematik geht oft nicht auf: Wo jede Macht tatsächlich lebt↑

Zähle die Mächte über die vier Rollen hinweg. Die Rechnung geht erst auf, wenn Legitimate Power korrekt behandelt wird: nicht als eine einzige unteilbare Macht, sondern als eine Familie eingegrenzter Autoritäten, die sich explizit fragmentieren.

• Reward und Coercive konzentrieren sich in der People-Lead-Rolle. Nicht zufällig und nicht aus soziologischer Vorliebe. Aus arbeitsrechtlicher Notwendigkeit. Das europäische Arbeitsrecht behandelt das Recht, etwas zu gewähren (Bonus, Beförderung, Gehaltserhöhung) und das Recht, es zurückzuhalten (Bewertung, Abmahnung, Kündigung), als zwei Seiten eines unteilbaren disziplinarischen Vertrags. Du kannst Sarahs Bonus-Autorität nicht einer Rolle und ihre Kündigungsautorität einem anderen zuweisen, ohne einen prozeduralen Zusammenbruch zu produzieren, den der Betriebsrat in einer einzigen Sitzung zerlegt. Reward und Coercive sind durch Gesetz aneinandergebunden. Sie konzentrieren sich auf eine Rolle, weil der rechtliche Rahmen ihnen nicht erlaubt, irgendwo anders zu wohnen.
• Legitimate Power fragmentiert explizit. Die People-Lead-Rolle hält HR-Legitimate-Autorität: Headcount-Entscheidungen, formales Performance-Management und Eskalation entlang der disziplinarischen Kette. Die Product-Owner-Rolle hält Product-Legitimate-Autorität: das Recht, Backlog-Priorität zu setzen und Lieferungen gegen die Geschäftsabsicht abzunehmen oder abzulehnen. Die Coach-Rolle hält Process-Legitimate-Autorität: das Recht, Working-Agreement-Verletzungen zu benennen und die Prozessentscheidungen des Teams zu moderieren. Das Team hält Architecture-Legitimate-Autorität: das Recht zu entscheiden, wie das System innerhalb seiner Domäne gebaut wird. Vier Geschmacksrichtungen von Legitimate, vier Rollen, kein Overlap.
• Expert Power lebt im Team kollektiv, mit der Product-Owner-Rolle, die eingegrenzte Expert Power auf der Markt- und Kundenseite hält. Es gibt keine individuelle Expert-Rolle oberhalb des Teams. Die kollektive Expertise des Teams ist die Expert Power.
• Referent Power lebt in der Coach-Rolle. Sie ist der einzige Rolle in der Konfiguration, deren Autorität ausschließlich auf Vertrauen basiert, nicht auf einem Vertrag. Das ist auch der Grund, warum Coaches strukturell von jedem Pfad zurück in die disziplinarische Kette ferngehalten werden müssen. In dem Moment, in dem Referent Power Coercive berührt, findet die Biologie einen Weg um sie herum.

Die fünf Mächte teilen sich nicht in vier gleiche Stücke. Zwei sind durch das Arbeitsrecht aneinandergebunden und konzentrieren sich auf eine Rolle. Eine fragmentiert über alle vier Rollen mit expliziten Geltungsbereichen. Eine gehört einem Kollektiv. Eine gehört der Rolle ohne vertraglichen Hebel. Die Rechnung ist asymmetrisch, und die Asymmetrie ist das Design.

🩹 Die Kosten der Konzentration: Warum die Reward-Coercive-Bündelung nicht kostenlos ist↑

Die Asymmetrie als beabsichtigt zu bezeichnen macht sie nicht kostenfrei. Reward und Coercive in einer Rolle zu konzentrieren erzeugt exakt den Rollenkonflikt, vor dem die Literatur gewarnt hat, nur lokalisiert in einer Stellenbeschreibung statt verteilt über das gesamte Leadership.

Von der People-Lead-Rolle wird weiterhin erwartet, etwas Coaching zu leisten. People Leads haben weiterhin 1:1s. Sie hören weiterhin von Workload, Reibung und Burnout-Signalen. In dem Moment, in dem diese Gespräche in Gebiete abdriften, die der oder die Entwickler*in als karriererelevant wahrnimmt, passiert dieselbe Abschaltung, die schon den Alleskönner-Manager abgeschaltet hat. Die Information verschwindet.

Die Lösung ist, das Zuhören der People Leads auf das einzugrenzen, was die disziplinarische Rolle legitim aufnehmen kann: Fürsorgepflicht-Signale, Workload-Schutz, Eskalationspfade, Karrieregespräche, die explizit über Karriere geführt werden. Das Skill-Development-Gespräch gehört zur Coach-Rolle. Das Gespräch über Teamdynamik gehört in die Retrospektiven des Teams, moderiert durch Coaches. Das Debrief eines fehlgeschlagenen Experiments gehört ins Team.

Wenn People Leads versuchen, irgendeines davon zu absorbieren, wird die Engineering-Organisation die Rolle leise umschiffen.

Das ist auch der Grund, warum der Hut-Stapel-Vorschlag, den Markus am Dienstagmorgen geöffnet hat, keine Skalierungsentscheidung ist. Es ist ein struktureller Kollaps, der darauf wartet, ratifiziert zu werden. Wenn eine Organisation ihre People Leads auffordert, auch die Coaches zu sein und auch über technische Entscheidungen im Namen des Teams zu entscheiden, sieht das Org-Chart einfacher aus. Die Machtverteilung hat alles wieder verschmolzen, was der Vier-Rollen-Split ausdrücklich fragmentieren sollte.

Die Entwickler*innen werden entsprechend reagieren: weniger Offenheit, weniger Risiko, weniger ehrliches Signal. Das Dashboard wird die Veränderung mehrere Quartale lang nicht widerspiegeln. Bis dahin haben die Personen, die es geflaggt hätten, entweder gekündigt oder gelernt zu performen. Markus’ Antwort am Freitag ist im Wesentlichen eine Ein-Seiten-Version dieses Absatzes.

💸 Der „Wir sind zu klein für alle vier“-Trugschluss↑

Der Standardeinwand an dieser Stelle lautet, dass kleine Organisationen sich nicht vier separate Rollen für ein Team leisten können. Eine Zwölf-Personen-Firma wird keinen dedizierten Team Coach einstellen. Ein Startup wird People Leads nicht von Coaches trennen oder Coaches von derdem CTO, derdie auch im Sprint Planning sitzt. Das stimmt, und es invalidiert die strukturelle Logik nicht.

Was sich in einer kleinen Organisation ändert, ist nicht die Anzahl der Mächte. Es ist die Rollenverteilung. Der*die CTO einer Fünfzehn-Personen-Firma hält oft Expert und Legitimate Power gleichzeitig, mit Referent Power, die aus der Gründungs-Team-Beziehung entsteht. Das funktioniert, weil der disziplinarische Vertrag leicht ist, das Reporting transparent ist und das Team klein genug ist, dass jede*r das System ohne strukturellen Mittler beobachten kann. Die fünf Mächte sind weiterhin da. Sie werden nur in weniger Händen gehalten, von Personen, die ehrlich darüber sein können, welchen Hut sie in einem bestimmten Gespräch gerade tragen.

Das Modell bricht bei Skalierung. Die exakte Schwelle variiert, aber irgendwo zwischen dreißig und fünfzig Entwickler*innen hört die informelle Ehrlichkeit der Kleinteam-Konfiguration auf zu funktionieren, und das Fehlen der Rollentrennung beginnt, exakt die Dynamiken zu produzieren, die der Vier-Rollen-Split eigentlich verhindern soll.

Vorzugeben, die Kleinteam-Konfiguration skaliere, ist genau das, was Zwanzig-Personen-Teams mit einer*einem erschöpften „Engineering Lead“ erzeugt, der*die aufgehört hat zu schlafen und angefangen hat, das Executive Team über den Zustand des Systems anzulügen.

🌊 Nicht jede Organisation lebt unter diesem Druck↑

Die oben beschriebenen Dynamiken der Rollenkollision sind am schärfsten in Umgebungen, in denen der disziplinarische Vertrag schwer wiegt: große Konzerne mit formalem Performance-Management, erzwungenen Verteilungskurven, jährlichen Bewertungszyklen und signifikanter variabler Vergütung, die an individuelle Bewertungen geknüpft ist.

In Organisationen, die individuelle Performance-Bewertungen bereits abgeschafft haben, die Vergütung von operativem Feedback entkoppelt haben oder die mit starken Tarifstrukturen arbeiten, die individuelle Manager-Diskretion begrenzen, ist der Coercive-Hebel strukturell kleiner. Das Risiko der Rollenkollision sinkt entsprechend.

Das ist genau das Terrain, das der Beyond-Observation-Bauplan im Detail kartiert. Der Vier-Rollen-Split nimmt an, dass der disziplinarische Vertrag Gewicht hat. In Organisationen, in denen das nicht so ist, bleibt der Vier-Rollen-Split aus Gründen kognitiver Last weiterhin nützlich, aber die Dringlichkeit ist geringer. Je sauberer das Vergütungssystem, desto kleiner muss die Lücke zwischen den Rollen sein.

🪜 Drei strukturelle Hebel: Wie die Asymmetrie tragbar wird↑

Drei Muster tauchen konsistent in Organisationen auf, die das Design tragen lassen. Keine Garantien, keine universellen Blaupausen; nur Hebel, die funktionieren können, wenn jemand bereit ist, sie zu ziehen.

🧱 Die Coaches lateralisieren↑

Die Coach-Rolle muss auf einem Pfad berichten, der nicht durch die disziplinarische Kette führt. Wenn sie an dieden Head of Engineering berichtet, derdie auch das Review der People Leads schreibt, ist die Isolation Theater. Die Coach-Rolle ist jetzt indirekt Teil des Coercive-Systems, und das Team wird es innerhalb von Wochen spüren. Der strukturelle Hebel ist eine gepunktete Berichtslinie für die Coach-Rolle, mit dem formalen Review-Pfad, der durch eine parallele Struktur läuft (ein*e Head of People, ein*e Head of Coaching, in kleineren Organisationen direkt zur CEO). Die Konstruktion sieht bürokratisch teuer aus. Sie ist der Preis ehrlicher Daten.

🧠 Dem Tech-Lead-Reflex widerstehen↑

Wenn Architekturentscheidungen sich verlangsamen oder die Qualität nachgibt, ist die Standardreaktion, eine*n Tech Lead zu ernennen, „um dem Team technische Führung zu geben“. Die Reaktion ist intuitiv. Und strukturell falsch. Sie entzieht dem Team technische Führung und konzentriert sie in einer Rolle, was den Flaschenhals erzeugt, den Conway’s Law vorhersagt, und die konversationelle Unterdrückung, die Woolleys Forschung misst.

Der korrekte Hebel ist die Umkehrung: Investiere in die kollektive Entscheidungsfähigkeit des Teams. Architectural Decision Records, moderiert vom Team selbst. Pairing- oder Ensemble-Arbeit an übergreifenden Änderungen. Senior-Entwickler*innen, die erklären und verteidigen, statt zu dekretieren. Das Team, dem beigebracht wird, gemeinsam zu entscheiden, wird zu einem Team, das schneller entscheidet, als der Tech-Lead-Rolle es reviewen könnte. Das Team, das von einem Tech Lead gerettet wird, wird zu einem Team, das ohne sie nicht entscheiden kann.

🔇 Den Coercive-Hebel dort leise halten, wo er nicht hingehört↑

Die disziplinarische Autorität der People Leads sollte laut sein, wo sie legitim ausgeübt wird: Headcount-Entscheidungen, formales Performance-Management, Beförderung, Eskalation. Sie sollte überall sonst leise sein. Konkret: Sie sollte nicht in die operativen Rituale des Teams eintreten.

People Lead besuchen das Daily nicht. People Leads besuchen die Retrospektive nicht. People Leads besuchen das Architectural Decision Record Review nicht. Diese Räume gehören dem Team und der*dem Coach, und die Anwesenheit von People Leads in ihnen kollabiert die Isolation, indem sie die Coercive-Beobachter*in wieder einführt.

Das ist schwer für People Leads, die selbst aus der Engineering-Welt kommen und die Arbeit vermissen, und dennoch nicht verhandelbar. People Leads, die jedes Daily besuchen, weil sie „nah am Team bleiben“ wollen, sind in der Biologie der Entwickler*innen dieselben Beobachter*innen, die dieselben Daten zerstören, die Wayne und Liden 1995 dokumentiert haben. Die Nähe kostet Ehrlichkeit.

Das Komplement dazu ist, die Asymmetrie sichtbar zu machen: ein schriftlicher Rollenvertrag, der bei der Teambildung verteilt wird und festhält, welche Entscheidungen dem PO gehören, welche dem Coach, welche dem People Lead und welche dem Team selbst. Entwickler*innen brauchen keine Soziologievorlesung. Sie brauchen das Wissen, dass Coaches von einem Prozessproblem zu erzählen sich nicht in ihrer Novemberbewertung niederschlägt, und sie brauchen dieses Wissen aus der Org-Struktur, nicht aus einer vagen verbalen Zusicherung.

🏁 Das Fazit: Vier Rollen, fünf Mächte, ein ehrliches Gespräch↑

Wenn das Design respektiert wird, wenn der Coach außerhalb der disziplinarischen Kette berichtet, wenn die Architektur des Teams in den Händen des Teams bleibt statt in denen einer*s Tech Leads, wenn People Leads sich aus den operativen Ritualen heraushalten, fließen die Daten ehrlich genug, dass das System gesteuert werden kann. Die People Leads können den eigentlichen Job machen: gut einstellen, Verantwortung dort halten, wo sie hingehört, und die Organisation vor den Ausfällen schützen, die die laterale Konfiguration strukturell nicht abdecken kann.

Wenn das Design kollabiert wird, sei es durch das Zurückrollen der Rollen unter ein „flachere Struktur“-Mandat, durch das Routen der Berichtslinie des Coach durch die disziplinarische Kette, durch das Beobachten der operativen Rituale durch People Leads oder durch die Ernennung von Tech Leads, „um dem Team beim Entscheiden zu helfen“, verdunstet die Isolation. Die Daten, von denen das System abhängt, degradieren leise, und bis das Dashboard die Degradation einholt, sind die Personen, die sie geflaggt hätten, schon weg.

Je weniger vertikale Ebenen eine Organisation hat, desto mehr braucht sie die lateralen Rollen, um die Konzentration der Macht zu verhindern. Je mehr sie Engineering-Qualität will, desto weniger sollte sie Tech Leads ernennen. Die Engineering-Entscheidung ist, ob die Konfiguration respektiert oder die Alleskönner-Manager unter neuem Vokabular wieder erfunden werden.

⏱️ TL;DR: Der 60-Sekunden-Realitätsabgleich↑

Wer als Executive gerade Rollen konsolidieren will, als People Lead aufgefordert wird, eine Coach-Rolle zu absorbieren, oder als CTO Tech Leads ernennen will, „um die technische Führung zu stärken“, findet hier die strukturelle Realität:

• 🪑 Fünf Mächte, vier Rollen, und die vierte Rolle ist das Team: French und Raven haben fünf Basen sozialer Macht gezählt. Der saubere moderne Split verteilt sie über vier Rollen: People Lead, Product Owner, Team Coach und das Team selbst. Die vierte Rolle ist mit Absicht kollektiv.
• ⚖️ Reward und Coercive sind durch Gesetz gebunden: Sie konzentrieren sich beim People Lead, weil das europäische Arbeitsrecht beide als einen unteilbaren disziplinarischen Vertrag behandelt. Sie können nicht getrennt werden. Das Design akzeptiert das und hält alles andere strukturell davon fern.
• 🧩 Legitimate Power fragmentiert per Design: HR-Legitimate beim People Lead. Product-Legitimate beim PO. Process-Legitimate beim Coach. Architecture-Legitimate beim Team. Vier Geltungsbereiche, vier Rollen, kein Overlap.
• 🧠 Expert Power gehört dem Team, nicht einem Tech Lead: Conway’s Law, die Forschung zu kollektiver Intelligenz und die DORA-Befunde konvergieren alle: Ein individueller Tech-Lead-Rolle erzeugt einen Architektur-Flaschenhals, unterdrückt konversationelle Gleichheit innerhalb des Teams und führt einen lateralen Coercive-Schatten ein. Die Senior-Entwickler*in ist ein beitragendes Mitglied, keine Autorität oberhalb des Teams.
• 🪞 Referent Power gehört dem Coach, isoliert von Coercive: Der Coach berichtet außerhalb der disziplinarischen Kette, oder die Isolation ist Theater. Wenn Referent Power Coercive berührt, routet die Biologie um sie herum.
• 🔇 Der People Lead bleibt aus den operativen Ritualen heraus: Dailies, Retros und ADR-Reviews gehören dem Team und dem Coach. Die Anwesenheit des People Lead führt die Coercive-Beobachter*in wieder ein und macht den Raum stumm.
• 🪨 Flache Hierarchien brauchen den Split mehr, nicht weniger: Weniger vertikale Ebenen konzentrieren Reward, Coercive und HR-Legitimate Power in weniger Rollen. Die laterale Konfiguration ist die strukturelle Isolation, die die Konzentration tragbar hält. Schneide sie weg, und das Machtgefälle in der Organisation wird steiler.
• 🏁 Das Fazit: Vier Rollen, fünf Mächte, ein ehrliches Gespräch. Die Rechnung geht nur auf, weil eine der vier Rollen das Team selbst ist.

🧾 Die Belege: Die Soziologie und die Daten↑

Wenn euer Executive-Team den Beweis braucht, dass die soeben angekündigte Rollenkonsolidierung strukturell garantiert das Team zum Schweigen bringt, legt ihm diese Quellen auf den Tisch.

Die soziologischen Grundlagen↑

• Die fünf Basen sozialer Macht: French, J. R. P., & Raven, B. (1959). „The Bases of Social Power." In Studies in Social Power (Cartwright, D., Hrsg.). University of Michigan, Institute for Social Research. Die ursprüngliche Taxonomie: Reward, Coercive, Legitimate, Expert, Referent. Der Rahmen, gegen den jedes spätere Führungsmodell implizit verglichen wird. Lest das Kapitel hier
• Funktionale Differenzierung in komplexen Systemen: Luhmann, N. (1984). Soziale Systeme: Grundriß einer allgemeinen Theorie (ISBN: 978-3518282663). Die systemtheoretische Argumentation, warum komplexe Systeme sich nach Funktion und nicht nach Hierarchie ausdifferenzieren, und warum ein Akteur innerhalb der Steuerungskette das System, das er steuert, nicht sauber beobachten kann.
• Cognitive Load und Schemawechsel: Sweller, J. (1988). „Cognitive Load During Problem Solving: Effects on Learning." Cognitive Science, 12(2), 257-285. Das ursprüngliche Paper zur Cognitive Load Theory. Spätere Verallgemeinerungen auf Wissensarbeit belegen, dass das Wechseln mentaler Modelle eine messbare Steuer auf die Entscheidungsqualität erhebt. Lest das Paper hier

Die Evidenz zum Rollenkonflikt↑

• Psychologische Sicherheit und der Coercive-Beobachter: Edmondson, A. C. (1999). „Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, 44(2), 350-383. Die empirische Grundlage dafür, warum Teams unter disziplinarischer Beobachtung systematisch genau das Signal unterdrücken, das das Management am dringendsten empfangen müsste. Reviewt die Studie hier
• Impression Management unter Beobachtung: Wayne, S. J., & Liden, R. C. (1995). „Effects of impression management on performance ratings: A longitudinal study." Academy of Management Journal, 38(1), 232-260. Längsschnittlicher Beweis, dass Mitarbeiter*innen unter beobachtenden Performance-Bewertungen kognitive Energie von der Arbeit auf das Erscheinungsbild der Arbeit umverteilen. Reviewt die Studie hier
• Die 94/6-Regel der Systemleistung: Deming, W. E. (1986). Out of the Crisis (ISBN: 978-0262541152). Die statistische Argumentation, dass der Großteil der Leistungsvariation dem System gehört, nicht dem Individuum, und dass eine Führungskraft, die ein Individuum bewertet, meistens das System bewertet, in dem das Individuum gerade steht.
• Split Roles in Performance Appraisal: Meyer, H. H., Kay, E., & French, J. R. P. (1965). „Split Roles in Performance Appraisal." Harvard Business Review. Die General-Electric-Studie, die vor sechzig Jahren etabliert hat, dass das Verbinden von Entwicklungsfeedback mit Vergütungsdiskussion beides zerstört. Lest den Artikel hier

Die Argumentation gegen den Tech-Lead-Flaschenhals↑

• Conway’s Law: Conway, M. E. (1968). „How Do Committees Invent?" Datamation, 14(5), 28-31. Die ursprüngliche Beobachtung, dass Systeme die Kommunikationsstrukturen der Organisationen spiegeln, die sie bauen. Das Korollar: Entscheidungs-Flaschenhälse werden zu Architektur-Flaschenhälsen. Lest das Paper hier
• Kollektive Intelligenz in Gruppen: Woolley, A. W., Chabris, C. F., Pentland, A., Hashmi, N., & Malone, T. W. (2010). „Evidence for a Collective Intelligence Factor in the Performance of Human Groups." Science, 330(6004), 686-688. Der empirische Befund, dass Gruppenleistung mit konversationeller Gleichheit und sozialer Sensitivität korreliert, nicht mit der durchschnittlichen oder maximalen individuellen Intelligenz der Mitglieder. Das strukturelle Argument gegen jeden privilegierten Entscheider-Rolle innerhalb eines Teams. Lest die Studie hier
• Dezentralisierte Architektur und Durchsatz: Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps (ISBN: 978-1942788331). Der längsschnittliche Befund des DORA-Programms, dass Hochleistungs-Engineering-Organisationen Architekturautorität auf die Teams verteilen; Niedrig-Performance-Organisationen konzentrieren sie in Lead Engineers und Architekt*innen. Einer der am häufigsten replizierten Befunde quer durch die State-of-DevOps-Reports.
• Generative Organisationskultur: Westrum, R. (2004). „A typology of organisational cultures." Quality and Safety in Health Care, 13(suppl 2), ii22-ii27. Die pathologisch/bürokratisch/generative Typologie, mit generativen Kulturen definiert durch den freien Informationsfluss über Rollen hinweg. Westrums ursprünglicher Kontext sind sicherheitskritische Industrien; DORA/Accelerate hat seine Kultur-Erhebung für die Softwareentwicklung operationalisiert. Die Verbindung zum Tech-Lead-Flaschenhals ist eine abgeleitete Inferenz aus dieser DORA-Anwendung, kein direkter Westrum-Befund. Lest das Paper hier
• Begrenzte Autorität in selbstorganisierten Teams: Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances (ISBN: 978-1578513338). Die empirische Argumentation für die Verteilung von Entscheidungsautorität auf abgegrenzte Teams, mit dem Team selbst als Ort operativer und architektonischer Entscheidungen.

Die Servant-Leadership-Literatur↑

• Der ursprüngliche Servant-Leadership-Aufsatz: Greenleaf, R. K. (1970). The Servant as Leader. Der Aufsatz, der den Begriff eingeführt hat und sofort das Rollenkonflikt-Problem produziert hat, das dieser Artikel adressiert: Dieselbe Person kann nicht zuverlässig dienen und richten. Lest den Aufsatz auf Internet Archive
• Die Grenzen von Servant Leadership in Hierarchien: Eva, N., Robin, M., Sendjaya, S., van Dierendonck, D., & Liden, R. C. (2019). „Servant Leadership: A systematic review and call for future research." The Leadership Quarterly, 30(1), 111-132. Eine Meta-Analyse, die anerkennt, dass Servant-Leadership-Effekte abhängig sind von der disziplinarischen Struktur, die die Führungskraft umgibt. Reviewt die Meta-Analyse hier

Die operativen Modelle↑

• Das Spotify-Modell und seine Grenzen: Kniberg, H., & Ivarsson, A. (2012). „Scaling Agile @ Spotify." Spotify Engineering Whitepaper. Die viel zitierte Blaupause für die Trennung von Chapter Leads (Personalentwicklung) und Squad Leads (Delivery), eine frühe industrielle Implementierung der Rollentrennungs-Logik, die dieser Artikel verallgemeinert. Kniberg selbst hat angemerkt, dass das Whitepaper eine Momentaufnahme war, keine Vorschrift, und Spotifys eigene Implementierung vom veröffentlichten Modell abgewichen ist. Die Referenz hier zielt spezifisch auf das Rollentrennungs-Prinzip, also Personalentwicklung getrennt von Delivery, nicht auf die Squad/Tribe/Chapter/Guild-Struktur als Ganzes. Lest das Whitepaper hier
• Die Behandlung von Rollen in der Kanban-Methode: Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business (ISBN: 978-0984521401). Die operative Argumentation für die Trennung von Flussmanagement und disziplinarischer Autorität, mit expliziten Warnungen vor den Konsequenzen ihrer Vermischung.
• Beyond Budgeting und entkoppelte Autorität: Bogsnes, B. (2016). Implementing Beyond Budgeting, 2. Aufl. (ISBN: 978-1119152477). Die Unternehmensblaupause für die Trennung von Zielsetzung, Performance-Bewertung und Ressourcenallokation in eigenständige kontinuierliche Prozesse, was den Rollensplit voraussetzt, den dieser Artikel beschreibt.

Die kognitiven Kosten↑

• Kontextwechsel und Kapazitätsverfall: Weinberg, G. M. (1992). Quality Software Management, Vol. 1: Systems Thinking (ISBN: 978-0932633224). Die Kapazitätstabelle, die zeigt, wie schnell die verfügbare kognitive Bandbreite mit zunehmender Anzahl gleichzeitiger Kontexte zerfällt. Ursprünglich für Engineering-Arbeit geschrieben; dieselbe Rechnung gilt für Führungsarbeit.
• Die 23-Minuten-Erholung: Mark, G., Gudith, D., & Klocke, U. (2008). „The cost of interrupted work: more speed and stress." CHI ‘08. Der empirische Anker, warum das Wechseln mentaler Modelle auf menschlichen Zeitskalen nicht kostenfrei ist. Lest die Studie hier