Führung, Einfluss und Entscheidungsfindung

Führen ohne Autorität

Die meisten Architekten führen nicht die Menschen, die bauen, was sie entwerfen. Teams berichten an Engineering-Manager, Prioritäten liegen beim Produktmanagement, Budgets bei der Bereichsleitung. Dennoch wird vom Architekten erwartet, dafür zu sorgen, dass bedeutende Entscheidungen gut getroffen und über viele Teams hinweg eingehalten werden; das ist die Kernverantwortung, die in Abschnitt 1.4 beschrieben wurde. Die Lücke zwischen Verantwortung und formaler Autorität ist die prägende Bedingung dieser Arbeit, und sie zu schließen ist eine Frage des Einflusses.

John French und Bertram Raven unterschieden in ihrer klassischen Studie über soziale Macht (1959) Machtgrundlagen, die mit einer Position verbunden sind (legitime Autorität, die Fähigkeit zu belohnen und die Fähigkeit zu bestrafen), von solchen, die zu einer Person gehören (Expertenmacht und Identifikationsmacht, also Respekt und Identifikation, die andere empfinden); Raven ergänzte später die Informationsmacht, die Fähigkeit, Fakten einzubringen, die Meinungen ändern. Architekten haben selten viel Positionsmacht, und wenn doch, ist ihr Einsatz teuer: Eine kraft Rang auferlegte Entscheidung wird befolgt, aber nicht getragen, und wer anderer Meinung war, hört auf, Ihnen von Problemen zu berichten. Dauerhafter Einfluss in der Architektur beruht fast vollständig auf Fachwissen, Information und Beziehungen.

Das ist kein Soft Skill, der an die technische Arbeit angeflanscht wird. Ein solides Design, das niemand übernimmt, hat dieselbe Wirkung wie gar kein Design, und ein mittelmäßiges Design, das Teams verstehen und mittragen, schlägt oft ein brillantes, das sie umgehen. Der Rest dieses Abschnitts behandelt Einfluss als eine Reihe erlernbarer Praktiken: Vertrauen aufbauen, Entscheidungen moderieren, mit Konflikten umgehen, nach oben kommunizieren, andere fördern und die Fallen vermeiden, in die Gruppen tappen.

Vertrauen und Glaubwürdigkeit aufbauen

David Maister, Charles Green und Robert Galford bieten in The Trusted Advisor (2000) ein nützliches Modell. Vertrauen wächst mit Glaubwürdigkeit (Sie wissen, wovon Sie sprechen), Verlässlichkeit (Sie tun, was Sie sagen) und Nähe (Menschen fühlen sich sicher, Schwieriges bei Ihnen anzusprechen), und es schrumpft mit Selbstbezogenheit (dem Eindruck, dass Sie Ihren eigenen Interessen dienen, etwa recht zu behalten, klug zu wirken oder Ihr Design zu schützen). Die Erkenntnis des Modells für Architekten: Die Selbstbezogenheit steht unter dem Bruchstrich, sie teilt alles andere. Einem Architekten, der brillant und verlässlich ist, aber erkennbar jede Diskussion gewinnen muss, wird nicht vertraut.

In der Praxis entsteht Glaubwürdigkeit auf kleinen, sichtbaren Wegen. Liegen Sie bei kleinen Dingen richtig, bevor Sie bei großen um Vertrauen bitten. Bleiben Sie nah genug am Code, um seine wirklichen Kosten zu verstehen: Schreiben Sie den Spike, reviewen Sie den Pull Request, nehmen Sie an einem Incident-Review teil. Sagen Sie, was Sie nicht wissen und wie Sie es herausfinden würden. Halten Sie jede Zusage ein, besonders die langweiligen. Würdigen Sie die Leistung anderer öffentlich und übernehmen Sie die Verantwortung für Ihre eigenen Fehler, ebenfalls öffentlich. Erklären Sie die Begründung hinter jedem Prinzip, damit andere es auch in Situationen anwenden können, die Sie nicht vorhergesehen haben.

Vertrauen hängt auch vom Klima um Sie herum ab. Amy Edmondsons Forschung zur psychologischen Sicherheit, beginnend mit einer Studie über Arbeitsteams von 1999, zeigte, dass Teams, deren Mitglieder es für sicher halten, Fehler zuzugeben und andere herauszufordern, mehr lernen und bessere Leistungen erbringen. Architekten prägen dieses Klima stärker, als ihnen bewusst ist. Auf schlechte Nachrichten mit Neugier statt mit Schuldzuweisung zu reagieren, ausdrücklich um Einwände zu bitten (Was würde das scheitern lassen?) und denen zu danken, die sie vorbringen: Das macht es möglich, von einem fehlerhaften Design zu erfahren, solange es noch günstig zu beheben ist.

Entscheidungen moderieren

Viele Architekturdiskussionen sind in Wahrheit Diskussionen über das Verfahren: wer entscheiden darf, wer gefragt werden muss und wie Meinungsverschiedenheiten beigelegt werden. Werden die Entscheidungsrechte geklärt, bevor man über die Sache spricht, nimmt das viel Hitze heraus. Abschnitt 11.4 beschrieb den Advice Process, bei dem jeder eine Entscheidung treffen darf, sofern er den Rat der Betroffenen und der Fachleute einholt; andere Organisationen nutzen ein Architektur-Review-Gremium, eine benannte entscheidungsverantwortliche Person je Domäne oder Rollenmatrizen wie RACI. Der konkrete Mechanismus ist weniger wichtig, als dass er im Voraus bekannt ist.

Innerhalb der jeweils geltenden Entscheidungsrechte ist der Architekt oft der Moderator: die Person, die die Frage formuliert, dafür sorgt, dass die richtigen Leute und Belege da sind, und die Gruppe zu einer Entscheidung führt, die Bestand hat. Verschiedene Entscheidungsverfahren passen zu verschiedenen Situationen, und das Verfahren bewusst zu wählen gehört zur Aufgabe.

Zwei Verfahren werden oft verwechselt. Konsens sucht einen Vorschlag, den alle aktiv unterstützen; er schafft starkes Commitment, ist aber langsam und gibt jeder einzelnen Person faktisch ein Vetorecht. Die Konsententscheidung, entwickelt ab den 1970er-Jahren in Gerard Endenburgs Soziokratie in den Niederlanden, nimmt einen Vorschlag an, sofern niemand einen begründeten Einwand erhebt, dass er Schaden anrichten oder die Gruppe zurückwerfen würde. Die Frage ändert sich von „Sind alle einverstanden?“ zu „Kann jemand damit nicht leben, und warum?“. Ein Satz aus der soziokratischen Praxis fasst die Schwelle gut: gut genug für jetzt, sicher genug für einen Versuch. Der Konsent funktioniert besonders gut bei Zweiwegtür-Entscheidungen, die sich überprüfen lassen, sobald neue Belege vorliegen. Der Rough Consensus der IETF, beschrieben in Abschnitt 4.8, ist ein naher Verwandter.

Lässt sich keine Einigung erzielen, muss jemand entscheiden, und es sollte bereits klar sein, wer. Disagree and Commit, ebenfalls in Abschnitt 4.8 behandelt, verlangt, dass die Beteiligten ihren Standpunkt vor der Entscheidung voll vertreten und die Entscheidung danach voll mittragen. Das funktioniert nur, wenn der Widerspruch wirklich gehört wurde, der Dissens festgehalten ist (im Architecture Decision Record, mit seinen Gründen) und es ein vereinbartes Signal gibt, das die Frage wieder öffnen würde.

Konflikte und Organisationspolitik

Organisationspolitik ist schlicht die Art, wie Gruppen mit unterschiedlichen Interessen, begrenzten Ressourcen und eigenen Karrieren zu Entscheidungen kommen. Sie ist keine Verfälschung der Architekturarbeit, sondern ihr Umfeld. Wer sie ignoriert, wird dadurch nicht prinzipientreuer, nur weniger wirksam. Die Werkzeuge aus früheren Kapiteln lassen sich direkt anwenden: Die Stakeholder-Landkarte und das Macht-Interesse-Raster aus Abschnitt 1.5 zeigen, wer betroffen ist und wer blockieren kann, und die Dokumentation der Abwägungen aus Abschnitt 1.6 macht Positionen sichtbar.

Roger Fishers und William Urys Getting to Yes (1981) ist nach wie vor der nützlichste Leitfaden für sachgerechtes Verhandeln, und seine vier Ideen lassen sich direkt übertragen. Trennen Sie die Menschen vom Problem: Die Leiterin des Zahlungsteams blockiert nicht, sie sorgt sich um Kartendaten. Konzentrieren Sie sich auf Interessen, nicht auf Positionen: „Wir dürfen Kafka nicht verwenden“ ist eine Position, „Wir können keine zusätzliche Rufbereitschaftslast übernehmen“ ist ein Interesse, das mehrere Designs erfüllen könnten. Entwickeln Sie Optionen zum beiderseitigen Vorteil, bevor Sie entscheiden. Bestehen Sie auf objektiven Kriterien, die vereinbart werden, bevor Optionen verglichen werden. Auch ihre Idee der besten Alternative zu einer Verhandlungslösung (BATNA) ist nützlich: Zu wissen, was passiert, wenn keine Einigung zustande kommt, zeigt allen, wie viel die Einigung wert ist.

Das Konfliktstil-Modell von Kenneth Thomas und Ralph Kilmann (1974) beschreibt fünf Arten, auf Konflikte zu reagieren, je nachdem, wie viel Gewicht Sie Ihren eigenen Anliegen und denen der Gegenseite geben. Keine ist immer richtig; die Kunst besteht darin, bewusst zu wählen, statt in Gewohnheiten zurückzufallen.

Einige praktische Gewohnheiten helfen in jedem Fall. Überraschen Sie einen Stakeholder nie in einer öffentlichen Besprechung mit einem Vorschlag, der ihn betrifft; sprechen Sie vorher unter vier Augen mit ihm (japanische Organisationen nennen diese vorbereitende Abstimmung Nemawashi). Wenn eine Eskalation nötig ist, eskalieren Sie gemeinsam: Beide Parteien legen der Person, die entscheiden kann, die Meinungsverschiedenheit und die Optionen vor, statt getrennt Lobbyarbeit zu betreiben. Und halten Sie Meinungsverschiedenheiten über Designs getrennt von Urteilen über Menschen, in dem, was Sie sagen, und in dem, was Sie schreiben.

Mit der Geschäftsleitung kommunizieren

Abschnitt 4.8 behandelte, wie man eine Botschaft auf ihr Publikum zuschneidet und mit der Antwort beginnt. Führungskräfte verdienen etwas mehr Aufmerksamkeit, weil sie die Budgets und die Autorität innehaben, von denen Architekturarbeit abhängt, und weil Architekten sie am häufigsten verlieren, indem sie zu viel erklären und zu wenig fordern.

Stellen Sie jedes Thema in den Begriffen dar, die Führungskräfte bereits steuern: Umsatz, Kosten, Risiko, Time-to-Market, Kundenerlebnis, Regulierung und Personal. Bringen Sie Optionen statt eines einzigen Plans mit, jeweils mit ihren Kosten, ihrem Risiko und dem, was sie aufgeben, und sagen Sie, welche Sie empfehlen und warum. Quantifizieren Sie, wo Sie es ehrlich können, und sagen Sie, wie belastbar die Zahlen sind; eine Spanne mit genannter Grundlage ist glaubwürdiger als Scheingenauigkeit. Sagen Sie ausdrücklich, welche Entscheidung oder Unterstützung Sie von ihnen brauchen und bis wann. Bereiten Sie sich auf die Frage vor: Was würden Sie tun, wenn es Ihr Geld wäre? Und lassen Sie eine Führungskraft nie zuerst von jemand anderem von einem ernsten Risiko erfahren.

Führungskräfte interessiert oft weniger, wie ein System funktioniert, als ob seine Verantwortlichen es im Griff haben. Zu zeigen, dass Risiken bekannt sind, Verantwortliche haben, gemessen und verringert werden (zum Beispiel durch ein Architektur-Risikoregister oder die Fitness Functions aus Abschnitt 11.3), schafft mehr Vertrauen als jedes Diagramm. Abschnitt 11.8 zeigt, wie man Architekturarbeit in die Form bringt, mit der Führungskräfte Investitionen vergleichen: den Business Case.

Der Architect Elevator

Gregor Hohpes The Software Architect Elevator (O’Reilly, 2020) liefert das einprägsamste Bild dieser Arbeit. Große Organisationen sind wie hohe Gebäude. Im Penthouse legt die Geschäftsleitung Strategie und Budgets fest; im Maschinenraum bauen und betreiben Engineers die Systeme; dazwischen liegen viele Etagen des Managements, und Informationen, die sie durchlaufen, werden unterwegs gefiltert und verzerrt. Hohpes Architect Elevator fährt zwischen Penthouse und Maschinenraum hin und her und trägt Informationen in beide Richtungen: Strategie und ihre Gründe hinunter zu den Menschen, die Systeme bauen, und technische Realitäten (Randbedingungen, Risiken, Kosten und Optionen, von denen das Unternehmen nicht wusste, dass es sie hat) hinauf zu denen, die strategische Entscheidungen treffen.

Hohpes Punkt ist, dass der Wert des Architekten im Verbinden der Etagen liegt. Ein Architekt, der im Penthouse bleibt, wird zum Strategen im Elfenbeinturm, dessen Pläne ignorieren, was technisch möglich ist; einer, der im Maschinenraum bleibt, wird zum geschätzten Experten, dessen Warnungen nie die Menschen erreichen, die darauf reagieren könnten. Den Aufzug gut zu nutzen heißt, auf jeder Etage Sprache und Detailtiefe zu wechseln, ohne die Substanz zu ändern; genau das ist die Publikumskompetenz aus Abschnitt 4.8, angewandt auf eine ganze Organisation.

Andere Architekten fördern

Ein Architekt, der jede bedeutende Entscheidung selbst trifft, wird zum Engpass, und die Architekturkompetenz der Organisation geht mit ihm. Andere zu fördern ist daher Teil der Rolle, kein optionales Extra. Es hilft, drei Tätigkeiten zu unterscheiden. Mentoring gibt Ihre Erfahrung und Ihren Rat weiter. Coaching stellt Fragen, die jemandem helfen, zu einer eigenen Antwort zu kommen, und baut so schneller Urteilsvermögen auf. Sponsoring nutzt Ihre Glaubwürdigkeit, um jemandem Chancen zu verschaffen: ihn für die Leitung eines Designs empfehlen, seinen Namen auf den Vorschlag setzen, ihn zur Besprechung mit der Geschäftsleitung einladen.

Zu den praktischen Techniken gehören Pairing bei Designs und Reviews, weniger erfahrene Engineers den ADR zu einer Entscheidung schreiben zu lassen und ihn mit ihnen durchzugehen, Architektur-Katas (Abschnitt 11.2) als Übung durchzuführen, Entscheidungen innerhalb benannter Guardrails zu delegieren und in Designdiskussionen laut zu denken, damit andere sehen, wie Abwägungen gewichtet werden, und nicht nur das Ergebnis.

Viele Organisationen bieten heute einen technischen Karrierepfad parallel zum Management. Will Larsons Staff Engineer: Leadership beyond the management track (2021) machte den Begriff Staff-plus für Staff, Principal und noch erfahrenere Individual Contributors populär und beschrieb vier verbreitete Archetypen auf Grundlage von Interviews mit Menschen in diesen Rollen. Tanya Reillys The Staff Engineer’s Path (O’Reilly, 2022) gliedert die Arbeit in Denken im großen Ganzen, die Umsetzung großer Projekte und die Weiterentwicklung der Engineers um Sie herum. In ihrem Vortrag „Being Glue“ von 2019 lenkte Reilly zudem die Aufmerksamkeit auf die koordinierende Arbeit (Blockaden lösen, das fehlende Dokument schreiben, die Lücke zwischen Teams bemerken), die Projekte am Leben hält, bei Beförderungen aber oft nicht honoriert wird; Architekten sollten bemerken, wer sie leistet, und dafür sorgen, dass sie zählt.

Entscheidungsfallen, noch einmal betrachtet

Abschnitt 1.6 nannte die individuellen Verzerrungen, die Architekturentscheidungen verfälschen: Ankereffekt, versunkene Kosten, Gruppendenken, lebenslaufgetriebene Entwicklung, Hype und Bestätigungsfehler. Wer Entscheidungen in Gruppen leitet, trifft auf zusätzliche eigene Fallen, die aus Status, Ermüdung und organisatorischer Eigendynamik entstehen statt aus individuellem Denken.