Jedes Design-Doc, das ich geschrieben oder reviewed habe, lebt an der Kreuzung zweier Gespräche: dem technischen, über das das Doc vorgibt zu sein, und dem politischen, das die Organisation tatsächlich führt — über Scope, Ownership und Budget. Vorzugeben, nur das erste existiere, ist wie Designs approved werden und trotzdem irgendwie im Kreis geshipt werden. Dieser Post erklärt, wie ich gelernt habe, für beide Audiences zu schreiben, ohne eine von beiden zu verlieren.

Zwei Audiences, zwei Gespräche

Jedes gute Design-Doc beantwortet gleichzeitig zwei Fragen:

  • Die technische Frage: Wie soll das Ding funktionieren?
  • Die politische Frage: Wer besitzt es, wer finanziert es, wer bekommt Anerkennung, wer verliert Optionalität, wer muss Ja sagen, damit es passiert?

Das Doc behauptet, um die erste zu gehen. Das Meeting dreht sich meistens um die zweite. Wenn du nur für die technische Audience schreibst, bekommst du Kommentare wie “sieht gut aus, lass uns den Scope reduzieren” — und schaust dann zu, wie dein Scope drei Wochen später in einem Slack-Thread ohne dich wieder expandiert.

Wie ich das auf die harte Tour gelernt habe

Bei einem meiner frühesten Engineering-Management-Stints schrieb ich, was ich für ein phänomenales Design-Doc für eine Infrastruktur-Konsolidierung hielt. Architekturdiagramme: sauber. Tradeoffs: aufgelistet. Migrationsplan: atomar. Alternativen: berücksichtigt.

Das Doc wurde im Review approved. Sechs Monate später hatte das Projekt etwa 40 % des Plans geshipt, zwei benachbarte Teams machten ihre eigenen Versionen derselben Arbeit, und ich saß in einem Raum und versuchte einem VP zu erklären, warum wir nicht fertig waren. Ich bin aus diesem Raum gegangen und habe erkannt:

  • Mein Doc hat die drei VPs nie benannt, die überlappende Ansprüche auf die Systeme hatten, die ich konsolidierte.
  • Es hat nie anerkannt, dass Team As On-Call-Rotation eine Constraint für das Migrationsfenster war.
  • Es hat nie gesagt, was wir absichtlich nicht machen würden — was bedeutete, dass andere Teams annahmen, ihr Lieblings-Feature sei im Scope.
  • Es hat nie benannt, wer das konsolidierte System besitzen würde, sobald es gebaut ist — was bedeutete, dass die Antwort zum Zeitpunkt, wo es wichtig wurde, “niemand” war.

Die Architektur war gut. Das Doc ist an der Politik gescheitert, und ich habe — auf die harte Tour — gelernt, dass die Politik Teil des Designs ist.

Das Template, das ich jetzt benutze

Jedes Design-Doc, das ich seitdem geschrieben habe, hat diese Abschnitte in dieser Reihenfolge. Die politischen sind tragend, nicht optional:

1. Das Problem (ein Absatz, user- oder operations-sichtbar)
2. Die Constraints (Teams, Budgets, Timelines, bestehende Systeme)
3. Der Vorschlag (ein Absatz Zusammenfassung vor den Details)
4. Non-Goals (was das explizit NICHT tut)
5. Berücksichtigte Alternativen (mindestens zwei; jede mit einem Grund, warum sie verloren hat)
6. Das technische Design (Diagramme + Prosa)
7. Der Migrations-/Rollout-Plan
8. Ownership (Namen von Menschen; "das Platform-Team" ist kein Name)
9. Offene Fragen (was wir noch nicht wissen)
10. Decision Log (was im Review entschieden wurde, wann, von wem)

Die Abschnitte, die jeder erwartet, sind 3, 6 und 7. Da lebt die Architektur. Aber Abschnitte 2, 4 und 8 sind es, wo das Doc das Projekt entweder shippt oder es still tötet.

Constraints sind keine Fußnoten

Abschnitt 2 sollte der am längsten diskutierte Abschnitt im Review sein. Nicht das technische Design. Die Constraints.

Eine Constraint sieht so aus:

  • “Die On-Call-Rotation von Team A kann keine weiteren Alerts absorbieren — jeder neue Service muss einen Zero-additional-Pages-Bar erfüllen, bevor wir Traffic umleiten.”
  • “Das Datenbank-Migrationsfenster ist 2 Stunden pro Quartal. Jedes Design, das mehr braucht, ist nicht shippbar.”
  • “Das Budget für dieses Projekt ist 0 EUR zusätzliche Infrastrukturausgaben — wir müssen in die bestehende Kapazität passen.”
  • “VP X hat dieses Feature dem Board für Q3 zugesagt. Ein Design, das über Q3 hinaus rutscht, ist politisch teuer, unabhängig vom Engineering-Wert.”

Wenn du das aufschreibst, schreibst du das politische Gespräch ins Doc. Die Leser wissen jetzt, womit sie einverstanden sind oder nicht. Die Alternative — diese Constraints implizit zu lassen und zu hoffen, dass alle dasselbe Verständnis teilen — ist wie sechs Leute ein Design-Review verlassen, mit sechs verschiedenen Projekten im Kopf.

Non-Goals schützen den Scope

Abschnitt 4 — Non-Goals — ist der einzige Abschnitt mit dem größten Hebel in jedem Design-Doc.

Er sagt explizit: “Dieser Vorschlag schließt X, Y oder Z nicht ein. Wenn du das willst, braucht es ein anderes Doc.”

In einem gesunden Design-Review ist der Non-Goals-Abschnitt der Ort, wo Scope Creep früh erwischt wird. Ohne ihn passiert Scope Creep still in den Monaten nach der Genehmigung, wenn Stakeholder, die nicht im Review waren, anfangen anzunehmen, ihr benachbartes Anliegen sei abgedeckt.

Ich verweigere inzwischen, ein Design-Doc ohne Non-Goals-Abschnitt zu genehmigen. Ein Doc ohne Non-Goals ist ein Doc, das durch Auslassung allem zugestimmt hat.

Ownership in Namen, nicht in Titeln

Abschnitt 8 — Ownership — ist der Abschnitt, in dem du Verantwortung entweder zuweist oder in die Leere leckt.

Gut:

Ownership: Amal H. besitzt den Rollout. Nach dem Rollout besitzt das Inventory-Team (DRI: Ben L.) den Betrieb. SLOs sind in ops/inventory.md definiert. Nach 90 Tagen stabilem Betrieb geht die Ownership an das Platform-Team (DRI: Priya N.) für die Langzeitwartung über.

Schlecht:

Ownership: Das Platform-Team wird das besitzen.

Die schlechte Version sieht wie Ownership aus, ist es aber nicht — “das Platform-Team” hat keinen Kalender, keinen Pager, keine Performance-Review. Einen Menschen zu benennen schafft eine Beziehung zwischen einer Person und einer Verantwortung. Ein Team zu benennen schafft diffuse Verantwortung.

Für Review vs. für Genehmigung schreiben

Eine Feinheit, die die meisten Design-Docs falsch machen: das Doc, das du für ein gesundes Review schreibst, ist nicht dasselbe Doc, das du für Genehmigungstheater schreibst.

Ein review-freundliches Doc:

  • Hat viele Non-Goals.
  • Listet Alternativen ehrlich auf, einschließlich der, die der Autor für am schlechtesten hält.
  • Hat einen “Offene Fragen”-Abschnitt voller wirklich ungelöster Dinge.
  • Endet mit einem Decision Log, der nach dem Review ausgefüllt wird.

Ein Genehmigungstheater-Doc:

  • Hat “Den Plan”, präsentiert als unvermeidlich.
  • Dismisst Alternativen in je einem Satz.
  • Hat keine offenen Fragen, weil der Autor nicht untervorbereitet wirken will.
  • Füllt das Decision Log mit “approved” vor.

Wenn die Design-Doc-Kultur deiner Org Genehmigungstheater-Docs belohnt, ist das die Kultur, die versagt — aber sie ist reparierbar, beginnend mit deinen eigenen Docs. Schreib review-freundliche Docs und akzeptiere, dass einige davon abgelehnt werden. So war Design-Review immer gedacht. Eine Approval-Rate von 100 % ist ein Approval-Prozess von 0 %.

Der 2026-Twist

KI-gestütztes Schreiben ändert hier etwas. Ich kann jetzt in 20 Minuten einen “vollständig aussehenden” ersten Draft eines Design-Docs generieren. Das ist für die technischen Abschnitte großartig — sie kommen strukturiert heraus, mit aufgelisteten Tradeoffs, in einem konsistenten Prosa-Stil.

Für die politischen Abschnitte ist es aktiv schädlich. Das LLM weiß nicht, wer die drei VPs mit überlappenden Ansprüchen sind. Es weiß nicht, welches Teams On-Call fragil ist. Es weiß nicht, was dieses Quartal der Budget-Vorwand ist im Gegensatz zum echten Budget.

Mein aktueller Workflow: Das AI die Abschnitte 3, 6, 7 und 9 draften lassen. Die Abschnitte 1, 2, 4, 8 und 10 selbst schreiben. Das AI kann auch da mit der Prosa helfen, aber die Substanz muss von mir kommen, weil sie in Köpfen lebt — nicht im Repo.

Die eine Frage, die ich jedem Design-Doc stelle

Bevor ich ein Design-Doc approve oder ablehne, stelle ich dem Autor eine Frage laut: “Wer wird unglücklich sein, wenn das genau so geshipt wird?”

Wenn sie keine spezifischen Leute benennen können, ist das Doc nicht review-fertig. Weil diese spezifischen Leute existieren — sie existieren immer — und wenn der Autor nicht weiß, wer sie sind, werden diese Leute in Monat drei auftauchen und fragen, warum sie nicht konsultiert wurden.

Wenn der Autor sie benennen kann, ist der nächste Schritt: “Hast du mit ihnen gesprochen?” Wenn die Antwort Nein ist, geh mit ihnen reden. Wenn die Antwort Ja ist, ist das Doc wahrscheinlich bereit.

Diese Frage hat mir mehr Monate Rework erspart als jede andere Gewohnheit, die ich habe.