agiLEipzig Meetup #43: Team Topologies

Als ich die Ankündigung für dieses Meetup las, war mir sofort klar: da muss ich hin!

Der Tag selbst war mal wieder einer dieser Tage … die Internen waren allesamt in einem Team-Event („Referats-Klausur“) gebunden.
Die Telefone von Referatsleiter und Stellvertreterin waren auf mich umgeleitet und alle Kollegen hatten Abwesenheitsnachrichten aktiviert.

„easy“ dachte ich noch. Keine Termine und nur eine Aufgabe:
aufpassen, dass nichts schief geht.

Um 9:44 erreichte das Funktionspostfach dann die lange erwartete Nachricht. Das Ministerium stimmt dem Angebot und der Kooperationsvereinbarung mit dem Sub-Dienstleister zu. Die Haushaltsmittel seien in vollem Umfang zur Verfügung gestellt worden.
Alles wird gut?

Ich informierte die Ansprechpartner, die gerade das Ergebnis langwieriger, zäher und wenig erfreulicher Abstimmungen dieses Jahres durch die Staging-Umgebungen pushen.
Alles wird gut?

Die Projektleiterin war hocherfreut und hoffte darauf, nun endlich so krank sein zu dürfen, wie sie es tatsächlich war. Ich wünschte ihr gute Besserung und lehnte mich zurück.

Und dann kam der Anruf.

Das von mir dargestellte Vorgehen entspräche nicht dem, was gestern noch mit dem Ministerium ausgemacht sei.
Und jetzt?

Wir vereinbarten, beiderseits zu klären, wie der aktuelle Stand sei und welche Optionen es gäbe, wenn dieser oder jener Fall vorliegen würde. Mein Part bestand darin, den Mittelabfluss (in der „freien“ Wirtschaft: #Zahlungsstrom) und den Prozess bis dahin zu klären.

Alexander Jones und die Jagd nach den verschwundenen Millionen …

Der Haushälter konnte unter der angegebenen Referenz nichts finden, wohl aber die Haushaltsmittel für die benachbarten Aktivitäten. Er war verwundert, dass die Haushaltsstelle auf das BMI („Bundesministerium des Innern“) hinwies. Er hätte eine Kennung aus dem eigenen Ressort erwartet. Dennoch konnte er mich beruhigen. Wenn es tatsächlich erst heute angewiesen sei, dann würden die Mittel am kommenden Tag für ihn sichtbar sein.

Das war der Stand mit dem ich diesen Arbeitstag widerwillig abschloss.
Ich nehme „Sachen“ ungern über Nacht mit nach Hause.

Wobei … bis dahin würde es noch etwas dauern.

Jetzt geht’s los!

Anders als erhofft, war ich nicht zu dem – dieses Mal – etwas früheren Start des agiLE-Meetup um 17:00 bei F&P. Tatsächlich hat es bis exakt 18:00 gedauert. Dann erst betrat ich die Räume im Außenstandort am Floßplatz.

Zum Glück war noch ein Stuhl neben Conrad frei und so begann ich, mich im Plenum auf die eigentliche #Sache einzustellen.

Ich bin zur Vorbereitung dem Link in der Ankündigung gefolgt und hatte mich so schon mit den Terminologien vertraut gemacht.
Worum es dabei eigentlich geht, wurde mir dann durch den Vortrag von Bastian klar.

„Alle Modelle sind falsch
und manche sind hilfreich.“

Er berichtete davon, wie F&P Team Topologies nutzt, um das zu visualisieren, was in der Organisation vorgeht. Und dafür ist das Modell außerordentlich hilfreich. Überhaupt hatte ich den Eindruck, dass hier viele saßen, die sich durch dieses Modell sehr klar und verständlich ausdrücken können. Sind die wirklich alle bei F&P? Ich war irritiert. Was ist da los? Landet früher oder später jeder aktive agiLE-Teilnehmer da? Oder ist das Modell schon der neue Standard und „alle“ arbeiten damit
– nur ich habe das bisher nicht mitbekommen?

Im Verlaufe des Abends sollte es sich in weiten Teilen aufklären.

Doch bis es soweit sein würde, stellte Bastian erst einmal den Werkzeugkasten vor und illustrierte die Grundelemente auf einem miro-Board mit Beispielen aus der Organisation F&P. Mir kam das irgendwie bekannt vor und so fragte ich, wie ‚Team Topologies‘ zum unFIX-Modell passt, das ich durch Jurgen Appelo auf dem vorletzten Barcamp kennengelernt hatte. Rolf nahm das zum Anlass und erwähnte, es gäbe auf Jurgens Seite Blogbeiträge, die unFIX in Beziehung zu anderen Modellen bringen. Einer davon bespräche auch „TT“. Der behandelt dann auch die vermeintliche Schwäche, die auch Alex J. herausstellte. „TT“ ist sehr auf IT und dort insbesondere auf Software-Entwicklung fokussiert. Sofern eine Organisation die Funktionen ‚Sales‘ oder ‚Marketing‘ begleitend zur eigentlichen Softwareentwicklung betreibt, dann führe das schnell zu sehr großen Teams – insbesondere, wenn man einen ‚Self Sustaining Team‘-Ansatz verfolge. Vor allem führe das dazu, dass Unterstützungsfunktionen wie eben Marketing entweder Leerlauf haben oder Team-fremde Aufgaben übernehmen. Beides ist sub-optimal. In Alex’ Organisation hätte diese Erkenntnis dazu geführt, die Unterstützungsfunktionen wieder aus den Teams herauszunehmen, die direkt auf den Wertstrom einzahlen. In der TT-Nomenklatur sind das „stream-aligned Teams“ und diese erzeugen den Kern der Wertschöpfung. Die anderen Typen sind „Enabling-Teams“, „Platform-Teams“ und „Complicated Subsystem Teams”.

Mit dieser Erfahrung im Gepäck fragte Alex dann auch, wie ein Team darzustellen sei, das bei ihnen „Operations Research“ heiße. Sie machen „sophisticated Mathe-Kram“ und manchmal käme auch „ein goldenes Ei“ dabei heraus. Das war ein gutes Beispiel dafür, wie schwer die Einordnung oftmals fällt – und wie wichtig die Auswahl der korrekten Topologie ist, wird sich dann noch im späteren Praxis-Teil nach der Pizza-Pause herausstellen.

Matthew Skelton and Manuel Pais: Team Types and Interaction Modes

Bastian nahm den Beitrag zu Anlass, um auf die Risiken dieses Modells hinzuweisen. Er berichtete davon, beim Lesen des Buches zunächst den Drang verspürt zu haben, das Modell dazu zu nutzen, um das Organigramm von F&P auf diese Weise abzubilden.
Doch was abbilden?
Den Status quo? Der wäre veraltet, noch bevor er fertig ist.
Das ideale Zielbild? Dafür kennt er sich gut genug aus – sagt er.
Oder die jeweils nächste Evolutionsstufe?
Dafür wäre das miro-Board nicht wirklich geeignet.
Man könne es nicht filtern oder situative Kontexte selektiv darstellen – zumindest war das seine Ansicht.

Diese Ausführungen und vor allem sein Begriff des „Nachteile einkaufen“ machten etwas mit mir. Als Frank dann noch von „vielen Nachteilen“ sprach, nahm ich das zum Anlass für einen Wortbeitrag, der in mir bereits seit lehr langer Zeit, vielleicht seit Jahren, schwelte und für den ich hier nun den Anlass hatte, die Worte zu suchen.

„Nachteile sind akzeptabel, solange die Vorteile überwiegen.“

Alexander Gerber

So kann ich es nun formulieren. An dem Abend lag mein Fokus eher auf dem vermeintlich anzustrebenden Ideal, dass nur Vorteile und keinerlei Nachteile bietet. Bei Franks Darstellung entstand bei mir der Eindruck, die schiere Quantität von Nachteilen würde in seinem Arbeitsumfeld schon genügen, um eine Option auszuschließen – je mehr Nachteile die Gruppe findet, umso weiter weg rückt eine Option?

Tatsächlich setzen sich Optionen ganz anders durch.
Ja, Quantität spielt dabei auch eine Rolle.
Vor allem jedoch Qualität – nämlich: wie gut geht es „mir“ damit?

Und jeder für sich kann recht gut beurteilen, was jeweils schwerer wiegt. Und wenn dann noch eine „treibende Kraft“ (EN: „leading force“) innerhalb der Organisation für diese Alternative optiert, dann ist alles gut. Eine solche, führende Kraft kann sowohl der dominante Einzelentscheider als auch eine Gruppe „trusted advisors“ oder ein demokratisch erreichter Konsens sein. Es gibt viele Wege, wie sich eine Option durchsetzt und zum Bestandteil der Organisations-Kultur wird. Viel erheblicher ist, wie die Organisation darauf reagiert, wenn sich die Umstände ändern …

An dem Abend schlug ich – auch unter dem Einfluss von Lukas Schmidt (/Slot 2: metrics & measures) und Tobias Leisgang – vor, regelmäßige und transparente Bewertungen der Optionen durchzuführen.
Das muss nicht immer „gemeinsam“ sein, solange „alle“ die Werte-Hierarchie mittragen und das nachvollziehen können, was bei einer früheren Klientin so passend „Einwertung“ genannt wird.

All das erfolgt in der dritten Phase der Team-Bildung, die Tuckman „Norming“ genannt hat.

Und nach meiner persönlichen Überzeugung bleiben alle Arbeitsumgebungen weit hinter ihren Möglichkeiten zurück, solange sie diese Phase nicht erfolgreich durchlaufen und dadurch abgeschlossen haben.

Spoiler: da wo ich tätig bin, ist das die meiste Zeit nicht der Fall – denn:
sobald ein Team den eigenen Erfolg verspürt und quasi allein Fahrrad fahren kann, braucht es mich nicht mehr und ich thematisiere dann je nach Kontext noch die Phase 5: das Loslassen und warum so viele Teams Angst davor haben.

Im Wrap up (später …) kam dann noch „Tuckman-Teambuilding als Kostenfaktor auf, der [vermeintlich] gegen Veränderungen in der Team-Zusammensetzung spräche. Da war er wieder, dieser Drang der Software-Entwickler zur Stabilität.

An dieser Stelle ein Reminder: jeden einzelnen Tag und in jedem einzelnen Meeting durchlaufen die Teilnehmer die Tuckman-Phasen, sofern sie ein Team sein müssen, um Ergebnisse zu liefern (vgl. Shared Vison).

Wenn Verantwortung als „Schuld“ verstanden und lediglich geschoben wird, dann passiert genau das nicht. Die einzelnen Akteure verstehen sich dann als solitäre Lieferanten oder Leistungsempfänger und eben nicht als Teil eines gemeinsamen („shared“) Ganzen.

Und dann kam auch noch Conway’s Law zur Sprache.
Torsten statuierte, dieses vermeintliche Gesetz sei gar keines
[meine Ergänzung: weil eine Kausalitätsbeziehung („wenn … dann“) fehlt]. Tatsächlich war es ursprünglich und Ende der 1960er-Jahre zunächst eher eine hypothetische Heuristik – also eine Art Glaubenssatz, die einem die Welt erklärt ohne wissenschaftlich exakt („ceteris paribus“ – „conditio sine qua non“) bewiesen werden zu können.

Und dann fügte Torsten auch noch hinzu – „Conway reverse“ würde schon gar nicht funktionieren. Wenn also jede Organisation ihre Kommunikationsbeziehungen in Software abbilde, so könne man nicht aus einer Software-Architektur ableiten, wer mit wem in Austausch steht.

Wir kamen da hin, weil ich auf das MS-Research-Paper ‘The Influence of Organizational Structure On Software Quality’ verwies, das im deutschen Wikipedia zu Conway’s Law referenziert wird. Ihm zufolge haben die Forscher die Commits für Windows Vista zur Grundlage genommen, um Kommunikationsbeziehungen der beteiligten Teams darzustellen. Auf dieser Grundlage gelang es Microsoft seinerzeit, Schwachstellen von Vista pro-aktiv zu suchen und zu beseitigen.
Diese Erfahrungen nahm Microsoft zum Anlass, die Organisation der Entwicklungseinheit für Windows 7 nach dem Architekturentwurf für das Betriebssystem zu gestalten. Das war anders als bisher. Davor wurden Teams nach anderen Kriterien zusammengestellt.
Wer kennt wen, Seniorität und Fachexpertise.
Kennste?

Am Ende der Pizza-Pause erfuhr ich dann auch, weshalb ich speziell über die Sachkenntnis von Torsten so erstaunt war. Anders als ich bisher annahm, führte ihn sein Weg „seit Corona“ über eine Zwischenstation zu F&P. Und deshalb war er „mittendrin“ in dieser Organisationsentwicklung.

Und für die übrigen, nicht-F&P-Teilnehmer ist das Modell schlicht, einfach und für jemanden, der sich mit Organisationsdesign befasst nahezu selbsterklärend.
Das ist schon mal was.

Anwendung

Im Praxisteil standen zwei Bereiche zur Auswahl, bei denen die Gruppen die „real world“ modellieren konnten. Bastian schlug die Gruppenbildung auf der Grundlage von Geburtstagen vor: gerade links – ungerade rechts. Und so fand ich mich in einer Gruppe wieder, die das Team „Interne Arbeitsmittel“ von F&P modellierte. Zunächst ging es darum herauszufinden, was dieses Team „eigentlich“ macht. Marie fragte, ob es sich um die Ausstattung der Arbeitsplätze kümmert. Der Gedanke war für mich nachvollziehbar und naheliegend bei dem Namen. Es war auch mein erster. Es stellte sich jedoch heraus, dass sie eine parametrisierte Instanz von Zendesk für Teams wie „Support“ oder „Community Management“ zur Verfügung stellen. Deshalb zeichnete ich „Zendesk“ als Plattform und „Support“ als „stream-aligned“. Daraufhin ergriff „Michel“ das Wort und widersprach der Darstellung. Mit den Worten „wie denn dann?“ reichte ich ihm die Stifte und ein Tuch und er zeichnete es auf, wie sie derzeit in der Organisation betrachtet werden. Heraus kamen drei Stufen (Zendesk als Plattform, ihre Instanz als Plattfom und das Arbeitsmittel-Team als stream-aligned). Ich fragte, welchen Beitrag sie denn zum Wertstrom liefern und woran sie den messen. Michel berichtete, was sie tun und wer ihre Leistung konsumiert. Ich gab zu bedenken, dass es wohl schwer sei, den Beitrag zu messen, weil dieser nur indirekt geleistet würde. Das traf seinen Nerv. Michel hatte immer den Eindruck, ihr Team werde falsch behandelt. Sie werden durch die Organisation dazu gedrängt, Indikatoren so darzustellen, dass sie einen Anteil am Umsatz ausdrücken.
Die umstehenden Kollegen von F&P setzten gerade an zu erklären, warum das „schwierig, aber machbar“ sein solle, als ich intervenierte.

Ich sagte Michel auf den Kopf zu, er habe aus meiner Sicht das richtige, das zutreffende schlechte Bauchgefühl dabei.

Die Erleichterung konnte ich ihm ansehen. Es war, als fiele eine Last von seinen Schultern. Und als wir seine kognitive Dissonanz aufgedeckt und er durch mich Bestätigung erfahren hatte, konnten wir uns mit den Folgen befassen.

Doch dann waren die 10 breakout-Minuten auch schon vorbei.

Wrap up

Die Zusammenfassung erfolgte nun als Standup. Das gab uns Teilnehmern die Möglichkeit, uns im Halbkreis um die jeweiligen Boards aufzustellen.
Ehrlicherweise muss ich zugeben, von den Ausführungen der anderen Gruppe habe ich kaum etwas mitbekommen. Eigentlich sind mir nur zwei Punkte in Erinnerung geblieben, die in einem Zusammenhang miteinander stehen. Die Sprechperson für die andere Session berichtete, sie hätten eine Umgestaltung verworfen, weil es ein Durchlaufen der Tuckman-Phasen bedeuten würde. Alex Drestl kommentierte daraufhin, eine solche Umbesetzung sei durchaus akzeptabel, wenn ein Team längerfristig und an einem strategisch wichtigen Vorhaben arbeite, bei dem aufgrund des Zeit-Horizonts die Mehrkosten für ein wiederholtes Team-Building akzeptabel sein könnten.

Wie solche Mehrkosten signifikant gesenkt werden können, schreibe ich noch weiter unten. Stichwort: Norming.

Michel stellte die Erkenntnis unserer Session dar. An dem spannenden Punkt hörte er auf. Jetzt, wo zumindest dieses Team für sich erkannt hat, falsch behandelt zu werden: wie geht es weiter?

Wird ein Team, das so etwas für sich feststellt in der jeweiligen Organisation die Ermächtigung (aka „Kompetenz“) haben, sich entsprechend umzugestalten? Was macht es mit denjenigen, die für sich erkennen nun in diesem Team falsch zu sein? Werden sie in ein anderes Team wechseln können? Und wie wird das ablaufen?

Auch hier ist es eine Frage des „Norming“. Allerdings nicht auf der Ebene der Teams, sondern auf der Ebene des Gesamtsystems; der Organisation.

Spoiler: solange es hierfür keine Vorgehensweise – geschrieben oder informell festgelegt – gibt, wird erst einmal wenig passieren. Und dann kommt da noch der Hang zur Stabilität …

Jemand sagte einmal so treffend:

„Die Kultur ist der Schatten des Systems“

Fazit

Die Werkzeugsammlung ‚Team Topologies‘ („TT“) bietet hilfreiche Unterstützung bei der Entwicklung einer leistungsfähigen Organisation, deren Zweck darin besteht, Software zu erschaffen und für die Nutzung bereitzustellen.

Im Zusammenspiel mit anderen Modellen, Werkzeugsammlungen und Vorgehensmodellen wie ‚Domain Driven Design‘ („DDD“) oder ‚Test Driven Development‘ („TDD“), DevOps, Wertstromanalyse und auch OKR („Objectives and Key Results“) bietet „TT“ eine ergänzende Möglichkeit, um Engstellen durch Überlastungen („cognitive load“) im Fluss der Kommunikation (à ‚Systemtheorie‘) zu identifizieren und durch aktive Umgestaltung zum Besseren zu verändern. Und wer Gefallen an diesem Tool gefunden hat, die:der kann dann das Premium-Paket zubuchen und ‚unFIX‘ machen.

Von einer Last befreit weder dieses Toolset noch die übrigen Methoden im Werkzeugkasten. Was nun im einzelnen Kontext aus konkreter Zuständigkeit und Organisationskultur als „gut“ und „besser“ anzusehen ist, darüber müssen sich die jeweiligen Akteure klar werden, klar sein und klar bleiben. Diese Aufgabe wird nicht durch „TT“ gelöst oder durch ihre Anwendung obsolet. Vielmehr gibt das Modell mit den 4 Team Typen und den 3 Interaktions-Modi ein überschaubares und sehr schnell erlernbares Instrumentarium an die Hand. Seine Anwendung führt schnell zu den Punkten, an denen die Schwachstellen einer Organisation deutlich erkennbar hervortreten. Dadurch wird Bedarf sichtbar und Veränderungen können vorgenommen werden.
Das allerdings muss „man“ wollen. Derartige Transparenz wird nicht immer und von allen freudig begrüßt.

Take aways

An diesem Abend öffnete mir ein Begriff die Augen: ‚kognitive Last‘ (Skelton: ‚Cognitive Load‘).

‚Mental Load‘ wird mittlerweile häufig im Kontext von Familie, Covid und Home Office genannt. Und die Parallelen sind für mich deutlich erkennbar. Wahrscheinlich konnte der Begriff deshalb so gut bei mir andocken. „Bestelltes Feld“.

Im Kontext der Erwerbsarbeit soll nun auch die Organisation eine Topologie aufweisen, die den Energie-Aufwand zur Bewältigung von Kontext-Wechseln (EN: ‚context switches‘) reduziert und niedrig hält.
Als Sohn eines Landschaftsarchitekten war ich hier gleich zuhause.

Die Kernaussage des Ansatzes ist: gestalte die Landschaft (Organisations-Topologie) so, dass sie die Menschen unterstützt und ihnen die Arbeit erleichtert, anstatt fortwährende Konfliktlast durch Abweichungen (EN: „odds“) zwischen Organisation und Produkt zu erzeugen.

Wenn die Architektur des Systems und der Organisation von einander abweichen, wird die Organisation gewinnen.

Ruth Malan (2018)

Das andere Take-Away war der Begriff „Interaction Type“.

Ich habe mit Tobias Leisgang zu einem ähnlichen Zeitpunkt als „Team Topologies“ entstand, ein Buchprojekt gestartet. Wir wollten aus anderer Perspektive auf ähnliche Konflikte, unsere Beobachtungen und Lösungsansätze dafür ausarbeiten und festhalten. Ich selbst verspürte während des Schreibens das Bedürfnis, 5 Arten der Zusammenarbeit zu unterschieden, um ausdrücken zu können, warum Entwicklungsarbeit („Co-Creation“) andere Kommunikationsstrukturen braucht als reproduktive Arbeit („Co-Operation“). Bei Team Topologies sind es 3 Arten der Interaktion und so beinhaltet der „TT-Begriff“ von „Collaboration“ im Wesentlichen „Co-Creation“. Dieser Begriffsinhalt blendet damit einen erheblichen Anteil dessen aus, was als „HP-Way“ bekannt wurde und bereits vor der Gründung von HP die Hauptursache war, weshalb Claude Shannon das formulieren konnte, was heute als Ursprung der Informationstheorie angesehen wird. Nach meiner Auffassung basiert dieser bahnbrechende und grundlegende Beitrag Shannons auf dem, was ich unter „Collaboration“ verstehe: Menschen teilen Gedanken und Informationen, die dann zu etwas Neuem inspirieren, ohne dass dieses Neue vom Teilenden zielgerichtet angestrebt wird. Nach meiner Auffassung ist „Collaboration“ hierfür ursächlich im wissenschaftlichen Sinne und weit entfernt von „glücklichen Umständen“ oder gar „Zufällen“. Es ist das tatsächlich zwangsläufige Ergebnis der Umstände und Abläufe. Und sobald das als solches akzeptiert und gültig angesehen wird, können solche Umstände und Abläufe aktiv gefördert – jedoch nicht wissenschaftlich exakt oder naturgesetzlich zwangsläufig geschaffen werden. Die Organisation kann solche Zustände fördern, billigen oder unterbinden.

No offence!

Ob eine Organisation zum einen oder anderen tendiert, hängt von ihrer jeweiligen Kultur ab. Traditionell oder modern.
Und manchmal gibt es auch beides – Country and Western.

Im Fall der Informationstheorie und später als Ursache für den Erfolg von HP wird berichtet, sie seien auf gemeinsame Pausen – insbesondere Mittagspausen – zurückzuführen.

Learnings

Dieser kleine Vorfall mit Michel und seinen Kollegen ist symptomatisch für ein Bündel von Phänomenen. Sie treten immer wieder auf, wenn die Ansicht einzelner Personen in Konflikt zum vermeintlichen Konsens steht.

Craig Larman hat diese als ‚Larman’s Laws of Organizational Behavior‘ ausformuliert. Torsten würde jetzt einwenden, es handle sich dabei nicht um Gesetze und er hat Recht. Und dennoch hilft es, diese nicht ganz ernst gemeinten, heuristischen „Grundsätze“ zu kennen. Zusammengefasst lautet die Essenz:

„Menschen reden solange,
bis sich nichts mehr ändern muss.“

Das lässt sich aus vielen Perspektiven rechtfertigen – bspw. aus Gründen der Energieeffizienz. Es ist schließlich weniger aufwendig zu reden als zu handeln (EN: “Talk is cheap!”).
Oder aus Perspektive der Sicherheit.
Lieber verlässlich falsch und jeder kann sich darauf einstellen als möglicherweise richtig oder anders falsch.
Wenn es „anders falsch“ ablaufen könnte, dann doch lieber „vorhersehbar falsch“ und jeder findet seinen Weg, damit umzugehen.

love it or leave it
and by all means do not change it!

Ich kenne das alles zur Genüge und achte deshalb darauf, den Status quo nur dann zu verteidigen, wenn er bewiesenermaßen passend ist und sich gegen alle anderen Alternativen durchgesetzt hat.

„Americans always do the right
– after exhausting all the alternatives.”

Churchillian Drift

Das ist jedoch nur in sehr, sehr wenigen Kontexten der Fall. In den allermeisten Fällen herrschen weniger moderne Zustände (die passendste Lösung) als mehr traditionelle („mach’n wa imma so“).

Armin Nassehi habe ich eine Erkenntnis zu verdanken, die dieser ganz lapidar in einem Nebensatz fallen lies und die mich wie ein Blitz traf. Modern sei demnach alles, was die zu den Gegebenheiten passende, beste Lösung sucht. Er versteht „passend“ dabei nach meiner Wahrnehmung in der vollen Mehrdimensionalität wie auch Gitta Peyn. Traditionelle Gesellschaften würden dagegen einen hohen Aufwand treiben, um den Status quo zu erhalten, schob er hinterher. Und das war der Blitz, der mich traf. Bei Gesellschaften schließt das sogar den Verlust von Menschenleben einzelner für „die Sache“ mit ein. Bei wirtschaftlich tätigen Organisationen ist die Entsprechung der Fachkräftemangel. Traditionelle Organisationen betreiben eher Akquise-Aufwand, um Personal- oder Kundenverluste auszugleichen als den Status quo zu ändern. Sie gehen so mit ihrer Beharrlichkeit unter.

Jetzt ist F&P nun alles andere als ein traditionelles Unternehmen. Und die jungen Kollegen sind weit von einem Verdacht entfernt, Verfechter traditioneller Organisationsformen zu sein. Ich schätze, sie sind eher Opfer eines myelitischen Effekts.

Hä? Was’n das?

Das habe ich mir gerade ausgedacht.
Myelin ist der Stoff, der den Unterschied zwischen Kahnemanns langsamen und schnellen Denken ausmacht. Es ist ein Lipid, also ein Fettstoff, der Nervenbahnen umhüllt. Immer, wenn das Gehirn Wiederholungen wahrnimmt, beginnt es die an der Aktivität beteiligten Nervenzellen (Neuronen) zu stabilisieren, zu verstärken und die Verbindung zwischen ihnen mit einer Fetthülle aus Myelin zu umhüllen. Aus vielen dünnen Kupferdrähten wird ein Kabel. Deshalb müssen wenige von uns darüber nachdenken, wie eine Tür zu öffnen ist oder welche Bewegungen für „Laufen“ erforderlich sind.

Blöd nur: Myelin unterscheidet nicht nach „richtig“ und „falsch“
– nur nach Häufigkeit.

Blöd auch: „unlearning“, also das Aufbrechen dieser verfestigten Verbindungen kostet in etwa 10x mehr Aufwand als das Erlernen.
[Man] sollte also den Dingen sehr viel Aufmerksamkeit widmen, die man immer wieder tut.
Zumindest, wenn sich abzeichnet, dass „man“ sie immer wieder tun wird.

Immer wieder das Falsche falsch tun kann sehr, sehr teuer werden.

Darin besteht dann auch die Schwierigkeit in der Praxis. Bei sehr wenigen Tätigkeiten sucht man sich schon zu Beginn Lehrer, Mentoren und Coaches. Wer garantiert mir denn, dass ich es für den Rest meines Lebens brauchen werde? Die Frage kennt jeder von uns aus der Schule.

Die meisten Mitmenschen haben sich deshalb ihre spezifischen Verhaltensweisen zu eigen gemacht, die sie dann immer wieder anwenden. Manche sprechen auch ‚Verhaltensmustern‘. Ob diese Muster nun zur vorliegenden Situation passen, ist für diese Menschen vollkommen unerheblich. Sie machen sich’s einfach und machen es einfach so wie immer. Und so kommt es, dass ein Gruppenkonsens gegenüber vermeintlichen „Angriffen“ verteidigt wird, weil die Gruppe Schutz und Sicherheit bietet und das solidarische Wesen Mensch in der Gruppe höhere Überlebenschancen hat. Blöd nur, wenn eine Kritik keinen Angriff, sondern eine Gelegenheit zur Verbesserung darstellt.
Da war es wieder, das moderne, agile #Mindset.

Ich wusste das alles an diesem Abend und ich bin mir der toxischen Wirkung von Höflichkeit im Angesicht der Veränderung bewusst. Und so „grätschte“ ich den unverändert hoch geschätzten Kolleg:innen „hinein“, um genau diesen toxischen Automatismus zu unterbinden. Und so kam es zum Moment der Erkenntnis, der sich hoffentlich auch für F&P auszahlen wird.

Mein Verhaltensmuster ist übrigens, erst einmal die Situation zu erfassen, um danach die mir ersichtlichen Handlungsoptionen zu listen, sie nach ihren erkennbaren Konsequenzen zu bewerten und dann die meistversprechendste Option auszuwählen. Das läuft bei mir oftmals so schnell ab, dass meist mit einem „Bling“ genau eine Handlungsoption bei mir erscheint, sobald ich den Kontext einigermaßen umfassend erfasst habe à „schnelles Denken“. Bei sehr vielen Menschen ist es auch so und doch anders. Es erscheint eine Option – oder keine. Der Unterschied zu vielen meiner Mitmenschen ist: wenn sich der Kontext ändert, erscheint mir eine andere Option. Das gilt auch für eine veränderte Wahrnehmung des Kontextes, weil bspw. eine neue Information das Bild in erheblichem Maß verändert.

Manche verstehen #Information als eine Mitteilung mit Neuigkeitswert.

Nachlese

Am Folgetag sprach ich mit Conrad. Eigentlich, weil wir den CRUScH-Workshop für den kommenden Tag final abstimmen wollten. Weil Conrad uns zur Pause verlassen hat, gab ich ihm mein Fazit und berichtete von „Tuckman“ als Argument gegen Veränderungen von Team-Zusammensetzungen. Als ausgebildeter Jurist fokussierte ich – wie immer – auf die ‚Norming‘-Phase. Conrad mit seinem Kommunikationsschwerpunkt sieht darin vor allem die Standardisierung von Kommunikation – wer mit wem wann und worüber auf welchem Kanal (persönlich, schriftlich, in Präsenz oder auf Distanz).

Für mich ist das nur ein Teilaspekt. Juristen verstehen unter „Norm“ jede Art von Festlegung, die nach der IF/THEN-Abfolge von Voraussetzung und Rechtsfolge dazu führt, dass ein SOLL-Zustand – das so genannte ‚positive Recht‘ – gelten soll. Und genau das ist die Funktion von Recht. Es regelt beim tatsächlichen Vorliegen eines Sachverhalts (aka „Lebenssachverhalt“) wie damit verfahren werden soll. Und es lebt davon und dadurch, dass dieses „SOLLEN“ auch als gültig akzeptiert wird.

Wenn nun die ‚Norming‘-Phase nicht abschließend durchlaufen wurde, führt bei traditioneller Herangehensweise jede Abweichung im „Lebenssachverhalt“ („ein anderer Fall“) dazu, dass die Akteure zurückfallen in die Storming-Phase mit der sie für sich klären, wer Recht hat, damit diese:r dann festlegt, was richtig ist. In hierarchischen Organisationen werden diese Fälle im Wege der Eskalation behandelt. In „flachen“ Organisationseinheiten wie [echten] Teams, werden auf der Grundlage historischer Erfahrungen, Persönlichkeitsstrukturen und fachlichen Kompetenzen „Bestimmer“ für die jeweiligen Einzelfälle gesucht und gefunden. Das dauert.

Viel besser wäre es nach meiner Auffassung, die möglichen, denkbaren, wahrscheinlichen und häufigen Fälle gemeinsam zusammenzutragen und festzulegen, wie mit ihnen verfahren werden soll – Voraussetzung > Rechtsfolge. Mich wundert es immer wieder, wenn Software-Entwickler, die auch meiner Erfahrung nach zur Stabilisierung durch Standardisierung neigen, es ablehnen, wegschieben oder ignorieren, ihre eigenen Angelegenheiten in der gleichen Weise zu regeln wie die der Nutzer: programmatisch.

Und dann ist da noch die Sache mit dem Erfolg. Für viele genügt es zu handeln.

„Hab‘ ich doch gemacht.“

In etwas weiter entwickelten Umgebungen wird über Werte und deren Messbarkeit gesprochen. „Wert“ kann natürlich so etwas softes wie Respekt sein. Das zielt eher auf Umgangsformen und ist sehr beliebt, wo #NewWork Einzug halten soll. Nach meiner Ansicht kann man sich mit „so etwas“ befassen, wenn man das Geschäft im Griff hat. Und da geht es zunächst um die Objektivierung des subjektiven Empfindens. Ist „schnell“ eher 5 Minuten oder eine Stunde? Und was, wenn es sich um die Antwort eines Webservers handelt?

Nach meiner Erfahrung klären sich die soften Themen dann meist bereits im Kontext dieser Objektivierung. Ist „Produktion“ wichtiger als „Kaffee-Pause“? Ist der schnelle „Kontakt zum Nutzer“ wichtiger als „die richtige Antwort“? Mit all diesen Festlegungen ergeben sich dann die soften Werte wie „Respekt“, „Mut“ und „Vertrauen“ meist schon aus „der #Sache“ heraus und am Ende geht es lediglich darum, auch das für jede:n zugänglich festzuhalten.

Und wenn das alles immer noch nicht so recht in Gang kommen will, hilft nach meiner Erfahrung eine sehr mächtige Frage:

Wie zahlt mein Beitrag auf [das strategische Ziel] ein?

In so mancher Umgebung wird es danach ungemütlich. Und auch das ist ein wertvoller Indikator. Für die Person, die diese Frage stellt wie auch für Personen, die sie beantworten oder nicht beantworten können.

Und wenn die Organisation die Frage ernst nimmt und in Zusammenhängen jenseits des einzelnen Teams beantworten möchte, dann landen die Beteiligten bei OKR oder anderen Methoden zur Ergebnismessung.

Mehr …

Wie alles begann:

Und dann:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from commodus.

Subscribe now to keep reading and get access to the full archive.

Continue reading