Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Als Architekt:in Wirkung entfalten

Hintergrund ist eben, dass ich glaube, dass das ein grundsätzliches Thema ist, was wir uns immer stellen müssen.

Die Frage, wie kriegen wir es hin, in den Projekten irgendetwas auf die Reihe zu bekommen und dafür zu sorgen, dass die besser laufen.

Die Rolle des Architekten

Ich habe mir als Frage aufgeschrieben, was bedeutet es eigentlich, als Architektin zu arbeiten.

Und ich glaube, es ist offensichtlich, nahezu offensichtlich, dass man eigentlich erst mal, wenn man so an TechnikerInnen denkt, dann geht es halt irgendwie um technische Skills.

Technische Skills

Und ArchitektInnen sind irgendwie auch Techniker an der Stelle.

Das heißt, es geht halt um solche Geschichten wie die Strukturierung von Software, das Einhalten von Qualitätszielen.

Und das ist eigentlich das, was Architektur treibt.

Das sind jetzt erst mal zumindest scheinbar technische Themen.

Qualitätsziele

Das heißt, die Frage ist, wie strukturiere ich mein System so, dass es besonders wartungsfreundlich ist und einfach erweiterbar und auch gut zu entwickelbar ist.

Und auf der anderen Seite habe ich dieses Thema, welche Technologien benutze ich, wie baue ich das System auf, dass es bestimmte Qualitätsziele einhält.

Also eben auch, was auch immer es ist, einfach wartbar ist oder eben besonders schnell ist, besonders sicher oder was auch immer.

Wobei da eigentlich schon so ein bisschen das Problem anfängt.

Herausforderungen bei Qualitätszielen

Denn abhängig davon, welche Qualitäten ich mir anschaue, bekomme ich das durch Technologieauswahl oder die Strukturierung von Software nicht mehr hin, diese Qualitätsziele tatsächlich umzusetzen.

Technische Skalierbarkeit

Also was das bedeutet, wenn ich ein System bauen will, was besonders skalierbar ist, was besonders performant ist, das ist etwas, wo ich sicher durch Maßnahmen in der Architektur dafür sorgen kann, dass das halt funktioniert.

Also ich kann sagen, ich baue ein System, was horizontal skalierbar ist.

Das ist eine Architekturmaßnahme, das ist eine Strukturierung.

Ich baue das auf einer Infrastruktur, Amazon Cloud oder was auch immer.

Dann ist das ein System, was eben besonders gut damit umgehen kann, auch hohe Last umzusetzen.

Dann habe ich tatsächlich ein Qualitätsziel umgesetzt durch eine Auswahl an Technik und Strukturierung und bin da sozusagen dann am Ziel angekommen.

Aber bei anderen Qualitäten kann das ein Problem sein.

Also ich glaube, eine Qualität, die häufig unterbewertet wird, ist dieses Thema mit der Benutzerfreundlichkeit.

Benutzerfreundlichkeit

Benutzerfreundlichkeit ist, glaube ich, deswegen wichtig, weil Systeme, die benutzerfreundlich sind, sorgen dafür, dass Menschen damit produktiver arbeiten können, dass sie damit lieber arbeiten.

Und das führt dazu, dass eben diese Systeme am Ende auch am Markt erfolgreicher sind.

Und das ist dem etwas, was ich jetzt nicht mehr durch die Auswahl einer Technologie oder die Strukturierung hinbekomme.

Also ein System wird nicht dadurch benutzerfreundlich, dass ich Angular benutze.

Und ein System wird halt auch nicht dadurch benutzerfreundlich, dass ich es in einer bestimmten Art und Weise strukturiere, also den Code in einer bestimmten Art und Weise strukturiere.

Ich habe eine Episode mit der Aminata zu dem Thema gemacht vor einiger Zeit, wo es genau um dieses Thema ging, mit der Benutzerfreundlichkeit.

Und da stellt sich heraus, dass es durchaus Ansätze gibt, die so ein bisschen architektonisch sind.

Aber das ist eben etwas, was wir normalerweise nicht so unter Architektur verstehen würden.

Und das ist dann etwas, wo ich jetzt selber, wenn ich jetzt sozusagen Verantwortung tragen würde in so einem Projekt, wo das ein großes Thema ist, wo ich dann auch tatsächlich sagen müsste, okay, ich hole mal jemanden dazu, der sich insbesondere darum kümmern kann.

Und ich mache Dinge, die halt eben nicht im Arc 42 Template drinstehen oder die halt einfach Technologieentscheidungen sind.

Und das gilt halt auch für andere Sachen.

Also wenn ich mir zum Beispiel Sicherheit angucke, bei Sicherheit kann es ganz kleine Code-Probleme geben.

Es kann sein, dass ich irgendeinen String nicht escape.

Dann habe ich ja ein VSQL-Injection oder was auch immer da das Problem ist.

Also ich habe einen Blogpost jetzt diese Woche geschrieben, da ging es um den VW-Datenskandal.

Da war es halt die Fehlkonfiguration eines Systems, sodass eben ein Heapdump gemacht werden konnte.

Und das führt eben dazu, dass Daten abfließen.

Und das ist wiederum etwas, wo ich auch sagen würde, so als Architekt, der hat irgendwie auf dieser abstrakteren Ebene arbeitet, kann ich eben diese Art von Sicherheit nicht gewährleisten.

Das heißt, ich müsste mich auf andere verlassen.

Kollaboration und Verantwortung

Was das bedeutet ist, dass ich also als Architekt eben nicht die volle Verantwortung übernehmen kann für sämtliche Qualitäten, die Software haben kann.

Und das bedeutet, dass ich eben an dieser Stelle auf Kollaboration mit anderen Menschen angewiesen bin und andere Rollen betrachten muss, andere Menschen dort haben muss und dort irgendwie etwas machen muss.

Und ich bin nicht sicher, ob aus dem Grund bestimmte Qualitätskriterien, wie zum Beispiel Performance oder Wartbarkeit, so häufig als die Merkmale einer guten Architektur wahrgenommen werden.

Denn das sind ja nun Sachen, die ich halt offensichtlich durch technische Maßnahmen, also klassische Architekturarbeit tatsächlich positiv beeinflussen kann.

Ich finde das aber im Gesamtkontext von Projekten nicht so wichtig.

Also beziehungsweise, ich finde es schwierig, wenn man sozusagen mit dieser Brille reingeht und sagt, naja, ich will halt irgendwie das System wartbar, performant und skalierbar machen.

Denn ich hatte es schon gesagt, Benutzerfreundlichkeit kann irgendwie deutlich wichtiger sein.

Und wenn ich ein System baue, was halt ganz wenig Menschen benutzen, weil es halt benutzerunfreundlich ist, dann habe ich halt am Ende ein Problem.

Und dann habe ich auch zum Beispiel in Skalierbarkeit umsonst investiert.

Und vielleicht der andere Punkt, und deswegen ist das so ein bisschen ein Produkt zu dem eigentlichen Thema, über das ich sprechen möchte.

Ich glaube, diese Wichtigkeit von technischen Skills ist relativ klar.

Also sprich, wenn ich sage, das ist eine Architektin, dann ist das eine Person, die technische Skills hat.

So nehme ich irgendwie an.

Und eigentlich brauchen wir darüber nicht zu reden, weil das intuitiv klar ist und die meisten Leute das genau irgendwie so sehen würden.

Ich glaube auch, dass es eben tatsächlich wichtig ist.

Aber ich glaube, es ist eben nur die Voraussetzung.

Und das führt eben zu dieser Geschichte, wie entfalte ich denn Wirkung?

Wirkung entfalten

Also ich habe extra diesen Begriff von Wirkung gewählt.

Und was das in gewisser Weise bedeutet, ist, dass ich, ich habe ja jetzt irgendein Wissen, ich habe irgendeine Idee, wie wir bestimmte Probleme in dem Projekt lösen können.

Ich will halt ein horizontal skalierbares System bauen.

Ich will ein System bauen, was in einer bestimmten Art und Weise strukturiert ist.

Und jetzt ist die Frage, wie entfalte ich eine Wirkung?

Also wie sorge ich dafür, dass das Projekt sich am Ende tatsächlich auch so verhält, wie ich es will?

Wobei, das ist ja eigentlich schon ein bisschen das Problem.

Also weil ich will ja nicht unbedingt, dass das Projekt sich so verhält, wie ich will, sondern ich will, dass es besser wird.

Und dazu habe ich eben nicht alles Wissen und alle Dinge in der Hand, so wie wir das gerade eben schon diskutiert haben mit Sicherheit und Benutzerfreundlichkeit.

Das heißt also, eigentlich ist schon diese Idee, dass ich Wirkung entfalte, indem ich sage, das Projekt macht eben das, was ich will.

Das ist eigentlich falsch.

Ich will eigentlich, dass es besser wird und ich habe einen bestimmten Puzzleteil davon, weil ja die Annahme ist, dass ich eben bestimmte technische Expertise habe, bestimmte Dinge irgendwie kann.

Ich wäre zum Beispiel sehr überrascht, wenn jemand sagt, ich bin Architekt, aber ich kann ein System nicht strukturieren.

Das heißt also, zumindest in diesem Bereich habe ich einen Teil des Puzzleteils, des Gesamtpuzzels in der Hand.

Ich habe eben diesen Teil, mit dem ich das System änderbar machen kann und vernünftig strukturieren kann.

Jetzt gibt es die Möglichkeit zu sagen, okay, das ist ja alles super.

Ich fange an und implementiere Dinge halt selber auf Code-Ebene.

Also ich mache zumindest zum Teil den Job, den auch Entwickler machen.

Das heißt also, ich setze mich hin und wirke jetzt eben auf Code-Ebene.

Ich bin mir ehrlich gesagt nicht sicher, wie die Wirkung entfalten wird.

Das heißt, ich will idealerweise dafür sorgen, dass das Projekt erfolgreich ist.

Jetzt setze ich mich hin und schreibe Code.

In dem Projekt, in dem man sich typischerweise bewegt, sind viele Menschen, die Code schreiben.

Ich kann jetzt nur eine bestimmte Menge Code schreiben.

Nehmen wir an, wir sind nur ein Scrum-Team.

Da gibt es vier Entwickler.

Ich bin eine davon und jetzt sitze ich da und schreibe Code.

Dann gibt es drei andere Personen, die auch Code schreiben.

Das heißt, der Code, den ich alleine schreibe, ist höchstens ein Viertel von dem Gesamtcode.

Also ungefähr Milchmädchenrechnung.

Ich kann dadurch eigentlich gar nicht so viel Wirkung entfalten und habe jetzt das begrenzt.

Ich bin halt eine Person und das, was ich mache, ist das, wo ich tatsächlich Wirkung entfalte.

Das führt mir dazu, dass, wenn man das so betrachtet, es nahezu überraschend ist, dass es Menschen gibt, die sagen, ich bin ein Coding-Architekt und ich glaube, weil ich ein Coding-Architekt bin, bin ich besonders wirksam.

Das ist eigentlich komisch, weil ich damit sage, die Wirkung ist eben mein Code und das ist wichtig.

Ich glaube, das ist auch nicht der Grund, weswegen wir Coding-Architekts beliebt sind und dass es eine Möglichkeit ist, diese Rolle auszufüllen.

Ich glaube, es hängt damit zusammen, dass man damit zum einen diese Bodenhaftung behält, dass man merkt, wie das System tatsächlich aussieht, darin selber arbeitet und dadurch eine bessere Idee hat, was mit dem System eigentlich los ist.

Dann ist es vielleicht gar nicht so relevant, dass man selber codet, sondern das ist eigentlich nur ein Mittel zum Zweck, weil ich dadurch Informationen aus dem Projekt bekomme, also darüber, wie das Projekt jetzt tatsächlich auf dieser Ebene aussieht und dadurch besser wirken kann, weil ich mehr Informationen habe und besser dann darauf reagieren kann.

Außerdem kann ich so ein paar Punkte verdeutlichen und sagen, hier sind bestimmte Ideen in diesem Code, hier sind vielleicht irgendwelche Patterns, hier sind irgendwelche Strukturmerkmale.

Ich setze das selber um und dadurch schaffe ich ein Beispiel.

Dann bedeutet das aber, dass ich eigentlich durch Code kommuniziere.

Code als Kommunikationsmittel

Zum einen sehe ich, welcher Code in dem System drin ist und das ist eine Möglichkeit, jetzt zu verstehen, wie das System eigentlich strukturiert ist und darüber zu kommunizieren.

Eigentlich ist es so, dass ich damit mit den anderen Entwicklern kommuniziere.

Die produzieren auch Code und das ist das gemeinsame Ding, an dem wir sitzen und von dem wir eine gemeinsame Idee haben.

Umgekehrt zeige ich durch das, was ich baue, wie Dinge umgesetzt werden können, wie bestimmte Probleme gelöst werden können und so weiter.

Dann ist Code eher ein Mittel zum Zweck und ein Hebel, mit dem ich das Projekt besser machen kann.

In dem Fall als Extremfall, als Kommunikationsmechanismus kann man das nahezu betrachten.

Da sind ein paar andere Sachen, die ich auch als Kommunikationsmechanismus nutzen kann.

Zum Beispiel gibt es da Peer Programming.

Peer Programming bedeutet, dass ich zu zweit an einem Rechner sitze und wir gemeinsam an Code arbeiten.

Das bedeutet auch eine sehr starke, sehr enge Kommunikation mit der anderen Person, mit der ich zusammenarbeite.

Bei Mob oder Xampp-Programming ist das ein ähnliches Thema.

Da kommuniziert das gesamte Team über den Code und hat darüber eine Idee.

Insgesamt ist das eine Rollenausgestaltung, die offensichtlich funktioniert.

Coding Architect ist sicherlich ein Ansatz, den ich wählen kann und der hat auch gut funktioniert und Vorteile hat, weil ich direkt an den Dingen arbeite, die relevant sind.

Aber ich muss ehrlich gestehen, dass das etwas ist, was ich typischerweise nicht tue.

Ich setze mich nicht hin und code im Projekt nicht prototypisch.

Es gibt Kolleginnen, die eher in dieser Art und Weise arbeiten.

Das sind unterschiedliche Möglichkeiten, um solche Probleme anzugehen.

Ich würde eher darüber reden.

Andere produzieren eher Code.

Ich glaube, es sind beides valide Möglichkeiten, einen Schritt weiterzukommen.

Das bedeutet aber dennoch, dass ich vor diesem Problem von Überzeugen stehe.

Ich will andere Leute beeinflussen oder überzeugen.

Ich möchte jetzt eigentlich, selbst wenn ich in diesem kleinen Scrum-Team sitze, die anderen drei Entwickler dazu bringen, gemeinsam Dinge durchzuhalten, umzusetzen und so weiter.

Eigentlich will ich die davon überzeugen, dass eine bestimmte Struktur des Codes vielleicht besser ist.

Wenn wir hexagonal arbeiten, ist das vielleicht besser als das, was wir jetzt gerade haben.

Wenn wir folgende fachliche Aufteilung in verschiedene fachliche Teile empfehlen, ist das vielleicht besser als das, was wir jetzt haben.

Das würde aber implizieren, dass ich es besser weiß.

Das nimmt an, dass die anderen, die im Team sitzen, überzeugt werden müssen.

Ich weiß also, wie es richtig geht.

Die wissen nicht, wie es richtig geht.

Ich muss ihnen das zeigen.

Das führt dazu, dass ich davon ausgehe, dass ich dort ein Wissensgefälle habe.

Ich muss gestehen, dass ich das zum einen unwahrscheinlich finde, weil wir in einer Branche sind, wo es einfach viele Facetten von den Problemen gibt.

Jemand, der eine andere Erfahrungswelt hat, vielleicht mit bestimmten Technologien andere Erfahrungen gesammelt hat – ich habe zum Beispiel eben nicht so viel Ahnung von Frontend-Technologien.

Das heißt, jemand, der mir sagt, Frontends baut man typischerweise so, oder das ist ein typisches Ding, was irgendwie funktioniert.

Es ist total vermessen, wenn ich mich jetzt hinstelle und sage, ich überzeuge mich von dem Gegenteil.

Es ist unwahrscheinlich, dass ich es in einem Team schaffe, auch wenn es nur diese vier Personen sind, die Person zu sein, die tatsächlich in allen Bereichen allen anderen Personen überlegen ist.

Ehrlich gesagt, fände ich das eigentlich auch traurig.

Das führt dazu, dass man sagt, ich bin die einzige Person, die tatsächlich Ahnung hat, die anderen nicht.

Ich hätte keine Lust, in so einem Projekt zu arbeiten, weil ich dort wenig lernen kann.

Und zum anderen glaube ich auch nicht, dass das überhaupt eine realistische Sache ist, dass man in so einem Projekt ist, wo man sagt, die anderen haben alle überhaupt keine Ahnung.

Das wäre extrem überraschend.

Dafür ist unsere Branche zu vielfältig und man kann zu viele unterschiedliche Erfahrungen machen.

Es gibt andere Branchen.

Mir ist das aufgefallen bei diesen Aircrash Investigations.

Da ist es so, dass man sagt, ein Pilot hat so und so viele Stunden Erfahrung auf irgendeinem Flugzeug.

Das ist der Indikator für die Erfahrung.

Das ist der einzige, der typischerweise herangezogen wird.

Ich kann mir vorstellen, dass das eher realistisch ist, weil da gibt es eine Skala.

Ich bin auf dem Airbus A320 so viele Stunden geflogen.

Das heißt, ich habe mehr Ahnung als jemand, der halb so viel mit dem Ding geflogen ist.

Bei uns ist es aber so, dass ich Frontend, Backend, Architektur, was auch immer, verstehen kann.

Das bedeutet, es ist viel vielfältiger, was dazu führt, dass die anderen Personen in anderen Bereichen besser davor sind.

Der Darth Kali auf Twitch schreibt, die wichtigste Aufgabe eines Architekten, einer Architektin ist es, die richtigen Leute an einen Tisch zu holen und gemeinsam eine Entscheidung zu treffen, welche das Projekt weiter bringt.

Das ist das, worauf ich tatsächlich hin möchte.

Ich bin mir gar nicht sicher, ob ich das zu 100 Prozent unterschreiben würde, weil das die moderierende Rolle betont.

Ich hole diese Leute an einen Tisch und strukturiere einen Entscheidungsprozess.

Das vernachlässigt, dass ich eine technische Expertise habe.

Was ich damit meine, ist, wenn man nur sagt, ich bringe die richtigen Leute an einen Tisch, dann kann das jede Person, die Ahnung davon hat, also die Moderations- und Managementskills hat.

Ich glaube, wir als Architektinnen können noch hinzufügen, dass wir eine technische Ahnung haben.

Das heißt, selbst wenn mir jemand etwas über UI-Architektur erzählt, kann ich versuchen, intelligente Fragen zu stellen und das in eine bestimmte Richtung zu bringen.

Ich glaube, das ist etwas, was man da vielleicht etwas vernachlässigt.

Der Darth Kali schreibt gerade, und vielleicht grundsätzlich.

Ich finde, das ist aber ein guter und wichtiger Ansatz.

Ich würde sagen, dieser Ansatz ist auf jeden Fall besser, als zu sagen, ich entscheide das jetzt mal kurz.

Das bedeutet aber, dass ich mich dann auch überzeugen lassen muss.

Das heißt, ich muss mich auch hinstellen und sagen, okay, cool, ich habe zwar eine Idee, die ist irgendwie so, aber die ist jetzt auf den zweiten Blick vielleicht doch eine schlechte Idee.

Ich versuche eigentlich, da so eine Art Logikkette aufzubauen und die dann zu validieren.

Das Beispiel, was ich da typischerweise wähle, ist diese Geschichte mit, okay, wir machen jetzt Microservices, also das ist eine Entscheidung.

Jetzt ist die Frage, warum, was aus Berater Perspektive für mich typischerweise eine Frage ist, also warum trifft der mit dieser Entscheidung, und dann kommt heraus, naja, weil wir mehr Unabhängigkeiten zwischen den Teams haben wollen und weniger Abstimmung.

Entscheidungen fällen kann.

Ich kann einen Docker-Container bauen, da ist eine Rust-Anwendung drin.

Ich kann einen Docker-Container bauen, da ist eine Java-Anwendung drin.

Ich kann also diese Entscheidungen in diese Teams verlagern, sodass die sich weniger koordinieren müssen.

Die können unabhängig voneinander deployen und so weiter und so weiter.

Also ja, die Lösung Microservices ist eine Lösung für dieses Problem, potenziell.

Und jetzt ist, glaube ich, ein weiterer Punkt, dass man sich halt überlegen kann, was sind denn eigentlich Alternativen?

Und da kann man jetzt irgendwie stärker reinbohren, also welche Art von Unabhängigkeiten meinen wir denn überhaupt?

Und es stellte sich halt in dem Beispiel heraus, stärkere Unabhängigkeit im Bezug auf Deployment war halt irgendwie der wesentliche Punkt.

Also eine Möglichkeit schaffen dafür, dass eben Teams öfter deployen, idealerweise unabhängig deployen.

Auch da wieder, ja, das bedeutet halt, dass sich das mit Microservices umsetzen kann.

Da ist jetzt noch ein anderer Rattenschwarz hinter.

Ich müsste jetzt nämlich tatsächlich unabhängige Continuous-Delivery-Pipelines idealerweise haben, die zum Beispiel unabhängige Tests haben.

Das heißt, Microservices reichen mir nicht aus.

Ich muss eben auch die Tests irgendwie aufteilen, weil ich ja unabhängige Deployment-Pipelines haben muss.

Das heißt, man kann jetzt von dort aus diese Entscheidung noch mal weiter hinterfragen.

Und es gibt jetzt Alternativen.

Man kann nämlich schauen, ob man die Continuous-Delivery-Pipeline für das monolithische System beschleunigt.

Dann hat man zwar kein unabhängiges Deployment, aber die Teams können eben öfter deployen.

Vielleicht ist das eben etwas, was reithilft.

Mechanismen dort sind irgendwie solche offenen Fragen.

Warum macht ihr das denn?

Warum macht ihr das denn?

Warum macht ihr das denn?

Also wir haben mehrfach Fragen, was eigentlich die Begründung ist.

Weil das ist ja eine Logikkette, die halt sagt, okay, wir haben halt Teams, die sich stark koordinieren müssen, weil sie eben beim Deployment aufeinander warten.

Und deswegen wollen wir Microservices.

Da sind also mindestens so drei Elemente.

Jetzt kann man eben anfangen und kann bei jedem von diesen Schritten fragen, okay, ist das tatsächlich etwas, was hilft?

Und gibt es irgendwie Alternativen?

Und dafür sind, glaube ich, so offene Fragen gut.

Dafür ist Zuhören gut.

Rückfragen stellen, das sozusagen für sich validieren.

Und hat irgendwie sozusagen diese innere Logik von diesem Ding, von dieser Entscheidung hinterfragen.

Und damit werden aber Entscheidungen auch eigentlich zu Kompromissen zwischen unterschiedlichen Perspektiven.

Also ich habe irgendwie eine Perspektive mit meinen Ideen.

Die anderen haben vielleicht eine andere Perspektive.

Also vielleicht ist es halt so, dass ich sage, naja, lass uns Microservices machen.

Ich habe gute Erfahrungen damit gemacht.

Ich habe ein Buch darüber geschrieben.

Das ist eine gute Idee.

Die anderen sagen, also das ist irgendwie doof.

Lass uns doch lieber bei den Monolithen bleiben.

Das ist, glaube ich, einfacher.

Und wir können ja die kontinuierste Hilfe-Pipeline beschleunigen.

Und dann müssen wir es halt irgendwie sozusagen auskegeln und zu irgendeinem Ergebnis kommen.

Und das ist halt formal zwischen Menschen ein Kompromiss.

Aber am Ende bedeutet das, dass wir vielleicht auch bei einem besseren Ergebnis herauskommen, weil wir halt mehr Aspekte betrachtet haben.

Nicht irgendwelche, also ich gerade als Berater habe das Problem, dass ich nie der Experte bin für das System, sondern ich bin der Experte für allgemeine Dinge, also allgemeine Konzepte.

Und das bedeutet, dass was wir machen, ist ein Kompromiss zwischen den Vorschlägen, die ich mache und den Ideen, die ein Kunde hat.

Und das wird aber am Ende nicht irgendwie so ein halbgarer Kompromiss, wo wir beide zufrieden sind, sondern es wird irgendwie ein besseres Ergebnis, weil wir mehr Perspektiven reingebracht haben.

Und dann wird die Kommunikation halt auch wichtiger mit Stakeholder, mit EntwicklerInnen und so weiter.

Und es gibt bestimmte Elemente, die einem dabei helfen.

Also damit hat man eigentlich ein Problem.

Also ein Problem, das mir tatsächlich auch an einigen Stellen passiert ist, dass ich mich irgendwie hinstelle und sage, das könnte man ja so oder so machen.

Und dann ist das plötzlich eine Entscheidung, obwohl ich eigentlich nur mal auf eine Option hingewiesen habe.

Und das kann irgendwie dadurch kommen, dass ich irgendwie nicht gewagt habe, etwas zu sagen und dass ich eben derjenige bin, der die Softwarestruktur im Stream macht, der offensichtlich ja nun wahnsinnig erfahren ist.

Und da ist es schwierig zu sagen, übrigens, ich bin irgendwie einer anderen Meinung.

Und das ist halt eine blöde Idee, was der Eberhard da gerade erzählt.

Und dem muss man sich halt, glaube ich, stellen.

Und ich glaube, dafür gibt es Mechanismen.

Also dieser gesamte Bereich kollaborative Modellierung, Events-Storming, was da irgendwie rumfliegt, das sind Sachen, wo man ja irgendwie sagt, jeder darf irgendwie Events schreiben.

Das ist sozusagen Gleichmacherei.

Das ist eben nicht so, dass jemand sich vorne hinstellt und sagt, so läuft der Geschäftsprozess, sondern es ist inhärent durch die Werkzeuge so, dass alle daran partizipieren können und halt Post-its schreiben können.

Und das funktioniert halt auch im Allgemeinen.

Also einfach dadurch, dass ich mich hinstelle und sage, okay, hier ist ein Miro-Board.

Ist das, was wir uns jetzt überlegt haben, eine gute oder eine schlechte Idee?

Macht da Punkte?

Stimmt über irgendwelche Post-its oder was auch immer?

Führt halt dazu, dass sich Leute dazu fast, also zwingend ist das das falsche Wort, aber ich erniedrige die Barriere dafür, dass sie sich halt teiligen.

Einfach durch ein Werkzeug.

Ich erniedrige die Barriere von, melde dich bitte und sag, der Eberhardt hat eine schlechte Idee, hin zu, mal halt ein Post-it und schreib drauf, was deine Idee ist oder klebe halt einen Punkt für, ist eine gute oder eine schlechte Idee.

Und das vielleicht auch irgendwie noch anonym.

Ich glaube, das ist halt eine Möglichkeit, diese Partizipation zu verbessern.

Das sozusagen erst mal dazu.

Jetzt kommt ein Thema, was mit diesem Thema stark in Verbindung steht.

Also was ich ja eigentlich beschrieben habe, ist, dass ich mich irgendwie als Architektin hinstelle und sage, ich möchte dafür sorgen, dass die Menschen, mit denen ich zusammenarbeite, idealerweise ihre Meinung von sich geben können und das halt idealerweise auch tatsächlich tun, mit einer möglichst niedrigen Barriere, damit ich halt Feedback bekomme und wir am Ende bessere Entscheidungen treffen.

Das ist ja die Motivation.

Das heißt, wenn ich mich irgendwie hinstelle und sage, ich bin in diesem Team und wir sind zu viert und ich treffe alle Entscheidungen, dann sind das halt meine Entscheidungen und die sind halt irgendwie, bedeuten halt, dass nur ich meine Expertise eingebracht habe, aber die anderen eben nicht.

So und das geht dann auch in eine andere Richtung.

Das geht nämlich auch in der Richtung, wo ich mich jetzt irgendwie hinstelle und sage, ich arbeite in einem Projekt als Architektin und da gibt es irgendwelche EntscheiderInnen und die treffen halt irgendwelche Entscheidungen und da hätte ich jetzt prinzipiell dieselbe Möglichkeit.

Also ich könnte jetzt irgendwie sagen, okay, ich gehe da in einen Diskurs, ich sage halt, ich finde diese Entscheidung gut oder schlecht oder was auch immer und wir diskutieren die halt.

Und was mir da so in den letzten Monaten so ein bisschen so blöd aufgestoßen ist, an einigen Stellen, ist halt diese Geschichte, dass Managemententscheidungen von ArchitektInnen häufig einfach als Managemententscheidungen, die man nicht hinterfragen kann, einfach akzeptiert werden.

Und das finde ich irgendwie schwierig.

Im Prinzip dieselbe Argumentation wie vorher.

Es bedeutet nämlich, dass ich meine Expertise im Bereich Architektur deutlich nutzbar mache und es bedeutet eben auch, dass ich mir eine Möglichkeit verbrauche, zu besseren Entscheidungen zu kommen.

Weil die halt irgendwas entscheiden, weiß ich nicht, irgendeine Technologie, die wir nutzen, irgendeine Aufteilung des Projekts, bedeutet das ja nicht, dass das die beste Entscheidung ist, sondern es kann sehr gut sein, dass die halt mit ihren Skills, die sie halt haben, einfach bestimmte Aspekte, die ich einfach reinbringen kann mit meinen Architekturskills, einfach nicht haben.

Also mein typisches Beispiel ist halt irgendwie, drei Teams sollen an einem Bauenden Kontext arbeiten.

So offensichtlich aus der Architekturperspektive vielleicht keine gute Idee, weil die halt an derselben Fachlichkeit arbeiten und sich stark koordinieren müssen.

Ist das jetzt etwas, was halt jemand versteht, der so auf dieser Management-Ebene arbeitet, bin ich mir nicht sicher.

Und ist ja vielleicht auch gar nicht so ein großes Problem, weil ich kann dieser Person das ja irgendwie erklären.

Und das ist eben etwas, was man sich verbaut, wenn man sagt, naja, also warum arbeiten jetzt mit diese drei Teams an dieser Fachlichkeit?

Weil das eine Managemententscheidung ist.

Ja, das ist halt keine Begründung.

Also das bedeutet halt nur, sagt ja nur, wie die Entscheidung gefällt worden ist.

Das bedeutet nicht, dass das etwas ist, was eben sinnvoll ist.

Ich finde das, also ich muss zugeben, und das ist vielleicht einer der Gründe, warum mir das halt irgendwie aufstößt, dass ich als Berater typischerweise professionell solche Sachen halt irgendwie hinterfrage.

Also das heißt, was ich typischerweise, was von mir typischerweise verlangt wird, ist, dass eine Entscheidung halt da ist und dass man dann sagt, hey, was hältst du denn davon?

Und dann kann ich halt irgendwie ohne Weiteres sagen, naja, also wenn halt drei Teams an der Fachlichkeit arbeiten, ich halte das für keine gute Idee.

Hier sind die Gründe dafür.

Dafür werde ich halt bezahlt.

Das ist halt bei Architekten irgendwie anders.

Nun ist es aber nicht so, dass ich halt sozusagen als Berater geboren wurde, sondern ich habe irgendwie selber auch als Architekt gearbeitet.

Und ich habe halt das Gefühl, dass, wenn man sich jetzt irgendwie hinstellt und einfach sagt, okay, diese Entscheidung, drei Teams sollen halt an dieser Sache halt arbeiten, ist für mich aus meiner Perspektive halt schwierig, weil, und das halt eben vernünftig begründet, dann wird man, glaube ich, meistens gehört oder zumindest halt nicht bestraft.

Und deswegen kann man das halt, glaube ich, durchaus machen.

Es ist aber auf der anderen Seite so, dass, also das ist auch etwas, was ich in der Diskussion vor einiger Zeit gelernt habe, und das ist, glaube ich, ein guter Punkt.

Also es kann irgendwie gut sein, dass man halt in einer Umgebung ist, wo man das häufiger versucht hat und dann halt irgendwann frustriert sagt, okay, ich kriege es halt nicht auf die Reihe und deswegen höre ich irgendwie auf, da Feedback zu geben.

Und das ist dann zumindest eine gute Erklärung, bedeutet halt aber trotzdem, dass halt am Ende die Ergebnisse halt sozusagen schwierig sind und man halt irgendwie bei suboptimalen Ergebnissen landet.

Ich finde, ich habe tatsächlich interessanterweise eher das Gefühl, dass da eine andere, dass die EntscheiderInnen teilweise darunter leiten und irgendwie sagen, naja, also warum kriege ich irgendwie kein Feedback?

Warum sagen die nicht, was wir anders machen sollten?

Und was eben bedeutet, also habt halt durchaus den Mut und sagt halt was dazu.

Ich glaube, mir persönlich hat es halt immer geholfen, auch als ich noch Architekt war.

Und ich verstehe halt, wie gesagt, ich finde es halt schwierig, da kein Feedback zu geben.

Ein Element davon ist, glaube ich, ich würde es jetzt mal Empathie nennen.

Ich weiß nicht, ob es so der ganz richtige Begriff ist.

Wir hatten diese Episode zu Psychological Safety und da hatte der, da hatten wir halt auch darüber gesprochen, dass eben die Empathie ein wichtiger Punkt ist, um vernünftig zu kommunizieren.

Mit dem Joseph Palrine war die Episode.

Und das bedeutet ich sollte halt diese Perspektive von anderen Menschen sozusagen einnehmen.

Ich weiß nicht, ob das so ein emotionales Ding ist.

Empathie ist für mich irgendwie ein emotionales Ding.

Es ist halt eher so ein, sagen wir mal, Rollenspiel, denke ich.

Also wie gucke ich jetzt als Manager, als Entscheider auf die Welt?

Und wir können jetzt mal ganz profan annehmen, dass da solche Sachen wie in der Rolle spielen, wie Deadlines, Aufwand, Geld oder was auch immer.

Was ja irgendwie Feines.

Die haben eine andere Perspektive und arbeiten auf dieser Ebene.

Und da ist es dann tatsächlich so, dass an einigen Stellen Dinge schwierig werden.

Also ich stelle jetzt fest, als Techniker, wir haben schlechte Qualität.

Jetzt ist die Frage, gibt es einen Schlüsselgrund, die zu verbessern?

Bekommen wir dadurch bessere Produktivität?

Das ist die Übersetzung, die ich leisten muss, damit jemand, der über Deadlines, Aufwand und so weiter redet, dann irgendwie sagen kann, ja, wir sollten die Qualität des Codes investieren.

Und das ist tatsächlich wirklich ein Problem, weil ich glaube, es ist schwer zu beziffern, wie viel Vorteil man da tatsächlich generiert.

Und das andere Problem ist, wenn ich ein System habe, das wirklich krass vergurkt ist, dann rede ich eigentlich über einen krassen Aufwand, um irgendwie wieder produktiv zu arbeiten, sodass es Spaß macht.

Sodass diese wirtschaftliche Diskussion vielleicht wirklich schwierig ist.

Oder ich habe vielleicht so einen Fall, wo ich sage, okay, ja, ich habe da eine Technologie, die ist veraltet, wird zwar noch unterstützt, aber irgendwann dann nicht mehr und dann habe ich ein Problem.

Wenn ich das jetzt irgendwie übersetze in Deadlines, Aufwand, also aus der Perspektive würde ich sagen, okay, muss ich da jetzt was tun?

Nee, muss ich nicht.

Dann lass mich lieber Features bauen.

Und das ist dann tatsächlich etwas, wo wir aber eigentlich in der Pflicht sind, diese Übersetzungsleistung zu liefern und zu sagen, naja, wenn du da nicht rangehst, dann passieren irgendwelche Dinge.

Und auf der anderen Seite ist das halt auch etwas, was so ein bisschen hilft, sozusagen Dinge zu filtern.

Also wenn man halt sagt, okay, ich versuche das jetzt da hin zu übersetzen und ich kann es halt in dieser Welt von Deadlines und so weiter keinen guten Punkt machen, dann ist das vielleicht insgesamt wirklich keine gute Idee.

Weil ich es sozusagen wirtschaftlich nicht rechnen kann.

Und dann muss man vielleicht darüber nachdenken, ob man eine andere, bessere Idee findet.

Also einfach zu sagen, hey, wir müssen halt die Kultqualität verbessern.

Meistens ist es halt so, dass da sehr, sehr viele Optionen sind, besser zu werden.

Und wenn man jetzt so ein Filter einschaltet und sagt, okay, und wo bringt es uns wirklich was?

Wo kann ich einen Case machen, der auch in Deadlines und so was sich niederschlägt?

Das ist dann vielleicht ein Filter, um dort richtig zu priorisieren.

Und ich finde das halt eigentlich okay.

Also nicht als zusätzlichen Fokussierungspunkt.

Ich habe mir hier noch aufgeschrieben, das bedeutet halt in gewisser Weise, dass wahrscheinlich zur Verbesserung eines Systems einer der besten Ansätze ist, ein Budget dafür zu reservieren.

Also zu sagen, jedes Team, das ein Sprint von 14 Tagen hat, also zehn produktive Tage, das setzt sich drei Tage hin und verbessert das System, so ein Budget.

Und dadurch wird eben die Verbesserung geschützt vor dem Zugriff von Leuten, die Features einfach machen wollen.

Das ist vielleicht wirklich der beste Weg, um dort zu einer Verbesserung zu kommen.

Und ein anderer Weg, das ist auch wieder so ein Kommunikationsding.

Vielleicht hilft es halt einfach, Dinge zu visualisieren.

Also zu sagen, guck mal hier, wenn ich das so visualisiere, dann ist unser gesamtes System rot.

Oder wir haben halt ein Technical Debt, der ist halt so und so hoch, obwohl ich das ganz schwierig finde, das halt tatsächlich zu beziffern.

Aber wenn ich dann irgendwie sagen kann, nicht und es wird irgendwie besser, also das nimmt irgendwie ab oder die Qualität nimmt zu oder was auch immer, dann kann ich dadurch halt irgendwie Progress signalisieren und kann dadurch dafür sorgen, dass eben vielleicht meine Initiative weitergebracht wird.

Und das ist wieder eine Geschichte von Kommunikation und halt sozusagen eben ein Schreiter kompatibler Kommunikation.

Wir haben da jetzt gerade durch die Agile-Meets-Architecture-Konferenz so ein paar ganz gute Episoden gehabt.

Also es gibt halt die Episode mit der Jacqui Read von vor 14 Tagen, wo es halt um Kommunikationspatterns ging.

Ich glaube das ist falsch, die ist von letzter Woche gewesen.

Also von letzter Woche.

Und das ist ein sehr breites Ding, also tatsächlich verschiedene Arten von Kommunikation, wo sie halt eben verschiedene Patterns vorgestellt hat.

Ich finde das halt sehr spannend.

Und ich finde halt auch die Episode, die wir diese Woche Dienstag gemacht haben mit Cosimo und Sophia zum Thema Impactful Mind Skills for Moments of Change and Uncertainty, da auch irgendwie relativ spannend, weil die halt viel sagt zu der Rolle sozusagen als Tech Leader und wie man sich da verhalten sollte und welche Ansätze es da gibt.

Ich glaube, das ist etwas, woraus wir etwas lernen können.

Und eine weitere Sache, die ich halt in dem Kontext immer wichtig finde, ist Fearless Change.

Darüber hatten wir auch eine Episode, wo es halt darum geht, wie ich eigentlich Änderungen in einer Organisation sozusagen durchsetzen kann.

Was wiederum bedeutet, dass eben tatsächlich Empathie und sich halt überlegen, was andere Menschen, wie andere Menschen das sozusagen sehen, ein ganz wichtiger Skill ist.

Weswegen ich es halt irgendwie hübsch bizarr finde, wenn es irgendwie Menschen gibt, die halt sagen, dass ein Übermaß an Empathie unser größtes Problem ist.

Ich glaube, das Gegenteil ist der Fall.

Und das eben auch im wirtschaftlichen Kontext, wo es halt letztendlich darum geht, effizient, effektiv irgendwie nicht möglichst viel Geld zu verdienen.

Ich glaube, auch da ist halt so etwas, ich versuche mal zu verstehen, was irgendwie entscheidend in solchen Rollen ein Thema ist.

Genau, Herr Bitschi hat gerade geschrieben, man muss die Leute ja auch mitnehmen.

Bei YouTube, ja, genau, guter Punkt.

Und das ist etwas, was ich tatsächlich in dieser Episode gar nicht so sehr gesagt habe.

Aber das ist, glaube ich, auch ein total wichtiger Aspekt.

Ja, doch, ich habe es gesagt.

Also wenn ich halt irgendwie diese vier Menschen habe und ich bin nur eine von diesen Menschen und ich habe irgendwie die anderen, ich muss jetzt irgendwie dafür sorgen, dass die anderen halt irgendwie auch mitgenommen sind und mitmachen.

Und das gilt eben auch für alle anderen, für Stakeholder und so weiter.

Und dafür ist dieser Prozess halt sozusagen wichtig.

Auch hier wieder mitnehmen, wie soll ich sagen, eigentlich, also ich möchte Sie nicht dabei mitnehmen, dass meine Ideen umgesetzt werden, sondern ich möchte, dass wir alle daran arbeiten, dass das Projekt sozusagen besser wird, dass wir irgendwie alle daran partizipieren.

Deswegen weiß ich nicht, ob der Begriff sozusagen optimal ist.

Ach so, und noch ein Hinweis, genau, das finde ich halt auch nochmal wichtig zu diesem Thema mit der Code-Qualität.

Ist ja, glaube ich, irgendwie eines von den Themen, wo TechnikerInnen und Management häufig aufeinanderprallen.

Was ich dabei irgendwie so lustig finde, ist, also in meiner Welt gibt es ganz viele EntscheiderInnen, die irgendwie sich hinstellen und sagen, irgendwie ist mein System technisch veraltet und auch schwer wartbar, müssen wir mal irgendwie neu machen.

Was halt bedeutet, dass genau diese Themen, die ja typischerweise mit TechnikerInnen identifiziert werden, also eben Code-Qualität, Änderbarkeit und so weiter, etwas ist, was halt an bestimmten Stellen auch Management natürlich interessiert, weil die halt irgendwann vielleicht feststellen, dass sie halt in einer Situation sind, aus der sie halt nicht mehr rauskommen.

Und dann fängt irgendwie wieder so ein Beratungsthema bei mir oder bei uns an.

Was eben bedeutet, dass eigentlich alle in Bezug auf die Code-Qualität an einem Strang ziehen sollten.

Sie tun es halt in der Praxis halt leider nicht.

Also es ist halt irgendwie wieder ein Kommunikationsproblem.

Also, da irgendwie darauf hinzuweisen, dass man vielleicht nicht…

Das passt übrigens auch zu dem Mitnehmen so ein bisschen.

Für mich gibt es bei den Entscheidungen so zwei Ebenen.

Also ich kann mich jetzt irgendwie hinstellen und kann sagen, ich habe halt selber eine bestimmte Meinung.

Also ich glaube halt, wir sollten dieses System mit Microservices bauen.

Und wenn ich halt Architekt der Architektin bin, kann ich das vielleicht auch irgendwie entscheiden.

Und das ist sozusagen diese sachlich-rationale Ebene.

Also nicht am Ende steht irgendwie die Entscheidung, wir bauen halt Monolithen oder eben ein Microservices-System.

Und das ist eben sozusagen diese rationale Ebene.

Die andere Ebene, also nicht die faktisch-rationale, das heißt, am Ende steht eben diese Entscheidung und sie wird halt irgendwie umgesetzt.

So und auf der anderen Ebene ist halt diese Geschichte mit, wenn wir etwas in einer bestimmten Art und Weise entscheiden, habe ich am Ende eine Organisation, die halt selber dazu in der Lage ist, Entscheidungen umzutreffen.

Also ohne, dass ich es jetzt mache, sondern selber.

Und die halt irgendwie auch tatsächlich umsetzt.

Und da passt das mit dem Mitnehmen vielleicht irgendwie dazu.

Das heißt also, ich stelle mich jetzt irgendwie hin und sage, okay, cool, wir bauen dieses System als Microservices.

Daraufhin sagt irgendwie die Entwicklungsmannschaft im Extremfall, finden wir irgendwie doof, wir wollen es als Monolith.

Sondern jetzt kann ich mich irgendwie hinstellen und kann irgendwie sagen, nee, also wenn ich halt irgendwie Architekt, Architekte bin, nee, das prügel ich jetzt durch, wir machen es als Microservices.

Und zwar deswegen, so hoffen wir zumindest, weil das eben die bessere Entscheidung ist auf dieser rationale, faktischen Ebene.

In Wirklichkeit stimmt das nicht, weil das ist ja nur meine Meinung.

Also ich kann nicht nachweisen, dass das wirklich die bessere Entscheidung ist.

Das wird höchstens retrospektiv klar.

Und was ich jetzt dadurch erzeuge, ist, dass diese andere Ebene, also kann das Team selber Entscheidungen treffen, fühlt es sich empowert und so weiter.

Die zerstöre ich dadurch, weil ich eben diese Entscheidung, die sie fällen würden, überschreibe.

Und das finde, also erstmal muss ich dazu sagen, wenn das so klar aufeinander trifft, diese beiden Perspektiven, dann ist eigentlich irgendwie schon etwas schief, weil es bedeutet, dass sie mich nicht überzeugen konnte und ich sie nicht.

Und das kann ja eigentlich nicht sein.

Also eigentlich müsste es halt so sein, dass man sich irgendwie einigen kann, insbesondere wenn halt eine Entscheidung so eindeutig gut oder schlecht ist.

Das heißt, vielleicht ist da noch ein anderes Problem, irgendwo ist es auf organisatorischer Ebene und auch Zusammenspiel-Ebene.

Und sonst gibt es halt für die Meisterentscheidung verschiedene ähnlich gute Lösungen.

Also wird es jetzt besser als Monolith oder als Microservicesystem?

Ja, ist irgendwie eine Abwägungswache.

Hängt ja auch davon ab, wie man die Monolithen aufteilt und so weiter und so weiter.

Ist also ein komplizierteres Thema.

Und da ist jetzt die Frage, wenn ich jetzt mich eben nicht hinstelle und sage, ich drücke meine Entscheidung durch, dann werde ich halt auf dieser anderen Ebene, also auf dieser Ebene von, was das Team tut und wie es da irgendwie funktioniert, eher einen Vorteil generieren und dass vielleicht dann tatsächlich etwas, worauf ich achten sollte.

Also das Team hat dann geübt, selber Entscheidungen zu treffen.

Für mich ein Beispiel ist halt irgendwie nicht wie bei euch ein Frontend.

Ich glaube, es ist total wichtig, dass ich beim Frontend eine Modularisierung habe, sodass eben unterschiedliche Teams unterschiedliche Teile des Frontends möglichst unabhängig entwickeln können.

Wenn sich die Menschen dagegen entscheiden und halt irgendwas bauen, was halt irgendwie den Fokus auf etwas legt, wo ich eben nicht so stark unabhängig entwickeln kann, dann würde ich mich wahrscheinlich hinsetzen und würde halt sagen, das ist eine blöde Entscheidung, ich überschreibe das.

Aber welche konkrete Technologie sie benutzen, wie sie das konkret ausführen, da weiß ich gar nicht, ob ich das irgendwie entscheiden wollen würde.

Da ist halt für mich die andere Ebene, also die Ebene, dass eben die Teams selber Entscheidungen treffen und dass die das irgendwie üben, glaube ich, wichtig.

HeavyTree schrieb, ich meine das Mitnehmen eher im Sinne davon, eine Resonanz, ein gemeinsames Verständnis und Einigung zu bekommen.

Genau, und das ist eigentlich das, was ich will.

Und das impliziert aber, und ich glaube, das ist so ein bisschen das, was ich sagen wollte, dass ich halt nicht versuchen darf, meine eigene Meinung einfach durchzusetzen, sondern ich muss mich irgendwie auch hinstellen und muss halt so ein bisschen, wie soll ich sagen, also da im Kompromiss bereit sein.

Also wenn ich ein System bauen will, das halt exakt so aussieht, wie ich es gerne hätte, sollte ich das zu Hause machen.

Wenn ich ein System, in anderen Situationen, muss ich anderen Leuten die Möglichkeit geben, da mit drauf zu achten oder das mit zu beeinflussen und dann kommt halt irgendwie auch was anderes raus.

Noch ein wichtiger Punkt ist, ich habe mir hier aufgeschrieben, ist das nicht alles relativ.

Also am Ende ist das ja eigentlich so, dass wir jetzt über ein Konzept für eine Organisation und über ein bestimmtes Menschenbild sprechen.

Partizipation vs. Diktatur

Also wir reden über etwas, wo ich partizipativ bin, wo ich mitbestimmt bin, wo ich irgendwie sage, die Leute sollen halt irgendwie mitbestimmen, sollen ihre Meinung zum Besten geben, wir wollen gemeinsam gute Entscheidungen treffen und so weiter und so weiter.

Und also demokratisch ist das glaube ich nicht, das ist was anderes, gemeinsam irgendwie Entscheidungen treffen, nicht durch Mehrheit, aber eben so, dass idealerweise diese Entscheidungen von allen geteilt werden.

Und was ich ja jetzt machen könnte, wäre, dass ich eben permanent, also dass ich das Gegenteil mache, ich könnte mich jetzt irgendwie hinstellen und könnte sagen, ich bin Eberhard, ich habe irgendwie wahnsinnig viel Erfahrung mit Architektur, ich mache jetzt einfach das, was ich halt für richtig halte und ihr müsst es halt ausführen.

Ich entscheide das jetzt, also diktatorisch.

Und ich habe irgendwie ein Menschenbild, was halt letztendlich sagt, die anderen haben irgendwie eh keinen Plan und deswegen höre ich halt nicht ernsthaft auf sie.

Ich hätte halt keinen Bock dazu, das auszuprobieren und das ist auch nicht der Typ, der ich bin, glaube ich zumindest, aber ich halte es nicht für ausgeschlossen, dass man damit tatsächlich erfolgreich sein kann und ich glaube, das haben irgendwie, also ich habe das Gefühl, diese Rolle, wo man sagt, ich habe einen Architekten, der sozusagen das alles vordenkt und die EntwicklerInnen führen das halt nur aus, das ist durchaus eine Räumenbeschreibung, die halt lange Zeit relativ populär war und es war schon so, dass die Projekte halt, glaube ich, einigermaßen funktioniert haben.

Was ich damit sagen, also ich möchte damit nicht sagen, dieses partizipative Modell ist eine schlechte Idee, im Gegenteil, ich glaube, es gibt eine Menge Gründe dafür, dass es ein gutes Modell ist und wenn man sich irgendwie, ich habe ja Episoden gemacht zum Thema Crew Resource Management und auch zum Thema Auftragstaktik und was eben ein militärisches Konzept ist und ich würde behaupten, diese Ansätze basieren halt darauf, dass ich versuche, anderen Menschen eine Rolle zuzuweisen, wo sie halt Dinge beeinflussen können.

Crew Resource Management sagt halt, ich muss dafür sorgen, wenn ich der Kapitän bin, dass das Flugzeug halt fliegt, dass der erste Offizier mir Feedback gibt und mir im Notfall irgendwie auch sagt, das, was du da gerade machst, ist irgendwie nicht so gut und das torpediere ich, indem ich sage, doch, ich habe recht, ich bin übrigens ja der Kapitän, du hast keine Ahnung und ich bin die erfahrene Person und ich mache das jetzt mal kurz.

So und das bedeutet eben, dass der diktatorische Ansatz dort, also ich würde behaupten, ich bin kein Flugkapitän oder kein Pilot, aber ich würde behaupten, damit hätte man halt echte Schwierigkeiten, wenn man das hat versucht umzusetzen und interessanterweise ist der Auftragstaktik ähnlich, also bei Auftragstaktik ist es eben so, dass ich einem Militär, einer militärischen Einheit einen Auftrag erteile und die militärische Einheit entscheidet oder die jeweilige Person entscheidet dann, wie sie es halt macht.

Das heißt also auch dort, dass ich irgendwie ein Ziel vorgebe, mein Beispiel ist immer, Alter, denn wie diese Brücke und ich erkläre halt auch das hier, weil wir uns darüber zurückziehen müssen und wie die das jetzt macht, ist irgendwie das Problem von denen und es ist eben auch so, dass die das, wenn jetzt irgendwelche Umstände sich halt ändern, nicht, wir haben uns vielleicht zurückgezogen, dann macht es halt keinen Sinn mehr die Brücke zu halten, dass sie dann eben auch entsprechend in meinem Sinne sozusagen handeln.

So das bedeutet, es gibt sehr gute Indikatoren dafür, dass eben diese Idee mit Partizipation, Delegation und so weiter eine gute Idee ist, auch außerhalb unserer eigenen Branche.

In Bereichen, in denen ich das überraschend finde, Militär finde ich persönlich überraschend, dass die halt irgendwie in diese Richtung gegangen sind, aber ich bin da halt auch nicht Laie, ich habe irgendwie Zivildienst gemacht.

Ich fand das halt beim Fliegen auch ein bisschen überraschend, weil das ist halt sehr stark strukturiert, da gibt es eine formale, also die haben eine formalisierte Sprache, die haben sehr klare Ziele, bei uns ist es irgendwie, glaube ich, sehr viel schwerer zu sagen, was die Ziele von irgendwelchen Projekten sind und das bedeutet aber, dass eben in diesen Bereichen diese Ansätze, die offiziell sinnvolle Ansätze sind und das bedeutet, es ist wahrscheinlich tatsächlich nicht gut, diese diktatorische Richtung zu gehen und da haben wir glaube ich auch in unserer Branche entsprechende Erfahrungen gesammelt.

Ich bin mir allerdings nicht sicher, wie groß sozusagen der Nachteil davon ist.

Happy Tree hatte noch geschrieben, wenn es das Management 10 Programmieren gibt, dann ist glaube ich, und das ist vielleicht noch ein Punkt da, das erste, was ich machen würde, also wenn ich damit eine Webanwendung bauen will, würde glaube ich investieren in die Richtung, dass die halt Webanwendungen bauen können.

Also vielleicht muss ich dann eben tatsächlich das Ziel, ich baue etwas, ich baue die Webanwendung, unterpriorisieren gegenüber, ich versuche denen halt sozusagen die Skills mitzugeben, um halt überhaupt in diesen Modus reinzukommen und dann ist irgendwie tatsächlich, glaube ich, diese Auswirkung auf das soziale Leben vielleicht noch wichtiger.

Das Kali schreibt, es gibt glaube ich auch EntwicklerInnen, die genau damit freien Sinn einfach ausführen.

Die Schuld liegt dann beim Architekten, wäre auch nicht meins, aber die Menschen sind unterschiedlich.

Ja, guter Punkt und das ist glaube ich eine gute Ergänzung zu diesem diktatorischen Ansatz.

Delegation von Verantwortung

Also dieser partizipative Ansatz impliziert halt, dass Menschen halt Verantwortung übernehmen, weil das ist ja letztendlich das, was dabei rauskommt und manche Menschen wollen das halt nicht und das führt dann wie zu der Frage, will ich die dazu zwingen.

Und Menschen zwingen ist vielleicht nie eine gute Idee, aber was ich halt interessant finde, ist, dass eben in solchen militärischen Konstrukten, die ja eigentlich auf sowas wie Befehl und Gehorsam scheinbar setzen, dass eben auch dort so eine Delegation von Verantwortung halt etwas ist und offensichtlich kriegen die das halt auch strukturiert in ihre Organisationen rein.

Also nicht die Armeen funktionieren so.

Von daher würde ich halt schon versuchen, die halt sozusagen in diese Richtung zu bringen.

Also ich glaube, es gibt zwei Möglichkeiten damit umzugehen.

Die eine Möglichkeit wäre, ich versuche halt diese Menschen in eine andere Richtung zu bringen.

Die andere Möglichkeit ist, ich gebe denen eben Aufgaben, die halt dafür geeignet sind.

Also baue das halt irgendwie und mach halt und sag mir, wenn du fertig bist.

Und ich kann mir halt auch vorstellen, dass das durchaus im Projekten halt erfolgsversprechend sein kann.

Ich habe mir am Ende noch aufgeschrieben, weil das irgendwie so eine Geschichte ist, die halt bei diesen Episoden halt, glaube ich, nochmal ein wichtiger Punkt ist.

Wie soll ich sagen?

Lernen aus Fehlern

Man kann das, glaube ich, alles sehr logisch erklären und es ist mir auch nachvollziehbar, dass das halt irgendwie etwas ist, wie eigentlich sowas funktionieren sollte.

Man muss aber ehrlich gestehen, dass wir halt alle auf diesen Ebenen halt irgendwo ständig scheitern.

Und für mich ist eigentlich dann der Punkt, dass wir dort uns zumindest lernen und halt weiterentwickeln.

Und da ist halt ein wichtiger Punkt, das sehe ich ja manchmal, diese Geschichte mit, naja, ich bin halt daran gescheitert, dass die anderen halt irgendwie doof sind und nicht, also dass halt andere sich sozusagen viel verhalten haben.

Das mag durchaus so sein.

Das hilft mir halt nur nichts, weil daraus kann ich halt irgendwie nichts lernen.

Selbstreflexion

Das heißt also, die Frage wäre halt, was kann ich jetzt irgendwie eigentlich anders tun?

Und ich fand halt insbesondere die Episode mit Sophie und Cosima interessant, weil die halt auch sehr stark genau darauf fokussiert haben zu sagen, also wir Tech-Leader, ich glaube Architekten sind eigentlich Tech-Leader, müssen halt irgendwie da an uns arbeiten.

Und das ist auch das Einzige, was wir beeinflussen können, also wir können die anderen irgendwie schwerlich beeinflussen.

Und es gibt halt ein Beispiel in tatsächlich jetzt in meiner Erlebniswelt, wo wir uns oder ich mich gefragt habe, was hätten wir denn eigentlich anders machen können?

Das Ergebnis war, naja, wir hätten uns da theoretisch anders verhalten können und hätten das wahrscheinlich, das Problem, was da irgendwie aufgetaucht ist, einfangen können, indem wir bestimmte Maßnahmen vorher ergriffen hätten und halt versucht hätten, vorher nochmal Dinge halt irgendwie klar zu ziehen und halt irgendwie da irgendwelche Gespräche im Voreinander zu führen.

Aber das ist halt irgendwie erst retrospektiv klar.

Sprich, das hätten wir ja vorher nicht antizipiert.

Mich hinterlässt das halt nicht sehr zufrieden, weil es ist jetzt irgendwie eine Situation, wo ich jetzt sagen würde, okay, das ist halt irgendwie nicht gut gelaufen.

Und es ist eben tatsächlich so, dass ich im Prinzip sage, naja, das konnte ich aber nicht wirklich verhindern und das konnten wir nicht wirklich verhindern.

Das ist etwas, wo erst retrospektiv klar ist, dass wir halt etwas machen können.

Wir wären in derselben Situation, würde sozusagen nochmal dasselbe passieren.

Was eben bedeutet, nicht, es könnte jetzt sein, dass in derselben Situation tatsächlich nochmal dasselbe passiert, was halt irgendwie doof ist.

Aber immerhin haben wir halt die Frage gestellt, okay, können wir daraus was lernen?

Und vielleicht ist es eben so, dass wir das nächste Mal, wenn wir eine ähnliche Situation haben, die eben auch zu so Schwierigkeiten führen kann, das dann eher erkennen und halt vorher Maßnahmen ergreifen und halt versuchen, die Situation sozusagen zu klären.

Das ist aber auf jeden Fall besser, als zu sagen, naja, die anderen haben sich halt irgendwie doof verhalten.

Nicht also, weil zumindest jetzt irgendwie bei mir im Kopf irgendwie drin ist, naja, also wir hätten halt schon Möglichkeiten gehabt, wenn wir halt mit der Person gesprochen hätten, vorher gesprochen hätten, die halt irgendwie abgeholt hätten, dann wäre das halt eben nicht später zu so einem Problem geworden.

Und vielleicht hilft mir das halt in der nächsten Situation, wenn ich jetzt irgendwie gesagt hätte, naja, die Person hat sich halt irgendwie aus mysteriösen Gründen daneben benommen und ich konnte es halt nicht verhindern, dann habe ich halt überhaupt gar keine Chance, in einer ähnlichen Situation überhaupt was besser zu machen.

Und das bedeutet eben, dass, glaube ich, die, also nicht, wir machen halt irgendwie alle ständig Fehler oder haben halt ständig Optionen, besser zu werden.

Ich habe irgendwie insbesondere da gespürt, dass es halt sehr leicht ist, dann zu sagen, naja, ich bin eben an den anderen Menschen gescheitert.

Das hilft halt eben nur nicht.

Also man muss da sozusagen von sich selbst irgendwie losarbeiten.

Und auch da wieder die Episode mit Cosima und Sophia, da war ja auch eben die Aussage, dass wir sozusagen als Techleads einen bestimmten Ansatz halt vorleben.

Und wenn wir den halt vorleben und umsetzen, dann folgen uns halt die anderen Leute halt sozusagen am ehesten noch nach.

Ich schaue noch, ob irgendwelche Fragen sind.

Das scheint aber nicht der Fall zu sein.

Dann würde ich sagen, sind wir soweit durch.

So eine kurze Vorschau.

Also wir werden nächste Woche am Freitag eine Episode haben.

Da ist das Thema noch nicht klar.

Und wir haben dann tatsächlich in der Woche da drauf, ich packe das mal hier auch in den Chat, da gibt es halt irgendwie einen Plan, den kann man auf der Webseite finden.

Und zwar ist es so, dass wir am 3.4., das müsste der Donnerstag sein, genau, am 3.4. haben wir um 15 Uhr die Session Wortly Maps meets Software Architecture mit Simon Wortley und Markus Hacker.

Da geht es also tatsächlich mit dem Erfinder der Wortley Maps um das Thema Wortley Maps und um das Thema, wie man damit Softwarearchitektur betreiben kann.

Und dann haben wir am Freitag, eine Stunde später als geplant, als üblich, also erst um 14 Uhr, die Episode Building Product Teams Beyond Organisational and Geographical Boundaries mit Anna Naht und Leyda Ullovic.

Das ist auch, das ist so eine Art Retrospektive von der HR Meets Architecture.

Also beide Episoden sind live von der HR Meets Architecture.

Simon Wortley hält dann ein Keynote, Markus Hacker spricht da und die beiden, Anna und Leyda, haben halt auch einen Talk, den werden wir dazu sozusagen nochmal dann zusammenfassen und anschauen.

Und wir haben, ich glaube, ich habe in den letzten Episoden auch schon gesagt, für die HR Meets Architecture ein Rabattcode, das ist AMA, S A I S, da gibt es irgendwie zehn Prozent weniger.

Das ist also dann nochmal eine Möglichkeit.

Ich hatte da übrigens auch einen Vortrag.

Das ist dann, haben wir auch nochmal eine Möglichkeit, da verbilligt hinzukommen.

Genau, dann würde ich sagen, vielen Dank.

Wir sehen uns vielleicht nächste Woche.

Vielen Dank auch für die vielen Fragen, für die Diskussion und ich wünsche ein schönes Wochenende und ich würde sagen, bis dahin.

Vielen Dank.