Dezentralisierung von Entscheidungsfindung mit Shawna Martell & Dan Fike
- Aisha Washington
- vor 1 Stunde
- 7 Min. Lesezeit
Engineering-Organisationen sagen oft, dass sie möchten, dass Teams autonom handeln. In der Praxis wandern Entscheidungen jedoch weiterhin nach oben, geraten in Meetings ins Stocken oder hängen davon ab, welcher erfahrene Architekt gerade verfügbar ist. Shawna Martell und Dan Fike beschreiben ein anderes, bei Cartek entwickeltes Modell: eine explizite Engineering-Strategie etablieren und anschließend vertrauenswürdige technische Führungskräfte – sogenannte Navigators – befähigen, Teams bei ihrer Anwendung zu unterstützen.
Ihr Ansatz betrachtet Dezentralisierung als mehr als das Delegieren von Befugnissen. Menschen benötigen gemeinsame Prinzipien, ausreichend lokalen Kontext, Zugang zu erfahrenen Beratern und eine Möglichkeit, die Strategie infrage zu stellen oder zu verbessern. Wenn diese Elemente zusammenwirken, können einzelne Mitwirkende folgenschwere Entscheidungen treffen, ohne jede Frage durch das Management oder eine zentralisierte Architekturinstanz leiten zu müssen.
Warum Autonomie eine Engineering-Strategie erfordert
Martell und Fike führen das Navigator-Programm auf ein wiederkehrendes Problem zurück: Ingenieure wollten klarere Orientierung. Ohne einen abgestimmten Rahmen konnten Teams konkurrierende technische Optionen nicht zuverlässig bewerten und wussten nicht, welche organisatorischen Prioritäten Vorrang haben sollten.
Das Ergebnis war nicht zwangsläufig schlechtes Engineering. Es war inkonsistentes Engineering. Zwei Teams, die vor ähnlichen Zielkonflikten standen, konnten zu unvereinbaren Schlussfolgerungen gelangen, weil jedes einen anderen, weitgehend impliziten Maßstab verwendete. Dieselben Debatten tauchten immer wieder auf und verbrauchten Zeit, ohne dauerhaftes organisatorisches Wissen zu schaffen.
Jede Entscheidung zentral genehmigen zu lassen, hätte die Inkonsistenz beseitigt, aber zugleich einen Engpass geschaffen. Stattdessen wollte Cartek die Grundlage guter Entscheidungen breit verfügbar machen. Seine Engineering-Strategie wurde zu einem gemeinsamen Bezugspunkt – einer dokumentierten Darstellung davon, wie die Organisation Zielkonflikte bewertet und was sie unter bestimmten Umständen tendenziell priorisiert.
Entscheidend ist, dass die Strategie als Reaktion auf Ingenieure entstand, die nach Kontext fragten. Martell und Fike stellen sie nicht als ein von Führungskräften isoliert entwickeltes Mandat dar. Ihr Zweck bestand darin, Mitwirkenden das Vertrauen zu geben, zu handeln, während ihre Entscheidungen zugleich mit einer übergeordneten Richtung verbunden blieben.
Mit der Realität beginnen, nicht mit einem Wunschposter
Ein bemerkenswerter Teil von Carteks Vorgehen war die Betonung darauf, zu dokumentieren, wie Entscheidungen bereits getroffen wurden. Das Team begann nicht damit, eine ideale zukünftige Organisation zu beschreiben. Zunächst untersuchte es den aktuellen Zustand, einschließlich Praktiken, die inkonsistent oder schwer zu rechtfertigen wirkten.
Diese Art organisatorischer Archäologie ist wichtig, weil jede Engineering-Gruppe bereits eine Strategie hat, auch wenn sie niemand aufgeschrieben hat. Sie zeigt sich in wiederholten Entscheidungen: ob Teams auf unmittelbare Performance oder künftige Skalierung optimieren, operative Komplexität akzeptieren, um Flexibilität zu erhöhen, oder ein bestehendes System erweitern, anstatt einen neuen Service zu schaffen.
Frühere Designdokumente und Architecture Decision Records können diese Muster sichtbar machen. Ein hilfreicher Eintrag hält die betrachteten Alternativen, die Vor- und Nachteile jeder Alternative sowie den Grund fest, warum sich eine Option durchsetzte. Mehrere gemeinsam betrachtete Einträge offenbaren die Werte hinter diesen Entscheidungen.
Martell und Fike unterscheiden diese Werte von den Entscheidungen selbst. Eine Entscheidung sagt, was in einem konkreten Fall passiert ist. Ein Prinzip bietet bedingte Orientierung, die auf einen anderen Fall übertragbar ist – sinngemäß: „Wenn diese Bedingungen gelten, bevorzuge diese Reaktion.“ Solche Prinzipien herauszuarbeiten, kann es erforderlich machen, die Menschen und Umstände hinter älteren Entscheidungen erneut zu betrachten, insbesondere wenn Dokumente ein Ergebnis festhalten, aber dessen Begründung auslassen.
Ehrlich zu beginnen macht Veränderungen auch messbar. Eine idealisierte Strategie kann inspirierend klingen und zugleich die Distanz zwischen Richtlinie und Praxis verschleiern. Eine Beschreibung des realen Systems schafft eine Ausgangsbasis, von der aus die Organisation gezielt besser werden kann.
Navigators helfen Teams, die Karte zu lesen
Der Name des Programms verdeutlicht eine wichtige Aufteilung der Verantwortung. Die Engineering-Strategie funktioniert wie eine Karte; Navigators helfen Menschen, sie in unbekanntem Gelände zu interpretieren. Sie tragen zur Strategie bei, aber ihre primäre Rolle besteht nicht darin, einen Masterplan vorzugeben oder jede technische Frage persönlich zu entscheiden.
Zum besprochenen Zeitpunkt unterstützten ungefähr ein Dutzend Navigators eine Engineering-Organisation mit rund 400 Personen. Sie kamen aus mehreren technischen Disziplinen, darunter Frontend- und Backend-Engineering, Zuverlässigkeit und Sicherheit. Ihre Positionen in der formalen Hierarchie unterschieden sich: Einige arbeiteten tief in Teams, während andere näher an der Führungsebene tätig waren.
Die Auswahl hing weniger vom Titel als von nachgewiesenem Urteilsvermögen, technischer Tiefe und Einfluss ab. Martell und Fike beschreiben ein informelles Netzwerk, das neben dem Management-Organigramm existiert. Bestimmte Ingenieure werden ganz natürlich zu den Personen, die Kollegen bei mehrdeutigen Problemen konsultieren. Das Navigator-Modell erkennt diese vertrauenswürdigen Personen an und verbindet sie, statt anzunehmen, dass Autorität ausschließlich entlang von Berichtslinien fließt.
Navigators benötigen umfassenden Kontext zu den Produkten und Systemen in ihrem Umfeld. Sie sollten wissen, welche Entscheidungen anstehen, erkennen, wenn Arbeit der Strategie widerspricht, und eingreifen, wenn ein Team Unterstützung benötigt. Das bedeutet nicht, die Kontrolle zu übernehmen. Ein Navigator kann ein Team durch einen Zielkonflikt begleiten, relevante Prinzipien benennen oder eine ungelöste Frage in die breitere Navigator-Gruppe einbringen.
Sie transportieren Informationen zudem in beide Richtungen. Die Strategie hilft Teams bei lokalen Entscheidungen, während die Schwierigkeiten, auf die Teams stoßen, zeigen, wo die Strategie unvollständig ist. Navigators sind daher sowohl Interpreten als auch wichtige Mitwirkende an ihrer fortlaufenden Überarbeitung.
Beratung ohne Architektur-Engpass
Cartek vermeidet bewusst, einen formellen Architekten zum verpflichtenden Zugangspunkt für technische Entscheidungen zu machen. Staff Engineers können dort Architekturarbeit leisten, wo sie benötigt wird, aber die Organisation möchte keine dauerhafte Rolle, die Entscheidungsbefugnis an einem Ort konzentriert.
Stattdessen ähnelt ihr Modell einem Prozess für Architekturberatung. Ein Ingenieur kann eine Entscheidung treffen, nachdem er die Betroffenen, Kollegen mit relevanter Erfahrung, die schriftliche Strategie und bei Bedarf einen Navigator konsultiert hat. Die Entscheidungsbefugnis bleibt verteilt, aber Konsultation wird erwartet.
Die Strategie dient als kollektive Beratungsquelle. Sie gibt auch weniger erfahrenen Ingenieuren einen Maßstab, an dem sie einen Vorschlag prüfen können. Beispielsweise kann sie verdeutlichen, wie die Organisation Performance gegenüber Skalierbarkeit oder Wartungskosten gegenüber Liefergeschwindigkeit gewichtet.
Nicht jede Frage lässt sich auf universelle Orientierung reduzieren. Martell und Fike nennen Entscheidungen wie die Frage, ob eine Fähigkeit in einen bestehenden Monolithen gehört oder einen neuen Service rechtfertigt. Eine Organisation kann eine allgemeine Richtung haben, ohne für jede Situation eine ausreichend präzise Regel zu besitzen. In diesen Fällen sollte die Strategie die Mehrdeutigkeit anerkennen und Ingenieure zu fundierter Konsultation anleiten.
Dadurch bleibt Urteilsvermögen erhalten, anstatt es durch Bürokratie zu ersetzen. Das Ziel ist nicht, jede künftige Antwort zu kodieren. Es geht darum, routinemäßige Entscheidungen zu erleichtern, wirklich schwierige sichtbar zu machen und Menschen eine konsistente Methode zu geben, über Ausnahmen nachzudenken.
Strategie sollte schrittweise weniger falsch werden
Martell und Fike verstehen Strategie als ein sich entwickelndes Instrument und nicht als eine abgeschlossene Doktrin. Anfängliche Prinzipien werden Lücken enthalten. Manche werden zu allgemein sein, während andere unter Bedingungen versagen können, die ihre Autoren nicht vorhergesehen haben.
Reale Entscheidungen liefern das Feedback, das zu ihrer Verbesserung nötig ist. Teams vergleichen eine Option mit der Strategie, entdecken, wo die Orientierung hilft oder versagt, und melden diese Erkenntnisse über ihre Navigators. Mit der Zeit können sowohl die einzelnen Entscheidungen als auch der gemeinsame Rahmen weniger falsch werden.
Begrenzte Mehrdeutigkeit zuzulassen, ist Teil des Designs. Teams benötigen weiterhin Raum, lokale „Mikrostrategien“ zu entwickeln, die zu ihren Systemen und Einschränkungen passen. Navigators helfen sicherzustellen, dass diese lokalen Ansätze mit der übergeordneten Richtung der Organisation vereinbar bleiben, ohne jedes Team zu einer identischen Umsetzung zu zwingen.
Die Beziehungen der Navigators untereinander stärken diese Feedbackschleife. Sie sind nicht gemeinsam für jede Entscheidung verantwortlich, können jedoch Kollegen konsultieren, wenn ein Problem mehrere Bereiche betrifft. Ihre Mischung aus breitem organisatorischem Bewusstsein und tiefem Spezialwissen ist besonders nützlich bei Themen, die Sicherheit, Zuverlässigkeit, Plattformarchitektur und Produktentwicklung übergreifen.
Dezentralisierung ist auch ein Mentoring-System
Die Verteilung von Entscheidungsbefugnissen funktioniert nur, wenn mehr Menschen lernen, sie auszuüben. Die Navigator-Rolle beinhaltet daher eine implizite Lehrverantwortung: wie man Zielkonflikte erkennt, angemessenen Rat einholt, Begründungen dokumentiert und mit unvollständigen Informationen entscheidet.
Das ist besonders wichtig für Engineers, denen zuvor keine Entscheidungen mit großer Wirkung anvertraut wurden. Ihnen zu sagen, sie sollten „Verantwortung übernehmen“, reicht nicht aus, wenn jeder folgenreiche Vorschlag später von einer unzugänglichen Gruppe erfahrener Führungskräfte überstimmt wird. Navigatoren können den Entscheidungsprozess transparent machen und Mitwirkende unterstützen, während die Entscheidung nah an der eigentlichen Arbeit bleibt.
Martell und Fike trennen außerdem die Navigator-Perspektive von der Management-Perspektive. Manager müssen Menschen, Auslieferung und die Umsetzung durch das Team in Einklang bringen. Navigatoren liefern fundiertes technisches Urteilsvermögen und verbinden lokale Engineering-Entscheidungen mit der organisationsweiten Strategie. Die beiden Perspektiven sollten einander ergänzen, statt in einer einzigen Rolle aufzugehen.
Kandidatinnen und Kandidaten werden anhand ihres bisherigen Beitrags erkannt und von leitenden Führungskräften nominiert, anstatt sich über einen herkömmlichen Prozess zu bewerben. Technische Glaubwürdigkeit allein reicht nicht aus. Wer nicht bereit ist, andere weiterzuentwickeln oder sein Urteilsvermögen zu teilen, wird den Zweck des Programms kaum erfüllen können.
Erfolg durch bessere Entscheidungen messen
Der Wert der Dezentralisierung zeigt sich in konkreten Entscheidungsergebnissen. Martell und Fike beschreiben ein Team, das für ein Problem, das in mehreren Bereichen auftrat, einen neuen gemeinsamen Plattformdienst erwog. Eine oberflächlich vernünftige Reaktion wäre gewesen, eine universelle Lösung zu entwickeln und einen langwierigen Prozess zu beginnen, um die Zustimmung aller Beteiligten zu sichern.
Ein Navigator verglich den Vorschlag mit der Strategie der Organisation und kam zu dem Schluss, dass eine Einheitsplattform nicht die bevorzugte Richtung war. Da die Strategie bereits einen abgestimmten Standard darstellte, konnte der Navigator die Frage klären, ohne die gesamte Argumentation von Grund auf neu aufbauen zu müssen.
Das veranschaulicht eine bedeutende Verschiebung der Beweislast. Statt dass Befürworter andere wiederholt davon überzeugen müssen, dass eine Richtung richtig ist, liefert die dokumentierte Strategie die Ausgangsposition. Abweichungen bleiben möglich, erfordern jedoch eine überzeugende Begründung.
Nützliche Fortschrittsindikatoren sind schnellere Entscheidungen, weniger unnötige Eskalationen, klarere Begründungen in Designdokumenten und größeres Vertrauen unter den Mitwirkenden. Auch qualitative Signale sind wichtig: Engineers sollten sich weniger orientierungslos fühlen, und wiederkehrende Debatten sollten zunehmend wiederverwendbare Prinzipien hervorbringen statt lediglich einen weiteren vorübergehenden Kompromiss.
Wie Engineering-Führungskräfte beginnen können
Martell und Fike machen deutlich, dass die Ernennung von Navigatoren vor der Formulierung einer Strategie wahrscheinlich nicht funktionieren wird. Ohne eine gemeinsame Landkarte könnten vertrauenswürdige Personen ihre persönlichen Präferenzen lediglich effizienter verteilen.
Führungskräfte können damit beginnen, frühere Architekturentscheidungen und aktuelle Designdokumente zu überprüfen. Sie sollten wiederkehrende Zielkonflikte identifizieren, zunächst die am wenigsten umstrittenen Prinzipien aufschreiben und die Lücke zwischen erklärten Werten und beobachtetem Verhalten untersuchen. Unbehagen angesichts dieser Bilanz ist ein nützlicher Hinweis: Es weist auf Praktiken hin, die die Organisation möglicherweise ändern möchte.
Eine praktische Abfolge besteht darin:
repräsentative Entscheidungen und ihre Begründungen zu dokumentieren;
bedingte Prinzipien aus wiederkehrenden Mustern abzuleiten;
Bereiche zu identifizieren, in denen die aktuelle Praxis der gewünschten Richtung widerspricht;
angesehene technische Mitwirkende zu finden, die andere bereits beraten;
diese Personen dort einzusetzen, wo sie lokale Arbeit mit der Organisationsstrategie verbinden können;
das Rahmenwerk zu überarbeiten, wenn reale Entscheidungen Lücken oder Widersprüche offenlegen.
Die tiefere Erkenntnis lautet, dass Dezentralisierung eine Infrastruktur für Urteilsvermögen voraussetzt. Schriftlich festgehaltene Prinzipien sorgen für Konsistenz, Navigatoren liefern Kontext und Mentoring, und Teams bringen die Evidenz ein, die das System in der Realität verankert. Zusammen ermöglichen diese Mechanismen, dass Entscheidungsbefugnisse näher an die Arbeit rücken, ohne dass die Organisation in unvereinbare technische Richtungen zerfällt.
