Matthias: [00:00:06.64] Herzlich willkommen zu einer neuen Ausgabe von der Macht der Craft mit mir, Matthias,

Alex: [00:00:11.27] Und wie immer mit mir dem Alex. Heute wollen wir uns mal wieder dem Lernen widmen, wenn auch in eine etwas andere Art.

Matthias: [00:00:21.70] Und zwar wollen wir heute darüber sprechen, wie man aus Problemsituationen lernen kann.

Alex: [00:00:26.41] Viel zu oft steht dabei die Suche nach einem Schuldigen im Vordergrund.

Matthias: [00:00:31.81] Du wirst erfahren, warum wir glauben, dass das nicht der richtige Fokus ist und wie man an die Sache anders herangehen kann.

Alex: [00:00:38.59] Viel Spaß mit dieser Ausgabe.

off: [00:00:43.38] Die Macht der Craft arbeitet für dich.

Alex: [00:00:49.61] Jede Anwendung in jedem Projekt wo wir arbeiten, gibts größere oder kleinere Problemchen. Immer wieder. Das ist nichts Schlimmes, nichts Außergewöhnliches. Aber im Großen und Ganzen passieren dauernd irgendwelche Sachen, auf die wir reagieren müssen, die uns Probleme verursachen. Wir wollen heute darüber reden, wie können wir diese Probleme am besten – ja für die größere Probleme geeignet? Wie können wir uns mal das Problem anschauen und analysieren und tatsächlich was draus lernen? Weil ja in so eine Situation was eigentlich in meinen Augen wichtig ist, ist, dass wir lernen, was tatsächlich passiert ist. Wie ist das Problem zustande gekommen und dass wir daraus ableiten können? Wie können wir es besser machen? Was können wir verändern, damit das Problem nicht auftritt? Und so weiter und so fort. Und das soll ja eigentlich das Ziel sein. Was aber sehr oft passiert oder ich oft beobachtet habe, ist, dass man das sogenannte blame game spielt. Was würdest du sagen, dass das bedeutet Matthias?

Matthias: [00:02:20.86] Naja, also ich würde mal sagen, man sucht einen Schuldigen, den man einzig und allein daran macht mans fest, der ist verantwortlich, dass das passiert ist. Und wenn ich denen nur ordentlich sanktioniere, dann wird er lernen, das nicht mehr zu machen – so unbedacht zum Beispiel. Und man hält damit das Problem für erledigt. Grob gesagt also Schuldzuweisungen in erster Linie und nicht die Überlegung, wie man das in Zukunft besser machen könnte.

Alex: [00:02:58.12] Gut beschrieben. Man kann eben sagen, obwohl man denkt, dass man genau diese Fragen beantwortet, die wichtig sind. Nämlich Wie können wir es vermeiden? Wie können wir besser werden? Was können wir verändern? Und so weiter. Was da rauskommen ist Person A, B und C sind schuld. Die kriegen jetzt dieses Jahr kein Bonus, keine Ahnung, irgend sowas. Und deswegen werden sie jetzt lernen, das richtig zu machen. Und dann passts.

Matthias: [00:03:25.39] Im schlimmsten Fall werden sie entlassen.

Alex: [00:03:27.58] Diese Blame Game ist auch ein Teil von Unternehmenskultur, von dem, wie man im Unternehmen arbeitet und miteinander umgeht. Ich kann mal erzählen von einem eine Geschichte, die ich mal so gehört habe. Es war mal ein Unternehmen. Die haben so ein paar mal im Jahr irgendwelche Programm Versionen rausgebracht. Und natürlich gibt es während das ganze Prozess in den sie diese Anwendung entwickeln, testen usw. regelmäßige Termine, in dem auf den Stand der Sachen geschaut wird. Sind wir noch im Zeitplan? Wo gibt es Probleme? Muss man ja irgendwo was anpassen oder korrigieren. Wer hat Probleme bei der Umsetzung? Wie auch immer, da sitzen sie ganz schöne Chefleins halt mal dort und jeder hat seinen Rede-Turnus. Und was passiert da? Also im Normalfall läuft immer alles super. Es läuft, alles klar, keiner hat Probleme. Es gibt keine größere Bedenken. Wir schaffen alles, das wird schon. Das ist, was ich wahrgenommen habe die ein oder andere Mal, wo ich dabei sein dürfte. Und – das Problem dabei ist: da ist keiner, die den Mut hat aufzustehen und sagen „Na, da gibt es ein Problem“, ja solche Aussagen kommen sehr selten bis gar nichts. Und zwar eben weil blame game, auch wenn es vielleicht keinen offensichtlichen blame game ist. Wenn man sich einfach sozusagen die Hosen runter lässt und sagt Ich schaff das nicht, dann fühlt sich jeder berechtigt zu den Zeitpunkt. Ja, wenn der es nicht schafft, dann können wir auch nicht. Aber Hauptsache irgendjemand anders hat damit angefangen. Ist auch so ne so ne Art von diesem Blame Game. Und natürlich ist die schlimmste Art und Weise, die um ein Problem bei der Lösungssuche eines Problems einfach die Zeit zu verplempern, um irgendeine Person verantwortlich in Anführungszeichen für das Problem zu machen. Denn runter zu putzen, ihm zu erklären, was er alles falsch gemacht hat und ihm zu sagen, er soll es besser machen, das hilft keiner. Das bringt in meinen Augen nicht.

Matthias: [00:06:05.61] Aber mal zu der Geschichte: Interessant wäre ja jetzt dann eigentlich noch, wie das ist. Also das sind diese zwischen Meetings, wo mir der Stand abgefragt wird und niemand sagt, dass es ein Problem gibt, weil man hat irgendwie Angst vor Sanktionen oder sonst irgendwas zum Beispiel. Aber was passiert dann, wenn die Version nicht ausgeliefert werden kann? Es ist ja dann glaube ich das Blame Game dann erst richtig losgeht, oder?

Alex: [00:06:36.21] Das ich kann dir sagen was passiert ist. Keiner hat sich gemeldet, die Version wurde ausgeliefert und dann war die Kacke am Dampfen. Ja, es gab nur Fehler über Fehler, Probleme, úber Probleme, Anwendungen haben nicht funktioniert, die waren nicht mehr bedienbar. Und ja, also es war der Anfang und dann gabs dann auch raus. Das hätten wir viel früher erkennen können, wenn. Und dadurch sind eine ganze Menge an Änderungen in die Unternehmenskultur und Unternehmensphilosophie viele Sachen geändert worden, viele Sachen sind besser geworden, aber nichtsdestotrotz haben wir immer diese kleine Angst im Hinterkopf, wir, wenn wir wirklich sagen, was los ist oder wenn wir wirklich erklären, warum ein Problem entstanden ist. Wenn ich der Meinung bin, dass sich da irgendwie das Problem verursacht haben könnte, dann sage ich lieber nichts. Weil wenn ich was sage, dann habe ich die A-Karte gezogen sozusagen.

Matthias: [00:07:48.11] Ja, also in so einer. Also wenn du in so einer Unternehmenskultur dann auch bist, dann tendiert man wahrscheinlich häufig auch dazu, wirklich Dinge auch unter den Teppich zu kehren und also einfach nur um die Gefahr, sanktioniert zu werden, zu minimieren, sozusagen. Und es ist halt irgendwie auch gefährlich.

Alex: [00:08:11.90] Es geht nicht immer nur um Sanktionen, das ist auch persönliches Ansehen oder dass man einfach als schwarze Peter verwendet wird. Ja, du hast dich jetzt gemeldet, also da wir eh alles kaputt ist nur wegen dir, dann können alle andere Probleme auch auf den Tisch, weil ja was soll’s. Du hast es schon verkackt. Und das ist eine sehr eine sehr toxische Kultur. Sie ist irgendwas, was nicht hilft und vor allem wir lernen nicht raus, weil das Person A, B und C halt irgendein Problem verursacht haben. Ist okay. Es mag auch Konsequenzen haben, kein Dings, aber das muss jetzt nicht der Grundprinzip, nach dem wir leben. Wir müssen versuchen besser zu werden, um zu lernen, wie wir besser mit diese Probleme umgehen können oder sie gar verhindern können. Und dies musste das Ziel, die wir folgen. Sei es bei jedwede Besprechung, in dem man Probleme ansprechen soll, bei Post-Mortem Analysen, beim was auch immer man für Tools verwendet, um um diese Problemen halt zu klären und daraus zu lernen. Das Wichtigste ist daraus zu lernen, nicht entschuldigen zu finden. Und öfters, wie es manche Unternehmen und manche Unternehmenskulturen habe ich manchmal das Gefühl das steht nicht tatsächlich im Vordergrund, sondern eher so nebenbei. Was sagst dazu?

Matthias: [00:09:46.02] Ja. Also leider scheint es ja tatsächlich so zu sein. Ich muss also ich für meinen Teil habe halt immer versucht, nicht – wie soll man sagen – hinterm hinteren Zaun zu halten, wenn irgendwas ist. Aber natürlich, das ist nicht immer leicht. Auf jeden Fall. Aber ja. Also ich finde es echt schade, wenn wenn man nicht sagen kann, was Sache ist, wenn man halt keine Ahnung aus welchem Grund auch immer Angst davor haben muss negativ rüberzukommen. Oder halt. Also eigentlich finde ich, sollte es sogar belohnt werden, wenn jemand Probleme aufzeigt, weil letztendlich kann man damit ja auch dazu beitragen, dass eben diese Katastrophe nicht passiert. Also wenn man jetzt noch mal an die Geschichte zurückdenkt, wenn in denen Zwischenmeetings halt von Anfang an jemand, der Bedenken hat, diese Bedenken einfach äußern kann, dann kann man halt viel, viel früher gegensteuern und kann nicht erst viel zu spät reagieren. Also eventuell hätte es dann die diese Blame Game an sich gar nicht gebraucht, weil ja. Nee. Also ich glaube, du weißt, was ich sagen will.

Alex: [00:11:09.71] Ich denke schon. Ich hoffe unsere Hörer auch.

Matthias: [00:11:13.22] Das hoffe ich auch. Unternehmenskultur spielt auf jeden Fall eine ganz große Rolle. Und als einzelner glaube ich, kann man da. Also wenn man jetzt unter einer Unternehmenskultur leidet, die diese, diese Schuldzuweisungen und so was betreibt, ist es halt glaube ich für den Einzelnen auch schwer, daran etwas zu ändern, weil es eben ein Ding der Unternehmenskultur ist.

Alex: [00:11:39.02] Was ich auch beobachtet habe, ist diese Blame Game fängt an zu geschehen. So was läuft eher auf Unternehmensebene oder wenn mehrere Abteilungen involviert sind. Oder weil das habe ich zum Beispiel in in unserem Team Matthias noch nie erlebt. Wir machen Gaudi und wir machen den Spaß. Ja, du bist schuld und bla bla es schon wieder verbockt. Aber damit ist der Käse gegessen, der ist völlig egal. Und dann geht es darum wie können. Wir unsere lokalisiert das Problem lösen und solange es nur uns betrifft, ist ja auch eigentlich gar kein Problem, das kriegt man gebacken. Ich denke, das Problem und diese Blame Game entsteht eher, wenn der Kreis größer wird. Sagen wir mal so, wenn es mehrere wiegesagt Abteilungen, die sich dann gegenseitig beschuldigen du weißt schon was ich meine.

Matthias: [00:12:34.60] Und vor allem wenn der Impact monetärer ist, also wenn es Geld kostet, auch dann geht es los. Und da glaube ich, ist es halt wirklich wichtig, dass sich Unternehmen im Ganzen klar werden, dass es sinnvoller ist zu versuchen daraus zu lernen, als irgendjemanden beschuldigen zu können.

Alex: [00:12:59.64] Hm, ja sehr gut. Ja, find ich auch. Aber warum passieren uns Fehler? Wir machen alle Fehler. Man kann ja immer passieren, dass ich irgendwas deploye und danach der Server puff macht. Gar nichts mehr geht. Super Alex, hast es wieder hingekriegt. Aber das liegt daran, dass wir Sachen ändern. Das die Sachen veränderbar sind. Wir können die Sachen verändern, wir ändern sie auch. Und dadurch passieren Fehler, Schäden oder Problemchen.

Matthias: [00:13:31.99] Und wir bewegen uns halt auch in einem eher komplexen Umfeld. Also es ist ja nicht nur deine Anwendung, die du deployst, sondern es ist ja auch der Server, auf den deployt wird bzw. die Cloud Infrastruktur des Rechenzentrum was auch immer. Also da sind ja viel mehr Faktoren noch drinnen als nur die Anwendung die du deployst.

Alex: [00:13:53.56] Aber zum Thema Komplex kommen wir vielleicht später, wenn wir über Cynefin reden. Aber natürlich hat es einen Einfluss und zwar einen großen Einfluss. Wo ich eigentlich hin wollte, ist mal klar zu machen, dass das Fehler passieren, ist normal. Das ist kein aussergewöhnliches Zustand. Fehler sind völlig normal, sind auch völlig okay. Wir müssen nur reagieren können. Es liegt an der Natur der Sache, dass wenn wir was ändern, uns Fehler passieren können. Fertig. Aber genau in der Natur der Sache liegt auch das die meiste Zeit die Sachen funktionieren, weil es ist nicht so, dass nur die ganz großen Probleme gibt. Die ganz großen Probleme sind die, die vielleicht an die Oberfläche kommen, wo es mehrere Leute merken. Aber immer wieder gibt es Pannen und Problemchen, die man innerhalb des Teams, innerhalb von der Gruppe wie auch immer halt man lösen muss, wo man ständig kontrolliert und schaut, dass die Systeme funktionieren, dass die Programme keine Fehler eingebracht haben, dass man das ordentlich testet und so weiter und so fort. Also das ist tägliche Arbeit und das gehört auch irgendwie mit dazu. Deswegen, dass die Sachen funktionieren und nicht funktionieren, ist völlig normal. Was bewundernswert ist, ist, dass wir tatsächlich es meistens hinkriegen, dass die meiste Zeit das Zeug funktioniert, irgendwie, wie wir ja sagen „Das ist ja aber der Job“. Also ich finde, das ist eine wichtige Konzepte oder eine wichtige Idee des „Es gibt nicht nur diese große Probleme, die überall man zu hören dann bekommt, sondern auch die ganz kleinen Probleme im alltäglichen Geschäft“. Und die merkt ja keiner. Weil wir sind schon so routiniert in der Arbeit mit sowas, dass wir sie – wird einfach weggebügelt, merkt keiner, passiert nichts, sieht keiner. Die sind aber trotzdem da. Also dass es Fehler gibt, ist völlig normal. Es ist auch nichts schlechtes, wenn man in der Lage ist, aus den Fehlern zu lernen. Ja oder nein?

Matthias: [00:16:11.16] Ja, vor allem wenn halt zum Beispiel das – wie soll man sagen? – Halt wieder das Ignorieren von den kleinen Fehlern bzw. das Verheimlichen von den kleinen Fehlern dazu führt, dass sich das irgendwann halt zu einer Katastrophe aufsummiert, sozusagen, also als nur als blödes Beispiel. Du hast irgendwie so einen Fehler, der keine Ahnung dazu führt, dass Requests auf eine bestimmte Route immer auf einen 500er laufen, der dir weggeloggt wird oder so und das ignorierst du, weil ja der Rest der Anmeldung funktioniert. Ja, das ist keine Ahnung, irgendein Health-Endpoint oder weiß der Teufel was? Aber wenn du nur lange genug wartest, führt es vielleicht dazu, dass die ständigen Logeinträge von deinem 500er dazu führen, dass deine Festplatte voll läuft und auf einmal stürzt dein Server ab und du hast es halt nur nicht gesagt, weil du ja keine Ahnung. Vielleicht hast du den den Code eingebaut und hast Angst davor, dass das auf dich zurückfällt und deswegen verschweigst du. Und dann ist er einmal selber weg. Nur mal so als blödes Beispiel halt. Und deswegen ja, also absolut. Also ich find Fehler sind auch tatsächlich das natürlichste der Welt. Jeder macht sie. Niemand ist allwissend. Und deswegen finde ich es für mich persönlich einfach wichtig, dass man zu Fehlern noch stehen kann. A Persönlich also dass man selbst in der Lage ist, Fehler einzugestehen. Da habe ich etwas falsch gemacht, das ist okay. Aber auf der anderen Seite auch, dass das Umfeld, dem ich den Fehler kommuniziere, dass das eben auch respektvoll damit umgehen kann. Also ist zum Beispiel auch anerkennen kann, dass du stehst immerhin dazu. Wie können wir es denn besser machen? Und dann ist man auch selbst gleich wieder in der Situation, wo man Vorschläge eventuell machen kann. Was kann man tun, damit dieses Problem nicht mehr auftritt? Und schon habe ich einen Verbesserungs Prozess. Aber wenn ich halt Angst davor haben muss solche Fehler einzugestehen, dann ja dann ist es halt kontraproduktiv.

Alex: [00:18:30.53] Jawohl. Okay, dann gucken wir was in solche Besprechungen solcher Analysen, wenn wir ein Problem analysieren, jetzt mal ein größeres Problem dann spielen – Ich werfe jetzt einfach zwei Begriffe in den Raum und da können wir uns ein bisschen darüber unterhalten. Da spielen kognitive Verzerrungen und kontrafaktische Aussagen eine Rolle. Jetzt habe ich gezeigt, dass ich total komische Wörter in Deutsch kann und jetzt – Was würdest du darunter verstehen oder was weißt du darüber? Über kognitive Verzerrungen und kontrafaktische Aussagen?

Matthias: [00:19:14.16] Ja, also ich stelle mir das jetzt so vor: „Wenn ich jetzt in so einem Meeting wäre, worum – wo es darum ginge, einen Schuldigen zu finden und man mich frägt, was ich gemacht habe und ich beschreibe mein mein Vorgehen und man mich dann frägt so ja oder mir sagt Hättest du diese und jene Aktion aber anders gemacht, dann wäre das ja ganz anders gelaufen, so als verstehe ich das. Also das ändert nichts an der Tatsache, die eigentlich passiert ist, sondern impliziert nur du hättest es besser machen können. Und es steht ja nicht mal zur Debatte. Die Frage ist halt eher Warum hat man in der Situation so gehandelt, wie man gehandelt hat? Und das zu beleuchten sollte da eher im Vordergrund stehen und eben nicht dieses Ja, hätte, hätte

Alex: [00:20:10.25] Ja genau so sehr auch so ein tolles Beispiel für Verzerrungen vor. Kontrafaktisch. Ja, du bist ja so ein Cowboy, ne du rennst immer vor. Und hättest du ein bisschen länger überlegt. Das ist genau, was du gesagt hast, dass er diese hätte, hätte, Fahrradkette. All diese Aussagen sind sie kontrafaktisch. Das ist irgendwas, was nicht passiert ist. Es bedeutet hier nicht kontrafaktisch. Es ist irgendwas, was nicht stattgefunden hat. Und deswegen kann uns eher wenig helfen, um zu verstehen, wie das Problem zustande gekommen ist. Alles, was wir nicht gemacht haben, hilft uns nicht, herauszufinden, warum das Problem auftrat

Matthias: [00:20:53.09] Und da ist nicht passiert ist. Kann man ja auch nicht mit Sicherheit sagen, es ist wirklich so und so dann ausgegangen wäre, ja? Und das ist dann halt auch absolut unpassend in so einer Aufarbeitung.

Alex: [00:21:10.25] So viel, zu zu kontrafaktisch. Und das Thema Verzerrung ist ein Problem, die jeder Mensch hat. Also das ist nichts Böses, sondern unser Gehirn funktioniert so, dass der manchmal faul ist. Was sagen wir mal, ist wirklich alles grundsätzlich faul? Und wenn er in der Lage ist, so eine Abkürzung zu nehmen, dann nimmt er sie auch. Und so bin ich nicht ganz tief und konzentriert über irgendwas denken muss, weil ich ein sofortigem Weg dahin finde, wo ich hin will oder wo ich denke dass ich hin will, dann nehme ich die Abkürzungen. Des macht das Gehirn halt mal so. Und dabei entstehen ja manchmal Probleme. Das funktioniert meistens gut, keine Frage. Aber es gibt diese sogenannten kognitive Verzerrungen und das bedeutet, dass das, was da ist, falsch bewertet wird. Ganz klassisch ist zum Beispiel die Aussage Hättest du das nicht gemacht, weil bei solche Situationen es ist wichtig, sich klar zu machen, was du wusstest, zu dem Zeitpunkt, wo du eine Entscheidung getroffen hast und nicht, was du im Nachhinein erfahren hast. Dass ich die Anwendung, die deployt habe, hat dazu geführt, dass der Server abgestürzt ist. Okay. Aber jetzt zu sagen: „Hättest du nicht deployt, bevor du mehr getestet hast?“ Wie gesagt, hätte, hätte, Fahrradkette. Und die Aussage: „Warum hätte ich mehr testen sollen, wenn ich schon alles getestet habe, was wir immer testen?“ Ja, also wenn du nicht wusstest, dass der Server ausfallen wird, ist die Menge an Testen, die wir bis jetzt gemacht hat, ihm völlig ok. Deswegen ist in Nachhinein zu sagen, du hättest mehr testen sollen irgendwie ein von diese kognitive Verzerrungen

Matthias: [00:23:10.61] Und man müsste eigentlich nur ein bisschen umformulieren. Also zumindest als Vorschlag. Vielleicht sollte man in Zukunft mehr testen, wo dann die Frage ist halt: „Ja, was denn?“ Also wie könnte man die konkrete Situation, die wir jetzt bei dem Deployment hatten? Wie könnte man die in Zukunft verhindern, indem man mehr testet? Das könnte ja ein valider Vorschlag sein, aber halt, wie du schon gesagt hast, halt net in diese Vergangenheitsform. Hätteste mal mehr getestet, weil er hilft niemandem.

Alex: [00:23:43.85] Und diese Verzerrungen gibt es viele. Diese kognitive Verzerrungen sind da und wir müssen uns bewusst sein, dass sie da sind. Und es ist wichtig, auch zu wissen, dass man sehr schlecht merkt, wenn man selbst in die Falle tappt. Wenn ich eine kognitive Verzerrung erleide, also wenn wenn eine Person selbst eine kognitive Verzerrung unterliegt, dann merkt sie es normalerweise nicht. Und das macht es so schwierig, sich selbst raus zu trainiert, nicht rein zu fallen. Weil wenn du es nicht merkt, kannst du es nicht verhindern. Und das Thema kontrafaktisch ne, Diese kontrafaktische Aussagen zeigen öfters einmal, dass irgendwelche Verzerrungen im Spiel sind. Nicht immer und nicht überall, aber kann ein Zeichen sein dafür. Und auf solche Sachen sollte man achten, um tatsächlich den Ergebnis zu erreichen, die wir wollen und nicht einfach einen Schuldigen zu benennen und wir sind alle happy, weil ich bin nicht schuld, passt. Nee nee, das wollen wir nicht. Wir wollen tatsächlich was lernen und das ist was wichtig ist. Ansonsten würde ich jetzt wieder mal einen kurzen Blick auf Cynefin – haben wir schon das letzte Mal erwähnt und kannst du mal kurz noch das Cynefin-Framework mal durchgehen und uns dann vielleicht erklären, wo du die Probleme von ein blame game findest?

Matthias: [00:25:16.56] Ja, das Cynefin Framework, da haben wir uns ja schon mal drüber unterhalten. Aber jetzt noch mal kurz zur Auffrischung: Das Cynefin-Framework versucht eine Gruppierung für Probleme, Aufgaben, Prozesse wie auch immer zu finden. Es fängt an mit ganz simplen, also der dem simplen Bereich sozusagen. Und da ist es so, dass alles bekannt ist. Es gibt eigentlich nichts Unbekanntes. Man weiß ganz genau, was zu tun ist, wenn man nur den richtigen Schritten sozusagen folgt. Danach kommt der komplizierte Bereich. Da ist es dann so, dass es bekannte Unbekannte gibt. Also soll heißen, das was unbekannt ist, ist mir zumindest bewusst und ich kann gut darauf reagieren. Im nächsten Schritt kommt der komplexe Bereich. Hier ist es dann so, dass es die unbekannten Unbekannten gibt, sozusagen. Also es heißt, mir sind Dinge nicht mal bewusst, die passieren können. Und im Anschluss kommt dann eben der chaotische Bereich. Da gibt es Unbekannte, die nicht mal zu wissen sind, also Extremereignisse zum Beispiel. Um das Ganze mal anhand von einem Beispiel vielleicht zu erläutern, kann man sich vorstellen, dass man jetzt als simple Aufgabe auf eine unbefahrenen Landstraße am helllichten Tag an dem Sonntag unterwegs ist, kein Auto weit und breit zu sehen. Und meine einzige Aufgabe ist, dieses Auto zu steuern. Es ist simpel, da kann nicht viel passieren. Wenn ich jetzt allerdings an einem Wochentag in der Nacht dieselbe Strecke fahre, ist es unter Umständen eben kompliziert. Wenn man sich jetzt hingegen vorstellt, dass man an einem Montagmorgen in die Arbeit fährt durch die Stadt im Berufsverkehr, dann ist es vielmehr eine komplexe Aufgabe. Also das heißt, ich muss auf viel mehr achten. Es können Dinge passieren, es können, wenn ich an der Ampel stehe, vor mir Fußgänger bei Rot über die Ampel laufen. Ich muss auch viel, viel mehr achten als in den anderen Fällen. Und in den chaotischen Bereich würde ich kommen, wenn unvorhersehbare Dinge passieren. Also wenn auf einmal ich im Gegenverkehr sehe, dass ein LKW die Kontrolle verliert, zum Beispiel, dass wir ein Ereignis, das kann ich nicht vorhersehen und müsste instinktiv darauf reagieren. Das wäre dann der chaotische Bereich.

Alex: [00:28:08.46] Toll, gute Beispiel gefällt mir.

Matthias: [00:28:11.22] Ja genau. Und jetzt ist dann natürlich die Frage Wie spielt das Ganze jetzt mit unserem Thema Schuld, Verantwortung, blame Game zusammen?

Alex: [00:28:22.50] Es ist eben so, dass bei der Softwareentwicklung im Allgemeinen uns sehr oft im Bereich „komplex“ befinden. Ja, also es gibt simple Aufgaben, es gibt komplizierte Aufgaben, wir sind ab und zu, wir verfallen ab und zu mal im Chaos, aber einen großen Teil der Aufgaben befindet sich im komplexen Bereich, weil auch wir nicht allein auf der Welt sind. Ja, und dass wir unsere kleine Aufgabe und unsere kleines Programm pflegen und hegen. Wir leben nicht alleine auf die Welt. Es gibt viele andere Anwendungen. Es gibt sehr viel Infrastruktur, die gepflegt werden will, die wir verwenden müssen. Und das macht das Betreiben unsere Anwendung so eine komplexe Angelegenheit. Und wenn du es auf Unternehmen Ebene siehst, da ist nicht nur eine Anwendung, sondern wahrscheinlich hunderte davon. Das mach komplexer, komplexer, komplexer also. Und in diesem komplexen Bereich haben wir ein Problem. Und zwar lass es mir präsentieren anhand der andere, wenn ich mich in simplen Bereich befinde, wie du gesagt hast, da gibt es bestimmte Rezepte, bestimmte Patterns, bestimmte Wege, wie man Sachen macht, sogenannte Best Practices, die gibt es und die kann ich anwenden. Und dann ist der Käs gegessen, das Problem gelöst, die Aufgabe gelöst. Dann diese komplizierte Umgebung. Gibt es diese Best Practices nicht – nicht mehr. Es gibt höchstens – ja – Praktiken, die sich als in der einen oder anderen Fall uns geholfen haben, aber es ist nicht mehr alles so eindeutig. Es gibt viel mehr Unbekannte. Es gibt überhaupt Unbekannte, was in ihm simpel nicht der Fall war. Wir können auf Probleme stoßen. Wir sind uns halbwegs bewusst, auf welche Probleme wir stoßen können. Und das ist im komplexen Bereich nicht mehr so ein Komplexe im Bereich ist, das Unbekannte Unbekannte genannt hast. Da weißt du viele Sachen nicht. Da weißt, du kannst einem Problem nicht entgegenwirken, weil du gar nicht weißt, dass du das Problem haben kannst.

Alex: [00:30:28.61] Wir sind alle nur Menschen, also werden diese Probleme auch auftreten. Je komplexer das System ist oder das Problem oder die Aufgabe, desto wahrscheinlicher ist es, irgendwelche Probleme auftreten. Das ist auch nicht neu. Deswegen ist in diesem Bereich da, wo die meisten Fehler, die tatsächlich Wellen schlagen, sagen wir mal so passieren. Komplex chaotischen, chaotischen Zustand, wie du sehr gut gesagt hast. Da kannst du nur reagieren, da hast du keine Zeit dir zu überlegen. Ja, funktioniert das oder wurde das funktionieren? Nee, du musst irgendwas machen. Schnell. Und danach guckst du. Hat’s geklappt oder hat es nicht geklappt? Wenn nicht geklappt hat, dann probier es was anders schnell. Und diese zwei Bereiche, da kann ganz schnell passieren, dass die Sache Wellen schlägt und dass wir uns dann im Blame Game wiederfinden. Ja, da geht es nicht mehr darum, herauszufinden, was hat das Problem verursacht, sondern eher wer. Und das hilft uns, wie wir gesagt haben, tatsächlich nicht zu lernen, wie wir das Problem auch verhindern können, wenn wir gar nicht wissen, was passiert ist. Oder was dazu geführt, dass das Problem auftrat und es kann nie eine Person sein. Das ist in meinen Augen, was das eine mit dem anderen zu tun hat. Also in simpel und kompliziert. Da chillen wir uns durch die Gegend, das kriegt man alles gebacken, das passt. Aber da haben wir noch einen Durchblick, sozusagen. Aber in komplexen Systemen, die sehr viele Teile haben, wo wir wahrscheinlich auch nicht die Hand auf jeden Untersystem haben. Da kann so viel passieren, so viel falsch gehen. So das es manchmal ein Wunder ist, dass überhaupt irgendwas funktioniert? Und da in diese Bereiche sehe ich zumindest das Problem. Wie sieht es bei dir?

Matthias: [00:32:15.96] Ja ne, ich finde die Einordnung sehr gut

Alex: [00:32:20.33] okay.

Matthias: [00:32:21.26] Also es scheint tatsächlich so zu sein, dass wir uns im Normalfall in einem komplexen System bewegen. Und wenn unvorhergesehen. Also wenn jetzt zum Beispiel ein Ja ins System, ein Webserver oder so ausfällt, dann kann es ganz schnell halt das Gesamtsystem ins Chaotische umschwingen.

Alex: [00:32:41.00] Genau.

Matthias: [00:32:41.66] Also wenn irgendwelche Sachen, die man einfach nicht vorhersehen konnte, passieren, dann wird aus meinem normalen, komplexen System auf einmal ganz schnell ein chaotisches System. Und dann muss ich unter Umständen schnell reagieren, um Schaden abzuwenden.

Alex: [00:32:59.31] So, jetzt haben wir mal gesehen, was ist mit diesem Blame Game auf sich hat. Warum es uns am lernen hindert, was alles passiert, wenn Fehler entstehen. Haben wir auch gehört, was diese kognitive Verzerrungen sind. Haben wir auch ein bisschen den Zusammenhang von Cynefin und die ganze Geschichte dargestellt? Und wie kann man das besser machen, Matthias?

Matthias: [00:33:27.56] Ja, das ist eine gute Frage. Ich würde einfach mal das Wort Learning Review Framework in den Raum werfen. Das ist ein Begriff, den ich aus dem Buch „Beyond Blame“ von Dave Zwieback hab und der beschreibt letztendlich damit, wie so was funktionieren könnte.

Alex: [00:33:47.78] Okay, was ist das Ziel von diesem Learning Review Framework?

Matthias: [00:33:52.71] Als würde man sagen genau das, worüber wir gerade die ganze Zeit reden, also wie man aus solchen Situationen lernen kann, ohne Schuldige zu suchen bzw. ohne ja eben zum Beispiel mit diesen kontrafaktischen Aussagen das Ganze zu verzerren, sondern wirklich halt zu verstehen, was ist passiert? Warum ist es so passiert, wie es passiert ist? Und – Wie kann man in Zukunft das anders machen? Mal ganz kurz zusammengefasst

Alex: [00:34:30.77] Also Problemklärung, Lösungsfindung und nicht Schuldzuweisungen.

Matthias: [00:34:34.55] Genau.

Alex: [00:34:34.55] Ja, das klingt schon mal gut. Will sagen eine gute Sache. Wie funktioniert das? Kannst du dich mal kurz vorstellen?

Matthias: [00:34:44.31] Naja, also in dem Beispiel, das in dem Buch bringt. Es ist halt quasi so, dass es ein auch ein Meeting gibt in Anführungszeichen, in dem man versucht eben diese ganze Geschichte zu rekonstruieren. Also er benutzt dafür eine sogenannte Timeline, wo dann im Prinzip chronologisch geordnet einfach gesagt wird, was ist zu welchem Zeitpunkt passiert? Wann hat man wie gehandelt? Welche Auswirkungen hat das gehabt und versucht eben so diesen gesamten Ablauf von dieser Problemsituation darzustellen.

Alex: [00:35:23.81] Also es wird eine Timeline erstellt, hab ich dich richtig verstanden?

Matthias: [00:35:27.95] Genau. Also das kann man sich wahrscheinlich auf einem Board einfach vorstellen und ein Zeitstrahl und du machst Striche wo du sagst das es ich 18 Uhr: „Alex hat auf den deploy-Knopf gedrückt“.

Alex: [00:35:42.71] Neein. Warum hat er das gemacht?

Matthias: [00:35:46.31] Ja, die Frage, die stellen wir jetzt an der Stelle nicht. Sondern was ist dann passiert? Also zum Beispiel keine Ahnung. Zur Hälfte des Deployment hat aus welchem Grund auch immer der Server rebootet und deswegen ist zum Beispiel ein halbes Release nur deployt worden. So, des könnte so so eine Feststellung sein. Und dann: was hat Alex als nächstes gemacht? Also was hat.

Alex: [00:36:16.01] Natürlich ist er nach Hause gegangen.

Matthias: [00:36:18.67] Natürlich. Nein. Aber. Und so versucht man halt im Prinzip auf diesen Zeitstrahl zu erfassen, was zu welchem Zeitpunkt passiert ist. Und man versucht natürlich da auch Dinge zu ermitteln, die man in Zukunft eben anders machen könnte. Also da kann man ja dann natürlich auch ein bisschen, wie soll man sagen, rückblickend betrachten. Also das, was wir mit diesen kontrafaktischen Aussagen ja eigentlich verhindern wollen. Also von wegen, hättest du mal das und das gemacht. Aber man kann das ja durchaus trotzdem, als wenn man es hat ich ja vorhin auch schon mal gesagt, man es ein bisschen anders formuliert, kann es ja durchaus auch etwas sein, das in Zukunft zu einer Verbesserung führen kann. Also keine Ahnung. Jetzt auf das Beispiel von eben bezogen. Eventuell müssen wir vor jedem Release in Zukunft gucken, ob gerade Server neu gestartet werden oder so Nee, also jetzt mal ganz blöd gesagt.

Alex: [00:37:14.18] Vor allem ich finde, für diese Timeline ist es wichtig, nicht nur die eine Person zu fragen. In diesem Fall Alex hat der Server zusammengeschossen, also muss Alex die Timeline voll kriegen, sondern auch andere Menschen, die im Prozess beteiligt sind. Zum Beispiel. DevOps-Leute, die die Infrastruktur betreuen. Wie hat sich das Problem bemerkbar bemerkbar gemacht? Haben irgendwelche sind irgendwelche Service Fälle aufgetreten? Konnten die Leute nicht mehr mit dem Server arbeiten? Was ist da passiert?

Matthias: [00:37:46.85] Genau. Also zum Beispiel aus welchem Grund hat der Server werdenden Deployment neu gestartet? Also das ist ja auch eine wichtige Information.

Alex: [00:37:55.91] Also all diese Informationen in eine Timeline zu sammeln ist der erste Schritt. Ja gut. Und dann eben wie du gesagt hast, diese Möglichkeiten zu finden, an denen wir Verbesserungsvorschläge herausarbeiten können. Und natürlich muss man sie dann auch priorisieren. Was erwarten wir uns mit dem wenigsten Arbeit am meisten nutzen. Und das kann man dann versuchen zu zu bringen.

Matthias: [00:38:24.32] Genau. Und was halt auch noch ganz wichtig ist bei so einem Meeting, wenn man so etwas durchführen will, ist halt eben, dass man am Anfang von diesem Meeting gewisse Sachen klar macht. Nämlich unter anderem eben, dass es nicht um die Schuldfrage gehen soll, sondern um die Frage, wie man in Zukunft verhindern kann, dass dieses Problem, das man gerade betrachtet, wieder passiert.

Alex: [00:38:52.28] Das ist so ein bisschen abhängig von Unternehmenskultur. Wenn ich Angst um meinen Job haben muss oder um mein Ansehen im Unternehmen haben muss, wenn ich irgendwas sage, dann werde ich es nicht sagen wahrscheinlich. Also von daher es geht auch ein bisschen darüber. Diese Unternehmenskultur zu verändern, so dass man keine Angst haben muss, zu sagen, was Sache ist, ohne dass irgendwelche Repressalien kommen oder man an Ansehen verliert oder was auch immer. Wenn man diese Kultur halt mal etablieren kann und das passiert natürlich nicht von heute auf morgen. Aber wenn man diese Art von Kultur etablieren kann, dann ist es sehr vorteilhaft, weil diese Timeline wirklich dann ordentlich gefüllt werden kann, weil keine hinterm Berg hält mit irgendwelche Probleme. Das ist keine Ahnung. Als ich die deployt habe der Server wurde zerschossen und keiner hatte mit einem Sterbenswörtchen erwähnt, das einen Tag zuvor die Serverversion und upgedated wurde. Ja, so als Beispiel. Das könnte auch ein Problem gewesen sein. Wenn wir es wissen, können wir das analysieren, wenn keiner sich meldet, um das zu wissen und um das zu sagen. Wie soll man daraus was lernen?

Matthias: [00:40:09.59] Genau. Vor allem wenn man ja den Schuldigen schon gefunden hat. Weil Alex hat ja deployt.

Alex: [00:40:15.89] Genau – danke!

Matthias: [00:40:20.18] Nein, aber das ist dann genau der Punkt. Also warum sollte doch jemand hinter einem Berg hervorkommen, wenn es ja schon einen Schuldigen gibt? Also wenn man sich jetzt wiederum in so einer Unternehmenskultur befindet. Das ist halt leider dann immer auch ein bisschen das Problem. Das sieht ja dann auch niemand die Notwendigkeit was zu sagen und das soll halt in so einem Meeting genau andersherum sein. Also hier ist es eben genau wichtig, dass eben alle Fakten auf den Tisch kommen. Und wie Alex gerade auch schon gesagt hat, die Tatsache, dass zum Beispiel eine Server-Version sich verändert hat, ihm am Vortag oder am gleichen Tag oder vielleicht ja sogar zeitgleich. Aber das sieht man ja dann an der Timeline. Wann hat sich die Server Version verändert? Dass solche Fakten ausgesprochen werden können. Das ist halt so der zentrale Punkt bei der ganzen Geschichte.

Alex: [00:41:11.99] Ja und auch ein sehr wichtiger Punkt finde ich von diese Methode ist offen und transparent mit dem Ergebnisse umgehen, so dass nicht im dunklen Kämmerlein alles gucken, machen, sondern das auch veröffentlichen, zeigen was passiert ist, warum es passiert ist, welche Maßnahmen ergriffen werden können oder ergriffen werden. Welche Experimente wagen wir? Welche Verfahren ändern sich vielleicht im Unternehmen? Also all das ist auch ein wichtiger Bestandteil. Aber wie du gesagt hast, ich denke, das Wichtigste von allen ist tatsächlich, den Leuten die Angst wegzunehmen. Sich hinzustellen und Probleme anzusprechen.

Matthias: [00:41:57.95] Ja, und auch Verantwortung für ihr Handeln übernehmen können, ohne extreme Konsequenzen

Alex: [00:42:07.76] Auspeitschungen zu fürchten.

Matthias: [00:42:09.38] Weil das muss man ja auch mal sagen, niemand macht ja absichtlich Fehler, also hoffe ich zumindest, sondern das passiert aus anderen Gründen, nicht aus Böswilligkeit oder Absicht. Und deswegen sollte man auch die Möglichkeit haben, diese Fehler zu diesen Fehlern stehen zu können, ohne Konsequenzen fürchten zu müssen. Das finde ich, ist irgendwie für mich so der zentrale Punkt. Also ich habe kein Problem damit einzugestehen, wenn ich was, wenn ich einen Fehler oder ein Problem verursacht habe. Aus welchem Grund auch immer. Aber klar ist halt trotzdem Ich habe das ja nicht mit Absicht gemacht.

Alex: [00:42:56.16] Und nichtsdestotrotz bedeutet das nicht, dass Taten keine Konsequenzen mehr haben.

Matthias: [00:43:01.79] Nee, gar nicht.

Alex: [00:43:03.89] Nein, natürlich nicht. Aber wenn man diese Angst wegkriegen kann oder wegkriegt, ist die Möglichkeit zu lernen und Problemen zu lösen, in meinen Augen deutlich höher.

Matthias: [00:43:19.40] Ja. Und damit sind wir am Ende dieser Folge angekommen.

Alex: [00:43:24.90] Du hast heute viel über Schuld und Verantwortung gehört.

Matthias: [00:43:28.56] Wir hoffen, du bewegst dich bereits in einem Umfeld, das ohne Schuldzuweisungen auskommt.

Alex: [00:43:32.97] Aber falls nicht, kannst du diese Folge gern weiterempfehlen.

Matthias: [00:43:37.11] Damit du auch in Zukunft keine Folge verpasst, kannst du einfach unter dem Podcast abonnieren.

Alex: [00:43:41.67] Wenn du schon immer mal wissen wolltest, was es mit einem Popcorn Board auf sich hat, dann hör einfach beim nächsten Mal wieder rein. Bis dann.

Matthias: [00:43:52.53] Bis dann.

off: [00:43:55.31] Die Macht der Craft arbeitet für dich.