Was ist ein Brag Document? Mit Beispiel

Woher der Begriff kommt

Populär gemacht hat die Formulierung die Programmiererin Julia Evans in einem Beitrag von 2019, „Get your work recognized: write a brag document“, mit einem schlichten Argument: Deine Führungskraft kann sich an deine Arbeit nicht in der Detailtiefe erinnern, in der du es kannst, und das von ihr zu erwarten ist unvernünftig. Das Dokument schließt diese Lücke, ohne sich auf fremdes Erinnern zu verlassen.

Die Praxis ist älter als der Name — Reviews haben schon immer die belohnt, die Belege aufbewahrten —, aber die Benennung war wichtig, weil sie daraus etwas machte, das man einer Kollegin empfehlen kann, ohne dass es nach Eigenwerbung klingt.

Was hineingehört

Die meisten listen nur ausgelieferte Funktionen und wundern sich dann, warum das Dokument dünn wirkt. Die folgenden Kategorien fallen systematisch heraus und sind meist das stärkste Material im Reviewgespräch.

• Ausgelieferte Arbeit, mit Daten und je einem messbaren Ergebnis.
• Arbeit, die kein Liefergegenstand war: Code-Reviews, Incident-Bearbeitung, Bereitschaftswochen, geführte Interviews, Dokumentation, die niemand beauftragt hat.
• Mentoring und Entblockieren — wem du geholfen hast, wobei, und was sich danach für die Person geändert hat.
• Entscheidungen, die du beeinflusst hast, auch die, bei denen das Argument der Beitrag war und das Artefakt von jemand anderem stammt.
• Was gescheitert ist, was du daraufhin geändert hast und was du anders machen würdest. Dieser Abschnitt verhindert, dass sich das Dokument wie Werbung liest.
• Fähigkeiten und Kontext, die du dir angeeignet hast: ein System, das dir jetzt gehört, ein Gebiet, zu dem man dich jetzt fragen kann.

Ein durchgerechnetes Beispiel

Der Unterschied zwischen einem brauchbaren und einem nutzlosen Eintrag liegt vollständig in der Konkretheit. Zwei Versionen desselben Halbjahrs:

• Schwach: „Die Import-Pipeline verbessert. Beim Onboarding neuer Teammitglieder geholfen. An der Roadmap mitgewirkt.“
• Stark: „Wiederholungsbehandlung beim Import neu geschrieben (Jan–Feb). Stille Fehlschläge gingen von etwa einem pro Woche auf null in den zwei Monaten danach; Fehlschläge tauchen jetzt im Queue-Dashboard auf, also erfährt Ops nicht mehr aus Kundenmeldungen davon. PR 2214.“
• Stark: „Zwei Engineers im März und April eingearbeitet — die Anleitung zur Umgebungseinrichtung geschrieben, die beide genutzt haben; Zeit bis zum ersten Commit sank von etwa einer Woche auf zwei Tage.“
• Stark: „Im Design-Review im Februar gegen den Multi-Region-Rollout argumentiert; wir haben ihn zurückgestellt und stattdessen die Queue-Korrektur ausgeliefert. Im Juni wurde der Rollout aus denselben Gründen gekürzt.“

Warum der Zeitrahmen von Reviews gegen dich arbeitet

Ein Review deckt sechs oder zwölf Monate ab. Das klarste Bild der bewertenden Person umfasst die letzten Wochen, denn so funktioniert Aufmerksamkeit bei allen, auch bei guten Führungskräften. Arbeit aus Monat zwei kommt bereits verblasst im Gespräch an, und Arbeit von jemandem, der gegangen ist, an einem Projekt, das gestrichen wurde, kommt vielleicht gar nicht an.

Es gibt ein zweites, mechanischeres Problem: Bewertende wechseln. Eine im April dazugekommene Führungskraft kann den Januar nicht aus dem Gedächtnis beurteilen, nur aus Spuren — und die vorhandenen Spuren sind Tickets und Kalendereinträge, die Termine und fertige Arbeit überrepräsentieren und alles Schwierige unterrepräsentieren.

Das ist eine Beobachtung dazu, wie Reviews laufen, kein Forschungsbefund, und sollte auch so behandelt werden. Es lässt sich aber leicht am eigenen letzten Review prüfen, und das ist hier die einzige Prüfung, die zählt.

Wie du es ohne weiteres Wochenritual füllst

Ein zweites Dokument hält niemand durch. Die realistische Variante ist, nichts zusätzlich zu schreiben und das Brag Document aus Material zusammenzusetzen, das du ohnehin produzierst: datierte Einträge dazu, was sich an dem Tag geändert hat, Nachrichten, in denen du eine Entscheidung erklärt hast, und Notizen nach einem Incident.

Das klappt, wenn das Rohmaterial über Beschreibung abrufbar ist statt über den Ablageort — also „was habe ich an der Import-Pipeline gemacht“ zu fragen und die sechs Einträge zu bekommen, die sie erwähnen, ohne dass du im Januar wusstest, dass sie im Dezember zählen würden. Ein halbes Jahr so zusammenzustellen ist Arbeit für zwanzig Minuten. Es aus dem Kalender zu rekonstruieren ist ein Nachmittag, und es ist falsch.

Was ein Brag Document nicht leistet

Es ersetzt nicht, dass Arbeit sichtbar ist, während sie passiert. Ein zum Review vorgelegtes Dokument, das sechs Monate unsichtbaren Beitrags erklärt, ist eine schwächere Position als es im März gesagt zu haben, und keine Detailtiefe rettet das.

Es hängt außerdem an der Kultur. In manchen Organisationen liest sich eine schriftliche Aufstellung als Vorbereitung, in anderen als Lobbyarbeit. Die Version, die überall gut ankommt, sind Belege statt Adjektive — Zahlen, Daten und Namen, und die Bewertung bleibt der lesenden Person überlassen. Und Zahlen ohne Ausgangswert sind Rauschen: „Fehler um 60 % gesenkt“ heißt nichts ohne den Wert davor, den Zeitraum und die Messmethode. Schließlich verschiebt nichts davon ein Gehaltsband oder einen Einstellungsstopp. Ein Brag Document gewinnt die Auseinandersetzungen, in denen es wirklich um Belege geht — das sind weniger, als es sich anfühlt, aber nicht keine.