On Lean and Agility

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).

Bild: Pexels / Tima Miroshnichenko - Lizenz

Wenn es ein Dauerbrenner-Thema in jeder halbwegs grossen Organisation gibt, dann sind es Meetings. Und der Tenor ist immer der selbe: es sind zu viele, sie sind zu lang, sie sind langweilig und ein Grossteil der Anwesenden kann nichts beitragen. Auf die Frage wie es besser ginge folgt dann meistens ein undifferenziertes "einfach weniger Meetings!", was aber nicht hilfreich ist. Lässt man nämlich einfach einige weg, entstehen meistens Verzögerungen oder Unterbrechungen im Informationsfluss.

Dass ein Grossteil aller Meetings gleichzeitig unerträglich und unersetzlich erscheint, ist dabei Teil des Problems - sehr viele der eingestellten Termine haben keinen inhaltlichen Focus, sondern es handelt sich um die Regelmeetings von Organisationseinheiten (die legendären Team-, Abteilungs-, Projekt- oder Technik-Runden). In ihnen wird alles abgehandelt was irgendwo gerade anliegt, mit der Folge, dass auch Nicht-Betroffene es sich anhören müssen, nur weil sie Teil der selben Organisationseinheit sind.

Da jedes dieser Themen aber für irgendeinen Zweck wichtig ist, ist ein einfaches Abschaffen keine praktikable Lösung. Zielführender ist es, diese Zwecke zu identifizieren und danach gleichartige Themen in Meetings zu konzentrieren, zu denen dann nur diejenigen eingeladen werden können, die benötigt werden oder ein Interesse haben. Bestenfalls werden die für den einzelnen Teilnehmer dadurch sowohl weniger als auch relevanter. Also: welche Kategorien könnte es geben?

Teilnehmer-Status sichtbar machen

Man mag davon halten was man will, aber Meetings können Statussymbole sein, denn in einem Führungskreis oder einer Expertenrunde eingeladen zu sein kann als Bestätigung der eigenen Bedeutung oder Expertise verstanden werden. Wenn sie nur diesen Zweck haben sind derartige Termine wenig sinnvoll aber politisch bedeutsam. Wenn man sie nicht abschaffen kann, kann man sie zumindest seltener stattfinden lassen oder verkürzen (z.B. zu einem 15-minütigen "Leadership Daily").

Berufliche Existenzberechtigung sichern

Ein weiterer etwas schräger Fall. Viele Führungsrollen (manche Manager, aber auch einige Scrum Master) laden vor allem deshalb zu Meetings ein, um sich durch deren Moderation oder durch dort festgestellte Unterstützungsbedarfe selbst Arbeit zu erzeugen, die man später als Nachweis der eigenen Mehrwertstiftung vorweisen kann. Auch das ist inhaltlich verzichtbar aber politisch heikel, ggf. müssen diese Rollen bei einer Abschaffung dieser Termine andere sinnstiftende Tätigkeiten bekommen.

Reporting und Controlling

Vermutlich der Klassiker unter den Meeting-Formaten. Irgendwer hat irgendwelche Aufgaben aus einem der letzten Termine mitgenommen und berichtet wie weit er gekommen ist. Das ist vor allem dann problematisch, wenn es in generische Meldungen wie "ich bin weiter dran" verflacht. Ein sinnvoller Umgang kann sein, nur dann einen Bericht abzugeben wenn es einen Fortschritt gibt, und den ggf. auf den Hinweis zu beschränken, dass es für alle Interessierten einen separaten Termin gibt.

Ein Ventil bieten

Auch das darf man nicht unterschätzen: für viele Menschen, die sonst weitgehend alleine arbeiten, bieten Meetings die Möglichkeit Luft abzulassen und sich Frust und Sorgen von der Seele zu reden. Diese Funktion kann durchaus hilfreich sein, es besteht aber das Risiko, dass das Ranten und Jammern alle anderen Themen überlagert. Ein sinnvoller Weg kann sein, das bewusst einzuplanen, es aber auch mit (Zeit-)Grenzen zu versehen (hier ein Beispiel dafür).

Kommunizieren

Eine der positiveren Kategorien. Meetings können genutzt werden um Informationen zu verteilen. Wichtig ist dabei, dass es sich nicht nur um Einweg-Kommunikation handelt (dann würde meistens eine Email reichen), sondern durch Nachfragen und Erklären ein besseres Verständnis möglich wird. Ebenfalls hinterfragen kann man, ob alles kommuniziert werden sollte "was gerade so anliegt" oder ob kleinere themenspezifische Termine mehr Focus und Mehrwert stiften würden.

Entscheiden

Vielleicht der idealtypische Meeting-Zweck. Während Vorarbeiten oder Informationsbeschaffung meistens dezentral und asynchron erfolgen können, ist das bei Entscheidungsfindungen (bzw. den dazugehörenden Diskussionen) nur schwer möglich. Alle Beteiligten in einen Raum oder Call zu holen, alle Argumente zu hören und eine Management- oder Mehrheitsentscheidung herbeizuführen ist der bei Weitem effektivste und effizienteste Weg damit umzugehen.

Lernen

Egal ob Retrospektive, Kaizen-Event, Post Mortem, Schulterblick oder Near Miss - es gibt eine grosse Vielfalt von Meetings die dem Thema Lernen gewidmet sind (und idealerweise auch die darauf aufbauende Arbeit an Verbesserungsschritten enthalten). Man kann auch nicht viel dagegen sagen, mit vielleicht einer Ausnahme - aus Fehlern zu lernen ohne daran zu arbeiten (oder daran arbeite zu dürfen) sie in Zukunft zu vermeiden, ist auf Dauer frustrierend. Aber das kommt zum Glück selten vor.

Zusammenarbeiten

Ein Grenzfall, da viele Menschen zwischen Meetings und "der eigentlichen Arbeit" unterscheiden. Zumindest in Kreativ- und Wissensberufen ist diese Trennung aber nicht aufrechtzuerhalten, hier kann es auch Arbeitstermine geben, in denen von Brainstorming bis Mob Programming alles Mögliche stattfinden kann. Und in Remote-Settings ist der Kalendereintrag für eine gemeinsame Arbeit an irgendetwas nicht mehr von einem Meeting zu unterscheiden.

Alleine Arbeiten

In Unternehmen mit vollen Kalendern kann auch diese ungewöhnliche Form von Terminen auftreten: in ihnen (oder in ihrem ersten Teil) findet keine Interaktion zwischen den Teilnehmern statt, stattdessen sind sie ein Blocker um alleine (aber in einem Raum mit den anderen) eine Tätigkeit zu erledigen, die dann für einen weiteren, interaktiven Teil benötigt wird. Das bekannteste Beispiel dürften die PR/FAQ-Dokumente sein, die zu Beginn jedes Meetings bei Amazon von jedem gelesen werden müssen.

Beziehungen entwickeln

Eigentlich ein Nebeneffekt, der vor allem in Umgebungen wichtig ist, in denen sich die Menschen zwischen ihren Meetings nur selten oder gar nicht sehen. Da der nachvollziebare Wunsch nach persönlichem Kennenlernen und Austauschen nicht mehr durch Kantinengespräche o.Ä. erfüllt werden kann, tauchen private Themen hier auch in beruflichen Meetings auf. Ein sinnvoller Umgang damit kann sein, spezielle Meetings nur für diesen Zweck einzurichten.¹

Anerkennung geben und Erfolge feiern

Ob Projekt-Resultate, steigende Kennzahlen oder andere Erfolge - die meisten Menschen freuen sich darüber, ihre Arbeitsergebnisse zeigen zu können, Anerkennung dafür zu bekommen oder anderen Anerkennung dafür zu geben. Auch das kann in Meetings passieren, entweder explizit mit diesem Zweck oder implizit, z.B. wenn bei Ergebnis-Präsentationen bestimmte Beiträge besonders lobend hervorgehoben werden.

Wie immer bei derartigen Aufzählungen liessen sich sicher noch weitere Kategorien finden, die wichtigsten dürften aber enthalten sein. Wie zu Beginn gesagt, sobald die Identifikation dieser Kategorien, bzw. Meeting-Zwecke stattgefunden hat, kann man bei einer Neustrukturiereung versuchen, die Meetings so zu restrukturieren, dass sie nur noch einem oder wenigen dieser Zwecke dienen, um so klarer zu machen, wer wo benötigt wird und wer nicht.

Bild: Pixabay / Benjamin Nelan - Lizenz

Wenn irgendwo eine Methode zur Organisation von Arbeit ausprobiert wird, und das Ergebnis nicht den Erwartungen entspricht, ist eine Aussage meistens nicht fern: die Methode selbst könne man nicht dafür verantwortlich machen, sie wäre nur ein Werkzeug. Bei anderer Benutzung hätte sie auch andere Ergebnisse gebracht. Das ist auch nicht falsch, es ist aber auch nicht völlig richtig, denn bis zu einem gewissen Grad verleiten Methoden ihre Anwender zu bestimmten Handlungen.

Der Fachbegriff für dieses Phänomen lautet Affordanz und lässt sich folgendermassen erklären: zum Gebrauch gedachte Subjekte haben Charakteristika, die bestimmte Anwendungen möglich oder unmöglich, anstrengend oder einfach und effektiv oder ineffektiv machen. Am Beispiel eines Hammers erklärt - das Einschlagen eines Nagels ist möglich, einfach und effektiv, das Eindrehen einer Schraube unmöglich, das Einreissen einer Wand möglich aber anstrengend und ineffektiv.

Auch auf die Methodenwelt lässt sich das Affordanz-Konzept übertragen, schliesslich sind auch Methoden zur Anwendung gedacht. Auch hier ein Beispiel: mit Scrum lässt sich die Arbeit eines einzelnen Software-Entwicklungsteams einfach und effektiv organisieren, der Betrieb einer Fabrik nach Scrum geht gar nicht, und im Regelbetrieb eines Call Center wäre es zwar möglich, aber durch die vielen (und in diesem Kontext unnötigen) Meetings hochgradig ineffektiv. 

Das alles scheint bisher noch wenig bemerkenswert, hat aber an einer Stelle weitreichendere Implikationen als man auf den ersten Blick denken könnte, nämlich dort, wo eine Anwendung möglich aber ineffektiv ist. Der Erfinder des Affordanzkonzepts, der amerikanische Psychologe James J. Gibson, erkannte durch seine Forschung, dass alleine die Möglichkeit einer Anwendung dazu verleitet, sie wahrzunehmen - und zwar auch dann, wenn das wenig sinnvoll ist. Mit seinen eigenen Worten:

The affordances of the environment are what it offers [...], what it provides or furnishes, either for good or ill.

James J. Gibson, The Theory of Affordances, 1979

Und mit diesem Wissen im Hinterkopf können wir die Betrachtung einer Methode als neutrales Werkzeug nicht mehr aufrechterhalten, ihr Angebotscharakter verleitet zu bestimmten Umsetzungs-Arten. Scrum bietet die Möglichkeit, sich durch harte Definitions of Ready in Wasserfall-artige Phasen aufzuteilen? Die Wahrscheinlichkeit ist gross, dass genau das passieren wird. In SAFe lassen sich bis zu drei Hierarchie-Ebenen einrichten? Mit hoher Wahrscheinlichkeit wird genau das passieren. Etc.

Um nicht missverstanden zu werden: Affordanz impliziert keine deterministische Gesetzmässigkeit, es ist also möglich, gegenzusteuern und eine unnötig schwerfällige Methodenumsetzung zu verhindern. Um das tun zu können ist es aber hilfreich, wenn man sich unterschwelliger psychologischer Mechanismen wie eben der Affordanz bewusst ist.

Wir müssen noch einmal zu einer der unschöneren Gruppen hauptberuflicher Agilisten kommen, dem agil-industriellen Komplex. Zur Erinnerung: er umfasst Zertifizierungsorganisationen, die von Trainings-Anbietern finanziert werden, welche von Unternehmensberatungen für wirkungslose Pseudo-Transformationen instrumentalisiert werden, die wiederum von Unternehmen beauftragt werden, deren interne Prozesse eher auf schnelle Scheinerfolge als auf nachhaltige Veränderungen ausgelegt sind.

Die problematischen Auswirkungen dieser Kommerzialisierungs-Maschinerie dürften mittlerweile in allen Bereichen des agilen Arbeitens spürbar sein, hier soll es aber um eine besonders folgenschwere gehen: die Aufblähung der ursprünglisch schlanken agilen Frameworks zu umfangreichen, schwergewichtigen Regelwerken, die von ihren (oft unfreiwilligen) Anwendern eher als Belastung und weniger als Hilfe empfunden werden - und schon gar nicht als Erleichterung.

Die Hauptursache dieser Entwicklung sind einmal mehr die Zertifizierungen, die die Haupt-Einkommensquelle und den Haupt-Ergebnistyp des agil-industriellen Komplexes bilden. Der für sie zu entrichtende drei- bis vierstellige Preis muss gerechtfertigt werden, was bedeutet, dass in allen von ihnen relevantes Wissen vermittelt werden muss. Relevant wird das durch seinen offiziellen Status, und um den zu erreichen, muss das Wissensgebiet (halb-)offizieller Teil eines Frameworks werden.

Wie diese Aufblähung aussieht, kann sich von Fall zu Fall unterscheiden, der offensichtlichste Weg ist aber, möglichst viel in den offiziellen Umfang eines zu vermarktenden Vorgehensmodells aufzunehmen. Das bekannteste Beispiel dafür ist SAFe, dessen Dokumentation mittlerweile eine deutlich dreistellige Seitenzahl umfassen dürfte, auch Disciplined Agile entwickelt sich seiner Übernahme durch PMI erkennbar in diese Richtung.

Einen anderen Weg sind Scrum Alliance, Scrum.org und Kanban University gegangen, deren eigentliche Regelwerke (Scrum Guide und Kanban Guide) sind mit ca 10 Seiten noch immer sehr komprimiert. Was bei ihnen aber dazukommt ist eine grosse Menge an "offiziellem" Zusatz-Material für die sinngemässe Auslegung, Anwendung oder Einbettung in andere Kontexte (z.B. Scrum + OKRs oder Kanban + Legal), wodurch der Gesamtumfang auch hier erheblich angewachsen ist.

Eine dritte Variante Kommerz-getriebener Aufblähung kann man schliesslich bei Frameworks beobachten, die keiner Organisation zugeordnet sind, sondern gewissermassen Open Source. Hier erfinden Beratungen und Schulungsanbieter ständig neue Elemente, kopieren sie voneinander und erklären sie zur notwendigen "best Practice". Der bekannteste derartige Fall sind zur Zeit die OKRs, deren Kommerz-Variante stark mit Meetings, Rollen und Regeln überfrachtet ist.

Eine spezielle und in allen Varianten vorhandene Art der Aufblähung besteht schliesslich in Form von prozessunterstützender komerzieller Software, die im Rahmen vieler "agiler Transitionen" den Anwendern der agilen Frameworks zwingend vorgeschrieben wird (Beispiele sind Jira für Scrum oder Workboard für OKRs). Da in diesen Kontexten das Vorgehen und die Software untrennbar miteinander verknüpft sind, wird das Wissen um die Software-Funktion de facto Teil des Methodenwissens.

Wie oben erwähnt, für die Anwender ist eine derartige Aufblähung in der Regel eine Belastung. Zum einen dadurch, dass alleine die Aneignung und das in Erinnerung halten eines derartig umfangreichen Wissensumfangs mit Aufwand und Anstrengung verbunden ist, zum anderen dadurch, dass der aufbauend darauf gestaltete Arbeitsalltag von zahlreichen Pflicht-Meetings, komplizierten Regeln und restiktiven Workflows der jeweiligen Anwendungen geprägt ist.

Häufige Reaktionen auf diese Belastung sind Frustration, Dienst nach Vorschrift, der heimliche Aufbau von "Schattenprozessen", mit denen sich die ungeliebten offiziellen Methoden umgehen lassen (deren unnötige Aufblähung den meisten gar nicht bewusst ist) oder ganz einfach der Verlust von Freude an der Arbeit und der Identifikation mit dem eigenen Unternehmen. Konsequenzen deren sich jeder bewusst sein sollte, der sich mit dem agil-industriellen Komplex einlässt.

Um mit einer positiven Note zu enden: es gibt einen Ausweg aus dieser Situation, und der besteht ganz schlicht daraus, zuerst aufzuzeigen, wie die jeweiligen agilen Frameworks eigentlich gedacht sind, und was alles nicht notwendig ist um sie so wie gedacht einzusetzen. Dieser überschüssige Teil, der z.B. im Fall von Kanban oder OKRs alle (!) neu eingeführten Rollen, Meetings und Software-Tools umfassen kann, kann einfach weggelassen werden - und nur dadurch wird bereits vieles einfacher und schneller.

Natürlich braucht es auch dazu in der Regel die Unterstützung von Experten, was eine wichtige Frage aufwirft: wie lässt sich sicherstellen, dass nicht auch die dem agil-industriellen Komplex angehören? Die einfache Antwort: man sollte nur diejenigen in die nähere Auswahl nehmen, deren Lösungen werder Zertifizierungen, noch prozessunterstützende Software, noch umfangreiche Regelwerke oder zahlreiche neue Rollen enthalten. Less is more.

Was man beim Ansehen des Videos im Hinterkopf behalten sollte: es gibt nicht die eine richtige Art OKRs zu verfassen, sondern viele verschiedene Varianten, die parallel nebeneinander koexistieren (siehe hier). Gothelf und Seiden haben starke (und fundierte) Meinungen, und das was sie sagen dürfte dem State of the Art entsprechen. Andere Umsetzungen sind aber nicht falsch - nur anders.

Grafik: Pixabay / Geralt - Lizenz

Jeff Gothelf: How to build a high-performance culture without culling the herd

Nick Brown: Escaping Story Points with Right-sizing

Charles Lambdin: A Persona How-To

Matt Philip: Team size is a polarity to be managed, not a problem to be solved

Melissa Suzuno: Why Ramsey Solutions Rotates Engineers in Their Product Trios

Es ist eine Zahl, die mir selber extrem unwirklich vorkommt, aber hier ist sie: dieser Eintrag ist der tausendste, den ich auf dieser Seite schreibe. Immerhin verteilt über fast zehn Jahre, aber auch das ist eine Zahl die leicht surreal wirkt. Rechnet man beides zusammen kommt man auf über 100 Einträge pro Jahr, und nochmal tiefer heruntergebrochen auf einen bis drei pro Woche. Seit Anfang 2015 hat es keine Woche gegeben, in der ich nicht mindestens einen veröffentlicht habe.

Was mich im Rückblick fast am meisten erstaunt ist dabei, dass mir nicht irgendwann die Themen ausgegangen sind (als ich losgelegt habe war ich mir nicht einmal sicher, dass ich genug Stoff für ein Jahr haben würde). Da praktisch alles, was ich aufgeschrieben habe, in irgendeinem Bezug zu meinem Beruf steht, ist auch das eine Erkenntnis - er ist so vielfältig und abwechselungsreich, dass sich aus ihm eine praktisch unbegrenzte Menge an Texten generieren lässt.

Dabei ist es übrigens nicht so, dass ich eine Art "Redaktionsrhythmus" habe, und immer zu bestimmten Zeitpunkten schreibe (die einzige Ausnahme sind die am Ende jedes Monats erscheinenden Kommentierten Links). Zum Teil findet das Verfassen (ganz oder in Teilen) mit zeitlichem Vorlauf statt, zeitweise können über 10 fertige Texte in der Pipeline stehen. Zum Teil sind die Themen aber auch solche, die mir erst am Tag der Veröffentlichung eingefallen sind. Das kann stark schwanken.

Da ich manchmal gefragt werde - was ich nicht habe, sind genaue Statistiken zu den verschiedenen Einträgen. Weder zur durchschnittlichen Länge (irgeneine vierstellige Zeichenzahl), noch zur Verteilung der Themengebiete (wie oben zu lesen - fast immer geht es um: Agile, Scrum, Kanban, Change Management. Und den Rest.), noch zu den durchschnittlichen Aufrufzahlen (ich weiss nur, dass der populärste Text über 16.000 Views hat). So wichtig sind diese Zahlen aber für mich auch nicht.

Eine der Besonderheiten der agilen Community sind die "Insider-Hypes", die von Zeit zu Zeit aufkommen. Es handelt sich dabei um in der breiten Öffentlichkeit eher unbekannte Frameworks, Praktiken und Methoden, die unter Agile Coaches und Scrum Mastern aber eine Zeit lang als "heisser Geheimtip" gelten, bevor sie irgendwann wieder in der Versenkung verschwinden. Einer dieser Insider-Hypes der letzten Jahre ist ein Management-Framework namens Tight Loose Tight.

Für einen Hype ist Tight Loose Tight dabei relativ alt, es wurde bereits um das Jahr 2000 herum von der amerikanischen Unternehmensberatung Mercer Delta erfunden (siehe hier). Formalisiert und popularisiert wurde es dann ab ca 2010 von dem Norweger Rune Ulvnes, was mittlerweile zu dem verbreiteten Missverständnis geführt hat, es handele sich um eine "Führungsmethode aus Norwegen". Aber unabhängig von ihrem Ursprung - was ist das eigentlich?

Liz Guthridge, eine Unternehmensberaterin, die den Ansatz schon vor über 20 Jahren bei Mercer Delta kennengelernt hat, beschreibt seine drei Bestandteile so:

• Tight for purpose and goals: The organization’s executive team set the purpose and goals and tightly controlled them.
• Loose for execution: The business units and functions had autonomy in how they implemented and delivered on the goals, often under resource constraints from the executive team.
• Tight for results: The executive team also defined and measured the results they expected.

Oder mit anderen Worten: einer klaren Zielsetzung folgt eine möglichst grosse Freiheit bei der Umsetzung, gefolgt von einer genauen (und möglichst empirischen) Überprüfung, ob das Ergebnis tatsächlich erreicht wurde. Tight steht dabei für enge Führung, Loose für Delegation und Autonomie.

Rune Ulvnes hat diese Grundstruktur weitgehend übernommen, ihr aber zusätzliche Elemente hinzugefügt. Die Execution-Phase ist bei ihm nochmal unterteilt in Sprints von ein bis vier Wochen, und nach ihnen erfolgt jeweils Feedback zu Umsetzbarkeit, Zielgruppenakzeptanz und anderen Aspekten an das Management, das basierend darauf seine Zielsetzungen anpassen kann. Die Anlehnung an Scrum mit seinen Sprints, Sprint Reviews und Retrospektiven ist hier sehr offensichtlich.

Was ausserdem zur "norwegischen Variante" gehört ist eine Einordnung in ein Raster, in dem anhand der beiden Variablen der Verantwortungs-Delegation und der Arbeitsteiligkeit vier Extremtypen identifizierbar sind: das Steve Jobs-artige Genie mit dem Führungsstil tight tight tight, die nur auf Ressorcen-Optimierung konditionierte Führung mit dem Stil loose tight loose, die Feature Factory mit dem Führungsstil loose loose loose und ein agiles Vorgehen mit dem Führungsstil tight loose tight.

Jede dieser Zuordnungen kann zwar für sich genommen kritisch hinterfragt werden, löst man sich aber von den (in diesem Zusammenhang z.T. nicht unproblematischen) Begrifflichkeiten, kann das Raster ein durchaus sinnvolles Werkzeug sein, anhand dessen man sowohl eine Analyse des Ist-Zustandes als auch eine kontinuierliche Überprüfung der Bewegung zum angestrebten Zielzustand (in diesem Fall in der rechten oberen Ecke) durchführen kann.

Wie so oft bei derartigen Denkmodellen kann die Bewertung weit auseinandergehen, von "ein Augenöffner" bis hin zu "ist doch total banal" habe ich über Tight Loose Tight schon alles Mögliche gehört. Ich würde es aber so sehen: wem das Ganze nichts bringt, der kann es ignorieren, wem es hilft, der kann es benutzen. Und wer in der agilen Community an seinem Status als Thought Leader arbeiten will, der kann auf diesen Insider-Hype aufspringen, und damit sogar Anderen etwas Gutes tun. Also nur zu.