Liquide Rollen statt fixer Positionen - Warum klassische Positionen –inklusive Führungspositionen – Schaden anrichten - Wie eine liquide Rollenverteilung in der Praxis aussieht - Welche Vorrausetzungen braucht es, wie organisiert man Führung und Karriere

1. Das Ende
der Karriere.

2. „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.

3. „Die Mitarbeiter wollen
das doch gar nicht.“
Eine der Anmerkungen war, dass die Kollegen das gar nicht wollen.

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

5. „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.

6. 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.

7. Tatsächliche Historie I
2005 Das Management führt Scrum ein (!)
2006 Standort Würzburg schafft Scrum wieder ab.
2007
20% aller Kollegen werden Scrum-Master.
Alle Geschäftsführer & Teamleads.
2008 Agile Fluency Level 1 und Cargo Cult
2010
XP-Practices: TDD, Pair Programming, CI/CD, Sustainable
Pace etc, DevOps Community of Practice
2011 Scrum-Master != Teamleads (finally), Scrum by Heart
2012
Servant 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.

8. Tatsächliche Historie II
2012 Das Team Allstars verzichtet auf feste Positionen.
2012 Viel Diskussion im Confluence
2012
Einzelne Teams geben Teamleiter zugunsten von
Teamvertreter auf
2012
Unterschriftensammlung 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.

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

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. Was wir lernen mussten …
Dann versuche ich mal zu erklären, wie sich das ganze ergeben hat.

17. 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.

18. 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?

19. +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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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:

31. 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."

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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.

39. 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?

40. 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.

41. 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.

42. 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.

43. 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.

44. 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?

45. 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.

46. 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.

47. 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.

48. 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.

49. 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.

50. Auftragsbearbeitung
Buchhaltung
Marketing
Business 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.

51. Auftragsbearbeitung
Buchhaltung
Marketing
Business Development
Zentrale Dienste
Team
Team
Team
Team
Team
Pfirsichorganisation
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.

52. 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.

53. 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.

54. 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.

55. 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.

56. 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.

57. 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,

58. Lernverhalten
individuell 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 Room
Tatsä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?

59. 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.

60. 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.

61. Communities
of Practice
BiWeekly Video-Conference
ca 4-5 Slackdays pro Jahr
Hospitieren, Rotieren
Dazu 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.

62. s
Curiosity
Honor
Acceptance
Mastery
Power
Freedom
Relatedness
Order
Goal
Status
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 ….

63. Curiosity
Honor
Acceptance
Mastery
Power
Freedom
Relatedness
Order
Goal
Status
… 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.

64. Selbstgewählte
TitelChief 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.

65. 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.

66. 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.

67. 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.

68. 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.

69. 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.

70. Product Owner
Phase Führungsstil Aufgaben
Forming Autoritär
Konzeption,
Produktmanagement
Storming
Autoritär,
Transaktional
Produktmanagement,
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.

71. 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.

72. 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.

73. Choose Your
Own Boss
CYOB
Und 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.

74. 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
CYOB
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.

75. 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.

76. Management
As
A
Service Aufgaben
Pflichten
Beistellungsleistungen
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.

77. 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.

78. 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.

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

80. Alignment
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.

81. Alignment
Autonomy
„How“
„Was“,
„Warum“
Wirksam
keit
Optimal, so sagt er, ist die Wirksamkeit oben rechts - hohe Autonomie bei hohem Alignment.

82. Alignment
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.

83. Alignment
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.

84. Alignment
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.

85. 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.

86. 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.

87. Stiefkinder
Ich hätte sie gerne noch reingenommen …
Jetzt kommen die Slides, die zeitlich gar nicht mehr gingen.

88. 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.

89. 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.

90. 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.“

91. 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.

92. Social Loafing
Mit 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“,

93. 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.

94. 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.

95. 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.

96. 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.

97. Curiosity
Honor
Acceptance
Mastery
Power
Freedom
Relatedness
Order
Goal
Status
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.

98. Bitte mitzählen:
Wer hat solches
Verhalten schon
erlebt?

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

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

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

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

103. „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.“

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

105. Wer hat solches Verhalten
schon erlebt?

106. Wer davon arbeitet in
einem grossen Unternehmen?

107. Hand aufs Herz:
Wer hat sich schon so verhalten?

108. Autorisierte Rollen verhindern
(zu einem guten Teil)
opportunistisches
Führungsverhalten.