# Modern Software Architecture: From Authority to Facilitation

**Podcast:** INNOQ Podcast
**Published:** 2026-04-13

## Transcript

Hallo und herzlich willkommen zu einer neuen Episode vom InnoQ Podcast.
Heute lang ersehnte Folge mit Holger Kraus.
Hi Holger, wie geht's?
Hallo Sven, mir geht's sehr gut.
Ich freue mich auf diesen Podcast.
Ja.
Was machst du eigentlich so bei InnoQ?
Vielleicht mal so als Selbstvorstellung.
Was mache ich bei InnoQ?
Also ich mache schon sehr lange bei InnoQ-Dingen.
Also bin schon seit 2010, glaube ich, bei InnoQ, also jetzt schon 16 Jahre und war so in verschiedenen Rollen in Projekten am Anfang ganz viel als Entwickler.
Dann habe ich in verschiedenen Rollen, äh, in verschiedenen Projekten eine Architektenrolle übernommen.
Und jetzt habe ich dann in den letzten zwei Jahren das InnoQ Lab geleitet.
Das ist so unsere interne Organisationseinheit, die unsere internen Projekte durchgeführt hat.
Ja, und auf jeden Fall, also wir waren ja auch mal in einem Projekt, zumindest bei einem Kunden zusammen.
Da war auf jeden Fall ein ziemlich beeindruckendes, was ziemlich beeinflussen Projekt in China, der Architect.
Also, vielleicht kommen wir darauf auch nochmal zurück.
Also, da muss ich sagen, ich war tief beeindruckt.
Genau.
Worüber reden wir denn heute?
Du hast einen Artikel geschrieben, den hängen wir auch in die Shownotes, und der heißt Jeder kann Architect sein.
Also im Prinzip so eine, wie bildet man eigentlich so eine so eine Ramp für, ich sage mal, Leute, die Interesse an Architektur haben.
Darüber würde ich sprechen.
Der Artikel hat ziemlich viel Ähnlichkeit mit dem Buch von Andrew Harmel Law, Facilitating Software Architecture.
Wenn man auch ab und zu mal so ein paar, wenn man vielleicht darauf nochmal zurückkommen.
Aber so ein paar Dinge, die sind dann doch anders als bei Andrew.
Zum einen, unser Kontext ist ein bisschen anders als bei ihm.
Und das finde ich, also das ist das, was mich sozusagen am heißesten macht für diese, warum ich diesem Podcast so lange hinterhergerannt bin.
Du hast auch eine Facilitator-Ausbildung gemacht.
Und da, das bringt, glaube ich, nochmal ganz andere Sicht rein und andere Möglichkeiten.
Also, ich habe, ich sag mal, von dir schon einen Haufen geklaut und wahrscheinlich falsch angewendet, aber das hat trotzdem sehr viel genutzt.
Genau.
Gut, würde ich sagen.
Du hast ja gesagt, du warst Entwickler, und dann hast du Zweifel gehabt.
Also hast du gesagt, Zweifel gehabt, als du diese Architektenrolle übernehmen solltest.
Weil ich verstehen kann.
Also, also ich weiß nicht, ob das, also zumindest dieses China-Projekt, da wäre mir, hätte ich ganz schön Schiss gehabt, ja, das hat sich ziemlich kompliziert angehört.
Aber dann bist du eigentlich, dann liefert dann eigentlich ganz ganz gut, sag ich mal so.
Wie kam es eigentlich dazu?
Also, was war dein Ursprungsbild von der Architektenrolle und wie hast du das nochmal so grundlegend überdacht?
Also das Interessante ist tatsächlich, dass die Fragen, die ich mir in diesem Artikel gestellt habe, gar nicht die Fragen waren, die mich zum Beispiel zu Beginn dieses China-Projekts stark beschäftigt haben, weil das aus meiner Sicht den Vorteil hatte, dass da viel klarer war, was eigentlich von mir erwartet wird.
Also, da ging es halt konkret darum, dass halt, dass wir eine Plattform, die schon in Europa lief, nach China bringen sollten.
Und das war eine Plattform, die aus vielen Self-Contained Systems bestand.
Und die Herausforderung war halt, dass wir für eine Domäne ein Self-Contained System brauchten, was von einem chinesischen Dienstleister entwickelt werden musste, weil es halt einfach auf den chinesischen Markt angepasst sein wird.
Und mein Job war da quasi so dem Team dabei zu helfen, zu verstehen, was sie da technisch bauen müssen.
Ich sage mal, da war für mich so im Kopf klar, ich bin halt der Typ, der jetzt irgendwie weiß, was Self-Contained Systems sind.
Und hab halt angenommen, das kennt man jetzt in China wahrscheinlich noch nicht so gut.
Mittlerweile würde ich sagen, hat sich das geändert.
Genau, also ich hatte da so quasi das Expertentum, was ich dachte, was man in der Rolle auch braucht.
Also, dass ich da klar sagen kann, bitte macht Dinge so oder so.
Und also die Fragen, die ich mir dann stellte im Zusammenhang mit dieser Architektenrolle, die ich in dem Artikel dann thematisiere, war halt dann, sollte ich halt dann irgendwann nach diesem Projekt für denselben Kunden Architekt für ein Self-Contained System oder für eine Vertikale auf der europäischen Plattform sein, was zu, ich weiß gar nicht mehr genau, ich glaube 90% aus Innoculan bestand.
Und also da konnte ich jetzt mein Selbstverständnis nicht daher davon ableiten, dass ich sagen konnte, ich bin jetzt der Typ, der Self-Contained Systems kennt.
Und irgendwie alles viel besser weißt als der Rest.
Und ich sage mal, ich glaube, uns Innoculateilt eine Erfahrung, wenn wir neu bei InnoQ anfangen, dass wir dann alle erstmal denken, oh Gott, sind die alle schlau hier.
Und man wird innerlich erstmal klein und traut sich nichts mehr.
Und dann merkt man dann, dass es auch nur Menschen sind.
So, aber ich sage mal so, die Rolle jetzt da jemand zu sein, der jetzt irgendwie dem Team sagt, was sie technisch tun sollen, quasi so als Alleinentscheider, mit der Rolle habe ich mich nicht wohl gefühlt.
Und das hat mich halt schon dann viel Überwindung gekostet, quasi diesen Job dann auch anzutreten.
Aber ich habe tatsächlich dann einfach vertraut darauf, dass ich während der Arbeit dann schon irgendwann feststellen werde, wann wird denn jetzt wirklich ein Architekt gebraucht.
Und das habe ich in dem Artikel eigentlich dargelegt, genau.
Ja, ich denke das auch.
Also, es ist auch schwierig, ne?
Du kommst, ich sag mal, wenn du so in diese, wenn ich jemand nach dieser Rolle fragt und man hofft ja immer, dass man ziemlich gute Leute im Team hat.
Und man weiß ja auch, ja, die kennen, also diese Person kennt sich da auf jeden Fall viel besser auf.
Aber es ist ein ziemlich hoher Druck, finde ich auch.
Weil man denke jetzt so, oh, ich stehe jetzt hier im Wind, ne?
Aber da gibt es einen Haufen Leute, die können eigentlich viele Sachen besser wie ich, ja.
Genau, aber du sagst, ja, ich habe, dass du gesagt hast, das wird schon irgendwie, ne?
Wie wurde das denn irgendwie?
Also, du bist dann da losgelaufen, und ich sag mal, das geht ja sowas wie, was jedem First Timer, also du warst da kein First Timer mehr, aber viele Leute, die jetzt zum ersten Mal so eine Rolle haben, sind natürlich schon unter Druck, ja.
Und wie lief das da für dich?
Also, du hast das ja praktisch neu überdacht, ja.
Was waren da so Auslöser?
Ja, ich habe einfach, also ich war halt erstmal dabei, habe mir so angeschaut, was musste eigentlich entwickelt werden.
Und hab halt auch mir angeschaut, an welchen Punkten wissen wir als Team eigentlich noch nicht, was wir bauen.
Hab dann versucht, diese Dinge zu klären und auch aufzuschreiben und abzustimmen.
Und ich sag mal, mir sind dann zunehmend so im Alltag immer mehr Situationen aufgefallen, wo ich gemerkt habe, so im Daily Entwickler berichten von ihrer aktuellen Story, die sie gerade bearbeiten und stellen sich während der Arbeit Fragen und wissen nicht so richtig, was jetzt das beste Vorgehen da wäre.
Und da habe ich dann irgendwann gemerkt, eigentlich ist das genau der Punkt, wo ich jetzt gebraucht werde.
Nämlich quasi zu sagen, ich glaube, wir brauchen hier eine Entscheidung als Team.
Lass uns das doch mal zusammen angucken.
Und das ist dann das, wo ich dann auch in dem Artikel darauf eingehe, dass ich mich dann halt als Gastgeber einer Entscheidung wahrnehme.
Also quasi wahrnehmen, hier wird eine Entscheidung gebraucht.
Oh, jetzt müssen wir mal Raum schaffen und jetzt stelle ich mal ein Meeting ein und überlege ich mir, wie wir in diesem Meeting vorgehen und genau, dass dann im Grunde den Leuten, die es gerade entwickelt, den Raum dann zu einer vernünftigen Entscheidung zu kommen, genau.
Also im Grunde genommen anders wie ich sag mal, das alte Führungsbild, mit Architektenklische, dass man sozusagen, dass eine Person die Entscheidung treffen muss.
Genau, also so als Schlüsselelement habe ich tatsächlich empfunden, ist so diesen dieses Gespür dazu, für zu entwickeln, hier schwebt gerade eine nicht getroffene Entscheidung.
Okay.
Da dann quasi derjenige zu sein, der den Weg dafür frei macht, dass das getan werden kann.
Ja, jetzt, wir hatten ja den Andrew, ich hatte den Andrew Harmel Law erwähnt.
Ich würde sein Buch auf jeden Fall auch in die Shownotes packen.
Also, ich finde, das Buch ist am Anfang ein bisschen komisch in Anführungszeichen, weil er einfach in einem anderen Kontext unterwegs ist.
Also ist wirklich in diesem Kontext autoritäres Architekt gleich autoritäres Führungsführungsperson.
Das ist bei uns eigentlich nie so.
Aber dann finde ich, hat er wirklich so ein sehr gut beschrieben, wie so ein, wie man sozusagen gemeinsam zu einer sehr guten Entscheidung kommt.
Muss man natürlich sagen, unsere Erlebnisse, die waren, die waren vor der Buchpublikation, aber er hat es halt, er hat es zumindest mal aufgeschrieben, damals als Buch.
Wie, wie schaffst du denn diesen Raum?
Also, wie kann ich jetzt in, wie kann ich denn so ein Raum schaffen und wie kann ich eine gute Entscheidung hervorrufen.
Genau.
Da gehe ich ja auch in einem Artikel drauf ein.
Also, da steht für mich halt der architektischer Decision-Record so im Zentrum als Struktur.
Und der gibt auch eine gewisse Struktur vor.
Und also, wenn ich jetzt zum Beispiel so eine Besprechung ansetze mit den Leuten, die ich für eine Entscheidung brauche, dann finde ich zum Beispiel einen ganz wichtigen Punkt, dass man zuerst mal Einigkeit erzielt, welches Problem wollen wir eigentlich lösen.
Weil da kommt oft schon dann so zum Ausdruck, dass eigentlich gerade jeder ganz unterschiedliche Dinge unter dem versteht, was wir eigentlich lösen wollen.
Da finde ich tatsächlich sehr fruchtbar, wenn man dann irgendwann feststellt.
So, jetzt haben wir uns auf eine Definition geeinigt und jetzt wissen wir auch, worüber wir gerade reden.
Genau.
So, und einen wichtigen Punkt habe ich jetzt gerade vergessen, weil ich gerade in diesem Teamkontext gedanklich unterwegs war.
Also eigentlich ist der wichtigste Punkt am Anfang erstmal zu überlegen, wer sind die Stakeholder?
Also, also wer ist von der Entscheidung wirklich betroffen?
Vielleicht nochmal ganz kurz zurück, ne, weil du hast ADR gesagt.
Wir können gar nicht davon ausgehen, dass jeder weiß, was ein ADR ist.
Vielleicht, genau, wir gehen jetzt nochmal, wir gehen jetzt sozusagen Stück für Stück durch die durch so ein ADR-Aufbau durch.
Weil auch gesagt, das ist der Prozess, genau.
Also wer sind die Betroffenen da bei mir stehen.
Ja, beziehungsweise nicht nur die Betroffenen, sondern auch eventuell Experten, die sich gerade zu dem Thema, was wir bearbeiten, besonders gut auskennen.
Und da muss ich halt auch irgendwie einen Weg finden, diese Stakeholder halt irgendwie in den Prozess mit zu integrieren.
Und das kann halt sehr unterschiedlich sein, weil ich würde halt so Sachen, die jetzt das Team betreffen, in dem ich gerade unterwegs bin, schon ein bisschen anders beurteilen, als jetzt was, als eine Entscheidung, die jetzt vielleicht meine Systemgrenzen so überragt.
So, also ich finde da immer den so die Unterscheidung von Mikro und Makroarchitektur immer eine sehr wichtige Also Mikroarchitektur, also das kommt auch aus diesem Self-Contained Systems Kontext.
Mikroarchitektur ist quasi das, was ich innerhalb meines Systems tue, wo im Grunde die Owner von diesem System auch eigentlich frei sind, Entscheidungen zu treffen, von denen sie überzeugt sind, dass sie die Ziele, die dieses System erfüllen soll, quasi auch erreichen können.
Das ist halt so, keine Ahnung, welche Datenbank ist vielleicht für meine Business-Domaine gerade, wie schneide ich meine Komponenten und sowas.
Und dann gibt es halt diese Makroarchitekture-Ebene, wo man überhaupt Einigkeit darüber erzielen muss.
Wie läuft die Kommunikation zwischen diesen Systemen?
Also zum Beispiel in dem Self-Context Systems-Kontext ist ja auch so dieses Element, dass man zum Beispiel möglichst aufeinander nur über asynchrone Mechanismen kommuniziert, damit man zum Beispiel halt nicht irgendwie so ein System hat, was zum Bottleneck wird, was dann zum Beispiel, wenn das nicht verfügbar ist, alle anderen irgendwie mit runterreißt.
Das sind so Architekturentscheidungen auf dieser Makroarchitekturebene und das würde ich halt zum Beispiel grundsätzlich auch anders dann so einen Entscheidungsprozess gestalten.
Ja, also ich habe gerade nochmal so eine Situation, ja, wo sehr viele Teams involviert sind.
Also im Grunde genommen, wir benutzen diesen Begriff Makroarchitektur nur spärlich, muss ich dazu sagen.
Aber die, wenn es sozusagen auf Mikroarchitekture-Ebene ist, da reicht es eigentlich, dass du die Leute, also die Teammitglieder sind die Betroffenen, und wir laden noch Experten ein, wenn wir zum Beispiel so ein Security-Thema haben und uns jetzt so gut mit Security auskennen, zum Beispiel.
Und aber auf Makro-Ebene, dann würdest du praktisch alle Stakeholder-Gruppen einladen.
Also wenn da zehn Teams sind und du hast so eine Makro-Entscheidung, dann müsst praktisch aus jedem Team jemand dabei sein.
Also da finde ich tatsächlich die entscheidende Frage erstmal, was gibt es denn schon in dem Kontext, in dem ich mich da bewege.
Also normalerweise kommen wir ja irgendwo hin und dann gibt es schon irgendeine Architektur und da wird sich irgendwann mal jemand überlegt haben, wir wollen gerne Self-Contained Systems als unsere Architektur verwenden.
So.
Und dann ist die Frage, ob die schon irgendwie eventuell irgendein Entscheidigungsgremium geschaffen haben, über den wir besprechen.
Und deshalb finde ich halt auch, man kann da, also ich möchte da gar keine allgemeinen Empfehlungen gegeben.
Oder ich will auch gar nicht sagen, ich mache das allgemein so oder so, sondern ich muss mir halt schon genau angucken, in welchem Kontext ich mich da gerade bewege.
Und quasi da die angemessene Lösung finden.
Aber wichtig ist, dass ich derjenige bin, der sieht, ich glaube, wir haben hier eine Entscheidungslücke und wir müssen da mal irgendwie einen Prozess initiieren.
Dann möglichst versuche, den zu organisieren.
Wenn es noch keine Instanz gibt, die das vielleicht schon tun könnte.
Also zum Beispiel könnte das sein, indem ich mich mit meinem Team zusammen hinsetze und ein ADR schreibe, der quasi erstmal so ein Vorschlagscharakter hat.
Also wir analysieren zusammen das Problem und sagen, das ist unsere Sichtweise und dann kann man das halt ins Wiki stellen und dann spricht man gezielt Leute an und bittet um Feedback.
Wir sollten vielleicht, bevor wir weitermachen, nochmal den Überblick über den über so ein ADR abschließen, damit, also du hast, also wir haben ein Problemkontext, also welches Problem wollen wir lösen, das hatten wir.
Wir hatten die Stakeholder, also alle Leute, die irgendwie Interesse haben, betroffen sind oder was beitragen können.
Was ist noch Teil von so einem Architecture Decision Record?
Das wird man nochmal so kurz.
Genau, also wie gesagt, am Anfang wichtig zu erstmal eine Einigung darüber herstellen, was ist das Problem, was wir lösen wollen.
Für mich gehört auch noch dazu, den Kontext zu beschreiben, in dem diese Entscheidung stattfindet.
Also Tragweite, was sind so Faktoren, die diese Entscheidung beeinflussen.
Aber auch schon mal sich Gedanken zu machen, anhand welcher Kriterien wollen wir denn eigentlich bewerten, ob das, was wir uns jetzt überlegt haben, eine geeignete Lösung ist.
So, und dann kommt halt der spannende Schritt des, das beschreibt der Andrew auch halt in seinem Buch, das Option Making.
Also dass man sich halt wirklich überlegt, welche Optionen habe ich denn, um dieses Problem zu lösen.
Ich finde das auch natürlich der interessante Teil.
Wir gucken, wenn wir später auf Code gucken, sehen wir immer nur die implementierte Option, aber wir wissen nicht, welche anderen Optionen gab es eigentlich und warum haben wir uns für diese Option entschieden.
Das ist ja schon ein guter Teil, ja.
Genau, wir haben die Optionen und dann irgendwann müssen wir nochmal entscheiden.
Kannst du nochmal so ein Beispiel für Kriterien nennen?
Weil, also wo kommt die, wo kommt es meine Frage her?
Weil ganz oft sieht man ja so, wenn man ADRs einführt, dass immer die Option gewählt wird, die am meisten grün Pluspunkte hat.
Und nicht am wenigsten Minus, aber das kann man so eigentlich, man kann nicht einfach nur Plus und Minus zählen, sondern es kommt halt wirklich auf die auf die Kriterien an.
Und hättest du mal da so ein paar Beispiele für ein Kriterium?
Das fällt mir tatsächlich schwer, das jetzt einfach aus dem Ärmel zu schütteln.
Okay, okay.
Also, was mir so spontan einfällt, wäre, das wäre aber auch tatsächlich eher schon was wieder auf so einer Makroarchitekturebene.
Also Mikroarchitekturentscheidungen sind ja dann sehr spezifisch teilweise.
Zum Beispiel, wie kann ich es hinkriegen, dass meine Gesamtplattform möglichst stabil läuft und ich unnötige Abhängigkeiten vermeide?
Oder wie kann ich es, das sind es jetzt eigentlich eher Fragen, aber das kann man auch als Kriterium formulieren.
Ja, klar, ja.
Oder ich möchte bestimmte Domain unabhängig von anderen skalieren können.
Ja.
Das wäre ein Kriterium zum Beispiel.
Genau, dann werden halt die einzelnen Optionen bewertet.
Die Frage ist: Also jetzt haben wir diesen ADR, den haben wir schriftlich.
Wir können über diesem Dokument brüten.
Die, wenn man die Stakeholder.
Was ich auch interessant finde, ist, wie schaffst du es, Optionen zu generieren?
Weil du sagst ja, du bist ja gegebenenfalls gar nichts, also du willst das ja gar nicht alleine machen, du sollst, du machst das im Team.
Gibt es irgendwelche besonderen Facilitator-Kniffe, jenseits von, naja, wir müssen jetzt mal über Optionen nachdenken.
Es gibt keine besondere Kniffe.
Okay.
Also, ich würde sagen, der wichtigste Kniff ist, dass man sich nicht sofort auf eine Option stürzt.
Also, das kennen wir alle, ne?
Jeder hat mal irgendwie ein neues Lieblingsframework und möchte das eigentlich gerne mal ausprobieren, aber da ist dann primär irgendwie so die Lust, das ausprobieren zu wollen, der wichtigste Faktor und nicht so ein klares inhaltliches Kriterium.
Und dann hilft es halt schon, wenn man sagt, okay, ich verstehe jetzt deinen Beweggrund dafür, aber gibt es denn vielleicht Alternativen?
Und dann merkt man dann dabei vielleicht auch, dass es einfach also das ist dann, also ich manchmal entwickeln sich dann auch noch zusätzliche Kriterien, weil man dann sieht, eine andere Lösung hat eigentlich einen ganz anderen Charakter und das schärft dann quasi auch nochmal die Bewertungskriterien.
Ja, also tatsächlich den Raum, diese Option zu bilden, nicht zu früh zu schließen.
Ja.
Nee, also das ist mir tatsächlich eben vor zwei Stunden auch aufgefallen.
Also, wir hatten gestern wir Lösungsoptionen für einen Problem diskutiert, ja.
Und da habe ich gesagt, okay, wir haben das jetzt besprochen und ich kippe die in Text.
Und beim Schreiben mit einem Kollegen ist dann irgendwie aufgefallen, und als wir nochmal danach diskutiert haben, es gibt ja eigentlich noch andere Möglichkeiten.
Keine Ahnung, warum wir da, also noch andere Optionen, die völlig valide sind, müssen wir noch mit aufnehmen, ja.
Also ich gebe dir auf jeden Fall recht, dass man nicht zu früh schließen sollte.
Ja, also ich finde in heutiger Zeit kann man natürlich auch KI irgendwie bemühen, ne?
Einfach mal gucken, was da für Vorschläge so kommen.
Oder davor hat man halt einfach mal eine Internetrecherche gemacht.
Gibt es Produkte, die dieses Problem schon lösen.
Ein bisschen recherchieren gehört dann halt auch dazu.
Oder die entsprechenden Experten-Interviewen.
Ja, also die, genau.
Das sowieso, weil die können auf jeden Fall nochmal, also wenn wir keine Experten sind, dann wird es dann ist immer die Gefahr, dass wir, dass wir naive Optionen aussuchen.
Ja, jetzt muss ich sagen, ich war immer aus meiner Sicht, hat es ganz, ich sag mal, hat es ganz gut funktioniert, dass ich bis hierhin gut unterwegs bin.
Also ich kann Leute, ich weiß, wenig einladen muss ich weiß wie ich die Kriterien definiere ich komme eigentlich auch ganz gut auf Optionen zusammen mit einem Team aber jetzt müssen wir irgendwie entscheiden und müssen die Leute mitnehmen also teilweise mitnehmen also wir wollen eigentlich gemeinsam entscheiden und das hat das schwieriger als man denkt also das müssen wir für mich habe ich auch ein bisschen von dir geklaut als du mal von deiner Facilitator Ausbildung erzählt hast und vielleicht also deswegen ich würde noch einmal ganz kurz fragen wie du überhaupt diese Facilitator Ausbildung gemacht hast was da drin vorkommt und dann würde ich nochmal auf die Entscheidungsfindung kommen, ja, sozusagen Personal Consulting von dir, wie man das vielleicht nutzen kann.
Also du hast halt eine Weiterbildung in Facilitation gemacht und wie, also erstmal vielleicht, wieso kam es eigentlich dazu?
Und was war die Motivation?
Also die Motivation war tatsächlich.
Also, also ich habe irgendwann mal, ich weiß gar nicht mehr genau an welchem.
Ich glaube auch durch die.
Also, ich habe die Ausbildung bei den Kommunikationslotsen in Köln gemacht, die ich sehr empfehlen kann.
Und die haben auch lange so eine Sparte Visual Facilitation gehabt.
Bicablo mag dem einen oder anderen was sagen.
Das sind so halt, ne, so Meetings visualisieren mit einfachen grafischen Elementen, die man lernen kann.
Und dann haben selbst Leute, die immer von sich dachten, ich kann nicht malen, haben irgendwie plötzlich ein Handwerkzeug an der Hand, mit dem sie irgendwie doch erstaunliche Bilder kreieren können.
Und so zum Beispiel für Klarheit in Meetings sorgen können.
Und wir haben bei der InnoQ tatsächlich mal so Schulungen angeboten zu Bicablo, die von den Kommunikationslotsen durchgeführt wurden.
Und da bin ich das erste Mal mit denen in Kontakt gekommen und habe dann auch noch bei irgendwelchen anderen Veranstaltungen von denen mal teilgenommen und fand das immer einen sehr interessanten Ansatz, den die so verfolgt haben.
Und fand es einfach super interessant.
Und genau.
Also schreibe ich auch im Artikel, also als ich mich da angemeldet habe, war mir tatsächlich nicht völlig klar, ob ich das, was ich da lerne, eins zu eins in meinem beruflichen Alltag umsetzen kann.
Okay, okay.
Aber ich habe gedacht, du hättest hättest das so tatsächlich gezielt rausgesucht.
Aber es war dann eher so.
Mir gefällt, was die tun.
Da kann ich nicht mehr.
Nee, genau.
Ich würde sagen, da ist einfach das passende Angebot um die Ecke gekommen und habe mich angesprochen.
Ja.
Ich kann mich erinnern an dieses Picablo.
Ich weiß gar nicht, warum ich da nicht dabei war.
Ich würde so sagen, es ereilte mich der Ruf und ich bin ihm gefolgt.
Ja.
Ja, ich finde, also die Fähigkeit, so Klarheit in so Meetings herbeizuführen und Struktur reinzubringen, ist auf jeden Fall was, was ich auch noch auf der Suche bin.
Was ich gerne noch betonen möchte, weil du dich gerade an dieser Struktur so festgebissen hast, mir geht es nicht darum, hier irgendwie so einen Rezept zu predigen, ne?
Der Punkt, der mir wichtig ist, ist halt, dass ich mich als Architekt in der Rolle sehe, Entscheidungen zu organisieren.
Und dafür zu sorgen, dass die richtigen Leute miteinander reden.
Und dass am Ende dann eine gute Entscheidung dabei rauskommt.
Und ob jetzt zum Beispiel diese Struktur die absolut beste der Welt ist, das würde ich gar nicht noch nicht mal behaupten.
Ich habe jetzt das Gefühl, das machen viele andere auch so.
Nicht totaler Blödsinn sein.
Nee, genau.
Aber wenn ihr zum Beispiel ein Team sagt, irgendwie finden wir das nicht so ideal, kann man das nicht irgendwie anders machen.
Also es muss halt auch zu dem Team passen.
Ja, stimmt.
Also ich arbeite zum Beispiel mit ziemlich vielen unterschiedlichen Teams und versuche die da zu unterstützen.
Und also Teams sind halt einfach unterschiedlich, ja.
Aber ich hätte jetzt trotzdem gedacht, du hast ja wahrscheinlich einen Methodenkoffer.
So wie es so schön heißt.
Also du kannst wahrscheinlich relativ einfach dich anpassen, wobei ich immer so das Gefühl habe, ich muss noch mehr an meinem Methodenkoffer arbeiten.
Wie gesagt, deswegen interessiert mich ja auch die Dinge, die du da, die du da gelernt hast, ja, in der Facilitator-Ausbildung.
Also gibt es irgendwelche Eckpunkte, wo du sagst, ja, das sind so, das sind so Key Learnings oder interessante interessante Bausteine, die man nutzen kann, um das so zu organisieren, dass wir zu einer guten Entscheidung kommen mit den richtigen Leuten.
Also das erwähne ich auch in dem Artikel.
Also der Punkt ist, das wichtigste Learning für mich war nicht, dass ich da jetzt einen zauberhaften Methodenkoffer mitkriegte.
Sondern wirklich eher so dieser Aspekt Facilitative Thinking.
Also eher so mein Blick, wie ich auf so eine Gruppe gucke.
Das finde ich den viel entscheidenden Aspekt.
Wie guckt man auf so eine Gruppe?
Mit welchem Blick oder mit welcher Blicke.
Ja, vor allen Dingen, also ich weiß nicht, ob.
Also ich wichtige Aspekt war ja noch das Thema Grundannahmen.
Ich glaube, da wolltest auch später nochmal drüber reden.
Also eigentlich habe ich das vorher gehabt, aber ja, wir können direkt darauf umschwenken.
Also, wenn du den Umweg, also wenn du erst über Grundannahmen reden willst, dann können wir das direkt jetzt machen, ja.
Ja, das war für mich halt schon so eines der wichtigsten AH-Erlebnisse eigentlich.
Das zu verstehen und wie einen das selber prägt und wie ich durch die Veränderung von Grundannahmen tatsächlich Veränderungen bewirken kann.
Ja, aber was ist eine Grundannahme?
Grundannahmen sind im Grunde so Glaubenssätze, die ich mir irgendwie angeeignet habe, irgendwie so durch Erfahrungen oft auch nicht unbedingt super reflektiert, sondern eher so ein Grundgefühl im Hintergrund, was irgendwie so meine Sicht der Welt irgendwie sehr stark beeinflusst.
Also zum Beispiel der Softwarearchitekt trifft alle Entscheidungen, könnte eine sein.
Oder die andere könnte sein, der Softwarearchitekt hilft eigentlich dem hilft dem Team, Entscheidungen herbeizuführen.
Sowas.
Finde ich jetzt also nicht das beste Beispiel.
Also, da würde ich eher das erste da noch drauf zurückkommen wollen.
Also dieses Bild, ich als Architekt bin irgendwie hier der seniorischste Mensch im Team und hab einfach den meisten Durchblick und deshalb steht mir.
Okay.
Und beziehungsweise die Annahme, dass andere glauben, ich müsste dieser Mensch sein.
Ah ja, okay.
Also, da finde ich tatsächlich den viel entscheidenderen Aspekt an der Stelle, als dass ich das selber von mir glauben wollen würde.
Mein Zweifel an der Rolle war ja eher.
Ich befürchte, andere glauben, dass ich das so tun müsste, obwohl es mir eigentlich völlig selber widerstrebt.
Also ich tick selber nicht so, und wenn ich dann das Gefühl habe, jetzt soll ich eine Rolle übernehmen, die mit genau diesen Erwartungen quasi bewertet wird, dann fühle ich mich dieser Wall nicht gewachsen.
Das bringt das eher zum Ausdruck.
Also, da ist die Grundannahme, andere glauben, der Architekt muss alles wissen.
So und aber in Wirklichkeit ist das nur in meinem Kopf.
Und danach treffe ich aber Entscheidungen, die dann zu einer Wirklichkeit werden.
So.
Und ich glaube, ein Aspekt, der dich im Vorgespräch interessiert, aber ja, dieser Aspekt, ich schreibe ja bei Grundannahmen ist nicht der Entscheidende Punkt, ob sie wahr sind, sondern ob sie irgendwie hilfreich sind.
Genau.
Und da habe ich ein schönes Beispiel.
Also wir haben in der Weiterbildung die Grundannahme diskutiert, jeder gibt sein Bestes immer.
Wenn du das Leuten sagst, entspringt schnell eine Diskussion, ob das denn wirklich stimmt.
So, ich weiß nicht.
Was sind deine Gedanken dazu?
Also, ich würde sagen, ja.
Also, zum Beispiel bei jetzt, wo bei mir im Kundenprojekt, da passieren an manchen Stellen wirklich verrückte Dinge.
Aber wir versuchen trotzdem, wir sagen jetzt irgendwie, die haben einen an der Klatsche oder sowas.
Sondern wir sagen, hey, die stehen morgens nicht auf, um uns alle in den Abgrund zu reißen.
Sondern die haben die haben das beste Interesse der Firma, oder zumindest mal, also ja, die hat sage einfach mal, die haben das beste Interesse im Hinterkopf.
Das stimmt nicht immer, ne?
Manchmal sind natürlich Eigeninteressen dabei.
Aber grundsätzlich würde ich sagen, das, also ist kein 100%-Fall, aber in weiß ich nicht, 80 Prozent der Fälle würde ich sagen, das ist eine richtige Grundannahme.
Sag ich, weiß nicht, wie du, wie du darüber denkst.
Die Erfahrung, die ich dann in diesen Diskussionen gemacht habe, war, dass ganz viele Leute dann sofort Leute im Kopf haben, denen sie unterstellen, dass sie nicht immer ihr Bestes geben oder im Sinn haben.
Also, da kommen dann schnell so Bilder von, da will sich doch einer eigentlich nur profilieren oder ich weiß nicht, in den Sinn, ne?
Wenn du das aus dieser Perspektive anschaust, ist es hilfreich, so zu denken.
Dann würde ich halt sagen, es ist sehr hilfreich, weil es mir quasi erlaubt, ohne eine nicht äußerbare Verdächtigung in eine Situation reinzugehen und wirklich offen das Gespräch zu suchen.
Also, wenn was nicht funktioniert, kann ich halt, dann arbeite ich nicht unbewusst mit einer Unterstellung, sondern kann wirklich interessiert ergründen, gibt es hier gerade irgendwelche Dinge, die das Fortkommen blockieren.
Gibt es was, was man vielleicht irgendwie lösen kann und dann funktioniert es?
Im Grunde ist das eine Grundannahme, die halt einfach ermöglicht, relativ vorurteilsfrei in eine Situation reinzugehen, weil sie quasi jedem erstmal das Beste unterstellt.
Und das und das finde ich halt, das sind so Elemente, die ich total wertvoll fand, weil ich so gemerkt habe, es hängt ganz viel davon ab, wie ich, wenn ich in dieser Rolle unterwegs bin, auf die Welt gucke.
Und das lässt sich auch nicht, also es gibt keine Methode, die du jetzt einfach abarbeiten kannst, und dann kommen immer haargenau dieselben Ergebnisse raus.
Also viel wichtiger ist tatsächlich, mit welcher Haltung begegne ich meinen Mitmenschen und sehe ich sie als Leute, die irgendwie, ich weiß nicht, Experten sind für die Dinge, die sie tun, die ganz viel wissen, von dem ich was lernen kann.
Oder sind das Leute, die ich irgendwie einen Norden muss, damit sie genau das tun, was ich will.
Ja, ja.
Oder das beeinflusst halt sehr stark, was hinten rauskommt, würde ich sagen.
Ja, ja, das stimmt.
Also, ich hatte mir im Vorfeld überlegt, können wir überlegen.
Also, also werde die Frage, ich habe hier so ein paar Grundannahmen rausgesucht.
Die könnten wir einzeln besprechen.
Ich stelle dir die vor und du kannst dann versuchen zu bewerten, was ermöglicht denn diese Grundornahme aus deiner Perspektive.
Ja, machen wir mal.
Ja.
So, also ich benutze hier ein Kartenset, was ich von den Kommunikationslotsen habe.
Kann man, glaube ich, nicht lesen.
Ich lese das vor.
Also die erste Grundannahme ist, Change kann man nicht bestellen, wie man eine Pizza bestellt.
Da würde ich auch sagen, ja, weil die Pit, ich meine, die Pizza, die suche ich mir aus und dann bekomme ich die geliefert.
Aber bei Change ist natürlich.
Du kannst vielleicht mit so einem gewissen Methodenkoffer da ran.
Ich sage immer Methodenkoffer.
Aber Organisationen sind halt unterschiedlich.
Also es ist ein komplexes System mit ziemlich vielen Reaktionen und Gegenreaktionen.
Also, ich glaube, man kann sich da nur inkrementell voranarbeiten.
Und vielleicht scheitert es auch.
Also die Pizza-Lieferung scheitert ja in aller Regel nicht, aber der Change kann scheitern.
Was ermöglicht mir denn diese Grundannahme?
Sie.
Also, was sie mir ermöglicht, glaube ich, ist, dass ich, dass ich jetzt nicht versuche, nach einem Algorithmus vorzugehen, sondern dass ich immer im Hinterkopf habe, dass ich vielleicht Sachen probieren muss und Feedback bekomme und mich auf das Feedback einstellen muss.
Das würde ich so würde ich so sehen.
Noch was.
Ja, ich würde es vielleicht mal dabei belassen, ja.
Also für mich steckt da halt vor allen Dingen drin, dass also Change bestellen wäre so irgendwie: so, ich gebe jemand dem Auftrag, verändert euch mal.
Oder ein anderes Bild, was auch irgendwie schief ist.
Wir rollen Change jetzt mal aus.
Ja.
Also, es geht ja ein Kern darum, dass eigentlich müssen wir, wenn wir Veränderungen wollen, müssen wir uns irgendwie gemeinsam auf den Weg machen.
Und wenn ich in irgendeiner Position bin, dass ich quasi diese Veränderung bewirken möchte, dann muss ich mich auch mit den Leuten zusammen auf den Weg machen.
Und das heißt auch, dass ich unter Umständen auch mich selber verändern muss.
Okay, ja.
Im Grunde weitet das so ein bisschen den Blick und macht deutlich, wo es bei Veränderungen drum geht.
Das wäre jetzt so meine Antwort.
Ja.
Ich hänge noch ein bisschen an dem Ausrollen, weil ist egal.
Ich würde sagen, machen wir weiter.
Du hast, du hast noch einen, du hast noch einen weiteren.
Einer geht noch, würde ich sagen.
Ja, gut, eine haben wir noch.
Bedeutung liegt nicht in den Dingen wie der Keks in der Schachtel.
Bedeutung liegt nicht in den Dingen wie der Keks in der Schachtel.
Gut.
Dann würde ich jetzt sagen, versucht mal, wenn ich auf meinen Berufsalltag schaue, also so eine Bedeutung, wie vielleicht wie Leute handeln, oder welche Anforderungen sie haben, ist ziemlich oft ein vielschichtiges Problem.
Hat Historie und so weiter.
Und dass ich versuche, jetzt nicht vom oberflächlichen Handeln zum Beispiel zu sagen, ja, das ist doch idiotisch zum Beispiel, warum machen die das denn, sondern dass ich versuche, dem Ganzen nach und nach auf den Grund zu gehen.
Also ich kann die Bedeutung nicht einfach öffnen, wie eine, wie ich meine, wie ich eine Schachtel öffne und dann sehe ich es, sondern das entsteht in einem längeren Dialog.
Ich weiß nicht, ob das Sinn macht, aber das wäre so mein Versuch.
Nein, das macht Sinn.
Und also meine Sicht darauf wäre halt, also wir geben Dingen ja selber einfach auch eine Bedeutung.
Und nur weil eine Sache für dich jetzt eine bestimmte Bedeutung hat, heißt das nicht, dass das für jeden anderen um dich herum dieselbe Bedeutung hat, sondern im Grunde macht es Sinn, sich mit den Leuten, die sich dann umgeben und in deinem Team sind erstmal in Dialog zu treten, was bedeutet das denn für uns und auch so zu schauen, welche unterschiedlichen Perspektiven gibt es darauf.
Welche unterschiedlichen Bedeutungen messen Leute dem zu.
Geht immer auch ein bisschen darum, erstmal so eine gemeinsame Basis überhaupt zu schaffen, dass wir ein Verständnis davon haben, worüber reden wir hier eigentlich.
Und ja.
Ja, die Amis haben ja da diesen Spruch, we look at the same page.
Also, das ist erstaunlich schwer hinzubekommen, dass alle das gleiche Verständnis haben.
Auf eine Situation.
Da hatte ich übrigens mal eine, da hatte ich einen interessanten Workshop.
Und zwar war der CTO dabei und aus jedem Team so einen Lead-Developer.
Dann haben wir über die wichtigsten Ziele des Unternehmens gesprochen.
Und was, also die wichtigsten Ziele des Unternehmens, die Auswirkungen auf die Softwarearchitektur haben.
Und da haben wir ewig rumdiskutiert.
Also da ist wir, die Leute in dem Workshop haben ewig rumdiskutiert, ich sag mal, die neuen Teamleads.
Und dann hat der CTO irgendwann gesagt, ich habe jetzt keine Lust mehr, euch zuzuhören, ist alles Quatsch.
Also jetzt mit einem Lächeln, ne?
Aber das war schon interessant.
Also, er hat halt gesagt, die wichtigsten Ziele für die Architektur aus Geschäft sind das, das, da so das, ja.
Und da fanden wir alle schon sehr interessant, dass wirklich jeder eine andere Meinung hatte.
Und das war völlig unklar, auch nach Jahren, nach Jahren, wo die in dieser Firma arbeiten, was eigentlich die Architekturziele sind.
Zumindest mal die Prioritäten.
Da war es eigentlich nicht schlecht.
Also, da muss ich jetzt gerade denken, dass alle sozusagen auf dasselbe Grundverständnis von dem Problem haben, dass wir hier versuchen mit Architektur zu lösen.
Gut.
Oh, schon 50 Minuten.
Grundannahmen.
Okay, also ich versuche.
Wir haben jetzt schon mal zwei Grundannahmen gehabt.
Du hattest gesagt, du hast ein paar mitgebracht, oder?
Ja, hier liegen noch ein paar.
Ja.
Die können wir vielleicht, ja.
Eine andere wäre noch: nicht wissen ist meine Ressource, Fragen sind mein Potenzial.
So, was ermöglicht mir das?
Ja, bevor ich das beantworte oder versuche, wir können die ja, also könnten die, wir können die ja alle, werden die nicht alle besprechen können, aber die können die alle in den Shownotes packen.
Da können die, die hört, Zuhörer können nochmal nochmal selber schauen.
So, jetzt nochmal kurz zurück.
Mein Nicht-Wissen ist mein.
Nichtwissen ist meine Ressource, Fragen sind mein Potenzial.
Ja, das weckt bei mir, hatte ich heute noch mit einer Kollegin die Diskussion, weckt bei mir so eine Erinnerung an eine Beraterqualifizierung, die ich mal gemacht habe.
Und zwar war Teil davon systemische Fragetechniken.
Und wir hatten da so ein, also wir hatten so ein Demo, so eine Demo-Session gehabt, wo die erste Session war halt Kollege von mir, sollte das Problem von einem der Trainer lösen.
Und da war nicht, nicht, also der ist jetzt nicht so rangegangen, also wäre ich da auch rangegangen, dass jetzt, dass ich nicht mit Nichtwissen da reingehen, sondern ständig irgendwie versucht hat, also er hat halt ständig versucht, wie gesagt, so hätte ich halt auch gemacht, sozusagen, hast du schon mal das probiert oder hast du schon mal das probiert oder hast du schon mal das probiert?
Wenn man die Antwort, nee, nee, nee.
Und zwar hat sehr weh getan, ja, also diese dazu zu hören.
Und dann kam der systemische Coach und der hat nämlich einfach Nicht-Wissen gehabt.
Und hat sozusagen Fragen, also diese systemischen Fragen genutzt und hat einfach durch so Fragetechniken halt wahnsinnig viel aus dem Gegenüber rausgeholt.
Das war wirklich sehr beeindruckend.
Und da habe ich so für mich gedacht, puh, krass, also wenn man sich dumm stellt, also jetzt im übertragenen Sinne und ich stelle einfach nur einen Haufen Fragen und ich kenne die richtigen Fragen, die ich stellen muss.
Also es gibt ja so systemische Fragetechniken, da kann ich wirklich zu sehr guten Lösungen kommen.
Weil alle Beteiligten haben einfach ein gutes Verständnis von dem von dem Problem, weil wir dieses Problem so tief erörtert haben, einfach nur durch Fragen, ja, wo man und so für mich hat er ziemlich viel freigesetzt.
Ich sage, ja gut, wenn ich nichts weiß, oder vielleicht weiß ich auch ein paar Sachen, aber ich stelle mich einfach dumm.
Und so kann ich halt sehr viel selbst über das Problem lernen, aber auch den Blick weiten von meinem, von der Person, die eigentlich das Problem lösen will, indem sie spricht und meine Fragen beantwortet.
Also in Kürze, ich habe jetzt so viel geredet, drei Minuten oder so, in Kürze halt mich befreit das einfach.
Wenn ich einfach, wenn ich sage, ich weiß jetzt nichts in Anführungszeichen, da kann ich viel offener an so eine Diskussion rangehen.
Ich gehe nicht auf die auf, ich sage nicht vorzeitig ja, wenn ich das Problem nicht wirklich verstanden habe.
Und durch dieses Nicht-Wissen kann ich halt sehr gut dem Problem auf die Spur kommen.
Beziehungsweise auch Optionen.
Also wenn wir Lösungsoptionen arbeiten und ich sage, verstehe ich nicht, also tut immer ein bisschen innerlich weh, zu sagen, ich habe jetzt leider überhaupt nichts kapiert.
Kannst das doch mal erklären.
Aber mich befreit das von mich befreit das davon, Angst zu haben, dass ich dass ich nicht frage und dadurch das Problem nicht gut verstehe oder die Lösungsoption nicht gut verstehe.
Also ich würde sogar noch ein Schritt weiter gehen.
Vielleicht befreist du damit sogar Leute in deinem Team.
Weil wenn du ihnen zeigst, dass du dich nicht schämst, wenn du was nicht weißt, trauen sich vielleicht dann auch Leute eine Frage zu stellen, wo sie denken, eigentlich darf ich das nicht fragen, weil jeder von mir erwartet, dass ich das weiß.
Und dadurch kommt eventuell auch dann ein Kommunikationsprozess in Gang, der vielleicht dringend mal nötig ist.
Leute dann plötzlich wieder ins Boot holt, die vielleicht irgendwie schon abgehängt waren oder so, wäre jetzt so meine Interpretation.
Ja, okay, ja, ja, stimmt.
Also würde ich auf jeden Fall.
Ich würde sagen, es zahlt halt total auf das ein, was so mein Problem mit dieser ursprünglichen Vorstellung von Architekt irgendwie so angeht.
Nicht derjenige sein, der jetzt auf alles die Antwort hat.
Ich muss irgendwie derjenige sein, der identifiziert, wenn hier gerade eine offene Frage im Raum steht.
Wäre so meine Interpretation.
Ja.
Mir fällt dazu noch ein, als ich im Studium am Lehrstuhl war, da waren ja auch einige sehr smarte Leute, alte Professoren mit langen Werten, die berühmt waren, aber auch, ich sag mal, ich hatte so einen Betreuer, Big Shout out hier, Alexander Eggert, jetzt Professor in Linz, ne?
Aber die hatten zum Beispiel überhaupt gar keinen Problem damit.
Das fand ich immer ziemlich interessant.
Also, das ist genau das, was du sagst, ne?
Also, wir haben uns immer gedacht, also wenn der jetzt hier eine Frage stellt, also wir haben dieselbe Frage gehabt, aber wir haben gesagt, wir können, also das würde uns irgendwie, wird wieder zeigen, dass wir überhaupt nichts kapiert haben, dass wir überhaupt nicht zugehört haben.
Aber der stellt die Frage auch, ne?
Und das war ziemlich befreiend, ja.
Also, ich fand das auch.
Es gibt auf jeden Fall in den Gruppen, ist eine gute, gute, relaxte Stimmung sozusagen.
Also darf man auch nicht vergessen, und du hast viel weniger Angst, so ein Problem zu verstehen.
Da stimme ich zu.
Ja, verdammt, jetzt hast du mich angefängst.
Komm, einer geht noch.
Einer geht noch und dann ziehen wir weiter.
Jetzt muss ich erst nochmal so ein bisschen gucken.
Veränderung ist an erster Stelle Selbstveränderung.
Oh ja.
Ich ja, also meine Reaktion dazu, ich hatte heute so ein ähnlich, heute war irgendwie sehr gesprächsstilter Tag für mich.
Wir hatten auch über eine gewisse Veränderung gesprochen.
Also wie bringt jetzt jetzt nicht ich, sondern eine Beobachtung von einem Kollegen, der Veränderung bringt oder verbringen soll.
Und das hat halt nicht so gut funktioniert.
Und dann war meine Meinung, naja, immer wenn du Veränderungen in so eine Organisation bringst, reagiert die Organisation ja auf irgendeine Art und Weise und meistens nicht so, wie du das erwartest.
Aber dein Ziel ist halt nicht, deinen Schuh durchzudrücken, sondern die Organisation, also die Organisation irgendwie zu helfen oder Leuten, Teams zu helfen.
Organisation ist vielleicht schon ziemlich viel.
Und diese Person, die hat sich nicht verändert.
Also da gab es ständig Feedback und das, also praktisch, die Veränderungsrufe wurden nicht angenommen, aber diese Person hat im Grunde genommen ihr Verhalten gar nicht angepasst.
Und jetzt ist sie weg.
Und vielleicht auch noch aus anderen Gründen, aber da habe ich gedacht, ja, wenn man die Veränderung einbringt, gibt es funktioniert nicht auf Anhieb, ich muss mich selbst auch verändern und auf das Feedback eingehen.
Vielleicht so.
Das wäre mein Interpretationsversuch.
Also ich stelle mir bei dem Beispiel, was du halt gerade präsentiert hast.
Die Frage, konnte diese Person denn an der Veränderung mitwirken?
Also konnte sie mit dabei, konnte sie Einfluss darauf nehmen, in welche Richtung die Veränderung stattfinden sollte.
Ja, also beziehungsweise hatte diese Person überhaupt einen guten Grund, sich selber zu verändern.
Ja, sagen wir mal, sie hatte das Mandat, eine gewisse Veränderung in die Organisation zu bringen?
Also, also von daher, du hast das Mandat.
Mandat bedeutet auch die Rückendeckung.
Von daher würde ich sagen, ja?
Mandat ist für mich aber nicht gleich Motiv?
Also für mich heißt es halt, Selbstveränderung ist, also Veränderung passiert dann, wenn ich selber die Entscheidung getroffen habe, dass ich jetzt was ändern möchte.
Ach so, ah, okay, okay.
Ja, also das würde ich mal sagen, also in dem Fall war das auf jeden Fall so.
Also, dass du hattest das, also das Mandat kam halt auch durch Selbstmotivation sozusagen.
Ich will das Mandat, ich will das ändern.
Wenn es das ist, was du, was du meinst.
Ja.
Okay, okay.
Genau.
Was hilft?
Aber vielleicht kannst du noch sagen, wobei hilft mir das?
Also ich will was ändern.
Deswegen muss ich mich ändern.
Also es kommt aus einer inneren Motivation raus.
Genau, es kommt aus einer inneren Motivation.
Und die Frage ist, ich möchte was ändern.
Die Frage ist dann aber gleichzeitig auch, will sonst noch jemand was ändern?
Ja, okay, ja.
Gibt es überhaupt eine gemeinsame Wahrnehmung eines Problems?
Also im Grunde heißt das, dass man erstmal damit starten sollte, wie wird denn eine Situation von unterschiedlichen Beteiligten wahrgenommen?
Und dann kann man eventuell auch, also wenn man dann zusammen zu dem Schluss kommt, ja, wir haben ja gerade alle fühlen eine Belastung mit dieser Situation?
Dann hat man vielleicht auch eine Situation geschaffen, wo sich eine Dynamik entwickeln kann, dass man zusammen an einem Strang zieht und eine Veränderung herbeiführen will?
Vielleicht letzte Frage, bevor wir nochmal so ein abschließendes Kapitel machen?
Wie jetzt hänge ich?
Aber wie schaffe ich das?
Also machst du dann Einzelinterviews oder man kommt immer auf den Kontext an, aber wie kriegst du raus, ob das, ob alle Leute, wie denken denn die anderen Leute über die Situation?
Wie wollen sich wer will sich überhaupt ändern?
Machst du da Einzelinterviews oder besprichst du das in der Gruppe?
Oder machst du Umfragen oder was wären da so Möglichkeiten, um dieses Wissen aufzubauen.
Das ist ein Punkt, wo ich wieder sagen würde, es kommt mehr auf die Haltung als auf die Methoden an.
Also die entscheidende Frage ist: interessiere ich mich dann dafür, was andere denken.
Ja, okay.
Weil ich das würde ich mal.
Dann brauche ich auch keine Einzelinterviews.
Aber gegebenem Fall, es interessiert mich wirklich.
Dann finde ich, gibt es auch da kein Patentrezept.
Okay.
Es gibt immer eine spezifische Gruppenkonstellation.
Es gibt spezifische Charaktere, die vielleicht auch unterschiedlich irgendwie auf bestimmte Ansprachen reagieren, keine Ahnung.
Also ich finde, das hat, also deshalb betone ich das immer.
Die Haltung ist tatsächlich der entscheidende Punkt.
Und wenn ich dann offen für die Situation bin, dann fällt mir gegebenenfalls das Richtige ein.
Das ist halt quasi kein Patentrezept, ne?
Ja.
Okay.
Und um da den Kreis zu schließen, das ist eigentlich auch.
Also, ich schreibe in meinem Artikel ganz viel über den ADR und so.
Das ist halt nicht unbedingt das Eigentliche.
Ich finde das eigentliche, worum es mir tatsächlich geht, aber das kann man nicht, das ist tatsächlich nicht so leicht auf den Punkt zu bringen, ist wirklich so diese innere Haltung.
Ich als Architekt fühle mich dafür verantwortlich, dass wir gute Entscheidungen treffen.
Und ich bin aufmerksam, identifiziere, wann eine Entscheidung gebraucht wird und bereite dann den Raum dafür, dass diese Entscheidung getroffen werden kann.
Und dass die Leute, die zusammen diese Entscheidung treffen sollten, dann wenig Hindernisse haben, um sie treffen zu können.
Also, wenn ich zum Beispiel dann einfach schon mal einen Besprechungstermin anberaumt habe, quasi so ein Meeting, eine bestimmte Agenda hat, wenn ich mir vorher bestimmte Fragen überlegt habe, die wir besprechen sollten, wenn ich ein klares Ziel für diese Besprechung definiere, das heißt es halt nicht irgendwie so ist, jo, ich habe da diese Besprechung, ich weiß auch nicht, was wir da machen, und am Ende miteinander verbracht und ist nichts dabei rausgekommen.
Also so würde ich die Rolle da sehen, dann halt ja das stimmt.
Also ich muss sagen, für mich war ja das Meeting das zentrale Element, ja, also weil ich mit vielen unterschiedlichen Teams so zusammengearbeitet habe und es mir halt auch aufgefallen, dass überhaupt so Meetingorganisation und wie ich die leite und wie man dem ganzen Struktur gibt, das war irgendwie so ein Riesending, ja.
Also ich hatte auch da zum Beispiel mit AinoCommi habe ich so ein Case-Podcast darüber gemacht, wie man so wie man in Anführungszeichen erfolgreich solche Meetings durchführt.
Und wir haben die dann auch tatsächlich jetzt bei uns da eben, wir sind so, also bei uns im Team haben wir das ziemlich strikt zeitweise durchgetaktet, welche Arten von Meetings haben wir, welche, was ist eigentlich der Outcome und wie müssen die aufgebaut sein, dass wir wirklich nicht die Zeit von den Leuten verschwenden und dass sie wirklich sehr effektiv dann, dass wir sehr effektiv zu dem gewünschten Ergebnis kommen.
Gut.
Vielen, vielen Dank.
Eine Frage hätte ich noch zum Abschluss.
Ich meine, du hast ja eigentlich schon, also vieles konnte man schon rauslesen oder raushören, vielmehr.
Aber wenn ich jetzt, was ich immer ganz interessant finde, ich bin Junior oder Mid-Level-Entwickler oder ich bin auch Senior-Entwickler.
Also ich bin schon eine Weile dabei, aber ich will mich jetzt mehr Richtung Architektur entwickeln.
Also wie du sagst, ich will die Entscheidungen herbeiführen, will den Leuten da helfen.
Gibt es so ein praktischen Rat von dir für jemanden, der morgen damit anfangen will und sich da mal ausprobieren will, ohne dass er jetzt offiziell diese Rolle, dass die Person diese Rolle bekommt.
Also da würde ich auch sagen, es geht nicht um die Rolle, sondern es geht um die Architekturentscheidung.
Also, wenn ich jetzt Entwickler in einem Team bin und feststelle, mir ist gerade nicht klar, wie ich da jetzt am besten dieses Feature implementiere, dann kann ich erstmal versuchen, Gespür dafür zu entwickeln, solche Situationen wahrzunehmen.
Und dann kann ich im Grunde selber anfangen, zum Beispiel, ich schreibe schon mal für mich ein ADR, bitte dann meine Kollegen, sich das mal anzugucken.
Okay.
Oder setze eben auch selber eine Besprechung an und sage, lass uns doch das Thema mal zusammen besprechen.
Also ich finde tatsächlich den wichtigsten Punkt, lernen, so diese Situation erstmal wahrzunehmen.
Weil, ne, also wichtig, das Schlimmste ist, wenn sich so eine Architektur einfach rausbildet, ohne dass ich mir bewusst darüber Gedanken gemacht habe.
Und also ich habe halt auch die Erfahrung gemacht, dass also wenn man sowas ein, zweimal in einem Team eigentlich gemacht hat, dann entwickelt sich eine Eigendynamik und Leute fangen selber an, ADRs zu schreiben.
Ja, das stimmt.
Also, das habe ich auch festgestellt, sozusagen einmal ADR, immer ADR.
Und wie du sagst, wenn man sich auch Gedanken drüber macht, wen betrifft diese Entscheidung.
Und wer ist Experte für die für die Entscheidungsfindung?
Also, wenn man das so ein paar Mal durchgenudelt hat, dann kann man eigentlich.
Man kann nicht mehr anders, ja.
Ich kenne und die Anziehen.
Da bleibt man dabei.
Und der Aspekt, den ich halt auch wichtig finde, ist, es geht eigentlich darum, so eine Kultur von Architekturentscheidung zu entwickeln.
Also in dem Kontext, in dem ich mich bewege.
Sodass ich als Person gar nicht dafür unbedingt gebraucht werde.
Also zu dieser faszilitativen Grundhaltung gehört halt auch, dass man quasi im entscheidenden Moment dann auch aus dem Weg gehen kann.
Also wenn alle sich eigentlich schon, also wenn alle quasi das Handwerk gelernt haben, dann wird man nicht mehr gebraucht.
Und vor allen Dingen hat man die Leute dann auch, haben die Leute sich selber davon überzeugt, dass das der Weg ist, den sie bestreiten wollen und dann leben sie das auch irgendwie weiter.
Verdammt, ich merke schon, ich bin gefeuert, aber noch niemand weiß es.
Ja, nee, gut.
Also, ich fand auch ganz interessant, du hast in deinen Fragen, die du mir vorher geschickt hattest, geschrieben, muss jetzt jeder Architekt eine Facilitator-Ausbildung machen.
Dazu ist mir halt die Frage in den Kopf geschossen, braucht man denn, wenn man diese Architekturrolle so begreift, überhaupt noch quasi Architekturwissen.
Das wäre auch eine naheliegende Frage, die man mir stellen könnte.
Ja.
Und da bin ich halt schon der Meinung, dass das ich sehe es schon als Voraussetzung, weil ich ja, also ich muss schon so ein bisschen in der Lage sein, also das heißt ein bisschen, ich muss schon in der Lage sein zu verstehen, mit welchen Problemen beschäftigt sich das Team denn gerade.
Ja, ja klar.
Und dieses Gespür zu entwickeln, jetzt hier wird ja eigentlich gerade eine Entscheidung gebraucht.
Ich weiß nicht, ob das so gut funktioniert, wenn man diesen Background nicht hat.
Nee, also das auf jeden Fall.
Also mir ging es nicht darum, dass ein Facilitator jetzt Architekturentscheidungen treffen kann, aber wenn man Architekt die Architektenrolle annimmt, ob man halt auch, also wie viel, vielleicht ist Facilitator-Ausbildung zu viel, aber wie viel mit wie viel muss man sich eigentlich damit beschäftigen, also mit diesen Facilitator-Inhalten?
Weil wir machen ja auch so Soft Skills-Schulungen, wo wir uns mit Konflikten auseinandersetzen, zum Beispiel mit Teamdynamiken und so weiter, und ob so Facilitation eigentlich auch dazu gehören sollte.
Also, ich glaube tatsächlich, dass eine komplette Facilitation-Weiterbildung dafür nicht unbedingt nötig sind.
Ich glaube tatsächlich, dass so der Gedanke, ich bin nicht die Person, die alles wissen muss.
Ich bin vor allen Dingen nicht die Person, die alles besser weiß.
Und der Gedanke, dass Architekturentscheidungen eher umgesetzt werden und gelebt werden, wenn auch alle entscheidenden Personen irgendwie das Gefühl hatten, daran beteiligt gewesen zu sein.
Ja, genau.
So ein paar Grundpfeiler, die ich schon sehr hilfreich finde.
Ja, genau.
Alright.
Auf jeden Fall vielen Dank.
Sehr erhellend muss ich sagen für mich.
Und ja, an alle, die an alle, ich wiederhole mich immer, Patrick Kur sagt ja immer, alle, die es bis hierhin geschafft haben, vielen Dank.
Und bis zum nächsten Mal.
Ciao, ciao.
Dankeschön.