Warum Führung ein Protokoll-Stack ist und du gerade nur auf Layer 7 sendest

Für frisch beförderte Teamleiter in der IT, die Führung lernen wollen und bisher vor allem Werkzeuge gesammelt haben: ein Feedback-Schema hier, ein Meeting-Format dort, ein Webinar über Zielvereinbarungen. Der Text arbeitet mit dem OSI-Modell, das in der Informatik Netzwerkkommunikation in sieben Schichten zerlegt, von der Leitung auf Layer 1 bis zur Anwendung auf Layer 7, mit der ein Mensch tatsächlich arbeitet, etwa dem Browser oder dem Mailprogramm. Wer nicht aus der IT kommt, kann sich ein Haus vorstellen: Die schönste Einrichtung im Obergeschoss hilft wenig, wenn das Fundament reißt. Du erfährst, woher das Denken in Schichten stammt, von Edsger W. Dijkstras Betriebssystem in Eindhoven über Hubert Zimmermanns OSI-Modell bis zum Protokollkrieg, den das Internet gewonnen hat. Danach verbindet der Text es mit dem, was Chris Argyris, Donald Schön und Henry Mintzberg über das Lernen von Führung herausgefunden haben. Nach der Lektüre weißt du, warum gute Führungswerkzeuge so oft wirkungslos bleiben und in welcher Reihenfolge Führung sich aufbauen lässt.

Jana leitet seit fünf Monaten das Team für Cloud-Infrastruktur. Sie nimmt den Job ernst. Sie hat ein Webinar über OKRs besucht, die Zielmethode, mit der große Tech-Konzerne ihre Teams ausrichten. Sie hat ein Buch über Einzelgespräche gelesen und sich ein Feedback-Modell mit drei Schritten auf eine Karteikarte geschrieben.

Im Oktober lädt sie zum OKR-Workshop. Whiteboard, Klebezettel, ein sorgfältig vorbereiteter Ablauf. Das Team macht höflich mit. Am Ende stehen drei Ziele an der Wand, deren Kennzahlen jeder im Raum ohnehin erreicht hätte. Zwei Wochen später fragt niemand mehr danach.

In derselben Woche probiert sie ihr Feedback-Modell aus. Ein Kollege hat in einem Change-Meeting eine Kollegin vor allen anderen abgekanzelt. Jana beschreibt im Einzelgespräch die Situation, das Verhalten und die Wirkung, genau wie auf der Karteikarte. Der Kollege verteidigt sich zehn Minuten lang. Am nächsten Morgen reicht er zwei Wochen Urlaub ein.

Am Freitag sitzt Jana vor ihrem Notizbuch und kommt zu einem von zwei Schlüssen. Entweder taugen diese Werkzeuge nichts. Oder sie selbst taugt nichts.

Beide Schlüsse sind falsch, und der Grund dafür ist eine Architekturfrage.

Führung lernen heißt meistens: Anwendungen installieren

Fast alles, was frisch beförderten Führungskräften angeboten wird, setzt ganz oben an. Wie du Feedback gibst. Wie du ein Gehaltsgespräch führst. Wie du Ziele vereinbarst. Wie du delegierst. Das sind wertvolle Fertigkeiten, und die meisten Bücher und Seminare vermitteln sie solide.

Sie haben allerdings eine stillschweigende Voraussetzung, die kaum jemand ausspricht: Sie gehen davon aus, dass darunter etwas funktioniert. Dass das Team der Führungskraft vertraut. Dass sie ihre neue Rolle verstanden hat. Dass Aufträge ankommen und Gespräche zustande kommen.

Jeder, der einmal eine Webanwendung betrieben hat, kennt das Prinzip aus der Technik. Wenn das Netzwerk darunter vierzig Prozent der Pakete verliert, kannst du die Anwendung so oft neu schreiben, wie du willst. Sie wird nie stabil laufen, weil das Problem auf einer anderen Schicht sitzt. Jana hat zwei sehr ordentliche Anwendungen installiert, auf einem Stack, dessen untere Schichten sie nie angeschaut hat. Ihr Team kannte sie fünf Monate als Chefin. Es wusste noch nicht, wofür sie steht und was mit unbequemen Wahrheiten bei ihr passiert.

Wer Führung lernen will, sammelt also oft genau die Werkzeuge, die am Ende der Kette stehen. Das ist verständlich, denn sie sind sichtbar, konkret und schnell erklärt. Es ist nur die falsche Reihenfolge.

Was das OSI-Modell über Führung verrät

Die Grundidee eines Schichtenmodells ist einfach und mächtig zugleich. Jede Schicht erledigt genau eine Aufgabe, nutzt dafür die Dienste der Schicht darunter und bietet ihre eigenen Dienste der Schicht darüber an. Aus dieser Idee folgen drei Eigenschaften, die sich eins zu eins auf Führung übertragen lassen:

1. Kapselung. Jede Schicht verlässt sich darauf, dass die darunter funktioniert, und muss sich nicht um deren Details kümmern. In der Führung heißt das: Steht das Vertrauen in deinem Team einmal stabil, musst du nicht in jedem Gespräch daran denken, und du kannst dich ganz auf die Sache konzentrieren.
2. Fehlerfortpflanzung. Ein Defekt in einer unteren Schicht zeigt sich fast immer als Symptom weiter oben. Ein Team, das sich nicht sicher fühlt, liefert dünne Retrospektiven und wehrt Feedback ab. Das Symptom erscheint im Meeting oder im Gespräch, die Ursache liegt tiefer.
3. Kein Überspringen. Über eine kaputte Leitung lässt sich kein zuverlässiges Transportprotokoll fahren. Ebenso wenig gelingt verlässliche Delegation, solange die Führungskraft innerlich noch selbst die beste Entwicklerin sein will.

Diese drei Eigenschaften erklären Janas Woche vollständig. Der OKR-Workshop und das Feedback-Gespräch waren sauber ausgeführte Anwendungen. Sie liefen auf Schichten, die noch nicht trugen.

Dass sich ein Netzwerkmodell so mühelos auf Führung übertragen lässt, hat einen Grund, der in seiner Entstehung liegt. Schichtenmodelle wurden in der Informatik erfunden, damit Menschen komplexe Systeme verstehen, bauen und reparieren können. Genau das müssen neue Führungskräfte mit ihrem Team tun.

Grundlagen: Woher das Denken in Schichten kommt und was es über Führung lernen verrät

Die Geschichte der Schichtenmodelle ist eine Geschichte über Verstehen. Sie beginnt mit einem Betriebssystem in den Niederlanden, führt über die Normungsbehörden in Genf zu einem Streit, den das Internet gewonnen hat, und endet bei Forschern, die ganz ohne Rechner herausgefunden haben, warum kluge Menschen schlecht aus ihren Fehlern lernen. Am Ende steht eine Frage, die für jeden gilt, der Führung lernen will: In welcher Reihenfolge lernt man ein System, das man nicht ganz durchschauen kann?

Edsger W. Dijkstra: Schichten, damit Menschen ein System verstehen

Edsger W. Dijkstra (1930–2002), niederländischer Informatiker, geboren in Rotterdam, war einer der Gründerväter der Softwaretechnik und erhielt 1972 den Turing Award, die höchste Auszeichnung der Informatik. Ab 1962 war er Professor an der Technischen Hochschule Eindhoven. Dort leitete er Mitte der 1960er Jahre ein kleines Team, das ein Betriebssystem für einen Rechner der Hochschule baute, nach deren niederländischem Kürzel THE-System genannt.

1968 beschrieb Dijkstra das System in den „Communications of the ACM“, und der Aufsatz wurde berühmt, weil er eine Bauweise vorstellte, die damals ungewöhnlich war. Das System bestand aus übereinanderliegenden Ebenen:

• Ebene 0 verteilte die Rechenzeit auf die Prozesse.
• Ebene 1 verwaltete den Speicher.
• Ebene 2 regelte die Kommunikation mit der Bedienkonsole.
• Ebene 3 kümmerte sich um die angeschlossenen Geräte.
• Ebene 4 enthielt die Programme der Nutzer.
• Ebene 5 war der Nutzer selbst, von dem Dijkstra trocken anmerkte, dass er nicht von seinem Team implementiert worden sei.

Jede Ebene durfte sich nur auf die Ebenen unter ihr verlassen. Das Team baute zuerst Ebene 0, prüfte sie und ging erst dann eine Ebene höher. So ließ sich jede Schicht für sich verstehen und testen, und ein Fehler ließ sich einer Ebene zuordnen. Sechs Jahre später gab Dijkstra dem Prinzip dahinter in einem Essay einen Namen, der bis heute in jedem Informatikstudium fällt: Trennung der Belange, im Englischen Separation of Concerns. Man denkt über eine Sache nach und lässt die anderen für diesen Moment bewusst beiseite.

Für Janas Woche ist an Dijkstras Vorgehen vor allem die Reihenfolge interessant. Er baute von unten nach oben und testete jede Ebene, bevor die nächste kam. Jana hat mit der obersten Ebene begonnen, mit den Anwendungen, und erst beim Scheitern gemerkt, dass sie nicht weiß, in welchem Zustand die Ebenen darunter sind.

Hubert Zimmermann und das OSI-Modell

Ein Jahrzehnt nach Dijkstra stand die Netzwerktechnik vor einem Problem, das sich mit seinem Prinzip lösen ließ. Computerhersteller bauten ihre Netze nach eigenen, untereinander unverträglichen Regeln, und Rechner verschiedener Marken konnten kaum miteinander sprechen. Die Internationale Organisation für Normung, kurz ISO, begann 1977, eine gemeinsame Architektur für offene Systeme zu entwickeln, also für Rechner, die über Herstellergrenzen hinweg Daten austauschen können.

Einer der wichtigsten Köpfe dieser Arbeit war Hubert Zimmermann (1941–2012), ein französischer Informatiker. Er hatte im französischen Forschungsnetz CYCLADES an der Paketvermittlung mitgearbeitet, einer der Techniken, auf denen heute das Internet beruht. 1980 beschrieb er das Referenzmodell in einem viel zitierten Aufsatz in der Fachzeitschrift „IEEE Transactions on Communications“. 1984 wurde es als internationale Norm ISO 7498 veröffentlicht. Zimmermann arbeitete danach bei France Télécom, gründete 1986 das Softwareunternehmen Chorus Systèmes und erhielt 1991 den SIGCOMM Award, eine der wichtigsten Auszeichnungen der Netzwerkforschung.

Das OSI-Modell übertrug Dijkstras Gedanken auf die Kommunikation zwischen Rechnern. Sieben Schichten, von der Leitung bis zur Anwendung, jede mit einer klar umrissenen Aufgabe und klaren Schnittstellen nach oben und unten. Bis heute lernt jeder angehende Netzwerktechniker diese sieben Schichten auswendig, und bis heute beginnt fast jede Fehlersuche mit der Frage, auf welcher Schicht das Problem sitzt.

Der Protokollkrieg: Was passiert, wenn ein Modell auf die Wirklichkeit trifft

Das OSI-Modell hatte allerdings einen Konkurrenten, und der gewann. Parallel zur Arbeit der ISO war in den USA eine Familie von Protokollen entstanden, die heute unter dem Namen TCP/IP bekannt ist. Am 1. Januar 1983 stellte das ARPANET, der Vorläufer des Internets, vollständig auf TCP/IP um. Mehrere Regierungen, darunter die der USA und einige europäische, setzten in den späten 1980er Jahren trotzdem auf OSI und schrieben es für ihre Behörden vor. Die Auseinandersetzung ging als Protokollkrieg in die Geschichte der Informatik ein. Mitte der 1990er Jahre war sie entschieden: Das Internet lief mit TCP/IP, und die US-Regierung strich 1995 ihre Pflicht zur OSI-Konformität.

TCP/IP kommt mit vier Schichten aus. Der US-amerikanische Internetpionier Steve Crocker, geboren 1944, der 1969 das erste Dokument der bis heute fortgeführten Reihe der Requests for Comments verfasst hatte, spottete 1987 über die sieben Schichten der Konkurrenz: Hätte man nur die alten Mystiker gefragt, hätte man sofort gesehen, dass es sieben Schichten sein mussten.

Ein Vierteljahrhundert nach dem Beginn der OSI-Arbeit gingen zwei erfahrene Netzbetreiber noch weiter. In einem Grundsatzdokument der Internet-Gemeinschaft, dem RFC 3439 von 2002, steht ein Abschnitt mit der Überschrift „Layering Considered Harmful“, Schichtung gilt als schädlich. Die Autoren erkennen den Nutzen von Schichten für das Denken an. In der Praxis aber, so ihre Beobachtung, verbergen Schichten Information voreinander, verdoppeln Funktionen und erzeugen unerwartete Nebenwirkungen.

Für die Frage, wie man Führung lernt, ist dieser Streit lehrreich. Als Bauplan hat das OSI-Modell den Protokollkrieg verloren, als Denkwerkzeug hat es überlebt, weil es Menschen hilft, ein komplexes System zu ordnen und Fehler einzugrenzen. Genau so ist der Führungsstack gemeint: als Landkarte, die eine Reihenfolge vorschlägt und beim Suchen hilft, wohl wissend, dass Schichten in der Wirklichkeit ineinandergreifen.

Chris Argyris und Donald Schön: Was wir sagen und was wir tun

Die nächste Linie führt weg vom Rechner zu der Frage, warum Menschen gelernte Methoden so oft nicht anwenden können, wenn es darauf ankommt. Chris Argyris (1923–2013), US-amerikanischer Organisationspsychologe, lehrte zuerst in Yale und ab 1971 in Harvard. Donald A. Schön (1930–1997), US-amerikanischer Philosoph und Organisationsforscher, lehrte am Massachusetts Institute of Technology und wurde später mit seinem Buch über den reflektierenden Praktiker bekannt. 1974 veröffentlichten die beiden „Theory in Practice“, ein Buch über die Frage, wie Fachleute im Beruf wirksamer werden.

Argyris und Schön unterschieden zwei Theorien, die jeder Mensch über sein eigenes Handeln hat:

• Die vertretene Theorie, im Englischen espoused theory, ist das, was jemand über sein Handeln sagt. Sie steht in Leitbildern, Seminarunterlagen und auf Karteikarten.
• Die handlungsleitende Theorie, die theory-in-use, ist das, was sich aus dem tatsächlichen Verhalten ablesen lässt, gerade unter Druck. Sie ist den Menschen selbst meist nicht bewusst.

Zwischen beiden klafft oft eine Lücke, und die Betroffenen sehen sie kaum. Dazu kommt eine zweite Unterscheidung. Beim einschleifigen Lernen, dem single-loop learning, korrigiert man eine Handlung, wenn sie nicht zum Ziel führt, und lässt die Annahmen dahinter unberührt. Beim doppelschleifigen Lernen, dem double-loop learning, stellt man auch die Annahmen in Frage, nach denen man gehandelt hat.

1991 schrieb Argyris in der „Harvard Business Review“ einen Aufsatz mit dem Titel „Teaching Smart People How to Learn“, und er liest sich, als hätte er an Jana gedacht. Argyris hatte hochqualifizierte Unternehmensberater beobachtet und festgestellt, dass gerade die Klügsten besonders schlecht aus Misserfolgen lernen. Weil sie selten gescheitert waren, hatten sie nie gelernt, mit dem Scheitern umzugehen. Wenn etwas schiefging, suchten sie die Ursache reflexhaft außerhalb oder schlossen auf ihr eigenes Versagen, ohne die Annahmen zu prüfen, auf denen ihr Vorgehen beruhte.

Janas zwei Schlüsse am Freitag sind genau diese beiden Reflexe. Entweder taugen die Werkzeuge nichts, oder sie selbst taugt nichts. Beide Schlüsse bleiben in einer Schleife. Die doppelschleifige Frage würde lauten: Welche Annahme steckte in meinem Vorgehen? Und die Antwort wäre die Voraussetzung, die alle Werkzeuge auf Layer 7 stillschweigend machen, dass darunter Vertrauen und Verbindung bestehen.

Henry Mintzberg: Führung als Praxis

Die dritte Linie stellt die Frage, ob man Führung überhaupt aus Büchern und Seminaren lernen kann. Henry Mintzberg, geboren 1939 in Montreal, kanadischer Managementforscher, lehrt seit 1968 an der McGill University. Für seine Doktorarbeit am Massachusetts Institute of Technology hatte er fünf Vorstandsvorsitzende je eine Woche lang begleitet und minutiös aufgeschrieben, was sie tatsächlich taten. 1973 erschien daraus „The Nature of Managerial Work“.

Das Ergebnis passte zu keinem Lehrbuch. Die Manager planten und kontrollierten kaum in langen, ruhigen Phasen. Ihr Tag bestand aus kurzen, zerstückelten Tätigkeiten, ständigen Unterbrechungen, vielen Gesprächen und wenig Lesen. Mintzberg folgerte daraus, dass Management eine Praxis ist, die sich aus Handwerk, Kunst und ein wenig Wissenschaft zusammensetzt. 2004 spitzte er diese Sicht in „Managers Not MBAs“ zu und kritisierte, dass Wirtschaftshochschulen Führung als analytische Disziplin lehren, losgelöst von der Erfahrung der Menschen, die sie ausüben.

Aus Mintzbergs Sicht hat Jana genau das getan, wovor er warnt: Sie hat Führung als Wissen erworben, als Webinar, Buch und Karteikarte, und es dann auf eine Praxis gelegt, die ganz anders funktioniert.

Was die Forschung über Führungstrainings weiß

Wie Führungskräfte tatsächlich lernen, beschäftigt die Personalentwicklung seit Jahrzehnten. Am bekanntesten ist eine Faustregel, die auf Forscher des Center for Creative Leadership in North Carolina zurückgeht: 70 Prozent lernen Führungskräfte durch herausfordernde Aufgaben, 20 Prozent durch andere Menschen und 10 Prozent durch formales Training. Die Regel ist in Unternehmen weit verbreitet, ihre Grundlage ist allerdings dünn. Sie beruht auf Selbstauskünften erfolgreicher Führungskräfte darüber, wie sie glaubten gelernt zu haben, und die auffällig runden Zahlen haben Kritiker misstrauisch gemacht.

Belastbarer ist eine große Metaanalyse, die ein US-amerikanisches Forscherteam 2017 im „Journal of Applied Psychology“ veröffentlichte. Sie wertete über 300 Studien zu Führungstrainings aus und kam zu einem ermutigenden Befund: Führungstraining wirkt, auf das Wissen der Teilnehmenden ebenso wie auf ihr Verhalten am Arbeitsplatz und auf die Ergebnisse ihrer Teams. Wie stark es wirkt, hängt allerdings vom Aufbau ab. Wirksamer waren Trainings, die auf einer Bedarfsanalyse beruhten, die Übung und Rückmeldung enthielten und die über mehrere Sitzungen verteilt waren.

Wo sich die Modelle widersprechen

Die Ansätze in diesem Kapitel passen an vielen Stellen zusammen. Reibung entsteht an drei Punkten.

1. Strenge Schichten oder durchlässige? Dijkstra und das OSI-Modell setzen auf saubere Trennung. Die Erfahrung mit TCP/IP und die Autoren von RFC 3439 zeigen, dass Schichten in der Wirklichkeit durchlässig sind. In der Führung ist das genauso: Ein gut geführtes Einzelgespräch auf Layer 5 stärkt das Vertrauen auf Layer 2, und gutes Feedback auf Layer 7 kann Vertrauen aufbauen, wenn das Fundament schon trägt. Die Reihenfolge von unten nach oben ist deshalb eine Empfehlung für den Aufbau und eine Landkarte für die Fehlersuche, und sie beschreibt nicht jede Wechselwirkung.
2. Klassenraum oder Praxis? Mintzberg bezweifelt, dass man Führung in Seminaren lernt, und die 70-20-10-Regel scheint ihm recht zu geben. Die Metaanalyse von 2017 zeigt dagegen, dass formales Training wirkt. Auflösen lässt sich der Widerspruch über den Aufbau: Training wirkt dann, wenn es nah an der Praxis bleibt, Übung enthält und sich über eine Zeit erstreckt, in der die Teilnehmenden ihr Wissen ausprobieren.
3. Werkzeug oder Haltung? Die meisten Führungsratgeber verbessern Werkzeuge. Argyris und Schön setzen eine Ebene tiefer an, bei den Annahmen, die bestimmen, wie jemand ein Werkzeug einsetzt. Für den Führungsstack folgt daraus, dass die unterste Schicht das Selbstverständnis der Führungskraft ist, ihre handlungsleitende Theorie.

Die neun Schichten des Führungsstacks

Der Führungsstack übernimmt die sieben Schichten des OSI-Modells und belegt sie mit Führungsaufgaben. Dazu kommen zwei Schichten, die jeder Techniker kennt: eine ganz unten, die vor allem anderen bootet, und eine ganz oben, über die Admins seit Jahrzehnten Witze machen.

• Layer 0, Kernel: dein Selbstverständnis. Der Wechsel vom Macher, der selbst baut, zum Multiplikator, der durch andere wirkt, und die Einsicht, dass jeder Mensch im Team Botschaften in seinem eigenen Empfangsformat aufnimmt.
• Layer 1, Physical: deine Präsenz und deine Erreichbarkeit, im Raum wie im Videocall.
• Layer 2, Data Link: dein Team als lokales Netz. Vertrauen, psychologische Sicherheit, die direkten Verbindungen zwischen den Menschen.
• Layer 3, Network: dein Netzwerk über das eigene Team hinaus. Stakeholder, Peers, Entscheider.
• Layer 4, Transport: Delegation, die zuverlässig ankommt.
• Layer 5, Session: Einzelgespräche und Meetings, die einen klaren Anfang, eine klare Mitte und ein klares Ende haben.
• Layer 6, Presentation: Übersetzen zwischen Technik und Business, klar sprechen.
• Layer 7, Application: die konkreten Werkzeuge der Führung wie Feedback, Konfliktlösung, Recruiting, Gehaltsgespräche und Trennungen.
• Layer 8, People und Politik: die Organisation mit ihren Interessen, Machtverhältnissen und ungeschriebenen Regeln.

Liest man Janas Woche mit dieser Landkarte, ergibt sich ein Befund, der sich wie ein Stacktrace lesen lässt. Das Feedback-Gespräch auf Layer 7 lief formal korrekt und erzeugte trotzdem Abwehr. Die Frage nach der Ursache führt fünf Schichten tiefer, zum Vertrauen im Team auf Layer 2. Der OKR-Workshop wiederum setzt voraus, dass ein Team gemeinsame Ziele als seine eigenen empfindet, und auch das ist eine Frage der unteren Schichten.

Diese Sichtweise hat eine entlastende Seite. Wenn ein Werkzeug nicht greift, ist das ein Debugging-Hinweis: Er zeigt, wo im Stack etwas hakt. Die Antwort liegt fast immer eine Schicht tiefer, als man zuerst sucht. In der Sprache von Argyris und Schön ist das der Schritt von der ersten zur zweiten Lernschleife.

Sie hat auch eine Seite, die Technikern sofort einleuchtet. Was gern als „Soft Skills“ zusammengefasst wird, lässt sich als Satz von Kommunikationsprotokollen lesen: Vereinbarungen darüber, wie Information zwischen Menschen fließt. Protokolle kann man lesen, verstehen und lernen, und wer jahrelang in Schichten und Schnittstellen gedacht hat, bringt dafür beste Voraussetzungen mit.

Was möglich ist

Wer Führung als Stack begreift, verändert vor allem die Reihenfolge, in der er lernt. Die Werkzeuge bleiben dieselben, das Feedback-Modell, die Zielmethode, das gute Einzelgespräch. Sie wandern nur an die Stelle, an der sie tragen.

Die Oktoberwoche hätte auch so laufen können. Jana hat die ersten Monate auf den unteren Schichten verbracht, und ihr Team weiß inzwischen ziemlich genau, wie sie auf schlechte Nachrichten reagiert. Als der Kollege im Change-Meeting eine Kollegin abkanzelt, spricht sie ihn am selben Nachmittag darauf an. Er verteidigt sich drei Minuten lang, dann wird er still und erzählt, dass ihn die Kollegin seit Wochen in jedem Meeting übergeht. Darüber reden die beiden eine halbe Stunde, und es ist kein angenehmes Gespräch. Am nächsten Morgen sitzt er an seinem Platz, und am Donnerstag entschuldigt er sich bei der Kollegin. Die Karteikarte hat Jana an diesem Tag nicht gebraucht.

Der Kurs Führungsstack geht genau so vor: von unten nach oben, Schicht für Schicht, in kurzen Videolektionen, die auf IT-Teamleiter zugeschnitten sind. Er ist für Menschen gedacht, die keine Führungsausbildung vom Arbeitgeber bekommen. Das Versprechen ist bewusst bodenständig: mit unter 500 € aus eigener Tasche und etwa zehn Stunden Zeit deutlich besser führen als vorher. Wer benachrichtigt werden möchte, sobald der Kurs öffnet, findet die Warteliste auf führungsstack.de.

Ein Werkzeug auf Layer 7 ist nur so gut wie die Schichten, auf denen es läuft.

---

Quellen

1. Argyris, Chris: Teaching Smart People How to Learn. In: Harvard Business Review 69 (3), Mai/Juni 1991, S. 99–109.
2. Argyris, Chris; Schön, Donald A.: Theory in Practice. Increasing Professional Effectiveness. Jossey-Bass, San Francisco 1974.
3. Bush, Randy; Meyer, David: Some Internet Architectural Guidelines and Philosophy. RFC 3439, Internet Engineering Task Force, Dezember 2002.
4. Clardy, Alan: 70-20-10 and the Dominance of Informal Learning. A Fact in Search of Evidence. In: Human Resource Development Review 17 (2), 2018, S. 153–178.
5. Dijkstra, Edsger W.: The Structure of the „THE“-Multiprogramming System. In: Communications of the ACM 11 (5), 1968, S. 341–346.
6. Dijkstra, Edsger W.: On the Role of Scientific Thought. EWD 447, Nuenen 1974. Abgedruckt in: Selected Writings on Computing. A Personal Perspective. Springer, New York 1982, S. 60–66.
7. Heinze, Holger: Der Führungsstack. Ein Führungssystem von Techies für Techies. Metakonkret, Oberursel 2026.
8. ISO 7498: Information Processing Systems. Open Systems Interconnection. Basic Reference Model. International Organization for Standardization, Genf 1984.
9. Lacerenza, Christina N.; Reyes, Denise L.; Marlow, Shannon L.; Joseph, Dana L.; Salas, Eduardo: Leadership Training Design, Delivery, and Implementation. A Meta-Analysis. In: Journal of Applied Psychology 102 (12), 2017, S. 1686–1718.
10. Mintzberg, Henry: The Nature of Managerial Work. Harper & Row, New York 1973.
11. Mintzberg, Henry: Managers Not MBAs. A Hard Look at the Soft Practice of Managing and Management Development. Berrett-Koehler, San Francisco 2004.
12. Zimmermann, Hubert: OSI Reference Model. The ISO Model of Architecture for Open Systems Interconnection. In: IEEE Transactions on Communications 28 (4), 1980, S. 425–432.