Das Ende der Karriere.

„Warum wir keine (festen) Titel und Positionen

mehr haben“

Wir haben vor einiger Zeit einen Blogartikel veröffentlicht, der so hiess: „Warum wir keine festen Titel und Positionen mehr haben.“. So richtig brandneu ist das nicht. Viele Firmen machen das schon so, wir haben es dann nur verbloggt. Es gab sehr viel Feedback zu diesem Artikel, und eines hat dazu geführt, dass ich hierher eingeladen wurde. Aber es gab auch viel anderes Feedback.

„Die Mitarbeiter wollen das doch gar nicht.“

Eine der Anmerkungen war, dass die Kollegen das gar nicht wollen.

„Es muss Lenker und Entscheider geben.“

Oder „Es muss Lenker und Entscheidet geben, Führungsrollen und Backboneinfrastruktur, damit es funktioniert.“

„Die Kollegen brauchen Titel und Positionen für die Karriere.“

Und der Kollegen ist ausserdem dagegen, weil er Titel und Positionen für die Visitenkarte braucht.

Grundannahme:

Spannend hinter diesen ganzen Kommentaren ist, dass sie die gleiche Hypothese haben: die Unternehmensleitung, also Albrecht, Björn und ich, haben beschlossen, dass das so läuft.

Tatsächliche Historie I

2005 Das Management führt Scrum ein (!)

2006 Standort Würzburg schafft Scrum wieder ab.

200720% aller Kollegen werden Scrum-Master. Alle Geschäftsführer & Teamleads.

2008 Agile Fluency Level 1 und Cargo Cult

2010XP-Practices: TDD, Pair Programming, CI/CD, Sustainable Pace etc, DevOps Community of Practice

2011 Scrum-Master != Teamleads (finally), Scrum by Heart

2012Servant Leadership & Stewardship statt Transaktionales Management

Tatsächlich sah das ganz anders aus. Wir haben 2005 auf die ebenso klassische wie dümmliche Art Scrum eingeführt, wie man das damals so tat - das Management, konkret ich, ha es eingeführt. Ich habe ein langes Memo gemacht, es gab einen Workshop, ein Whitepaper, viel Dokumentation und Training. In München, wo ich die Kollegen direkt vor der Flinte hatte blieb es auch erhalten - die Kollegen vom Standort Würzburg haben es probiert und sind dann recht schnell zu dem Schluss gekommen, dass Scrum nicht zu unserer Arbeit damals - also Webentwicklung - passt. 2 Jahre später haben wir dann alle Geschäftsführer und Teamleads zu Scrum-Mastern gemacht.

Tatsächliche Historie II

2012 Das Team Allstars verzichtet auf feste Positionen.

2012 Viel Diskussion im Confluence

2012Einzelne Teams geben Teamleiter zugunsten von Teamvertreter auf

2012Unterschriftensammlung im Wiki „Ich verzichte auf meinen Titel“ - 85% unterschreiben.

2013 In München werden die Rollen von den Teams verteilt

2014 Gehälter und Feedback über agile Werkzeuge

2015 Ich verblogge, was die Kollegen 2012 gemacht haben.

Tatsächlich sah das in der Praxis ganz anders aus. Wir haben in München lange Jahre ein sehr innovatives Team gehabt, mit Sebastian Springer als Teamleiter. Die haben nicht nur Zeit zum nachdenken gehabt, sondern auch viele gute Leute. Und die haben mit dynamischen Rollen angefangen. Parallel dazu haben andere Kollegen Blogartikel etc ins Wiki gehoben, die das behandelt haben. 2012 hat ein neu entstehendes Team direkt auf den Teamleiter verzichtet, und Basti hat gemeinsam mit seinem Team seine eigene hierarchische Teamleitung deaktiviert. Kollege Albrecht hat im Wiki das Experiment gemacht, einfach mal eine Umfrage zu machen, wer auf seinen Titel verzichten würde - und sehr schnell haben viele darauf verzichtet. 2013 und 2014 ist das in München dann über den ganzen Standort dynamisch geworden, es sind Werkzeuge wie Moving Motivators, Personality Poker, etc dazugekommen - auf initiative der Leute und Teams. Das habe ich dann „für die Nachwelt“ im Wiki zusammengefasst, und erst auf Wunsch der Kollegen in den Blog gestellt, weil die meinten, das wäre eine gute Idee.

There is no masterplan.Es gab also keinen Masterplan. Das hat sich bei uns so ergeben.

Agil ist das, was neben den Fehlern

von den Experimenten übrigbleibt.

Emergente Methoden sind diejenigen, mit denen man häufiger gewinnt als verliert. Man könnte auch sagen: agil ist das, was von den Experimenten übrig bleibt, wenn man die Fehler abzieht.

Cynefin

In komplexen Systemen kann der Zusammenhang zwischen Ursache

und Wirkung nur im Nachhinein verstanden werden.

Und wenn man Cynefin trauen darf, dann wäre so ein Masterplan auch gar nicht sinnvoll gewesen. Software - und gerade innovative Entwicklung im Web- und Mobile-Bereich wie bei uns - verhält sich komplex. Und in Komplexen Systemen gibt es keine direkte Verbindung von Ursache und Wirkung - sondern beide sind über Zeit getrennt. Aber man kann es im Nachhinein verstehen und erklären.

Dann versuche ich das doch mal.

Cynefin

In komplexen Systemen kann der Zusammenhang zwischen Ursache

und Wirkung nur im Nachhinein verstanden werden.

Und deshalb bin ich heute hier. Um mal nachträglich zu schauen, warum es genau so gekommen ist. Erwarten sie auch keine brillanten Ideen von mir, das meiste von dem was wir tun ist geklaut. Hier auf diesem Laptop befinden sich 250 Fachbücher zu diesen Themen im Kindle, und da sind auch die von den anderen Sprechern hier dabei. Ein paar von unseren Scrub-Mastern haben auch bei Boris gelernt, und it-agile berät uns schon immer. Manchmal beim Bier privat und manchmal auch beauftragt.

Johann-Peter Hartmann

@johannhartmann slideshare.net/johannhartmann

Ich, das ist Johann-Peter Hartmann, komme aus München und bin auch über Twitter zu erreichen. Im Moment mache ich wieder sehr viele Talks - alleine in diesem Herbst habe ich 7 neue Vorträge zu allen möglichen Themen von DevOps über Leadership zu Firmenkultur halten dürfen. Eigentlich komme ich aber von einem echten IT-Background, ich bin noch eins von den Kindern mit dem Commodore 64.

Im Sinne von Scrum bin ich bei dem Thema heute ein echtes Pig und kein Chicken. Ich habe die Firma, in der ich heute arbeite, vor 18 Jahren selbst gegründet, daneben noch eine Security-Firme gegründet, und bei zwei Startups war ich als Investor dabei. Agile Leadership und die damit verbundenen Fehler sind also eine Frage des eigenen Geldes, ich habe in meinem Leben praktisch nichts ausser diese Sachen geleistet und würde es daher ungern kaputt machen.

Chief Tailwind Officer

Hacker

Als ich die erste Firma gegründet habe wurde ich als Hacker vom Dienst quasi automatisch der CTO. Durch die agile Geschichte von oben hat sich das dann quasi vollständig erledigt, weil die Teams selbst über das Wie - und damit auch über die eingesetzten Methoden, Lösungen und Werkzeuge - entscheiden. Also heisse ich seit 2012 „Chief Tailwind Officer“, das ist im Sinne von Servant Leadership und, um die Seefahrtsmetapher noch eins mehr zu überdehnen, Stewardship.

Was wir lernen mussten …

Dann versuche ich mal zu erklären, wie sich das ganze ergeben hat.

Net Negative Productive(Senior) Progammer

Ein schöner Fehler von uns: wir haben in einem Team einen Entwickler gehabt, der sehr erfahren und ein sehr guter Developer ist. zu den meisten Themen bringt er ein wirklich gutes Knowhow mit, und weil er auch noch freundlich ist hört jeder gerne auf ihn.

Senior-Architect: alleine oder im Pair für ca 40% der Storypoints eines 7-Kopf-Teams verantwortlich.

Dann hat er das Team verlassen.

Was ist mit der Teamperformance passiert?

Und tatsächlich hat er durch die Decke performt. In einem 7 Entwickler grossem Team hat er 40% der Storypoints im Mittel durchgesetzt. Bei jedem Problem wurde zunächst mit ihm gesprochen, und man konnte seine Handschrift auch in den Klassen sehen, die die Kollegen entwickelten. Dann hat er das Team und die Firma verlassen, aus privaten Gründen und in guter Freundschaft. Unser Kunde kam umgehend zu mir und hat seiner Panik Ausdruck verliehen. Und ich habe ihm gleich ein viel höheres Geldangebot gemacht. Alle Deadlines haben gewackelt, und Angst machte sich breit. Was meinen Sie, was dann tatsächlich passiert ist?

+20% Genau, innerhalb der nächste 5 Sprints stieg die Performance des Teams auf 120% der ursprünglichen Performance. Die verbliebenen Kollegen haben seinen Performance nicht nur absorbiert, sondern sogar wieder aufgeholt.

Senior vs

Junior

Die nächste Geschichte. In einem Team hatten wir einen sehr erfahrenen Senior. Sein Name ist in vielen OpenSource-Bibliotheken zu finden, er ist der Datenbankguru und regelmässig als Speaker auf Konferenzen. Im gleichen Team hatten wir einen Auszubildenden, der nicht nur ziemlich pfiffig war, sondern auch engagiert - am Wochenende hat er gerne den Source gesäubert und Prototypen gebaut. Engagement war hoch, und er kannte sich nach kurzer Zeit sehr gut aus. Er kam mit guten Vorschlägen zur Anpassung und Gestaltung der Architektur, und weil sie alle mochten, wurden sie auch umgesetzt.

Senior

Developer

Senior

Junior

Offizielle VerantwortungKompetenz

Wen haben die Kollegen bei Architekturfragen um Hilfe gebeten?

Wenn Sie in diesem Team wären - wen hätten Sie zu Architekturthemen um Rat gefragt? Den mit der offiziellen Rolle, oder den Kollegen mit dem Detailwissen? Genau so war es bei uns auch - die Entwickler haben sich immer an den Kollegen mit dem konkreten Sachknowhow gewandt, nicht an den erfahrenen Kollegen, der sich mit der Applikation bei weitem nicht so gut auskannte.

Der obsolete Teamlead

Und ein drittes Beispiel von uns: Beim Staffing eines neuen Teams war klar, dass es durch haarige Zeiten gehen würde. Die Firma, die mit dem Projekt begonnen hatte war an ihm insolvent gegangen, und alle Beteiligten waren am Ende Ihrer Kräfte.

Unklare Anforderungen Ambitionierte Architektur Technical Debt Dienstleister insolvent

In diesem Projekt sah wirklich alles schlecht aus. Kunde war ein Konzern, bei dem die Fachabteilungen sich nicht ganz einig waren. Dementsprechend waren die Anforderungen unklar. Deshalb hatte der erste Dienstleister auf diesem Projekt auch seinen besten Architekten an das Projekt gesetzt, der seine Fähigkeiten auch gleich in einer ambitionierten Architektur dargelegt hat. Lieferdruck und Komplexität haben dann im Zusammenspiel dafür gesorgt, dass der Technical Debt schnell ansteigt, und am Ende gab es das, was es geben musste. Missglückter Launch, zweiter Versuch schlägt auch fehl, der Dienstleister geht insolvent.

Schwieriges Projekt: erfahrene Kollegen & Stimmungsteamlead

Als wir das Projekt erbten haben wir dementsprechend ein Team mit erfahrenen Kollegen - und einem emphatischen Teamlead zusammengestellt, um das zu überleben. Die Aufgabe vom Teamlead war klar - die Stimmung drehen, und die Lieferfähigkeit wieder herstellen.

Es hat funktioniert.

?Und es hat funktioniert - die Kollegen haben das Projekt gut eingefangen und auf Schienen gesetzt, und mit den ersten Erfolgen kam auch die gute Stimmung zurück. Ohne den Teamlead hätte es nicht funktioniert, er hat das Projekt tatsächlich gerettet. Aber: er wurde danach nicht mehr gebraucht. Der kritische Pfad war jetzt nicht mehr die Teamstimmung, sondern die operative Arbeit. Und da wanderten die Führungsaufgaben auch automatisch hin - zum erfahrenen Senior im Team, der Architektur gut mit den Kollegen diskutieren und verhandeln konnte, und zum Senior, der Vision und Alignment für das Produkt voll im Griff hatte und ein gutes Vertrauen geniesst.

Es wird kein Teamlead mehr gebraucht.

?Und dann waren wir in einer interessanten Situation. Der alte Teamlead war da, allgemein respektiert und anerkannt. Aber man brauchte ihn nicht mehr. Weil das Team inzwischen sehr reif war, war auch kein Ersatz notwendig. Formell brauchte zu diesem Zeitpunkt bei uns jedes Team einen Teamlead, und deshalb gab es ihn - aber faktisch hatte sich die Rolle für dieses Team erledigt, es gab keine Aufgaben mehr, die übrigblieben.

Der Scrum-Master, der gar keiner war.

Und noch eine Geschichte. Wir hatten zu der Zeit noch die klassische Karriere - Junior, Developer, Senior, Teamleiter, Scrum-Master und Scrum-PO. Die Weiterentwicklung wurde vor allem durch die Vorgesetzten durchgeführt. Das hat zu interessanten Effekten geführt. Ein Kollege wollte gerne Scrum-Master werden, und das Feedback seiner Kollegen war gar nicht schlecht - sie trauten ihm das zu. Daraufhin haben wir ihn zur Zertifizierung geschickt und auf agile Konferenzen, und bei nächster Chance wurde er zum Scrum-Master in dem Team, das diese Rolle für ihn auch bestätigt hat. Faktisch handelt es sich bei dem Kollegen um einen klassischen Asperger-Fall, ein Nerd reinster Güte. Jeglicher Instinkt für die Emotion anderer Leute fehlt, die Kommunikation fällt im Scrub-Kontext schwer. Das hat natürlich nicht geklappt. Die Position war aber vergeben, und der Kollege hatte den Titel schon im Lebenslauf.

Da stimmt doch was nicht.

Wir haben noch viele solche Geschichten erlebt. Mein Kollegen Albrecht hat auf der OOP einen Talk über unsere schönsten Fehler gemacht, und wir haben eine viel grössere Sammlung im Wiki.

Allergile Reaktionen

Dinge, die passieren, wenn Agil Dinge

transparent macht.

Wir haben festgestellt, dass viele Dinge, wenn man sie mit agiler Arbeit bewirft, kaputtgehen. Da verhält sich agile Arbeit wahlweise wie Pandoras Büchse oder die Borg - wenn man einmal damit anfängt kommt alles in Bewegung, und plötzlich merkt man, wie Dinge in Wahrheit gar nicht so funktionieren, wie man bisher dachte. Es ist etwas ungerecht, dass ich hier agil den schwarzen Peter unterschiebe - agil macht nur transparent was wirklich geschieht, und wir sehen die komplexe Welt, die ohnehin schon da war.

So sollte agil eigentlich

eingeführt werden …

Deshalb sollten die anwesenden Herrn Gloger und Wolf eigentlich bei jeder Scrub-Einführung erst einmal folgende Frage stellen:

Dies ist deine letzte Chance - danach gibt es kein Zurück. [öffnet seine Hand] Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deinem Bett auf und glaubst an das was du glauben willst. [öffnet die andere Hand] Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe Dich in die tiefsten Tiefen des Kaninchenbaus. [Neo greift nach der roten Kapsel] Bedenke: Alles was ich dir anbiete ist die Wahrheit, nicht mehr. [Neo schluckt die rote Kapsel]Folge mir."

Die Architektur entwickelt sich durch die Arbeit der Kollegen kontinuierlich.

Entscheidungen werden gemeinsam Visualisiert und getroffen.

Der Architekt entscheidet über die Architektur.

Und genau das ist uns passiert. Bisher gingen wir davon aus, dass der Architekt entscheidet, wie die Architektur auszusehen hat. Bei agilen Methoden ergab das keinen Sinn mehr. Architektur war keine Einmalaktion mehr, sonder passierte die ganze Zeit über, und an Stelle des Architekten kam die Querschnittfunktion des Architektur-Gärtnerns, die die ganze Zeit über passiert.

Das Team entscheidet über das Wie. Es gibt Leadership für das WAS (der PO) und

Leadership zur Unterstützung des Wie (der SCrum-Master)

Es gibt einen Vorgesetzten, und der ist weisungsbefugt - er trägt ja auch die

Verantwortung.

Vorher gingen wir davon aus, dass der Vorgesetzte Anweisen kann - schliesslich trägt er auch die Verantwortung für das, was das Team produziert, gegenüber seiner Führungsebene. In der agilen Welt ist das Team verantwortlich für das Vorgehen. Der Vorgesetzten darf nicht mehr Anweisen. Der Scrum-PO darf immerhin noch ansagen, welche Arbeit in welcher Reihenfolge geschieht, der Scrum-Master selbst ist zum besseren Flaschengeist verkommen.

DevOps: das cRossfunktionale Team trägt die vollständige Verantwortung für

Prozessverbesserung und Produkt, über den kompletten Valuestream.

Es gibt einen Vorgesetzten, und der ist weisungsbefugt - er trägt ja auch die

Verantwortung.

DevOps geht an der Stelle sogar noch einen Schritt weiter und dehnt die Verantwortung des Teams auf die Gesamtstrecke - von Produktentwicklung bis zur Businessanalyse im operativen Betrieb - aus.

Wir verteilen die Aufgaben in jedem Sprint im Planning so,

wie es das Team für richtig hält.

Die Aufgaben sind klar in der Stellenbeschreibung dokumentiert.

Sonst bitte den Teamleiter fragen.

Bisher war es so, dass ich mir eine Stelle aussuchte nach den Aufgaben, damit ich das machen konnte was meinen Interessen und Fähigkeiten am meisten entgegen kommt. Statt dessen schaut sich das Team mit mir im Sprint Planning 2 alle 2 Wochen an, wer welche Aufgaben machen sollte. Und wenn meine Backend-Architektur-Fähigkeiten immer Ärger im Frontend erzeugen, dann paire ich mit dem UXler so lange bei seinen Aufgaben, dass es nicht wieder passiert.

Die Rollen im Team werden in Retrospektiven nach Fähigkeit und

Bedarf zugeordnet. Der Scrum-Master wird neuer PO, ein Kollege rückt nach.

Die Position ist fix und ergibt sich aus dem Karrierelevel des Mitarbeiters.

Bisher hatte ich einen klaren Karrierepfad, bei dem ich mich von Stufe zu Stufe bewege, und jede Stufe ist ein Upgrade in Macht, Ansehen und Geld. Ich mache das, was meine Position enthält.In der agilen Welt gibt es nicht immer für alle Positionen die definierten Aufgaben, und das ist auch nicht planbar. Also braucht es t-shaped - oder M-shaped Personen, die mehrere Rollen in Frage kommen. Und je nach Bedarf bedienen sie die Rolle, die das Projekt braucht.

Jeder ist für alles Verantwortlich. Es zählen nur Teamergebnisse. Im

vernetzten gibt es nur selten alleine Schuldige oder alleine erfolgreiche.

Wir haben klare Verantwortlichkeiten. Wenn niemand den Hut aufhat, dann passiert

auch nichts.

Bisher gab es klare Verantwortlichkeiten. Die klare Accountability sorgt dafür, dass die Leute sich verantwortlich fühlen. Ohne diese Verantwortung würde man weder kontrollieren, noch bestrafen und belohnen können. In der agilen Welt schlägt die Verantwortung auf alle durch. Es zählt das Teamergebnis im Produkt. Wenn ich in einer vernetzten Welt nach einem Schuldigen Suche lande ich immer im Blamestorming, und es kann auch jeder konstruieren, warum er er Vater des Erfolges war. So richtig eindeutig ist es in der Praxis aber nicht.

Der Projekterfolg ist eine Gemeinschaftsleistung. Das team ist so

erfolgreich wie seine Kooperation.

Der Teamleiter ist für den Projekterfolg verantwortlich. Er kann Teile dieser

Verantwortung delegieren.

Bislang gingen wir davon aus, dass Verantwortung eine Kaskade war, die von ganz oben kommt und Stufe für Stufe in der Hierarchie nach unten verteilt wird. Im komplexen und vernetzten gibt es diese eindeutige Verantwortung nicht mehr. Ich weiß ja noch nicht mal, für welche Dinge ich am Ende überall Verantwortung gebraucht haben werden. Deshalb wechselt die Verantwortung nicht nur vom Individuum zum Team, sondern auch von der Teilverantwortung zur Gesamtverantwortung.

Viele kennen vermutlich diese Team-Performance-Kurve von Katzenbach und Smith. Wie soll ich denn individuellen Erfolg als Ziel erklären, wenn der kooperative Erfolg viel höher ist. Was ist denn die Individualleistung im High Performing Team?

Im Gegensatz zu meinem Vorgesetzten können meine unmittelbaren Kollegen in

Team und CoPS gut beurteilen, welche Talente und Interessen ich mitbringe.

Der Vorgesetzte ist für die Weiterentwicklung verantwortlich. Gemeinsam mit dem Kollegen

arbeitet er an der Weiterentwicklung.

In der bisherigen Welt hatte der Vorgesetzte - oder die Vorgesetzten - die Macht über meine Weiterentwicklung. Sie haben mich beurteilt, meine Leistungen bewertet und mich dementsprechend weiterentwickelt. In komplexen Umgebungen ist der Effekt von Individualleistung von aussen praktisch nicht mehr zu erkennen. Faktisch ist mein Selbst- und mein Fremdbild oft nicht nah beieinander. Für ein angemessenes Bild ist eine kontinuierliche Diskussion nötig.

Wenn jemand sehr erfolgreich auf einem Thema arbeitet ist er offensichtlich am richtigen Platz. Die Entwicklung folgt diesen Talenten und seinen Interessen.

Wer in einem Karrierelevel sehr erfolgreich arbeitet hat es sich verdient einen Schritt auf

der Karriereleiter nach oben zu gehen.

Bisher waren Karrieren weitgehend lineare Bewegungen nach oben. Wenn ich mich irgendwo bewährt habe, dann habe ich es mir redlich verdient, eine Stufe nach oben zu rutschen, und mit mehr Einfluss und Macht mehr zu bewegen. In komplexen Umgebungen ist die Wirksamkeit einer hierarchisch höhenwertigen Position nicht auch höher. Ganz im Gegenteil: wenn ein Kollege mit einer bestimmten Aufgabe sehr viel Benefit für das Unternehmen erzeugt, sollte man ihn dort genau nicht entfernen. Wenn man selbst - oder jemand im Unternehmen - an anderer Stelle einen höheren Benefit erwartet, dann sollte auch gewechselt werden. Auch um einem Bore-Out vorzubeugen.

Es gibt viele Führungsaufgaben, die immer in Bewegung sind, neu entstehen

und wieder vergehen. Sie sollten jeweils von der passenden Person bedient

werden.

Führung ist eine hierarchische Funktion. Sei hängt an höher bezahlten Positionen, die damit

beauftragt sind.

Bisher gingen wir davon aus, dass Führung eine hierarchische Funktion ist, die von einer Person auf einer hierarchischen Position eingenommen wird. Manchmal, in Matrix-Organisationen, wird diese Aufgabe auch individuell von 2 Personen bedient. Komplexe Welten können nur mit Selbstorganisation effektiv bedient werden, eine Steuerung von aussen ist nicht möglich. Management ist deshalb unwirksam, und Führungsaufgaben sind nur aus dem Inneren des Systems zu erkennen - und dort kann auch erkannt werden, wer diese Aufgabe am besten übernimmt.

Es dauert monate, bis man in eine komplexe Software eingearbeitet ist, und

ein Team auf Performing-Level ist. Der Aufbau von neuen Kompetenzen ist

preiswerter als das Einarbeiten.

Wenn eine Kompetenz im Team fehlt, muss diese für den Zeitraum des Bedarfes

nachgestafft werden.

Bisher ging man davon aus, dass Kollegen mit Kompetenzen wie Legosteine zu einem grossen Ganzen zusammengesteckt werden können. Dass wir spontan einen Frontend-Entwickler oder einen Scrum-Master neu dazunehmen können, wenn der gerade fehlt. Heute wissen wir, dass nicht nur die Einarbeitung in eine komplexe Domäne oder Software Monate dauern kann, auch das Herstellen eines performanten Teams dauert lange. Wenn die Performance da ist sollte man den Teufel tun und sie nicht durch Personenschach zerstören, sondern lieber mit den vorhandenen Kollegen den Knowhowaufbau lokal vornehmen.

Hmpf.

Das klingt sehr aufwändig, ich würde das gerne vermeiden.

Nachdem wir das alles gesehen hatten war unsere erste Reaktion etwa das: Das ist zu aufwändig. Erstens bekomme ich die Kultur des Unternehmens gar nicht so schnell gedreht, dass das gehen würde, zweitens: ist das überhaupt gesichert?

Das ist doch nur modernistische Agilromantik.

So NewWork-Esoterik.

Eine Basisdemokratische Träumerei.

Ich meine, andere Unternehmen machen das ja auch nicht, und verdienen trotzdem viel Geld. Seien wir mal ehrlich: das ist doch nur so modernistische Agilromantik. NewWork-Esoterik, mit der Coaches jetzt die nächste Kuh durch das Dorf treiben. Das ist Basisdemokratisches Gutmenschentum in Unternehmen für die Zeit nach den Asylanten.

Komplexe Systeme verhalten sich auch dann noch komplex,

wenn Sie es nicht möchten.

Die agile Gemeinheit.Und genau da schlägt aber wieder die agile Gemeinheit zu. Komplexe Systeme verhalten sich auch dann wie welche, wenn man es nicht möchte. Und damit haben ich alle die Muster am Hals, die in diesen zu finden sind.

Selbstorganisation Inspect & Adapt

Emergenz Lernende Systeme

Die agile Gemeinheit.Ich habe Erfolgsstrategien für diese Welten - nämlich Selbstorganisation, Inspect & Adapt, Emergenz in Strukturen und Methoden und Antifragilität durch lernende Eigenschaften.

Selbstorganisation Inspect & Adapt

Emergenz Lernende Systeme

Positionen, Strukturen, Rollen, Führung

Eigentlich ist unsere Aufgabe also ganz einfach: Da diese Regeln für komplexe Systeme universell sind, gelten Sie auch für Positionen, Strukturen, Rollen und Führung selbst.

Positionen, Strukturen, Rollen, Führung

Komplexe Systeme verhalten sich auch dann noch komplex,

wenn Sie es nicht möchten.

Ich wiederhole noch einmal: Komplexe Systeme verhalten sich auch dann komplex, wenn Sie es nicht möchten.

AuftragsbearbeitungBuchhaltung

MarketingBusiness Development

Zentrale Dienste

Team

Team

Team

Team

Team

Team

Pfirsichorganisation

Wie jede deutsche agile Firma sind wir auch bei einem Pfirsichmodell von Niels Pfläging gelandet, bei dem weitgehend autonome Teams das Unternehmenszentrum als Service nutzen. Die Teams sind meist stabil.

AuftragsbearbeitungBuchhaltung

MarketingBusiness Development

Zentrale Dienste

Team

Team

Team

Team

TeamPfirsichorganisation

Team

Zentrum Team

Extern

Aufgaben wandern per Markt dorthin, wo sie mittelfristig am günstigsten sind.

Was im Team selbst, was im Zentrum oder was extern gemacht wird ist eine Frage des Marktes- es wird dort gemacht, wo es am günstigsten ist.

Quervernetzung über Communities of Practices

Auch ähnlich zu vielen agilen Unternehmen haben wir eine Quervernetzung über Communities of Practice. Viele kennen Sie heute als Gilden und Chapter, weil das bei uns älter ist als das Spotify-Modell heissen sie noch so, wie sie damals hiessen :-) Beispiel sind die agile COP, die DevOps-Gruppe, die Open-Device-Lab-Gruppe etc.

Rollen statt Positionen

M-Shaped People

Team

Wir sprechen bei uns - ja, liegt auch am Firmennamen - von M-Shaped-Kollegen. Meist hat ein Kollege mehr als eine Kompetenz, der Datenbankmensch ist auch gut in System Engineering, der Product Owner ist auch gut im UX des User Journeys, der Scrum-Master kann auch als Product Owner oder als Coach für ein anderes Team arbeiten.

Rollen statt Positionen

Retrospektiven: - Bedarf dokumentieren - Decision Matrix zu Optionen - intern oder extern? - Konsent

Team

Die Rollenverteilung innerhalb des Teams geschieht über Retrospektiven. Oft haben wir zwei Retrospektivenformate pro Team - einmal die zur Iteration gehörigen normalen Retrospektiven, dazu etwa zweimonatlich Grundsatzretrospektiven, bei denen es um die Betrachtung des Gesamtsystems geht. Da kann bei uns zB ein Kunde vom Team abgewählt werden. Dort werden auch die Rollen bei Bedarf adaptiert.

Rollen statt Positionen

Rollentausch Rollenanpassung Rollenerzeugung

Staffinganforderung

Team

Die Sachen, die dann passieren können ist ein einfacher Rollentausch - wir haben Teams, bei denen der Scrum-Master zum Product Owner wurde, der System-Engineer die Datenbank geerbt hat etc. Die Rolle kann auch neu definiert werden, es können auch neue Rollen geschaffen werden, die es so noch nicht im Team gab. Es entstehen auch Staffing-Anforderungen, wenn das Team es nicht alleine kann. Meist handelt es sich dann um Kollegen, mit denen man schon gearbeitet hat, um den Performing-Level nicht zu zerstören.

Rollen statt Positionen

Wenn es nicht mehr funktioniert

wird es deaktiviert.

Da ist der Wechsel zu Rollen recht nützlich. Wenn die Umgebung sich so ändert, dass die Position die Aufgaben nicht mehr gerecht wird, dann hat man die Gelegenheit das ganze zu korrigieren. Es kann also passieren, dass eine gefühlte Herabsetzung passiert.

Weiterentwicklung und Kompetenzausbildung ist tatsächlich ein schwieriges Thema. Kennt jemand diese Grafik? Die ist schon lange debunked, die Zahlen sind purer Unsinn. Tatsächlich ist Lernen von sehr viel mehr Faktoren abhängig, von Alter, Geschlecht, Umgebung,

Lernverhaltenindividuell unterschiedlich

in informeller Umgebung

selbstgesteuert und involviert

besser mit praktischer Erfahrung

in Verbindung mit vorhandenem Wissen

besser mit positiver Einstellung zum Lernen

Quelle: Training from the Back of the RoomTatsächlich ist das Lernverhalten hochunterschiedlich nach Person, und es gibt nur wenige Dinge, die für praktisch alle gelten. Zum Beispiel lernt man in informeller Umgebung besser, man lernt selbstgesteuert und involviert in das Lernen besser, eine positive Grundeinstellung zum Lernen verbessert auch das Lernresultat. Wenn ich Dinge auch praktisch anwende setzt sich das Wissen besser fest, und auch dann, wenn ich es selbst mit vorhandenem Wissen in Bezug setzen kann. Wenn man sich diese Methoden anschaut? Funktionieren Kurse gut? Oder Konferenzen?

Slack time Communities of Practice

Barcamps (z.B. 7.6-12.6.2016 auf Mallorca)

Bei uns ist der Schwerpunkt damit auf Slacktime gerutscht, oder auch Google Time genannt. Das sind Arbeitszeiten, bei denen die Kollegen ausschliesslich selbst bestimmen, was zu tun ist. Wir stellen noch nicht mal den Anspruch darauf, dass sie mit Projekten oder der Firma zu tun haben. Aber: sie müssen den Kollegen vorgestellt werden. Analog gibt es Barcamps, die einmal im Jahr offsite für die ganze Firma stattfinden und als OpenSpace organisiert sind.

In den Slackdays werden konkrete Projekte gemacht - hier ein paar Fotos davon - aber auch Themengebiete zur Fortbildung. Heute - genau jetzt ist das bei uns der Fall - gibt es zB die Themen Alignment herstellen, Teambewertung und Public Speaking als Thema. Aktuell werden ca 13 Slackdays pro Person genutzt, mit 26 Freitagen pro Jahr, Urlaub, Krankheit etc wären 19 möglich.

Communities of Practice

BiWeekly Video-Conference

ca 4-5 Slackdays pro Jahr

Hospitieren, RotierenDazu kommen unsere Communities of Practice, zum Beispiel mit dem Thema Agile Coaching (war mal Scrum), Product Owner, Dev&Ops (eher System-Engineering in Wahrheit), und das M-Team, das sich um Firmenkultur kümmert. Teilnehmen kann jeder, den das Thema interessiert - vorausgesetzt, dass sein Team die Teilnahme stützt. Dort wird auch besprochen, wer wo wie wann zur Probe Aufgaben übernimmt, hospitiert oder ähnliches.

s

Curiosity Honor Acceptance Mastery Power Freedom Relatedness OrderGoalStatus

Was passiert denn, wenn ich meine

Position verliere?Unsere Erfahrung zeigt: Ja, das schmerzt in der Tat, und man muss damit umgehen. Ein Degradieren der eigenen Position ist etwas, was man dem eigenen sozialen Umfeld praktisch nicht mitteilen kann. Wenn man sich die intrinsischen Motivationen anschaut - ich nutze hier die Champfrogs-Liste von Jurgen Apollo ….

Curiosity Honor Acceptance Mastery Power Freedom Relatedness OrderGoalStatus

… dann wird etwa die Hälfte in Mitleidenschaft gezogen. Die Akzeptanz, die Anerkennung der Leistung, die Macht, der Handlungsspielraum, die Verlässlichkeit wie auch der eigene Status werden beschädigt. Ich glaube, dass es nicht möglich ist den Kollegen das Einkommen in Deutschland zu reduzieren. Das wäre aber, angesichts der schon ohnehin vorhandenen Einbußen, auch fast geschmacklos.

Selbstgewählte Titel

Chief Puppeteer Secret Weapon

Kommunikator DevOps Shepherd

Software Guy Communication Samurai

Open Source Rockstar Mrs Monneypenny

Personalgranate

Das erste was wir gemacht haben - nach vielen Vorbildern - wir haben die Titel durch selbstgewählte Titel ersetzt. Da kommen so Titel wie oben zu sehen heraus. Das ist aber eher die Ausnahme - das Gros der Kollegen nimmt Titel, die passen und die in ihrem sozialen Graphen funktionieren. Die sichtbare Karriere ist dann eine, die der eigenen Entscheidung entspricht.

Rollenbeschreibung a la Holocracy

Rolle: Infrastrukturreparierer Purpose: Buzz über Firma & Produkte erzeugen Domains: - Social-Media Accounts, Mailingliste - Inhalte auf Website & Blog

Typische Aufgaben: - Verhältnis zu potentiellen Kunden aufbauen - Produkte und Firma auf den Kanälen promoten - Speaker & Kontakte vermitteln

Dazu kommen interne Rollenbeschreibungen - die nicht die Position einer Person beschreiben, sondern die aktiv eingenommene Rolle innerhalb des Teams - die auch von einer anderen Person eingenommen werden kann.

Track-Record im Wiki

Im Wiki wird gesammelt:

- Rollen des Kollegen - Kudos von Kollegen - Kundenstatements

Die Dinge, die der Kollege macht werden auch im Wiki dokumentiert - mit Rolle, Kollegenjudos und Kundenstatements. Das macht die Weiterentwicklung und die Fähigkeitsakquisition transparent. Und man kann nachschlagen, wo man welches Knowhow findet, wenn man jemand mal im Rat fragen will.

Peer Review Poker Personality Poker

Moving Motivators

Daneben haben wir eine ganze Reihe von Tools im Einsatz, um Selbstbild und Fremdbild innerhalb des Teams in Gleichklang zu haben. Konkret setzen wir Personality Poker und Moving Motivators ein - wer nutzt das noch? Und wir haben einen Peer Review erarbeitet, bei dem man mit den Kollegen um die eigene Bewertung pokert - auch das ist wieder ein aktiver Abgleich mit dem Fremdbild.

Führungs- rollen

Scrum-Master Scrum-PO

Teamvertreter Unternehmensleitung

Mit diesen Aktivitäten bewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.

Scrum Master

Phase Führungsstil Aufgaben

Forming Autoritär, Coaching Prozess, Training

Storming Autoritär, Coaching Prozess, Konfliktmanagement

Norming Servant, Coaching Teambuilding, Transparenz

Performing Servant, Obsolet Entwicklung, Sparring

Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss.

Product Owner

Phase Führungsstil Aufgaben

Forming Autoritär Konzeption, Produktmanagement

StormingAutoritär,

TransaktionalProduktmanagement,

Constraints

Norming Transaktional, Kooperativ

Mentale Modelle, Purpose

Performing Transformational, Kooperativ

Purpose, mentale Modelle

Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen.

Teamvertreter

Phase Führungsstil Aufgaben

Forming Servant, Stewardship Unternehmensressourcen

Storming Servant, Kooperativ Alignment, Ressourcen

Norming Servant, Kooperativ Alignment, Ressourcen, Repräsentation

Performing Stewardship, Kooperativ

Entwicklung, Sparring

Die ersten drei Rollen werden direkt vom Team bestimmt, die letzte vom Team ausgewählt .Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss. Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen. Der Teamvertreter dient sowohl Stewardship als auch Alignment. Er hat das Team im Unternehmen zu vertreten, den Zugriff auf andere Ressourcen zu stützen und Alignment von Team und Unternehmen zu stützen. Manchmal ist das der Scrum-Master in Personalunion.

Unternehmensleitung

Phase Führungsstil Aufgaben

Forming Stewardship, Kooperativ

Unternehmensressourcen, Alignment

Storming Stewardship, Obsolet Ressourcen, Aligment

Norming Stewardship, Hosting Alignment, Ressourcen, Repräsentation

Performing Stewardship, Servant, Kooperativ

Organisationsentwicklung ermöglichen, Sparring

Die Unternehmensleitung - bei uns leider immer noch in Personalunion mit Gründern und Gesellschaftern - aber ich glaube, dieses Machtkonglomerat gilt für viele agile Firmen - dient vor allem als Service nach Innen. Alignment ist dabei ein Teil des Services, dazu komme ich später.

Choose Your Own Boss

CYOBUnd er hat eine einfache Lösung - Choose Your Own Boss. Gary Hamel sieht das in Zukunft für jede Leadership-Funktion. Google arbeitet heute schon zum Teil so, dort heisst es „distributed Leadership“. Die Lifetime-Position wird also in Zukunft für unsere Branche abgelöst durch eine Rolle, die auch von den Kollegen getragen wird.

Rolle Autorisierung

Scrum-Master Auf Zeit vom Team bestimmt

Scrum-PO Auf Zeit vom Team bestimmt

Teamvertreter Auf Zeit vom Team bestimmt

Geschäftsleitung Anhand des Problems aus N gewählt

CYOBMit diesen Aktivitäten bewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.

CYOB

Selbstorganisation Inspect & Adapt

Emergenz Lernende Systeme

Durch die Anpassungsfähigkeit und den Markt ist Choose your own boss ebenfalls adaptionsfähig. Funktionierende Systeme entstehen dadurch, nicht funktionierende verschwinden wieder.Und man muss in der Führungsrolle plausible Angebote machen, um beauftragt zu werden. Ich habe nächste Woche zB einen Workshop mit den Kollegen aus den Teams, bei denen meine persönlichen Aufgaben von Ihnen per Business Value Poker verteilt werden.

Management As A Service Aufgaben

PflichtenBeistellungsleistungen

Dabei ist nur der individuelle Faktor neu, eine interne API für „Management as a Service“ hatten wir schon im Rahmen einer Firmenretrospektive erzeugt. Dort sind nicht nur die Pflichten, sondern auch die Voraussetzungen dabei. Mit einigen Teams sind die noch mal extra verhandelt.Kein Spass: da steht sogar die angestrebte Lead time drin. Das ist bei einem vollen Terminkalender manchmal nicht so einfach, da wäre mir Cycle Time deutlich lieber. Aber wenn es nicht klappt kann man sich ja noch einen der Kollegen schnappen.

Verantwortung

Verantwortungslose Führung.

„Wie Hosting Leadership, nur ohne Esoterik.“

Einer der Aspekte ist etwas, was ich „verantwortungslose Führung“ nenne. Konkret bedeutet das, dass ich keinerlei Entscheidungen für das Team treffe, auch wenn es lieber zu mir delegieren möchte.

Stakes vom Unternehmen explizit machen

Gewichtung durch das Team

Optionen & Decision Matrix

Verantwortungslose Führung.

Team-Entscheidung

Etwas, was wir häufig einsetzen wenn Stakes ausserhalb des Teams berücksichtig werden müssen: die externen Stakes werden ermittelt und explizit gemacht - gerne numerisch. Das Team bildet dann die Gesamthalt aller zu berücksichtigenden Stakes, gewichtet sie und notiert die Optionen, die aktuell zur Verfügung stehen und trifft eine Entscheidung. Auf die Weise bleiben die Entscheidungen und die Umsetzungsverantwortung beim Team.

Baustellen

Aber natürlich gibt es bei uns noch viele Baustellen, ich greife mal eine heraus.

Align

men

t

Autonomy

„How“

„Was“, „Warum“

Was wir noch überhaupt nicht im Griff haben ist das hier: Diese Grafik kennen vermutlich einige Leute hier. Sie stammt ursprünglich von Moltke, und wurde im Art of Action von Stephen Bungay. Moltke sieht Alignment und Autonomie nicht im Widerspruch, sondern als Faktoren, die parallel erfüllt werden müssen.

Align

men

t

Autonomy

„How“

„Was“, „Warum“

Wirksam

keit

Optimal, so sagt er, ist die Wirksamkeit oben rechts - hohe Autonomie bei hohem Alignment.

Align

men

t

Autonomy

„How“

„Was“, „Warum“

Wirksam

keit

Im Moment sind wir etwa hier - wir haben sehr viel Autonomie, aber da gehört auch viel wirklose Autonomie dazu.

Align

men

t

Autonomy

„How“

„Was“, „Warum“

Wirklose Autonomie:

Lokales Optimum != globales Optimum Opportunismus

GroupThink

Das sind vor allem Dinge, die zwar im Teamkontext optimal sind - aber im Unternehmenskontext schädlich sind. Spotify nannte Anfang der Woche auf der Lean Kanban Central Europe zB das völlig verteilte Ticketing-System bei ihnen als Beispiel. Ein anderes Beispiel ist eine Microservice-Basierte Architektur, bei der gemeinsames Logging fehlt, so dass ein übergreifendes Business Analytics nicht mehr möglich ist. Wir haben bei uns mit 70 Entwicklern 7 unterschiedliche Chatsysteme im Einsatz - versuchen Sie da mal, ChatOps als Teil von DevOps zu nutzen.Aber auch Opportunismus und GroupThink, beides meistens unbewusst, tritt hier auf. Da fehlen uns noch Mechanismen, um das wieder auszubalancieren.

Align

men

t

Autonomy

„How“

„Was“, „Warum“

Wirksam

keit

Hier brauchen wir noch einen Mechanismus zur Reduktion wirkloser Autonomie und Erzeugung von besserem Alignment. Da haben wir uns schon ein bisschen bewegt - über Workshops mit Gerhard Wohland, der die Kopf zB hinter dem Pfirsichmodell ist, Firmenretrospektiven und Futurespectives über die ganze Firma. Im Moment stehen die Inhalte von Scaling @ Lego von Henrik Kniberg hoch im Kurs. Hoffentlich wird uns die Woche auf der Insel im Juni da weiterbringen.

Fazit

Komplexe System brauchen auch adaptive Aufgabenverteilung, Rollen und Führung.

Bottom-Up autorisierte Rollen statt Positionen

Mechanismen für Karriere, Entwicklung und Gehalt

Alignment noch eher unklar :-)

Die Kollegen nennen das „Management as a Service“. Da gibt es eine auf einer Firmenretrospektive definierte API, welche Dinge ein Geschäftsführer als Service bereitstellen soll. Das ganze gibt es auch umgekehrt - als API, die man umgekehrt braucht. Bei mir sieht das zB so aus, dass ich wöchentlich ein Mittagessen mit den Teams habe, bei den grossen Retros dabei bin, einen Tag alle zwei Wochen mit bei ihnen im Team bin und Zugriff auf den internen Chat habe, um die notwendige Basiskompetenz zu haben.

Danke! Fragen: @johannhartmann hartmann@mayflower.de Slides mit Tonspur: http://slideshare.net/johannhartmann

Wer Fragen hat, kann sich gerne an mich wenden. Wer Beratung dazu will -die Kollegen hier fragen, die können so Dinge.

StiefkinderIch hätte sie gerne noch reingenommen …

Jetzt kommen die Slides, die zeitlich gar nicht mehr gingen.

Erfolg

Erfolg

Erfolg

Erfolg

Misserfolg

Peter- Prinzip

Was uns da passiert ist ist natürlich in der Managementliteratur wohldokumentiert. Die Beförderung ging so lange gut, bis der Level erreicht wurde, bei dem es nicht mehr funktioniert.

Erfolg

Erfolg

Erfolg

ErfolgMisserfolg

Peterprinzip Komplex

Bei dynamischen und komplexen Environments wird es noch eins schlimmer. Dort ist es normal, dass die Inkompetenz nicht durch die neue Position, sondern durch den Wandel des aktuellen Verhaltens der Position erzeugt wird.

Verantwortung

„Jemand muss den Hut aufhaben, sonst passiert gar nichts!“

Ein weiteres Thema von Führungspositionen ist die Verteilung von Verantwortung.Wir alle kennen den Spruch „Wenn niemand den Hut aufhat, dann wird auch gar nichts passieren.“

Verantwortung

Architekt Senior Entwickler

Teamleiter Projektmanager

Teamleiter

Deshalb gibt es oft in Firmen wie in Softwareteams klare Verantwortungen - für Design, Weiterentwicklung, den Prozess, den Teamerfolg, den Projekterfolg und die Weiterentwicklung der Kollegen.

Social LoafingMit mehr Leuten weniger leisten!

Warum Personen Ihre Leistung reduzieren, wenn sie in Teams arbeiten.

Bei Teamarbeit gibt es schon eine ganze Weile Forschung zur Performance. Einer der wichtigen Punkte dort ist Social Loafing, also das reduzieren der individuellen Leistung in Teams. Folgende Gründe gibt es dafür: „lost in the crowd“,

Reduktion der eigenen Leistung, wenn …

… die eigene Leistung für entbehrlich gehalten wird.

Social Loafing

Wenn die wichtigen Bereiche der Arbeit an die die Leitungsfunktionen verteilt werden, dann sinkt die Bedeutung der individuellen Leistung im Vergleich ab - „Dispensability of Effort“ passiert, man denkt, die eigene Leistung wäre verzichtbar. Und reduziert die Leistung dementsprechend.

Reduktion der eigenen Leistung, wenn …

… der Zusammenhang zwischen eigener und der Teamleistung unklar ist

Social Loafing

Es gibt auch den Lost in the Crowd-Effekt. Wenn jede Leistung von mir noch mal vom Senior adaptiert wird, wenn ich nur Dinge mache, die mir vom Architekten und haarklein vorgegeben wurden - dann sehe ich nicht, was mein Beitrag zur Teamleistung ist.

Reduktion der eigenen Leistung, wenn …

… die eigenen Aufgaben als simpel betrachtet werden

Social Loafing

Bei komplexen Aufgaben wirkt die Teamarbeit positiv auf die eigene Leistung - bei simplen Aufgaben ist das anders. Wenn also die anspruchsvollen Aufgaben zu den Architekten und den Seniors fallen, dann sinkt meine Leistung.

Reduktion der eigenen Leistung, wenn …

… die Teamleistung selbst nicht anerkannt wird

Social Loafing

Das gilt auch für das grosse Ganze. Wenn die Teamleistung selbst nicht anerkannt wird, weil nur die Führungskräfte damit hausieren gehen - auch dann geht die Motivation verloren die eigene Leistung einzubringen.

Curiosity Honor Acceptance Mastery Power Freedom Relatedness OrderGoalStatus

Opportunistische Karriere

Das ist auch durchaus verständlich - wenn meine Kernmotivatoren Ehre, Akzeptanz, Macht, Freiheit oder Status sind - dann habe ich eine starke Motivation im Rank nach oben zu kommen. Und daneben gibt es natürlich auch noch mehr Geld, sozialen Prestige, Respekt für die neue Position.

Bitte mitzählen:

Wer hat solches Verhalten schon

erlebt?

„Bestimmte Informationen habe nur ich - und ich gebe sie nicht weiter. Das ist ein taktischer Vorteil.“

„Ich streue die Informationen im Unternehmen selektiv so, dass die Kollegen machen was ich für richtig halte.“

„Ich limitiere die zur Verfügung stehenden Optionen künstlich, um eine Entscheidung in meinem Sinne zu erleichtern.“

„Ich schalte mich als Zwischenschritt beim Zugriff auf wichtige Ressourcen ein, obwohl ich keinen relevanten Beitrag habe.“

„Bestimmte Kommunikationskanäle müssen über mich laufen, damit ich Kritik und Whisteblowing an meiner Person frühzeitig erkennen kann. Dann kann ich mich direkt selbst darum kümmern.“

„Wenn ich sehe, dass Konkurrenz zu mir entsteht, versuche ich mich frühzeitig einzumischen.“

Wer hat solches Verhalten schon erlebt?

Wer davon arbeitet ineinem grossen Unternehmen?

Hand aufs Herz:

Wer hat sich schon so verhalten?

Autorisierte Rollen verhindern (zu einem guten Teil) opportunistisches

Führungsverhalten.