Vom Entwickler zur Führungskraft

100
Vom Entwickler zur Führungskraft Hallo! Und willkommen! Erste Frage: ist es ok, wenn ich Euch Duze? Ist es auch ok wenn ich ehrlich bin? Ok. Wer von Euch ist Führungskraft? Wer ist Teamleiter, Projektleiter oder ähnliches? Wer ist agile Führungskraft? Wer ist Product Owner? Wer ist Scrum- Master? Wer ist Entwickler?

description

Wer als Entwickler Führungskraft werden möchte - oder noch schlimmer - von anderen zu erklärt wird, hat einen langen und schmerzhaften Weg vor sich. Und die Erfolgsquote, das belegen die eigenen Vorgesetzten jeden Tag, ist nicht hoch. Viele gute Pläne und logische Schlussfolgerungen funktionieren in der Praxis nicht mehr, und die kollegiale Unterstützung wird durch Politik ersetzt. Die schönsten instinktiven Fehler, die besten Katastrophen nach Lehrbuch und Methode werden von jemanden vorgestellt, der sie schon alle gemacht hat.

Transcript of Vom Entwickler zur Führungskraft

Page 1: Vom Entwickler zur Führungskraft

Vom Entwickler zur Führungskraft

Hallo! Und willkommen! Erste Frage: ist es ok, wenn ich Euch Duze? Ist es auch ok wenn ich ehrlich bin? Ok. Wer von Euch ist Führungskraft? Wer ist Teamleiter, Projektleiter oder ähnliches? Wer ist agile Führungskraft? Wer ist Product Owner? Wer ist Scrum-Master? Wer ist Entwickler?

Page 2: Vom Entwickler zur Führungskraft

Johann-Peter Hartmann

Kein Vortrag über Komplexität und dynamische Märkte und das passende Management.

Ich bin Johann-Peter Hartmann. Eine kleine Präambel: das ist kein Vortrag über Komplexität und das Management derselben - auch wenn ich das gerne gemacht hätte. Das ist auch eines meiner grossen Themen, dazu stehe ich auch gerne dazu zur Verfügung. Dieser Talk ist mehr über die Grundlagen von Management, wenn man ihm als Entwickler über den Weg kommt.

Page 3: Vom Entwickler zur Führungskraft

Hacker

Wenn ich mich irgendwo vorstelle bezeichne ich mich immer als Hacker. Ich habe sogar einen zweiten Satz Visitenkarten auf denen „Hacker“ steht.

Page 4: Vom Entwickler zur Führungskraft

Hacker

Das stimmt natürlich in Wahrheit nicht. Ich bin kein Hacker. Ich werde nicht polizeilich verfolgt, und auch die NSA hat mir noch kein attraktives Angebot gemacht.

Page 5: Vom Entwickler zur Führungskraft

Developer Administrator Securitynerd

Jeweils so mittelsuper.

Etwas ehrlicher wäre eine Mischung aus Entwickler, Administrator und Securitynerd. Wenn ich noch ehrlicher bin, dann bin ich in jedem Bereich so mittelsuper, und es wird jeweils weniger.

Page 6: Vom Entwickler zur Führungskraft

Klugscheisser

Und wenn man meine Kollegen kollektiv mit Rohypnol und Wahrheitsserum der Wahl behandeln würde käme vermutlich diese Berufsbezeichnung heraus.

Page 7: Vom Entwickler zur Führungskraft

Geschäftsführer

Auf meiner richtigen Visitenkarte steht aber seltsamerweise etwas anderes, unpassendes. Nämlich Geschäftsführer. Nun werden einige von Euch sagen „Wieso, das ist doch das gleiche wie Klugscheisser. Oder noch schlimmer.“. Ja, sehe ich ähnlich :-).

Page 8: Vom Entwickler zur Führungskraft

C.T.O.Chief Tailwind Officer

„Rückenwind“

Deshalb stelle ich mich meist selbst als CTO vor, damit ich nicht so inkompetent wirke. Lang schreibe ich das immer als „Chief Tailwind Officer“, also dem Verantwortlichen für Rückenwind. Im Verlauf dieses Talks wird auch herauskommen, warum ich das für besser halte.

Page 9: Vom Entwickler zur Führungskraft

Warum macht der CTO, wenn der nur Entwicklung kann?

Das stellt sich natürlich die Frage: warum macht der das, wenn der das gar nicht kann? Warum will der das überhaupt?

Page 10: Vom Entwickler zur Führungskraft

Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status

Jurgen Appelo hat eine gut zu merkende Liste der Motivatoren gemacht, die uns antreiben. Jeder von uns hat sie in unterschiedlicher Ausprägung und Wichtigkeit. Curiosity treibt die Entdecker und Innovatoren an, Honor diejenigen, die nach Ihren Werten leben, Acceptance ist die Anerkennung durch andere, Mastery das Können, und natürlich spielen persönliche Macht und Freiheit eine grosse Rolle. Relatedness ist die Motivation etwas gemeinsam zu machen, Order das Verlässliche, Goal ist die Sinnhaftigkeit, Status der Rang, den ich erreicht habe.

Page 11: Vom Entwickler zur Führungskraft

Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status

Bei mir standen zu dem Zeitpunkt vor allem Neugier, Könnerschaft, Macht und Sinnhaftigkeit im Vordergrund. Ich wollte gerne neue Dinge gestalten, wirksam sein und das auf aktuellen und guten Technologien. Deshalb heisst die Firma auch Mayflower, wie das Schiff, das die ersten Siedler auf den neuentdeckten Kontinent brachte.

Page 12: Vom Entwickler zur Führungskraft

Developer Administrator Securitynerd

GeschäftsführerAlso wurde ich Geschäftsführer. Das Problem war bloß, dass ich eigentlich ganz andere Dinge gelernt habe - nämlich Developer, Administrator und Securitynerd. Da war zwar BWL als Vertiefungsfach in der Informatik, aber mal ganz ehrlich, helfen tut das nicht.

Page 13: Vom Entwickler zur Führungskraft

Wie geht eigentlich …

Führungskraft?Und dann stellt sich natürlich die Frage: wie geht eigentlich Führungskraft?

Page 14: Vom Entwickler zur Führungskraft

Hier sehen wir den Klassiker von Führungskräften. Ich war vorher einer von den Minions, jetzt darf ich selbst bestimmen. Abgebildet wird das ganze in einem Organigramm. Wer hat ein Organigramm in der Firma?

Page 15: Vom Entwickler zur Führungskraft

Denken

Handeln

Und natürlich haben wir auch mit dieser Grundidee angefangen: man trennt das Denken vom tun, um besser skalierten zu können. In der Industrialisierung machte das sehr viel Sinn: ich reduziere die Aufgabenkomplexität der Minions auf ein Minimum, und wenn ich jemanden habe der weiß wie es geht kann ich beliebige Mengen von Minions darunter hängen, die jeweils nur einfache Aufgaben machen. Und ich treffe alle Entscheidungen selbst, weil ich der Experte bin und die Verantwortung trage.

Page 16: Vom Entwickler zur Führungskraft

•Micromanagement •Klare Ansagen •Kontrolle ist notwendig •Strafen bei Nichterfüllung

Hierarchisch Authoritär

Diese naive Aufgabenteilung ist autoritär und hierarchisch. Ich habe die Verantwortung, also sage ich Dir, was Du genau zu tun hast. Im Detail. Und ich kontrolliere fortwährend, ob Du wirklich das machst womit ich Dich beauftragt habe. Wenn Du es nicht gemacht hast, bestrafe ich Dich gemäß Hierarchie. Wie man sieht: die Idee kommt vom Militär, bei dem man das Grundproblem des Skalierens über Idioten schon seit Jahrtausenden hat.

Page 17: Vom Entwickler zur Führungskraft

Leider ist in unserer Welt nicht alles Militär. Und deshalb klappt diese Methode auch nicht so richtig gut in unserer Praxis. Und genau sie ist für das hervorragende Image, das Management bei uns genießt, verantwortlich.

Page 18: Vom Entwickler zur Führungskraft

•Smarte Ziele setzen •Methoden etablieren •Belohnen •Effizienz steigern •Bonus

!

Transaktional

Deshalb haben die Management-Denker eine bessere Variante gefunden, die den Minion als etwas weniger dement ansieht : Transaktionales Management. Hier setzt der Chef Ziele, und am Ende der Ziele steht eine Belohnung, keine Strafe - die ist dann die Abwesenheit der Belohnung. Peter Druckers Management by Objectives ist eine Form von transaktionalem Management. Er definiert die Prozesse, und er sieht es als seine Aufgabe, durch Aufträge und Belohnung die Effizienz zu steigern. Das haben wir tatsächlich auch gemacht.

Page 19: Vom Entwickler zur Führungskraft

Hierarchisch Authoritär

Meine Startposition

So schlau war ich aber 2000 nicht. Also mal der Default der Dummen: Hierarchisch autoritär. Im Nachhinein waren die meisten der Minions zu der Zeit gleich kompetent oder kompetenter, das mit der Trennung Wissen zu Tun klappte also nur so mittel.

Page 20: Vom Entwickler zur Führungskraft

Wie lange hätte ich gebraucht?

Optimism Bias

Denken

Und es war tatsächlich streng autoritär: Es gibt eine Aufgabe für mein Team, und ich soll sagen, wie lange das dauert. Also beginne ich zu denken, und Frage mich: wie lange hätte ich als Developer gebraucht? Und normalerweise verschätze ich mich, weil ich die potentielle Risiken unterschätze. Das heißt Optimism Bias. Und das konnten die Kollegen nicht liefern. Genauso wie ich es selbst vorher nicht liefern konnte. Siehe http://en.wikipedia.org/wiki/Optimism_bias

Page 21: Vom Entwickler zur Führungskraft

Denken

Viel kürzer!

Illusory SuperiorityUnd weil die Jungs das nicht in der von mir geschätzten Zeit geschafft haben komme ich zu dem Schluss, dass es offensichtlich Ihre Schuld ist. Ich hätte es geschafft, sie nicht. Deshalb bin ich ja auch Chef, und sie nicht. Weil ich es ohnehin etwas besser beurteilen kann. Siehe http://en.wikipedia.org/wiki/Illusory_superiority

Page 22: Vom Entwickler zur Führungskraft

Denken

„Lake Wobegon“ Effekt:

80% halten sich für überdurchschnittlich.

Jetzt könnte man sagen, dass liegt ja nur an mir. Faktisch liegt es uns aber im Blut. 80% aller Leute halten sich für überdurchschnittlich, und die Tatsache, dass man Führungskraft ist, macht es nicht einfacher. Siehe: http://en.wikipedia.org/wiki/Lake_Wobegon#The_Lake_Wobegon_effect

Page 23: Vom Entwickler zur Führungskraft

„I love deadlines. I like the whooshing sound they make as they fly by“

Douglas Adams

Oops.

Was ist also passiert? Wir haben die Deadlines, auf die ich mich committed habe, nicht halten können. Das konnte man schon vorher gut sehen. Und was macht man als Developer, wenn man sieht, dass das eigene Team die Deadline nicht hält?

Page 24: Vom Entwickler zur Führungskraft

Hero-Culture

40 Stunden/Woche 60 Stunden/Woche 80 Stunden/Woche 120 Stunden/Woche

Genau, ich fange an selbst zu entwickeln. Dann kann ich den Kollegen beweisen dass es geht, und meine Wichtigkeit als Chef wird noch deutlicher, weil ich ja das Projekt rette. Ohne mich geht gar nichts. Damit kann ich auch meinem eigenen Chef zeigen, wie unverzichtbar ich bin. Und überhaupt, faktisch gibt es gar keinen Weg ohne mich, diese Deadline zu halten. Siehe: http://c2.com/cgi/wiki?HeroCulture

Page 25: Vom Entwickler zur Führungskraft

Dispensability of Effort

Wenn ich verzichtbar bin brauche ich auch nichts zu leisten.

Motivation- -Wenn einer da ist, der die Verantwortung übernimmt, dann hat der Rest der Gruppe das Gefühl weniger zum Gruppenerfolg beizutragen. Das heißt, dass der individuelle Beitrag als vernachlässigbar betrachtet wird. Und wenn ich in Wahrheit gar nicht gebraucht werde sinkt nicht nur die Motivation, sondern auch die Gesamtleistung des Teams. Siehe http://en.wikipedia.org/wiki/Social_loafing#Dispensability_of_effort

Page 26: Vom Entwickler zur Führungskraft

Mein doppelter Arbeitseinsatz resultiert in weniger Output?

?Und das Resultat ist eine Sauerei: ich setze zwar deutlich mehr Zeit ein, aber am Ende wird noch weniger geschafft als es ohne meine Verdopplung der Arbeitszeit der Fall gewesen wäre. Ich wollte die Deadline retten, habe aber eigentlich kontraproduktiv gewirkt, und die Deadline in Summe noch weiter nach hinten geschoben.

Page 27: Vom Entwickler zur Führungskraft

Attribution Bias

Deine Aktion = generelles Verhalten Meine Aktion = Situationsbedingt

„Die anderen sind einfach nicht so engagiert wie ich!“

Da bin ich also in der Situation: ich selbst arbeite mehr, die Kollegen arbeiten weniger und sind schlecht motiviert. Da kommt gleich der nächste kognitive Bias ins Spiel: ich interpretiere meine eigenen Handlungen als streng logisch und situativ, die meiner Kollegen allerdings als verhaltensgetrieben. Siehe: http://en.wikipedia.org/wiki/Attribution_bias

Page 28: Vom Entwickler zur Führungskraft

Fazit: Ich bin intrinsisch motiviert, die anderen aber nicht.

Extrinsic Incentives Bias

Und im Schluss kam ich zu dem Fazit, dass die anderen Kollegen im Gegensatz zu mir nicht intrinsisch motiviert sind und das Projekt voranbringen wollen. Sie arbeiten so viel wie sie von mir beauftragt und kontrolliert werden, gerade an der Grenze zur Kündigung. Siehe: http://en.wikipedia.org/wiki/Extrinsic_incentives_bias

Page 29: Vom Entwickler zur Führungskraft

Theory X: Der Mensch ist unwillig. Anweisungen und Kontrolle

Theory Y: Der Mensch ist engagiert. Eigenverantwortung und Freiraum

Das ist Douglas McGregor, einer der Vorreiter was die Wirkung von Leuten in Unternehmen betrifft. Und er hat zwei Menschenbilder entwickelt. Das eine ist Theory X - der Mensch arbeitet nur dann, wenn ich ihn antreibe, und ohne Gehalt und Kontrolle würde er gar nichts tun. Das ist das, was ich gerade in meinen Kollegen wahrnehme. Und Theory Y - der Mensch ist aus sich heraus motiviert und arbeitet sinngetrieben, und ich muss ihm nur den Freiraum geben, damit er eigenverantwortlich arbeiten kann. So sehe ich mich selbst.

Page 30: Vom Entwickler zur Führungskraft

Theory X: Der Mensch ist unwillig. Anweisungen und Kontrolle

Theory X ist richtig.

Fazit: ich komme als Führungskraft zu dem Schluss, dass Theory X vermutlich für mein Umfeld stimmt. Und ich beginne detailliertere Anweisungen zu geben, will Reports haben, mache Micromanagement. Ich plane mehr und dokumentiere den Idioten gegenüber alles im Detail, damit sie gar nicht auf die Idee kommen, etwas anderes zu machen. Und ich kontrolliere, ob alles wie geplant geliefert wird. Weil ich nicht sehe, wie es sonst funktionieren kann.

Page 31: Vom Entwickler zur Führungskraft

•Micromanagement •Klare Ansagen •Kontrolle ist notwendig •Strafen bei Nichterfüllung

Hierarchisch Authoritär

Ich habe also herausgefunden: Offensichtlich ist hierarchisch und autoritär wie beim Militär doch die richtige Lösung.

Page 32: Vom Entwickler zur Führungskraft

Das ist ein Problem.

Und das ist ein Problem. Speziell bei Software. Software ist nämlich in einer besonderen Situation, sie findet meist in einer komplexen Welt statt.

Page 33: Vom Entwickler zur Führungskraft

Bitte A machen!Dann kommt B raus!

Die Grundannahme von transaktionalem Management ist, dass der Boss weiß, wie eine Lösung aussehen soll. Also sagt er dem Kollegen: Mach A, damit B rauskommt. Und das A ist dem Boss genauso bekannt wie das B, das erreicht werden soll.

Page 34: Vom Entwickler zur Führungskraft

einfach schwierig

Un

klar

Kla

r

An

ford

eru

ng

Lösung

Landscape Stacey Diagram

Das Problem bei IT-Projekten ist aber, dass weder die Anforderung noch die Lösung vollständig planbar sind. Ich habe eine schwierige Anforderung, und ich habe eine schwierige Lösung. Und das macht es komplex.

Page 35: Vom Entwickler zur Führungskraft

einfach schwierig

Un

klar

Kla

r

An

ford

eru

ng

Lösung

Anforderung

Lösung

Landscape Stacey Diagram

Beide bedingen sich gegenseitig. Wenn ich meine Lösung wähle hat das eine Folge auf meine viele andere Anforderungen, die damit gut oder eben auch nicht gut machbar sind. Der Einsatz einer Library hat einen Effekt auf viele Requirements. Und es hat eine Folge auf andere Lösungen, die zB entweder kompatibel oder nicht kompatibel sind.

Page 36: Vom Entwickler zur Führungskraft

Bitte A? machen!Dann kommt B? raus!

Anforderung

Lösung

Und im Fazit? Es ist weder die Lösung noch die Anforderung vollständig klar. Ich kann also einen Auftrag bei Software also gar nicht so erteilen, dass er die richtige Lösung für die richtige Anforderung herauskommt - außer ich plane selbst alles im Detail vor, in einer Tiefe, dass auch ein Idiot es umsetzen könnte. Dann bin ich aber wieder im detailgeplanten Micromanagement, und es spart keine Zeit, dass da noch ein Minion ist, der es dann runterprogrammiert.

Page 37: Vom Entwickler zur Führungskraft

Fazit: Die Performance wird nicht besser

Da arbeite ich also wie eine Sau, bin nur von Idioten umgeben und kann denen noch nicht mal einfach erklären, was sie eigentlich tun sollen? Was für eine Grütze ist das denn?

Page 38: Vom Entwickler zur Führungskraft

39% in Time, Scope &

Budget

Jetzt könnte man sagen, dass sei eher die Ausnahme, aber es geht unserer Branche offensichtlich insgesamt so: Der Standish Group Chaos Report 2013 berichtet: bei weniger als der Hälfte aller Projekte sind wir in der Lage, sie in Zeit und Budget zu liefern. Sprich: der größere Teil unserer Branche liefert nicht das versprochene.

Page 39: Vom Entwickler zur Führungskraft

Tribal LeadershipLevel 1: ALL life sucks

people are despairingly hostile, banding together to get ahead in a violent and unfair world

Kennt jemand das Buch Tribal Leadership von Dave Logan, John King, and Halee Fischer? Ich mag die Stages aus Tribal Leadership, um zu beschreiben wie sich Projekte, Teams und Organisationen anfühlen. Der erste Stage ist ALL Life sucks. Und das ist manchmal sogar der bessere Fall, denn wenigstens leide ich nicht alleine, sondern die Kollegen mit mir.

Page 40: Vom Entwickler zur Führungskraft

Tribal LeadershipLevel 2: MY life sucks

people are passively antagonistic, seen it all before and watched it fail, quietly sarcastic and resigned, judging, yet never interested enough to spark any passion

Der nächste Level ist my life sucks - die Stimmung im Team ist sarkastisch, die Leute verurteilen schnell und zynisch, kommen aber nicht mit eigenen Impulsen. Das kenne ich selbst tatsächlich wirklich gut, das habe ich im Lauf meiner Karriere schon mehrfach gemacht. Wer kennt diesen Modus? In einem Projekt hing bei uns über Wochen ein Strick von der Decke, weil es einfach zur Stimmung passte. Kein Spass, ich habe Fotos davon, und den Strick gibt es immer noch, nur nicht mehr im Teamraum.

Page 41: Vom Entwickler zur Führungskraft

Tribal LeadershipLevel 3: I am great (and you are not)knowledge is power, so people hoard it; they have to win, and winning is personal. the mood is one of wanting help and support, yet being continually disappointed that „others don’t have their ambition or skill“

Level 3 ist der Klassiker, also zumindest meiner. Und das typische Resultat des Theory-X-Managements. Man will zwar gewinnen, aber persönlich. Meine Leistung steht über der Teamleistung. Ich bin enttäuscht von Ehrgeiz und Fähigkeiten der anderen. Wer kennt so einen Modus? Laut Buch ist das der verbreiteste Modus mit ca 45%. Das Gefühl und das Anstreben der Überlegenheit kann übrigens für mehrere/alle Personen im Team gelten. Der Punkt ist: das Team und die Teamleistung spielt keine Rolle, meine eigene Leistung zählt. Wer wie Management by Objectives individuelle Ziele setzt incentiviert dieses Verhalten sogar.

Page 42: Vom Entwickler zur Führungskraft

P?Performance schlecht,

Verlässlichkeit schlecht Team unzufrieden

Was macht man, wenn man in so einem Modus ist? Statistisch macht der Mainstream der Firmen das, was wir damals auch gemacht haben. Und deshalb haben wir damals, 2005 auch geschaut, wo eine Lösung dafür herkommen kann.

Page 43: Vom Entwickler zur Führungskraft

Agil!

Und eine der üblichen Lösungen ist Agilität. Wer arbeitet hier mit Scrum? Genau, wir auch, bis heute. Ab und zu mal ein bisschen Kanban, wenn es in Maintenance kippt, aber meistens Scrum.

Page 44: Vom Entwickler zur Führungskraft

Scrum erweckt den Eindruck, es hätte nur ein paar einfache Regeln, ein paar einfache Rollen, und man könnte es schnell implementieren. Alles passt auf einen Bierdeckel. Und morgen sind wir dann so weit. Das haben wir, 2005, auch geglaubt. (Die Leute von it-agile sind übrigens erwiesenermassen super, man darf sich von Ihren Bierdeckeln nicht täuschen lassen. Ich empfehle sie bedingungslos weiter, man kann mit denen nur gewinnen, die sind korrekt gepolt.)

Page 45: Vom Entwickler zur Führungskraft

Scrum Level 1

Wolf in Sheeps Clothes

„Transaktionale Führung“

Und weil es so einfach ist, haben wir ein Whitepaper zur Einführung gemacht. Und wir haben gefragt, wer Scrummaster werden will. Und alle Projekt- und Teamleiter meldeten sich. Also haben wir sie zertifizieren lassen. Und waren beeindruckt: hey, eine Projektmanagementmethode, die man in 2 Tagen lernt! Keine Jahre von Erfahrungen erforderlich! Von dieser Effizienz können sich die anderen Methoden mal was abschneiden! Fazit: unsere Teamleiter waren jetzt auch Scrummaster. Und inWahrheit Command & Control Manager, die vorgeben, jetzt zusätzlich Scrum-Master zu sein. Und sie waren es auch, es stand auf dem Zertifikat der Scrum Alliance, es muss also wahr sein.

Page 46: Vom Entwickler zur Führungskraft

Scrum Level 1• verteilt die Tasks • koordiniert Meetings • steuert die Kollegen • gibt Anweisungen

Und was machten sie? Alles, was sie vorher auch getan haben. Das Daily morgens wird zum Reporting genutzt. Gerne auch schriftlich protokolliert. Er moderiert die Meetings und verteilt auch die Aufgaben direkt an die Personen. Wenn die Schätzungen der Kollegen über seinen Erwartungen liegen fragt er noch mal nach, ob man das wirklich so meint, oder es nicht tatsächlich doch schneller ginge, wenn man Faktor X berücksichtigt. Er kontrolliert die Schätzungen über ein Excel. Er hat eine Statistik, wieviele Storypoints jeder Entwickler im Mittel schafft, und nimmt ihn beiseite, wenn er unterdurchschnittlich performt.

Page 47: Vom Entwickler zur Führungskraft

Scrum Level 1• Excel

• „Schätzungen sind schlecht“ • Storypoints/Stunden • Storypoints/Kollege • Konkurrenz

Der Wolf im Schafspelz hat ein Excel und ist bereit es einzusetzen. Er prüft die Güte der Schätzungen und eskaliert zum Team, weil sie nicht stimmen. Er ermittelt die Storypoints pro Stunde, und ermittelt die Zielvelocity des Teams inklusive Urlaubstage, damit das Team weiß, auf was es sich committet. Er misst die Leistung der Kollegen und nimmt sich die Underperformer in ein persönliches Gespräch. In einem Fall, glücklicherweise bei einem Partnerunternehmen, wurden sogar Vergleichsteams gebildet, um die Performance vergleichen zu können.

Page 48: Vom Entwickler zur Führungskraft

Scrum Level 1

Im Team fühlt sich das ganze so an als würde nur wieder eine neue Kuh durchs Dorf getrieben, die jetzt eben mal Scrum heißt. Man sieht nicht, dass das für einen Sinn ergibt und unterstützt es auch nur so mittel. Faktisch ist es das alte, transaktionale Management unter dem Deckmantel von Agil. Es fühlt sich schon besser an, weil mehr Releases und damit mehr Transparenz kommt, aber Pair Programming ist weiterhin verboten, und Agilität ist fake.

Page 49: Vom Entwickler zur Führungskraft

Scrum Level 2

Scrum Scribe

Irgendwann haben wir dann auch herausgefunden, dass Scrum und agil so nicht funktioniert . Dass es nicht reicht, nur die Titel und die Namen der Meetings zu ändern, bei gleichbleibendem Verhalten. Also wurde bei uns jemand anderes als der Projekt/Team-Leiter Scrum-Master. Also nicht mehr der Teamleiter, sondern ein Developer. Und häufig wurde bei uns genau der Entwickler „nebenher“ Scrum-master, der am besten in der Entwicklung „verzichtbar“ war.

Page 50: Vom Entwickler zur Führungskraft

Scrum Level 2

Scrum Scribe

• läd zu Meetings ein • besorgt Obst & Kekse • pflegt die Artefakte • ist freundlich • vom Team ignoriert

Und dieser Scrum-master unterscheidet sich vor allem durch die Macht, die er gegenüber dem Wolf im Schafspelz nicht mehr hat. Weil er aus dem Team kommt, und den Auftrag Scrum-Master von seinem Vorgesetzten bekommen hat, macht er das, was er kann. Also organisiert er die Meetings, sagt zum Standup Bescheid, besorgt Haribo und Obst, führt Gespräche, läd zum gemeinsamen Biergartenbesuch ein. Das Teambuilding im Hochseilgarten wird organisiert, Ratings und Fortbildungen laufen über ihn. Er erzeugt „Shallow Benefits“, die zwar irgendwie nett sind, aber nicht die Kernprobleme angehen.

Page 51: Vom Entwickler zur Führungskraft

Scrum Level 2

Scrum Scribe

Showstopper, die keine Showstopper sind

Bei uns konnte man das daran erkennen, dass nur Showstopper ans Tageslicht kamen, die faktisch keine waren. Es gibt keine funktionierenden Releases, Leute kündigen und gleichzeitig wird über mehr Ram für den CI-Server und ein zweites Flipchart diskutiert. Das Projekt ging den Berg runter, der Kunde war sauer, und gleichzeitig ging man zusammen ins Kino.

Page 52: Vom Entwickler zur Führungskraft

Scrum Level 3

Facilitator

„Servant Leader“

Irgendwann haben wir dann auch mitbekommen, dass das nicht zielführend ist. Und wir sind in den nächsten Level gegangen. Das war der Facilitator. Der wusste immerhin, wozu die Meetings eigentlich da sind. Er hat nicht nur das Zertifikat zum Scrum-Master, sondern er hat es grob verstanden. Der Facilitator ist als Führungsstil immerhin ein Servant Leader, aber mit der Betonung auf Servant. Leadership war da bei uns erst mal wenig.

Page 53: Vom Entwickler zur Führungskraft

Scrum Level 3• Meetings erfüllen ihren Zweck • Team entscheidet • relevante Showstopper • managed Konflikte

Facilitator

Aber: Mit dem Facilitator haben wir dann endlich das geliefert, was Scrum wirklich versprochen hat. Die Teams haben selbst Verantwortung übernommen und sich wirklich selbst organisiert. Die Showstopper waren tatsächlich das, was das Team blockiert hat. Das Team hält zusammen und kooperiert. Bei wem ist das so? Aber: es läuft alles, aber das Team stagniert. Es läuft gut, die Kollegen sind zufrieden, aber inspiriert und begeistert ist niemand.

Page 54: Vom Entwickler zur Führungskraft

Scrum Level 4

Coach

„Servant Leader“ Transformationale Führung

Der nächste Level bei uns war der Coach. Der ist endlich da, wo es wirklich Spass zu machen beginnt. Bei ihm liegt der Servant Leader zwar immer noch mit dem Schwerpunkt auf Servant, aber er kümmert sich schon darum, dass sich das Team weiterentwickelt. Das ist bei uns erst ab 2012 so wirklich passiert, also 7 Jahre nach der Einführung von Scrum. Das geht vermutlich schneller, bei uns aber nicht. Das besondere an diesen Leuten: die machen das aus Berufung, nicht aus Beauftragung. Die Kollegen betteln förmlich darum, als Scrum-master zu arbeiten, weil sie den Sinn sehen, verstehen und es für das richtige halten. Und als Unternehmen sollte man dankbar dafür sein, so eine Chance zu bekommen.

Page 55: Vom Entwickler zur Führungskraft

Scrum Level 4• Das Team entwickelt

sich weiter • Das Team trägt den Prozess • Performance steigt

Coach

In diesem Kontext wird es dann auch tatsächlich so langsam richtig gut. Als Führungskraft macht das viel Spass. Man steht nicht mehr im Mittelpunkt, sondern das Team spielt. Man kümmert sich nur noch darum, wie sich das Team weiterentwickeln kann.

Page 56: Vom Entwickler zur Führungskraft

„Das Team nicht vor Problemen schützen, sondern an Problemen wachsen lassen.“

Scrum Level 4

Coach

Und das ist eine deutliche Differenz zum klassischen Scrum-Master - seine Aufgabe ist nicht mehr der Schutz des Teams, sondern das Wachsen lassen. Da haben wir auch wirklich lange gebraucht, das zu begreifen. Der Scrum-Master muss das Team nicht schützen. Das haben wir vorher gedacht. Er muss das Team dann schützen, wenn es das Problem nicht selbst lösen kann. Sonst müssen Probleme auf das Team durchschlagen, damit es wachsen kann. Er muss nur sicherstellen, dass das Wachsen passieren kann.

Page 57: Vom Entwickler zur Führungskraft

Tribal LeadershipLevel 4: We are great

people are fully themselves & everyone seems happy, inspired & genuine. the culture emphasizes on shared core values and interdependent strategy. a „we are a great tribe“ always has an adversary & the bigger the foe, the more powerful the tribe.

Wenn man Glück hat kommt man in dem Modus auf Tribal Leadership Level 4. Das Team macht seinen Job, man kann liefern, der Scrum-Prozess funktioniert. Aber: Man definiert sich durch die Überlegenheit zu einer anderen Partei. Der Kunde, das andere Team, der Konkurrent - es gibt immer eine Partei, die als Gegner, der keineswegs great ist, wahrgenommen wird.

Page 58: Vom Entwickler zur Führungskraft

Scrum Level 5

Servant Leader

„Servant Leader“ Transformationale Führung

Danach kommt der Level 5. Da gibt es nicht nur Servant im Fokus, sondern auch Leadership. Und das macht er Transformational.

Page 59: Vom Entwickler zur Führungskraft

Everybody wants Change – but nobody likes to Be Changed

Scrum Level 5

Servant Leader

Henrik Kniberg

KernproblemTransformationale Führung richtet sich an den intrinsischen Anteil der Motivation. Und wenn die Leute selbstbestimmt und selbstorganisiert arbeiten wollen habe ich ein Problem. Ich kann nicht mehr einfach anweisen, sondern ich muss erreichen, dass die Kollegen es selbst wollen. Und das ist doof und absolut nicht einfach. Henrik Kniberg formuliert das Problem so: jeder möchte Änderung, aber niemand will geändert werden will.

Page 60: Vom Entwickler zur Führungskraft

Wie beauftrage ich intrinsisch?

Scrum Level 5

KernproblemUnd damit haben wir heute tatsächlich schwer zu kämpfen - wie beauftrage ich jemanden intrinsisch? Die Antwort ist natürlich leicht: gar nicht. Er muss es selbst wollen. Und meine Aufgabe als Führungskraft ist zu machen, dass er es selbst will. Und das ist eine ziemlich harte Aufgabe, die einen erst mal ratlos lässt.

Page 61: Vom Entwickler zur Führungskraft

Scrum Level 5

Transaktionale Ratlosigkeit

Die Leute brauchen eine andere Einstellung!

Die Kollegen müssen sich mehr am Kunden orientieren!

Da fehlt einfach die Disziplin!

Bei uns ist das tatsächlich bis heute ein Kernproblem. Wir sind nur transnationales Management gewohnt, und auf einmal werden uns die Lösungen weggenommen, und wir bleiben ratlos zurück. Man erkennt das an Kommentaren wie „Warum ändert sich die Kultur nicht, die blockiert doch nur?“, „Die Leute brauchen eine andere Einstellung.“, „Die Kollegen müssen sich mehr am Kunden orientieren.“. Und ich weiß zwar, dass ich das als Führungskraft umsetzen muss, aber per Kommando funktioniert das nicht. Wie denn sonst, bitteschön? Wir, und ich, sind davon ziemlich überfordert.

Page 62: Vom Entwickler zur Führungskraft

Transformationale Führung

• Inspiriert, wird bewundert • ist ein Vorbild, stiftet Sinn • fördert eigenständiges Denken • Individuum im Fokus

Servant Leader

Die Lösung dafür verspricht transformationale Führung. Dort sieht Leadership so aus: die Führungskraft inspiriert und wird bewundert. Sie ist ein Vorbild und stiftet Sinn für die Leute.

Page 63: Vom Entwickler zur Führungskraft

Transformationale Führung

• Ändert die Kollegen nicht. • Zeigt den Vorteil hinter der Änderung • Schafft die Umgebung zum Wandel • Der Wandel passiert von alleine

Der Hack dahinter

Warum funktioniert das? Weil man die Kollegen nicht ändern kann, probiert man es gar nicht. Sondern man zeigt - durch das eigene Handeln und die Vorbildfunktion - warum es für den Kollegen auch attraktiv sein kann, sich zu ändern. Indem man sie begeistert, und ihnen den Raum gibt, das richtige zu tun. Dann, so die Theorie, passiert der Wandel von alleine. Nicht weil man es angesprochen oder beauftragt hat, sondern, weil es attraktiv und einfach ist, sich zu ändern..

Page 64: Vom Entwickler zur Führungskraft

Transformationale Führung

• Effektive Kommunikation (Fairness)

• Unternehmerische Haltung (Innovation)

• Umsetzungsstärke (Ergebnisorientierung)

Wie sieht eine Umgebung aus, in der ich als Führungskraft transformational wirken kann? - Kommunikation: Transparenz, Offenheit, Aufrichtigkeit, Eindeutigkeit und Respekt - Handeln: Vorbildfunktion, wirtschaftlichen Umgang, Gesamtbewusstsein inkl. Kosten und Mitarbeiterzufriedenheit, Veränderungs- und

Verbesserungsinitiativen fördern und machen - sinnvolle Ziele verfolgen, Fokus und Umsetzungsstärke bei den eigenen Zielen zeigen und bei den Kollegen fördern.

Page 65: Vom Entwickler zur Führungskraft

Empirie

• bessere wirtschaftlichen Erfolge • mehr Leistungsbereitschaft • bessere persönlichen Beziehungen • geringere Fluktuationsraten • einer größeren Mitarbeiterzufriedenheit • mehr Kreativität • höhere Rate der Umsetzung von Zielen

Robbins, 2011

Jetzt kann man natürlich sagen: das ist schön und gut, in der Praxis funktioniert das nicht. Faktisch gibt praktisch jede Statistik das Gegenteil wieder. Quelle: Robbins, S., Fundamentals of Management, 7th ed., Pearson Inc.: New Jersey, 2011, S. 331

Page 66: Vom Entwickler zur Führungskraft

Tribal LeadershipLevel 5: Life is great

the language revolves around infinite potential and how the group is going to make history - not beat a competitor, but because doing so will make a global impact. this group is in competition with what’s possible, not with another tribe.

Wenn man Glück hat kommt man in dem Modus auf Tribal Leadership Level 4. Das Team macht seinen Job, man kann liefern, Scrum funktioniert. Hier entstehen die High Performance Teams, die ein vielfaches mehr als der Branchenschnitt liefern können. Ich persönlich glaube fest daran, und habe solche Teams schon gesehen.

Page 67: Vom Entwickler zur Führungskraft

Also einfach nur Scrum machen, und dann kommt das?

Also brauche ich einfach nur Scrum einzuführen und alles wird gut? Nein, da gibt es ein Problem. Das erste ist: das mit dem Lernen geht nicht so schnell. Wir haben selbst bislang 9 Jahre gebraucht und sind nicht angekommen. Wer hier in der Runde macht offiziell Scrum? Bei wem ist das passiert, mit der transformationalen Führung durch den Servant Leader? Genau, man ist noch nicht im Ziel. Warum ist das so?

Page 68: Vom Entwickler zur Führungskraft

Ist meine Firma kompatibel?

Und da sind wir genau beim ersten Problem: Man kann nicht einfach das so machen.

Page 69: Vom Entwickler zur Führungskraft

Die Organisationskultur

„Organisationskultur ist die Sammlung von Traditionen, Werten, Regeln, Glaubenssätzen und Haltungen, die einen durchgehenden Kontext für alles bilden, was wir in dieser Organisation tun und denken.“

Der Haken an Scrum ist: es findet in Unternehmen statt. Und die gibt es schon. Und da gibt es schon Lösungen für alles. Konkret gibt es eine Organisationskultur. Definition siehe oben.

Page 70: Vom Entwickler zur Führungskraft

William E. Schneider hat in seinem Buch „Turn the Ship around“ eine einfache Klassifizierung von Firmenkultur gemacht, in seinem Core Culture Questionnaire. Das ist ein Fragebogen - gerne mal selbst machen, haben wir bei uns auch, in dem anhand von der Entscheidungskultur in der Vergangenheit ermittelt wird, wie die Kultur tickt.

Page 71: Vom Entwickler zur Führungskraft

Und das gemeine ist: transformationale Führung findet vor allem in den beiden Quadranten auf der linken Seite statt, transnationale Führung vor allem auf der rechten Seite. Wenn man die Umfrage macht und es eine Kultur ergibt, die vor allem auf der rechten Seite stattfindet, dann kann man sich praktisch auf viele Probleme und wenig Wirksamkeit bei jeglicher Bemühung in Richtung Scrum einstellen - denn dann werden die Entscheidungen von jemanden getroffen, der das Problem nicht vollständig versteht und der es dann auch nicht auslöffeln muss.

Page 72: Vom Entwickler zur Führungskraft

Wenn das Offizielle nicht funktioniert … !

!

… übernimmt das Inoffizielle.

Aber es läuft doch alles …

Jetzt könnte man sagen: naja, wenn das alles so schlecht wäre, dann würde ja gar nichts funktionieren. Aber es funktioniert doch alles. Und da passiert eine Gemeinheit: Die Kollegen sorgen schon von sich aus dafür, dass etwas funktioniert.

Page 73: Vom Entwickler zur Führungskraft

„Politik-Steuern“

Aber es läuft doch alles …

Das Resultat von dieser Unterscheidung zwischen dem offiziellen und dem wirklichen ist Politik. Wer ist in einem Konzern oder arbeitet für einen Konzern? Wer hat schon mal in einem anderen Budget oder Auftrag etwas untergemogelt, was zwar sinnvoll war, aber nicht offiziell zu bekommen war? Genau. Nur weil es funktioniert heisst es noch nicht, dass es auch wirklich gut funktioniert. Gerhard Wohland nennt das die Hinterbühne, die dann übernimmt, wenn die Vorderbühne versagt.Wen stört das, eigentlich? Genau - sie macht unsere Arbeit nicht schneller, und erschwert uns sogar das richtige zu tun. Olaf Lewitz, auch so eine agile coole Sau, nennt das Political Tax. Umwege, die keinen Sinn ergeben, die aber vom offiziellen gefordert werden.

Page 74: Vom Entwickler zur Führungskraft

Bin ich kompatibel?

Und die nächste Frage ist - bin ich denn kompatibel dazu? Kann ich das überhaupt liefern? Tauge ich zum Inspirator, oder ist das einfach nur eine viel zu grosse Nummer?

Page 75: Vom Entwickler zur Führungskraft

Transformationale Führung

• Inspiriert, wird bewundert • ist ein Vorbild, stiftet Sinn • fördert eigenständiges Denken • Individuum im Fokus

Servant Leader

Hier noch einmal das, was man leisten soll. Diese Type, die da oben beschrieben wird - sie ist offensichtlich sowas wie Steve Jobs und Mahatma Gandhi in einer Person. Was muss ich hier als Führungskraft tatsächlich machen? Genau, ich arbeite vor allem mit Leuten, bin Vorbild und will nicht selbst bestimmen.

Page 76: Vom Entwickler zur Führungskraft

Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status

• Inspiriert, wird bewundert • ist ein Vorbild, stiftet Sinn • fördert eigenständiges Denken • Individuum im Fokus

Ich erinnere noch mal an meine Motivatoren, ein Vorgesetzter zu werden: Neugier, Meisterschaft, Macht und Zielorientierung? Faktisch ist nur Goal noch nützlich, der Rest stört eher. Als transaktionaler klassischer Manager wäre ich total richtig, wenn da mehr Order wäre, aber als transformationaler? Wohl eher nicht.

Page 77: Vom Entwickler zur Führungskraft

Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status

• Inspiriert, wird bewundert • ist ein Vorbild, stiftet Sinn • fördert eigenständiges Denken • Individuum im Fokus

Das wären die 4 Motivatoren, die mir deutlich weitergeholfen hätten. Aber mir fällt es bis heute nicht leicht mich für Leute mehr zu interessieren als für wirklich geile Technik oder Methoden.

Page 78: Vom Entwickler zur Führungskraft

Meine Motive zur Führung disqualifizieren mich.

Und das ist eigentlich völlig gemein - die Motive zur Führungsrolle disqualifizieren mich in der Ausführung. Genau das, was mich motiviert braucht niemand bei einer transformationalen Führungskraft. Mir ist das definitiv passiert, und vermutlich gilt das auch für andere. Gemein, aber wahr.

Page 79: Vom Entwickler zur Führungskraft

Introversion Sensing Thinking Judgment

• Inspiriert, wird bewundert • ist ein Vorbild, stiftet Sinn • fördert eigenständiges Denken • Individuum im Fokus

!

!

Glücklicherweise bin ich nicht alleine unqualifiziert. Kennt jemand den Myers-Briggs Typindikator? Das ist eine einfache Klassifizierung von Persönlichkeitstypen, die zwar so nicht stimmt, aber trotzdem Hervorragend zum Denken taugt. Bei uns Softwareentwicklern ist vor allem der Typ ISTJ verbreitet. ISTJ Inspektoren nehmen alles ganz genau und absolut wörtlich: sie sind zurückhaltend, sachlich, logisch und pflichtbewusst. Sie vertrauen ganz auf ihre praktischen Erfahrungen und ihr Wissen. Sicherheit, Struktur und Routine sind essentiell für sie. Für die Aufgaben einer Transformationalen Führung bräuchte man aber genau die Orientierung an den anderen (Extroversion an der Stelle), und das Wahrnehmen der Interessen der anderen (Feeling statt Thinking).

Page 80: Vom Entwickler zur Führungskraft

Und nu?

Ok, da sind wir also - wir wissen zwar, wo wir hinwollen, aber irgendwie stehen wir uns nicht nur selbst im Weg, auch das Unternehmen möchte gar nicht die richtige Form von Führung haben. Soll ich jetzt die Art von Führung machen, die mein Unternehmen vorsieht? Obwohl sie vermutlich in schlechte Resultaten mündet?

Page 81: Vom Entwickler zur Führungskraft

Tools für gute Führung

Wenn ich Glück habe, kann ich ohne größere Widerstände ein paar Tools für gute Führung nutzen. Wenn ich wirklich viel Glück habe kann ich es in meinem Unternehmen unterbringen, ohne das das doofe, transaktionale Management dagegen ist, sondern sogar dafür.

Page 82: Vom Entwickler zur Führungskraft

Radical Management

Steve Denning

Ein guter Ansatz ist bei Stephen Denning zu finden - in seinem Buch Radical Management. Das kann man Management verkaufen, er schreibt auch fürs Forbes Magazine. Er geht zwar ein bisschen größer ran und bezieht sich gleich auf Unternehmen, aber trotzdem sind die Ansätze hochplausibel und gut. Und man kann es - manchmal - auch dem oberen Management gut verkaufen.

Page 83: Vom Entwickler zur Führungskraft

Management 3.0

Jurgen Apello

Martie: Ein einfaches und trotzdem gutes Tooling ist Management 3.0 von Jurgen Apello. dahinter steht ein Buch (Management 3.0), noch ein Buch (How to change the world), Kurse mit Zertifizierungen und ein ganzer Stapel an guten Tools. Die wir auch einsetzen. Management 3.0 kann in seinen Tools auch dann eingesetzt werden, wenn der Rest der Firma das nicht macht.

Page 84: Vom Entwickler zur Führungskraft

Core Protocols

Jim & Michele McCarthy

http://www.mccarthyshow.com/

Ebenfalls ein gutes Tooling für eine gute Zusammenarbeit in einem Team. Wenn man sich nach Ihnen richtet laufen viele Dinge - und nicht nur Entscheidungen - quasi von alleine in eine gute Richtung. Transformationale Führung passiert in Folge, als Outcome dieser Methoden.

Page 85: Vom Entwickler zur Führungskraft

Ich mogel mir und meiner Firma einfach gute Führung unter.

Wenn meine Firma solche Dinge nicht unterstützt muss ich es eben selbst machen. Auf der Hinterbühne, im Inoffiziellen. Nicht schön, aber besser als das falsche oder gar nichts.

Page 86: Vom Entwickler zur Führungskraft

Teamentscheidungen

… sind _nicht_ demokratisch!

KonsensKonsent

DeciderDot-Voting

Decision MatrixAgile

Modeling

Ein guter Ansatz für gute Führung ist die Entscheidungen von mir selbst wegzunehmen, und sie in das Team zu heben. Einfach ist Konsens, Konsent oder Dot-Voting. Aber auch andere Formen wie Decider aus den Core Protocols oder das Agile Modeling für Architekturentscheidungen helfen. Allen Methoden ist gemeinsam, dass sie versuchen alle relevanten Aspekte von allen Personen mit dazu zu nehmen.

Page 87: Vom Entwickler zur Führungskraft

Vertrauen aufbauen

Personal History Exercise

Temenos

Sich verwundbar machen Gewaltfreie

Kommunikation

Feedback Matrix

Kritik lieben lernen

Um als gute Führungskraft tatsächlich wirksam zu sein brauch die das Vertrauen der Leute. Ohne Vertrauen bin ich nicht in der Lage Leadership zu liefern. Glücklicherweise gibt es Tools, die einem dabei helfen.

Page 88: Vom Entwickler zur Führungskraft

Kommunikation fördern

Relevante Meetings

(ROTI)

_gute_ 1:1, minimal monatlich

Gemeinsames mentales Modell

schaffen

Accidental Meetings

Rituale

CoPs

Damit ich als Führungskraft wirksam sein kann muss ich mein Hauptwerkzeug nutzen - Kommunikation. Und da sollte man natürlich kein schlechtes Werkzeug einsetzen, sondern ein möglichst gutes. Und dazu brauche ich regelmässige, gute und relevante Kommunikation. Zu den 1:1 komme ich gleich noch.

Page 89: Vom Entwickler zur Führungskraft

Meine Learnings

Was jetzt kommt ist alles andere als brillant, aber mir hat es zumindest geholfen. Und, wie oben dokumentiert ist mein Gehirn nicht zur Führungskraft geboren, sondern muss mit Waffengewalt dazu gezwungen werden.

Page 90: Vom Entwickler zur Führungskraft

Zuhören>Reden

http://randsinrepose.com/archives/the-update-the-vent-and-the-disaster/

Unter dieser URL verbirgt sich eine Anleitung für 1:1. Und zwar eine kriminalistische. Sie fokussiert auf Zuhören, und ihr Job ist es, der kleinsten Stimme Gehört zu verschaffen. Also Führungskraft habe ich im Default die Klappe zu halten und zuzuhören.

Page 91: Vom Entwickler zur Führungskraft

Reverse Happiness Metric

Womit habe ich heute einen Kollegen happy gemacht?

Wer weiss, was eine Happiness Metric ist? Das kommt aus dem agilen, und man dokumentiert kontinuierlich wie glücklich man ist- allgemein, mit der Firma, dem Projekt , was gerade super ist und was nicht, und wie man es verbessern könnte. Reverse heisst, dass ich es umgekehrt mache. Ich frage nicht wie happy ich bin, sondern was ich getan habe, damit die Kollegen happy sind. Das sind Dinge wie gutes Feedback, aktive Lösung von Problemen ohne vorher drüber gesprochen zu haben und ähnliches. Das faszinierende: im Gegenzug bekommt man Einfluss. Die Kollegen kommen und fragen einem um Rat, und wollen Feedback.

Page 92: Vom Entwickler zur Führungskraft

Sehr, sehr gut

Ich bin sehr gut. Wenn ich Kritik an mir

gut umsetzen kann werde ich sehr, sehr gut.

Auch wenn das gerade ein bisschen albern klingt, mir hilft es. Die Anforderung des Transformationalem Leaderships - Vorbild, bewundert werden und inspirieren - ist für uns Normalsterblichen fast nicht leistbar. Auf gar keinen Fall aus dem Stand. Also müssen wir normalen Leute uns dem nähern. Und wie mache ich das? Mit Kritik. Ich selbst helfe mir immer so: ich bin sehr sehr gut. Dann kommt jemand und kritisiert mich. Und wenn ich die Kritik richtig verstehe und sie gut umsetzen kann, dann bin ich noch eins besser. Also sehr, sehr gut.

Page 93: Vom Entwickler zur Führungskraft

Ich bin nicht OK.Du bist nicht OK.

Kommunikation ist sinnlos.Konfliktverhalten: vermeiden

Ich bin nicht OK.Du bist OK.

Kommunikation aus dem Kind-IchKonfliktverhalten: nachgeben

Ich bin OK.Du bist nicht OK.

Kommunikation an Kind-Ich gerichtet.Konfliktverhalten: Durchsetzen

Ich bin OK.Du bist OK.

Parallele Transaktion ErwachsenKonfliktverhalten: Kompromiss,

Lösungsgetrieben

Home

Dieses Diagramm kommt aus der Transaktionsanalyse. Es reduziert die Kommunikation auf 4 Ebenen. Die erste Situation ist eine Situation, in der sowohl mein Ansprechpartner als auch ich denken, wir wären gerade nicht ok, sprich: uns geht es schlecht. Der zweite, blaue Quadrant ist eine Situation in der ich mich in der Opferrolle sehe - ungerecht behandelt, man hört mir nicht zu, die Leute machen einfach nicht das richtige, obwohl ich es ihnen drei mal gesagt habe und es sowieso offensichtlich ist. Jemand soll machen, dass es mir wieder besser geht, das Kind-Ich. Der gelbe Quadrant ist eine Situation, in der ich als Führungskraft wie ein Erwachsener zu einem Kind kommuniziere: ich erkläre wie es läuft, wie es zu interpretieren ist und was zu tun ist. Der grüne Quadrant ist die Erwachsen-Erwachsen-Situation: man redet über ein Problem, beide Einschätzungen integriert und eine gemeinsame Lösung die beide Seiten bedient, gefunden. Produktiv arbeiten kann man nur in dem Quadraten ohne Opfer und ohne Erklärer, also im ich-bin-ok & du-bist-ok-Quadranten.

Page 94: Vom Entwickler zur Führungskraft

Dein Team ist das beste Team

das Du hast.Und nicht nur auf der bilateralen Ebene gilt das. Man kommt für transformationale Führung praktisch nicht um eine positive Grundeinstellung nicht drumherum. Wer begeistern will, muss auch selbst begeistert sein können. Und es hilft nichts, dass man mit der Vermutung nur mit Pflachpfeifen zu tun zu haben eventuell recht hat. Nur mit einer positiven Grundhaltung kann man die Situation verbessern.

Page 95: Vom Entwickler zur Führungskraft

!Boss

Gute Führung braucht weder Titel noch Position

Und das letzte Tool zum Self-Adjustment: Wenn ich gezwungen bin über meinen Titel oder über meine Position zu arbeiten habe ich schon verloren. Jemand der sagt, dass er der Boss ist weil er der Boss ist geniesst keine Bewunderung, ist kein Vorbild und inspiriert nicht. Die einzige Chance ist sich so zu verhalten, dass es auch ohne Titel und Position passieren kann.

Page 96: Vom Entwickler zur Führungskraft

Zukunft

No Managers (Holacracy, Zappos, Valve)

Choose Your Own Boss (Gary Hamel)

Generation Y

Einige Firmen sind schon weiter, was das No Boss angeht - sie arbeiten ohne. Ein bekanntes Beispiel ist Zappos, in dem es keine fixen Hierarchien gibt, sondern gewählte Stellvertreter. Die dann eine Führungsrolle übernehmen, aber eben nur auf Zeit. Valve geht noch eins weiter und hat gar keine fixen Führungsstrukturen. Gary Hamel, seines Zeichens ebenfalls Autor vieler Management-Bücher, spricht von „Choose your own boss“, ich suche mir selbst aus, für den ich arbeiten will. Das gibt es bei uns auch, und wir haben auch Teams, die sich selbst den Stellvertreter für die Managementrunde ausgesucht haben - und sich entschieden haben, den alle 2 Monate rotieren zu lassen. Und nicht zuletzt haben wir die Generation Y die kommenden Jahre vorm HR-Visier, die Generation der Jahre 80 bis 90. Und bei denen, so sagt man, steht der obere Teil der Bedürfnispyramide im Vordergrund. Und deshalb fordert die nicht nur nach interessanten Aufgaben, sondern nach Weiterentwicklung und vor allem nach guter Leadership.

Page 97: Vom Entwickler zur Führungskraft

Jetzt komme ich langsam zum Schluss - diese beiden relativ frischen Bücher würde ich auch gerne empfehlen. Lars beschäftigt sich mit den Problemen, wo klassisches - sprich meist transaktionales - Management versagt, mit schönen Beispielen. Niels Pfläging, der eigentlich Controller ist, hat in seinem Buch Organisation für Komplexität endlich eine Form gefunden, die gut lesbar ist und Spass macht.

Page 98: Vom Entwickler zur Führungskraft

Hey, mich interessiert das…

Auf einen http://intrinsify.me/ Wevent kommen

Einen Stoos Satellite besuchenhttp://www.stoosnetwork.org/satellites/

Wen das Thema interessiert: mehr gute Informationen kann man bei Stoos oder Intrinsify bekommen. Die Intrinsify WEvents sind ein echtes Happening, ich kann nur empfehlen, dort einmal vorbei zu schauen. Das ist für uns Führungskräfte Lernen auf Steroiden.

Page 99: Vom Entwickler zur Führungskraft

Also gar keine autoritären Anweisungen mehr?

Doch, klar. Aber nur für die Übergangszeit. Und mit weniger Performance als möglich.

Deshalb gar keine Anweisungen? Nein, transformationales Management ist das Ziel, es ist nicht einfach aus dem Stand da. Und für die Übergangszeit muss ich transaktional arbeiten. Aber eben nur so, dass es mich nicht in der Bewegung stört, und nur als Zwischenmethoden.

Page 100: Vom Entwickler zur Führungskraft

Danke!

Slides mit Volltext: http://slideshare.net/johannhartmann/

Gute Fragen: @johannhartmann

Andere Fragen: [email protected]