Engineering-Organigramm: Teams den Systemen zuordnen, die ihnen gehören

Die meisten Organigramme beantworten eine Frage: Wer berichtet an wen? Engineers brauchen diese Antwort selten. Während eines Incidents müssen sie wissen, welchem Team der ausgefallene Service gehört und wer Rufbereitschaft hat. In einem Design-Review müssen sie wissen, welche Teams eine Änderung betrifft und wie diese Teams zusammenarbeiten. Ein Diagramm aus Namen und Titeln beantwortet nichts davon.

Dieser Beitrag baut ein Engineering-Organigramm, das genau das leistet. Es behält die Berichtswege für die Personalseite und ergänzt, was das Engineering braucht: Teamtyp, eigene Systeme, Rufbereitschaftszeiten und die Art, wie Teams zusammenarbeiten. Es nutzt für Teams das Vokabular von Team Topologies und endet damit, was du beschriften solltest und wie das Diagramm aktuell bleibt.

Was ein Engineering-Organigramm zeigen sollte

Ab einer Handvoll Teams lässt du einzelne Engineers weg und zeigst eine Karte pro Teamlead. Ein Diagramm mit sechzig Namen ist ein Telefonbuch; ein Diagramm mit acht Teams ist eine Landkarte. Verlinke jedes Team mit seiner eigenen Mitgliederliste, falls jemand die Namen braucht.

Berichtswege sind nicht die ganze Geschichte

Mel Conways Aufsatz „How Do Committees Invent?“ erschien im April 1968 in Datamation. Auf seiner eigenen Seite zum Gesetz fasst er die These so zusammen: Eine Organisation, die ein System entwirft, erzeugt einen Entwurf, dessen Struktur die Kommunikationsstruktur der Organisation kopiert. Fred Brooks nannte das später Conways Gesetz, und der Name blieb.

Achte auf das Wort Kommunikation. Ein Organigramm zeigt Berichtswege, und die sind nur ein Teil davon, wie Menschen kommunizieren. Zwei Teams unter verschiedenen Directors, die jeden Tag miteinander reden, prägen das System stärker als die Linie zwischen ihren Managern. Deshalb schreibt das Diagramm in diesem Beitrag auf, wie Teams zusammenarbeiten, und nicht nur, an wen sie berichten.

Das Gesetz funktioniert auch als Designwerkzeug. Wenn zwei Services unabhängig bleiben sollen, gib sie nicht Teams, die jede Änderung abstimmen müssen. Conways Aufsatz ergänzt eine Folgerung: Der erste Entwurf ist selten der beste, also muss die Organisation flexibel genug sein, sich mit ihm zu ändern.

Teamtypen und Interaktionsmodi

Team Topologies von Matthew Skelton und Manuel Pais gibt Teams ein kleines, gemeinsames Vokabular: vier Teamtypen und drei Arten, wie Teams interagieren.

Die drei Interaktionsmodi:

• Collaboration. Zwei Teams arbeiten für einen festgelegten Zeitraum eng zusammen, um etwas Neues zu erarbeiten, etwa eine API oder eine Praxis. Das ist teuer, also gib der Zusammenarbeit ein Enddatum.
• X-as-a-Service. Ein Team stellt etwas bereit, das andere nutzt es mit wenig Interaktion, zum Beispiel eine Deployment-Pipeline.
• Facilitating. Ein Team hilft einem anderen und coacht es, etwa während es einen neuen Testansatz einführt.

Eine Warnung von der Team-Topologies-Website selbst: Dort heißt es, der Ansatz sei keine Methode, um ein neues Organigramm zu entwerfen. Er beschreibt, wie Arbeit zwischen Teams fließt. Nutze sein Vokabular als Beschriftung in deinem Diagramm, nicht als Grund, jeden Berichtsweg neu zu zeichnen.

Ownership an einem Ort halten

Ownership, die nur in einem Diagramm steht, veraltet. Halte die Quelle der Wahrheit dort, wo Engineers ohnehin nachsehen, und lass das Diagramm sie auf Teamebene spiegeln.

In einem Servicekatalog wie Backstage muss jede Komponente einen Owner nennen: Im Katalog-Deskriptorformat ist spec.owner ein Pflichtfeld, und der Owner ist eine einzelne Entität, meist ein Team. In einem Repository ordnet eine CODEOWNERS-Datei Pfade den verantwortlichen Personen oder Teams zu, und GitHub fordert automatisch ein Review der Code Owner an, wenn ein Pull Request, der kein Entwurf ist, ihren Code ändert.

Wenn Diagramm und Katalog sich widersprechen, hat meist der Katalog recht, und das Diagramm ist überfällig für ein Review.

Das Beispiel: Engineering in einem Onlineshop

Die Engineering-Abteilung eines Onlineshops hat einen VP und zwei Directors. Product Engineering führt drei Teams: Checkout und Search, beide Stream-aligned, und Payments, ein Complicated-Subsystem-Team, dem die Zahlungsabwicklung und das Fraud-Scoring gehören. Platform Engineering führt das Platform-Team, dem CI/CD, die Kubernetes-Cluster und der Observability-Stack gehören, und ein Developer-Experience-Team, dessen Lead-Rolle noch offen ist.

In diesem Quartal laufen zwei Interaktionen. Payments und Checkout arbeiten bis Ende Q2 gemeinsam an 3-D Secure. Developer Experience begleitet Checkout beim Umstieg auf Contract-Tests.

So liest du es:

• Von oben nach unten, die Berichtswege. Der VP, zwei Directors und fünf Teamleads. Die Linien zeigen, wer an wen berichtet, sonst nichts.
• Kartenfarbe, Teamtyp. Bernstein für Stream-aligned, Rosé für Complicated Subsystem, Blau für Platform und Violett für Enabling. Manager oberhalb der Teamebene bleiben grau.
• Unter jedem Team, die Engineering-Sicht. Die Services des Teams, seine Rufbereitschaftszeiten und seine aktuelle Interaktion mit anderen Teams.
• Die gestrichelte Karte ist eine offene Stelle. Developer Experience hat noch keinen Lead, und das Diagramm sagt das, statt die Lücke zu verstecken.

Was du beschriften solltest

• Teamnamen so, wie die Leute sie sagen. Wenn im Incident-Kanal „Checkout“ steht, steht im Diagramm Checkout.
• Eigene Systeme mit den Namen aus Katalog, Dashboards und Alerts.
• Rufbereitschaftszeiten und wohin eskaliert wird.
• Interaktionsmodus und ein Enddatum für jede Collaboration.
• Gepunktete Linien, etwa für eine Security-Engineerin, die an das Security-Team berichtet, aber jeden Tag mit Payments arbeitet.
• Standort oder Zeitzone, wenn Teams über mehrere verteilt sind.
• Das Datum des letzten Reviews, direkt im Diagramm.

Häufige Fehler

• Personen ohne Teams. Ein Baum aus Namen sagt niemandem, wohin er sich wenden soll, wenn etwas kaputtgeht.
• Systeme ohne Owner. Wenn ein Service unter keinem Team auftaucht, ist genau das der Befund. Weise ihn zu, bevor der nächste Incident es tut.
• Geteilte Ownership. Zwei Owner heißt meist keiner. Backstage verlangt nicht ohne Grund einen einzigen Owner.
• Collaboration ohne Ende. Collaboration ist für einen festgelegten Zeitraum gedacht. Eine, die nie endet, bedeutet oft, dass die Grenze zwischen den beiden Teams an der falschen Stelle liegt.
• Überlastete Teams. Ein Team, dem ein Dutzend Services und zwei Rufbereitschaften gehören, wird bei allem langsam sein. Team Topologies behandelt die kognitive Last eines Teams als Grenze, die man beim Entwurf berücksichtigt, und das Diagramm macht diese Last sichtbar.
• Ein Diagramm, das niemand pflegt. Aktualisiere es bei jeder Umorganisation und jedem neuen Service, und prüfe es regelmäßig.

Das Organigramm zeigt, wem was gehört; es zeigt nicht, wie die Systeme zusammenpassen. Dafür zeichnest du ein C4-Modell-Diagramm oder ein Microservices-Architekturdiagramm und hältst beide aktuell, wie in Architekturdiagramme, die nicht veralten beschrieben.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an, oder starte mit der Organigramm-Vorlage.
2. Füge aus dem Organigramm-Pack eine Mitarbeiter-Karte für den VP hinzu und trag Name, Titel, Abteilung und Standort ein.
3. Füge Personen über die Plus-Griffe hinzu: unten für eine unterstellte Person, seitlich für eine gleichgestellte, oben für eine Führungskraft. Das Diagramm ordnet sich von oben nach unten selbst an.
4. Füge für jede Rolle, die du besetzen willst, eine Offene Stelle-Karte hinzu.
5. Setz die Kartenfarbe jedes Teamleads auf seinen Teamtyp und lass Manager oberhalb der Teamebene grau.
6. Füge unter jedem Teamlead einen Text aus dem Basis-Pack mit Teamtyp, eigenen Systemen, Rufbereitschaftszeiten und aktuellem Interaktionsmodus hinzu.

Das Beispiel nutzt 8 Diagramm-Nodes und bleibt damit im Free-Plan. Text zählt nicht zum Limit. Die Seite zum Organigramm-Tool erklärt Teilen und Export.

FAQ

Sollte ein Engineering-Organigramm jeden Engineer zeigen? Bei wenigen Teams ja. Darüber hinaus zeigst du Teams und ihre Leads und verlinkst jedes Team mit seiner eigenen Mitgliederliste. Das Diagramm bleibt lesbar und ändert sich seltener.

Wie zeige ich eine Führungskraft mit gepunkteter Linie? Zeichne eine gestrichelte Linie von der zweiten Führungskraft und behalte die durchgezogene Linie für die Person, die die Leistungsbeurteilungen führt. In Archboard wird eine Verbindung von einer zweiten Führungskraft zu einer gepunkteten Linie, und das Layout richtet sich weiter nach der ersten.

Was ist der Unterschied zwischen einem Organigramm und einer Team-Topologie? Ein Organigramm zeigt Berichtswege. Eine Team-Topologie zeigt Teamtypen und wie Teams interagieren. Zeichne beides oder ergänze das Organigramm wie im Beispiel um die Interaktionen.

Wo sollte Service-Ownership gepflegt werden? In einem Servicekatalog oder in CODEOWNERS-Dateien, wo Tools und Menschen sie finden. Das Organigramm spiegelt sie auf Teamebene.

Wie oft sollte ein Engineering-Organigramm aktualisiert werden? Bei jeder Umorganisation, jedem neuen Team oder neuen Service, dazu bei einem regelmäßigen Review, etwa monatlich. Schreib das Datum des letzten Reviews ins Diagramm.

Kostenlos starten — ein Seat, keine Kreditkarte.