#1 - Flight Levels mit Klaus Leopold

Shownotes

Klaus Leopold ist Informatiker, Berater und Autor des wunderbaren Buches "Agilität neu denken". Wir sprechen über das Flight Level Modell und wie echte Business Agilität gelingt.

Weiterführende Links:

Unser Gast:

Transkript anzeigen

Klaus: Ja, ich glaube, wenn wir in einer Organisation eine Sache versuchen einzuführen, dann wäre es, Fokus aufzubauen.

Andreas: Klaus Leopold ist Informatiker, Berater und Autor des wunderbaren Buches "Agilität neu denken". Im Podcast sprechen wir über das Flight Level Modell und wie echte Business Agilität gelingt.

Andreas: Klaus, Herzlich willkommen.

Klaus: Hallo. Danke für die Einladung.

Andreas: Sehr gerne. Zum Einstieg, kannst du uns das Flight Level Modell kurz erklären?

Klaus: Das Flight Level Modell kurz erklären? Es geht im Wesentlichen darum, dass wir unternehmensweit Agilität verbreiten wollen. Und das funktioniert halt nicht, wenn wir isoliert denken. Wir müssen eben auf drei verschiedenen Ebenen denken. Und das sind genau die Flight Levels. Flight Level ist ein Begriff aus der Luftfahrt und beschreibt, wie hoch wir fliegen. Und wir können in Unternehmen auch verschieden hoch fliegen. Wir können sehr bodennahe unterwegs sein. Dann sind wir auf Flight eins unterwegs. Das heißt, wir sehen, wie die Teams arbeiten, die operative Ebene. Häufig ist es so, dass ein Team alleine nicht 100 % von einem Kunden Wert generieren kann. Ja, deswegen müssen wir ein bisschen höher fliegen. Das wäre dann Flight Level zwei, die koordinative Ebene, wo wir sicherstellen, dass das richtige Team zur richtigen Zeit an der richtigen Sache arbeitet. Wir koordinieren quasi Teams. Und ja, hin und wieder hat es auch sehr viel Schönes, wenn wir uns überlegen, wohin fliegen wir überhaupt? Und das ist dann Flight Level drei, die strategische Ebene. Wo geht die Reise überhaupt hin? Und die Pointe vom Flight Modell ist, dass eben quasi diese drei Ebenen miteinander das Miteinander tun müssen, wenn wir eine gesamte Organisation fit für den Markt machen wollen.

Andreas: Mich haben Flight Levels direkt an einen Professor von mir, der hat auch immer Flughöhen gesagt. Von daher hatte ich direkt positive Assoziationen. Mit ihm sind wir immer im Helikopter. Er hat das aber eher so als "wir sind auf der strategischen Ebene, operativen Ebene" ...genau. Aber wie bist du auf diese Analogie, auf diese Metapher gekommen? Was war da, also, was waren deine praktischen Erfahrungen und Beobachtungen, dass du dieses Modell entwickelt hast?

Klaus: Also das ist durch Zufall entstanden und am Anfang hatte es überhaupt nur zwei Ebenen, und zwar die Geschichte war so: Also, ich war als Berater unterwegs und war halt viel in der Kanban Welt verwurzelt und da war eine Organisation und da ging es um über 340 Teams, irgendwas in der Größenordnung und die Leute haben gesagt, wir wollen agil werden. Diese 340 Teams, die müssen wir jetzt bitte agil machen. Die haben gedacht okay, das ist cool. Welche Farbe sollte der Porsche haben? Weil es ist doch ein fetter Auftrag. Und dann dachte ich mir "Naja, vielleicht ist es schön, dass ich dann einen funkelnden Porsche habe. Aber der Organisation mache ich mal überhaupt nichts Gutes damit." Und ich hab dann irgendwie versucht, diese Message rüberzubringen, dass ich gesagt habe okay, diese 340 Teams, die liefern nicht direkt an den Kunden. Wir müssen aber das quasi, was an den Kunden geht, das müssen wir in den Fokus stellen. Das heißt, wir müssen etwas höher fliegen. Und da ist das erste Mal quasi so die Analogie zu einer Flughöhe aufgekommen. Also wir können uns die Teams anschauen, wie die tun, und das ist super, wenn die gut tun. Aber sobald sich Teams koordinieren müssen, damit sie an den Kunden liefern, brauchen wir eine andere Abstraktionshöhe. Und da ist quasi diese Idee der Ebenen geboren worden. Wir müssen höher fliegen, ja.

Andreas: Also ich mag diese Metapher also nicht nur wegen der Flughöhen ungemein, sondern was ich daran mag, dass dann im Flight Modell, dass Du jemandem, der jetzt noch nicht so in dieser ganzen agilen Methoden Welt drin ist oder auch vielleicht Methoden verseucht ist, dass Du mit Menschen und mit Gruppen einfach mal darüber sprechen kannst "Was bedeuten denn agile... Was ist eigentlich eine agile Organisation und worauf kommt es denn genau an?" Und das mal unabhängig von einer Methode und diesem ganzen Rattenschwanz an Wording, was dahinter hängt. Ich mag das auch zum Beispiel sehr gerne, um OKR nochmal zu erklären und den Leuten zu sagen "Worum geht es hier eigentlich? Was ist eigentlich der Kern dieses Vorgehensmodells?" Aber was glaubst du denn, was beobachtest du? Auf welchen dieser Flight Levels haben Organisationen denn die größten Probleme?

Klaus: Ist natürlich unterschiedlich, aber ... man sieht schon ein Muster, sagen wir mal so. Also, was ich relativ häufig sehe, dass auf der operativen Ebene sehr viel getan wird. Wir machen Scrum, wir machen Kanban. Dann wird eine Methode nach der anderen irgendwie durch die Organisation durch getrieben und die tun auch, das passt. Was ich auch sehe, dass häufig auf der strategischen Ebene eine Idee ist, was zu tun ist, keine Ahnung. Mckinsey BCG war da, hat 300 Seiten Folien hinterlassen. Also das ist unsere Strategie und ja, wird auch irgendwie verstanden. Aber das sind dann irgendwie so zwei Türme, ja. Die einen glauben halt zu wissen, was in den nächsten fünf Jahren zu tun ist. Die anderen glauben zu wissen, wie man gut arbeitet, aber das sind teilweise zwei Parallelwelten. Und deswegen ist diese Einflugschneise von Flight Level zwei schon recht sexy, weil da geht es ja im Wesentlichen darum, dass wir Teams koordinieren, aber eben auch an die Strategie anknüpfen. Und in vielen Organisationen ist das schon so, der der Missing Link quasi. Aber natürlich nicht überall. Jede Organisation ist in einer anderen Situation. Aber ja, wenn man wettet und man wettet auf Flight Level zwei, macht man nicht viel falsch.

Andreas: Ja deckt sich zumindest mit meinen Erfahrungen. Beziehungsweise ich musste schmunzeln, als du sagst "Naja, da haben die 300 Folien Strategiepapier hinterlassen." Ist ja auch oft, was ich ergänzend auch oft sehe ist, dass diese eigentlich extrem notwendige und wichtige Priorisierung auf Flight Level drei überhaupt nicht stattfindet. Das heißt, es gibt so ein riesiges, teilweise extrem generisch abgestecktes, nennen wir es mal abgesteckte Strategie. Bei den meisten Dingen sage ich auch okay, das ist eine Wunschliste von Dingen, aber es ist keine... Ich sehe noch keine Strategie darin. Und das wirklich mal zu priorisieren, das ist dann eine Aufgabe, also in zehn Jahren, würde ich sagen, da setze ich blind drauf, dass so ein bisschen das Portfolio eines Unternehmens null priorisiert ist. Und das führt natürlich dann, das kann man ja auch wunderbar an deinem Modell wieder erklären, zu einer Last auf der Organisation, die die Flight Level drei auch gar nicht tragen und auffangen kann. Erst recht, wenn diese Etage dazwischen dann auch fehlt.

Klaus: Absolut.

Andreas: Wenn wir jetzt mal auf Flight Level drei gehen und du hast ja selber gesagt, da wird dann viel gemacht, da werden dann Trainings gemacht und Teams machen Scrum, Kanban und da sind ja auch tatsächlich oft Leute dabei, die es verstanden haben. Also wo man wirklich sagt "Hey, also jetzt noch ein agiles Training und noch mal eine agile Bewegung. Das bringts gar nicht, das braucht ihr nicht. Die Probleme liegen woanders." Aber was glaubst du denn, wie sehr behindert so ein bisschen dieser... Ich meine, wenn wir uns mit Agilität beschäftigen, sind die Leute relativ schnell bei agilen Methoden und Rahmenwerken. Was glaubst du denn? Sind wir da ein bisschen zu Methoden verseucht? Also verstehen wir nicht, worum es bei Agilität eigentlich geht und übersetzen das unmittelbar mit Technik und Methode.

Klaus: Ja, es ist halt die kurze Variante. Also ich tue mich selbst einigermaßen schwer, wenn immer die Frage kommt was ist Flight Levels eigentlich? Bzw. wenn ich höre okay, Flight Level Methode Flight Level Framework. Ich sage immer okay, Flight Levels, aber es ist eigentlich ein Denkmodell, was uns hilft herauszufinden, welche Hebel wir in Bewegung setzen müssen, damit wir das erreichen, was wir erreichen wollen. Aber es ist halt schon verdammt unsexy. Wer will schon denken, ja, und wenn ich halt jetzt mit so einem Framework um die Ecke komme oder mit einer Methode. Da steht halt genau drin, was du tun musst. Das gibt bis zu einem gewissen Grad Sicherheit. Aber es ist halt leider vermeintliche Sicherheit. Ja, du bist voller Passagier von irgendwas, was da abgeht und ja, es ist halt überhaupt nicht meins. Meine Idee, wie Veränderung irgendwie passieren sollte, muss ich verstehen was abgeht und nicht blind irgendwas kopieren. Und ich glaube es ist halt, also sind wir Methoden verseucht, es ist halt schön. Und dann liest man die Case Study. Ja und die haben Framework X eingeführt und alles ist gut. Ja, klingt cool. Dann machen wir das halt auch. Aber man darf halt auch nicht enttäuscht sein, wenn es nix wird.

Andreas: Ja. Es ist so, dieser Wunsch oder diese Suche nach dem Best Practices. Das dockt ja so ein bisschen an. Wenn wir eine Best Practice haben, müssen wir selber nicht nachdenken.

Klaus: Genau. Das ist ja schon das Beste.

Andreas: Dabei hat Agilität ja im Kern dann am Ende auch was mit einer permanenten Weiterentwicklung und auch Lernen zu tun. Ja, und Lernen ist halt zwischendurch unbequem, tut auch mal weh. Und das ist aber wichtig, dass man in dem Prozess bleibt. Ich habe da schon öfter mal ein schönes Zitat gelesen, ich kann es leider aber nicht mehr zuordnen. Copy Paste ist das Lieblings Werkzeug der Bürokraten.

Klaus: Es klingt sehr schön. Ja, ganz genau. Nein also, in der Flight Levels Welt setzt sich das ja weiter fort. Also das eine ist, dass du jetzt nicht ein Framework oder irgendwas kopierst und sagst also kopieren im Sinne von das musst du jetzt genauso machen. Aber ich glaube auch der Change, wie Veränderung in Flight Levels gedacht wird, ist schon ein zentraler Punkt. Mein Schmähbruder, das ist Sigi Kaltenecker, mit dem ich auch jetzt gerade ein neues Buch gemeinsam schreibe, der spricht immer von den zwei Seiten derselben Medaille. Also du hast auf der einen Seite das ganze Technische und so, was du tun musst, was ja auch im Framework sehr schön beschrieben ist. Aber auf der anderen Seite hast du das... Wie treibst du die Veränderung, also den Veränderungsteil? Und das ist eben einigermaßen untrennbar von einander. Und ich glaube, gerade in der Flight Levels Welt ist es so, dass wir auf diesen Change Aspekt, dass wir auf den auch sehr viel Wert legen. Und die Pointe dahinter ist, dass wir eben nicht Sachen für Leute bauen, sondern mit Leuten bauen. Also wenn es darum geht, jetzt ein Flight Level zwei zum Beispiel zu starten, dann fangen wir nicht damit zusammen, dass ich jetzt keine Ahnung eine Runde Manager zusammensetzt oder, dass überhaupt noch schlimmer ein Consultant daherkommt und sagt "Ach ja, übrigens, ich weiß jetzt, wie ihr am besten arbeitet und zwar so", sondern wir starten damit, dass wir mal versuchen rauszufinden, was ist das Problem, was wir überhaupt lösen. Ja, und die Leute, die quasi dann mit diesem Board arbeiten sollten, die bauen das auch. Und ich glaube, das ist ganz wichtig, nicht etwas für die Leute tun, sondern es mit den Leuten zu tun. Und dann, apropos Framework, weicht man auch häufig von irgendwelchen Vorstellungen, wie das Framework skizziert, wie etwas laufen sollte, ab, wenn man sagt okay, das passt aber nicht so gut zu unserer Organisation und das muss meiner Meinung nach erlaubt sein.

Andreas: Wie sehr glaubst du denn das, wenn du sagst "Naja, Flight Level zwei ist eigentlich das Problem"... Also ich hätte eine Hypothese dazu, dass wir so ein Stück weit was die Organisation von Arbeit angeht, so dieser noch immer anhängigen Idee hinterherlaufen, dass so Spezialisierung, die Leute in Abteilungen zu stecken... Und irgendwie ist das ja alles von dem Wunsch geprägt, immer alles abzuurteilen, also abzuteilen, abzugrenzen. So, kleine Königreiche in sich zu schaffen. Also die Hypothese, die Leute haben irgendwie auf diesem Weg verlernt, irgendwie miteinander zu arbeiten. Also, dass die Produktion nur Aufträge hat, wenn vielleicht Marketing und Vertrieb erfolgreich sind, dass Vertrieb nur genug Leads hat, wenn Markt, also so dieses ganze Zusammenspiel. Glaubst Du auch, dass ist ein Grund, warum dieses Flight Level zwei eigentlich in den meisten Organisationen dann irgendwie gar nicht ausgeprägt ist. Oder, dass so eine geringe Sensibilität dafür da ist, dass es genau darum auch in der agilen Organisation geht, diese, ja diese Abhängigkeit, diese Synchronisation immer wieder herzustellen.

Klaus: Ja, also ich glaube, das ist ein ganz spannendes Thema. Also ja, Abteilung bedeutet ja, man teilt sich von etwas ab, man ist abgetrennt vom Ganzen. Die Frage ist aber was ist das Ganze? Ohne jetzt philosophisch zu werden. Aber häufig ist es ja so, dass wir vieles über die Aufbauorganisation lösen wollen. Der Heilige Gral "cross-funktionale Teams" versucht ja genau dieses Abteilungsdenken quasi aufzuheben, indem wir sagen, wir geben alles Wissen, was wir haben, in ein Team rein und das liefert direkt an den Markt. Die Schwierigkeit ist halt, je größer eine Organisation wird und vor allem, wenn wir auch aus der Softwareentwicklung rausgehen und uns Unternehmen anschauen, die ,keine Ahnung, Airbag Systeme, Drohnen, die Navigationssysteme für Flugzeuge bauen oder so, wo Hardware und das alles ein integraler Bestandteil ist. Und dann von cross-funktionalen Teams zu träumen, die quasi an den Markt liefern, dann wird es, dann wird es schon... Da braucht man echt eine große Enttäuschungskompetenz sagen wir so, weil es wird nicht funktionieren unterm Strich. Dann habe ich ein Team mit 40 Leuten, weil ich brauche Physiker, ich brauche keine Ahnung, Materialspezialisten, ich brauche irgendwelche Chemiker, ich brauche Mechaniker, ich brauche ganz, ganz viele Leute und halt die Softwareentwickler auch noch. Das wird halt schwierig irgendwann. Und da rede ich noch gar nicht von den Juristen und was ich noch immer alles brauche.

Klaus: Und ich glaube, das ist genau die Pointe von Flight Level zwei, dass wir sagen okay, versuchen wir das Problem nicht immer über die Aufbauorganisation zu lösen. Das ist überhaupt so, wie Flight Level es an den Start geht. In der Aufbauorganisation werden wir das Problem nicht lösen können, sondern wir können es in der Ablauf Organisation lösen. Und Flight Level sagt ja nicht Du musst deine Organisation ändern, sondern ein Flight Level zwei Board holt die richtigen Leute zur richtigen Zeit vors Board, damit sie sich miteinander koordinieren und das Schöne ist, Wurscht, wo sie in der Abteilung, in der Abteilung, in der Organisation, wie sind Organisationen abgeteilt sind. Das heißt, wir müssen nicht unbedingt die Silos, die Wissenssilos abreißen. Je mehr ich abreißen kann, umso besser. Ja, da braucht man überhaupt nicht drüber diskutieren. Cross-funktional, Cross Funktionalität ist geil. Also je mehr ich von den Silos abreißen kann, umso besser. Ich werde aber nie alle Silos abreißen können. Wurscht. Ich werde dann halt cross-funktionale Silos haben. Ich werde Produktsilos haben, ich werde Marktsegmentsilos haben. Was immer, ich werde einen Silo haben und Flight aber sagt okay, reißen wir nicht die Silos ab, sondern bauen wir oder bohren wir Interaktionslöcher in die Silos rein, damit wir quasi Silo übergreifend Spezialisten gebietübergreifend miteinander uns koordinieren können. Und das ist die große Pointe von Flight Level zwei.

Andreas: Das ist ja aber leider nicht eindeutig. Worüber wir gerade reden, das ist ja ... Du könntest ja, wenn du das so ein bisschen auf die Spitze treibst, sagst du eigentlich gerade "Naja, ihr könnt auch in euren Abteilungen bleiben. Nur lasst uns anfangen, über Flight Level zwei, um Mal bei dieser Metapher zu bleiben, Verbindungen zu schaffen oder auch eben Löcher in diese Wissens Silos zu bohren. Darunter könnt ihr euch auf Flight Level eins dann doch wieder organisieren, wie es euch eben passt, solange ihr Flight Level zwei irgendwie gut im Griff habt." Und das ist, mir fällt da gerade ein, es gibt ein schönes Buch "Six Simple Rules" Yves Morieux ist auch ein Berater und der hat ein tolles Bild da drinne. Das ist glaube ich auch noch mal gut von der anderen Seite auf den Punkt bringt, was Flight Level zwei eigentlich ist. Er meint "Stell dir vor, du hast einen Staffellauf" und er erzählt die Geschichte. Auch, wenn es beim Staffellauf nur um die schnellsten Läufer ginge, dann bräuchte er den Staffellauf nicht. Dann könnte es da einfach die Zeiten der Läufer addieren. Und dann hättest er irgendwie... dann wüsstest du, wer gewinnt beim Staffellauf aber macht man nicht. Warum? Weil eben genau dieser Übergabe Punkt nur ein gewisser Bereich ist und sogar seine Empfehlung an Führungspersönlichkeiten ist:

Andreas: "Versucht nicht alles trennscharf zu definieren." Oder übertragen auf den Staffellauf: "Wir definieren, dass der Button bei 98,5 Metern übergeben wird, ganz egal, wie schnell der andere losgelaufen ist, wie schnell der andere ankommt." Er sagt "Lass das fuzzy". Also sein Tipp an Führungskräfte zu sagen "Versuche gar nicht, alles so genau zu definieren. Lass da so ein bisschen leichten Unschärfebereich, in dem die Leute sich und das ist ja dann am Ende Flight Level zwei auch einfach mal ein bisschen aufeinander einruckeln müssen und da darf es halt auch mal Konflikte geben und dann darf man kontrovers diskutiert werden." Am Ende geht es darum, dass dann doch alle ein gemeinsames Bild haben. Wofür machen wir es nochmal? Was war noch mal auf Flight Level drei die Priorisierung? Und sind wir hier wirklich noch in Synchronisation?

Klaus: Absolut.

Andreas: Wenn du jetzt sagst, wenn man wieder zurückkommt. Okay, vielleicht sind wir doch ein bisschen zu methodenverseucht. Worauf sollte ich denn vielleicht als Unternehmen dann achten, wenn ich jetzt sage, ich will nicht einsteigen über eine Methode, weil die Gefahr da viel zu groß ist, dass ich mich dann auch in diesen ganzen Methoden verliere? Was würdest du empfehlen und sagen, was sind so gute Instrumente, Punkte, um in so ein agiles Fahrwasser reinzukommen, ohne dass ich mich direkt einer Methode verschreibe?

Klaus: Ja, also es klingt jetzt vielleicht einigermaßen allgemein, aber ich glaube, darauf kommt es unterm Strich wirklich drauf an. Ja, also ich glaube, man muss einmal Verantwortung übernehmen. Also sei der Pilot deines eigenen Erfolges. Also wir machen ja auch quasi Outsourcing mehr oder weniger, wenn wir sagen, wir nehmen jetzt dieses Framework und das schrauben wir einfach rein und dann wird schon gehen. Also sei der Pilot deines eigenen Erfolges. Du hast es selbst in der Hand. Ja, was glaube ich, ganz wichtig ist: "Verstehe, was du derzeit tust und welche Auswirkung dein derzeitiges Tun hat." Ja, das ist etwas, was ganz, ganz selten wirklich gemacht wird, sondern wir gehen halt die Abkürzung und sagen: "Ach ja, und da jetzt Methode X mit der ist dann besser." ohne zu wissen, was eigentlich derzeit das Problem ist. Ja, und ich glaube, wenn ich das verstanden habe, was derzeit das Problem ist, da gibt es ja die schönen Sprüche von Einstein und so weiter. Ja, wenn ich weiß, dass die Welt in einer Stunde untergeht, würde ich wissen 45 59 Minuten dafür verwenden, das Problem zu verstehen oder so irgendwie. Ja, aber genau das tritt ja dann ein, weil der dritte Punkt "Werde besser", der geht ja dann meistens relativ einfach, wenn man wirklich weiß, was abgeht. Das wären so meine drei Punkte. Sei der Pilot deines eigenen Erfolges. Der zweite Punkt verstehe, was du derzeit tust und welche Auswirkungen das hat. Und der dritte Punkt werde besser. Und lass dich inspirieren. Natürlich von allem rundherum.

Andreas: Das ist ja auch wieder meine Oma hätte dann immer gesagt "Du hast deinen Kopf nicht nur zum Haareschneiden." Das ist natürlich auch ein, also ein anstrengender Prozess, sich diese Frage überhaupt mal zu stellen: "Also was ist denn gerade das Problem, das wir versuchen zu lösen?" und sich mal von der ja, also von dieser "Schnell, schnell. Ich beobachte ein Symptom und das ist gleich das Problem." [zu trennen.]

Klaus: Ja.

Andreas: Nee, wir müssen uns jetzt mal Zeit nehmen oder wirklich da reingehen. Und du hast ja in deinem Buch die Punkte, die ich mir da notiert habe, diese einfachen Dinge zu sagen. Wie können wir das Problem am besten verstehen? Vielleicht, indem wir es visualisieren, also indem wir uns einfach ein Bord nehmen, mit ein paar Kästen Pfeilen, Post-Its mal uns versuchen, die Welt zu erklären. Das sind ja ohnehin auch immer nur dann auch immer nur Modelle und es ist ja nie die Wahrheit. Aber es ist zumindest mal... lernen wir auf dem Weg dahin vielleicht besser zu verstehen, wo könnte denn tatsächlich so ein bisschen mehr dieser Root Cause liegen? Und ein zweiter Punkt ist ja dann, wenn wir schon die Wahrheit nicht kennen, auch wenn wir uns so sehr danach sehnen. Wir immer nur Hypothesen anstellen können und dann auch wieder beobachten, ob wir uns denn verbessern. Aber diese Beurteilung, ob wir uns verbessern, kann ich ja dann nur treffen, wenn ich einen klaren Ausgangspunkt habe, nämlich sage das genau das sind die Probleme. So äußern sie sich. Wir sind zu langsam am Markt, die Produkte sind schlecht, die Kunden beschweren sich, was auch immer das Problem ist. Dazu gehört nur leider auch eine Kultur, in der man auch mal über Probleme sprechen darf...

Klaus: Wohl wahr.

Andreas: ...und nicht einer, der sagt "Ja Herr Diehl, wir haben keine Probleme, wir haben nur Herausforderungen" da sag ich "Ja, das ist super."

Klaus: Ja, wie gesagt, wieder dieses Bullshit Bingo!

Andreas: Ja, genau. Was wären denn, wenn ein Unternehmen zu dir kommt und sagt "Okay, Klaus, verstehe ich alles. Aber mit diesem Denken, da haben wir nicht so viel Zeit für. Gib uns mal drei Quick Hacks." So vielleicht zum Abschluss. Hast du da noch irgendwas, wo du sagst Mensch, wenn du in diese agile Welt einsteigen willst, was denn dann? Gibt es da gibt es da noch was, was du ergänzend noch hintendran schieben würdest. Das sind die Punkte, die ich unbedingt machen würde.

Klaus: Also die Frage ist natürlich wie Wie schlau ist es, dass ich jetzt genau drei Quick Hacks sage? Aber ich sage einen Quick Hack und der Quick Hack, also der ist gar nicht so quick, glaube ich. Aber der hilft dabei, genau die drei Punkte, die ich davor gesagt habe, besser greifbar zu bekommen, und das ist Fokus aufzubauen. Ich glaube, wenn wir in einer Organisation eine Sache versuchen einzuführen, dann wäre es, Fokus aufzubauen. Und das verursacht, je nachdem, wie sehr wir es machen, genug Schmerz, dass wir quasi gezwungen sind zu verstehen, wie wir derzeit arbeiten und welche Auswirkungen es hat. Und wir werden dann auch besser werden wollen. Aber ich glaube mit Fokus, dass es so ziemlich der größte Hebel. Also man kann natürlich visualisieren, wie man arbeitet, das ist super und so, aber häufig bleibt dann dabei, dass man die Dysfunktionalität besser verwalten kann. Das bringt halt auch nicht so viel. Und ich glaube, sobald wir den Weg gehen, Fokus aufzubauen, sei es jetzt durch irgendwelche Work-In-Process Limits in der Organisation oder sei es durch durch gute Sequenzierung der Arbeit. Apropos Priorisierung Andreas, was du vorher schon erzählt hast am Level drei ja, oder es heißt, dass wir in gewissen Zeit-Boxen versuchen, Commitments aufzubauen. Es gibt ja verschiedenste Wege, wie wir Fokus aufbauen können. Wenn wir das schaffen, dann dann geht es schon recht viel weiter.

Andreas: Ja sehr schön. Das war schon ein sehr gutes und ich denke auch brauchbares Schlusswort. Klaus, ich bedanke mich. Es hat mich extrem gefreut und vielleicht bis zum nächsten Mal.

Klaus: Vielen Dank für die Einladung, lieber Andreas.

Andreas: Tschüss.

Klaus: Ciao.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.