Wie man ein Async-First-Engineering-Team führt
Praktisches Playbook für Async-First-Engineering-Teams – von Kommunikationsnormen bis zu Entscheidungsritualen, die wirklich funktionieren.
By Ellis Keane · 2026-04-06
Als der Telegraf das tägliche Briefing überflüssig machte
Im Jahr 1844 sendete Samuel Morse die erste Telegrafnachricht zwischen Washington und Baltimore, und innerhalb eines Jahrzehnts begannen Unternehmen, die auf tägliche Kurierberichte angewiesen waren, anders zu arbeiten. Nicht weil sie „Telegraf-first" sein wollten (das sagte niemand), sondern weil sich die Rahmenbedingungen verändert hatten. Informationen konnten schneller als ein Pferd reisen, und so wurden die Rituale, die auf Pferden aufgebaut waren, still und leise überflüssig.
Die Parallele zur Führung eines Async-First-Engineering-Teams ist unangenehm direkt. Wir haben Slack, Linear, GitHub, Notion und etwa sieben weitere Tools, die Informationen mit der Geschwindigkeit eines Webhooks bewegen – und dennoch organisieren die meisten Teams ihren Alltag noch immer um synchrone Rituale herum, die für eine Zeit entworfen wurden, als man im selben Raum sein musste, um Kontext zu teilen: das tägliche Standup, bei dem jeder seine Jira-Tickets einem Manager vorliest, der exakt dasselbe Board auf einem zweiten Monitor geöffnet hat; der „kurze Sync", der 45 Minuten dauert, weil drei Personen nacheinander Screen-Sharing machen, während alle anderen aufs Handy schauen.
Für ein kleines Engineering-Team wie unseres – vier Personen über drei Zeitzonen verteilt – war es der einfache Teil, zu erkennen, dass sich die Rahmenbedingungen verändert hatten. Die Rituale neu aufzubauen, dauerte länger.
Wie ein Async-First-Engineering-Team wirklich aussieht
Async-First-Engineering bedeutet, dass der Standard-Kommunikationsmodus eures Teams asynchron ist. Entscheidungen werden schriftlich festgehalten. Der Status ist sichtbar, ohne nachfragen zu müssen. Kontext ist dokumentiert, sodass ihn Personen nach eigenem Zeitplan finden können. Meetings finden noch statt, aber sie sind die Ausnahme, in die man bewusst eintritt, nicht der Standard, aus dem man sich abmelden muss.
Das bedeutet nicht, dass niemand jemals in Echtzeit spricht – das wäre absurd und ehrlich gesagt auch ein bisschen einsam. Design-Reviews, Konfliktlösungen, Brainstorming-Sessions und die Art nuancierter Architektur-Diskussionen, bei denen man Körpersprache lesen und auf Whiteboards zeichnen muss, bleiben alle synchron, und das ist in Ordnung. Der Unterschied liegt darin, welchen Modus man zuerst wählt, wenn man etwas kommunizieren muss – und für die meisten Dinge in einem Engineering-Team lautet die Antwort: es aufschreiben statt einen Anruf einzuplanen. Denn ein gut geschriebener Linear-Kommentar um 14:00 Uhr in New York ist am nächsten Morgen um 9:00 Uhr in Berlin noch genauso verständlich.
Async-First bedeutet nicht Async-Only. Es bedeutet, dass euer Standard asynchron ist und ihr bewusst in synchrone Kommunikation wechselt, wenn die Situation es wirklich erfordert.
Die vier Säulen (die offensichtlich klingen, bis man sie ausprobiert)
Im vergangenen Jahr haben wir Sugarbug als vierköpfiges Team aufgebaut, das über die US-Ostküste und Europa verteilt ist. Was unser Async-First-Engineering-Team wirklich zum Funktionieren gebracht hat, waren nicht die Tools oder die Richtlinien – es waren die Gewohnheiten. Hier sind die vier, die geblieben sind.
1. Entscheidungen dort schriftlich festhalten, wo sie getroffen wurden
Das macht fast niemand konsequent. Eine Entscheidung wird in einem Slack-Thread getroffen. Jemand sagt „okay, nehmen wir Option B." Und dann... bleibt sie dort. In einem Thread, der in drei Wochen praktisch nicht mehr auffindbar sein wird.
Die Lösung ist kein Entscheidungsprotokoll (zumindest nicht in erster Linie). Die Lösung ist eine Norm: Wer die endgültige Entscheidung trifft, schreibt eine Ein-Satz-Zusammenfassung dessen, was entschieden wurde und warum – in dem Tool, in dem die Arbeit stattfindet. Wenn ihr entschieden habt, das API-Antwortformat zu ändern, gehört diese Zusammenfassung in das Linear-Issue oder die GitHub-PR-Beschreibung, nicht in einen Slack-Thread oder ein Meeting-Transkript, das niemand nochmals ansehen wird.
Wir haben das auf die harte Tour gelernt: Ein PR lag drei Tage lang im Review, weil der Reviewer nicht wusste, dass wir uns bereits für serverseitiges Rendering für diese Seite entschieden hatten – die Entscheidung war in einem Slack-Thread der Vorwoche vergraben, und niemand hatte sie in das Issue eingetragen. Der Reviewer hinterließ sechs Kommentare zu clientseitigen Hydration-Kompromissen, die bereits geklärt waren, der Autor wurde frustriert, und wir verloren fast eine Woche für eine Diskussion, die zehn Sekunden hätte dauern sollen, wenn der Kontext von Anfang an der Arbeit beigefügt gewesen wäre.
Danach hörten wir auf, ein separates Entscheidungsdokument pflegen zu wollen (das etwa zwei Wochen lang funktioniert hatte, bevor es zu einem weiteren Dokument wurde, das niemand mehr aktualisierte), und begannen, Entscheidungen direkt in das Issue selbst zu schreiben. Zehn Sekunden Aufwand – und die Entscheidung überlebt, weil sie an der Arbeit hängt und nicht in einem Meta-Dokument schwebt, das niemand prüft.
2. Status sichtbar machen, nicht berichten lassen
Für unser Team war das Status-Update-Meeting das teuerste synchrone Ritual – jede Person erzählt, was sie gestern getan hat und was sie heute tut, während alle anderen halb zuhören und auf ihre Runde warten. In einem Async-First-Team sollte der Status etwas sein, das man sehen kann – nicht etwas, das jemand einem mitteilen muss.
Das bedeutet, euer Projektmanagement-Tool muss die Realität tatsächlich widerspiegeln. Wenn ein Linear-Issue auf „In Progress" steht, sollte das daran liegen, dass jemand gerade wirklich daran arbeitet – nicht weil er es am Montag dorthin verschoben hat und es seitdem nicht angerührt hat. GitHub-PRs sollten beschreibende Titel und verlinkte Issues haben. Figma-Dateien sollten eine klare Benennung haben, die zeigt, was in Bearbeitung und was abgenommen ist.
Was den Status sichtbar macht
- Verknüpfte PRs mit Issues – Jeder kann sehen, welcher Code zu welcher Aufgabe gehört
- Klare Branch-Benennung –
feat/user-onboarding-flow sagt mehr als fix-stuff
- Aktualisierte Issue-Zustände – Tickets verschieben, wenn die Arbeit sich wirklich bewegt, nicht während Standups
- Schriftliche Wochenzusammenfassungen – Eine Person schreibt einen Digest, alle lesen ihn asynchron
Was den Status unsichtbar hält
- Nur mündliche Updates – Informationen verschwinden in dem Moment, in dem das Meeting endet
- Status-Meetings als einzige Informationsquelle – Was im Standup nicht gesagt wurde, hat nicht stattgefunden
- Veraltete Boards – Ein Kanban-Board, das seit Montag nicht mehr angefasst wurde
- Kontext in DMs gesperrt – Zwei Personen wissen es, alle anderen raten
3. Antwortfenster definieren, keine Antwortzeiten
Eine der subtileren Ängste bei der asynchronen Kommunikation ist das offene Warten. Man sendet eine Nachricht und weiß nicht, ob man in zwanzig Minuten oder morgen Nachmittag eine Antwort bekommt. Die Ungewissheit ist schlimmer als die eigentliche Verzögerung.
Die Lösung ist nicht, schnellere Antworten zu fordern (das recreiert nur die synchrone Kultur mit zusätzlichen Schritten). Es geht darum, explizite Erwartungen bezüglich der Antwortfenster für verschiedene Kommunikationstypen festzulegen. Bei unserem Team sieht das in etwa so aus:
- Slack-Nachrichten in öffentlichen Kanälen: Innerhalb von 4 Arbeitsstunden
- PR-Reviews: Innerhalb eines Werktages
- Linear-Issue-Kommentare: Innerhalb eines Werktages
- Als dringend markierte DMs: Innerhalb von 1 Stunde während der Arbeitszeit
- Alles andere: Innerhalb von 2 Werktagen
Die spezifischen Fenster sind weniger wichtig als die Tatsache, dass sie existieren und alle ihnen zugestimmt haben. Sobald der Rhythmus explizit ist, verschwindet die „Hat er das überhaupt gesehen?"-Angst, und die Leute hören auf, nach dreißig Minuten Stille Follow-up-Nachrichten zu senden.
4. Synchrone Zeit für das schützen, was sie wirklich braucht
Etwas, das wir nicht erwartet hatten: Die Meetings, die wir behielten, wurden spürbar besser. Wenn ein Meeting die Ausnahme statt des Standards ist, kommen die Teilnehmer vorbereitet und engagiert, weil sie wissen, dass dies das einzige Fenster ist, in dem sie etwas gemeinsam klären können.
Wir behielten drei Arten von synchronen Meetings:
- Wöchentlicher Team-Sync (max. 30 Minuten) – Keine Status-Updates, sondern Blocker, übergreifende Themen und „Glaubt sonst noch jemand, dass diese Architekturentscheidung uns beißen wird?"-Gespräche
- Design-Reviews – Einige Dinge brauchen wirklich synchrones visuelles Feedback
- Pair-Programming-Sessions – Wenn zwei Personen feststecken, ist es immer noch schneller, es gemeinsam durchzusprechen als asynchrones Hin-und-Her
Alles andere, was früher ein Meeting war, wurde zu einem schriftlichen Vorschlag, einem Loom-Video oder einem Kommentar-Thread im relevanten Issue. Unser Kalender sah nicht mehr aus wie ein Tetris-Spiel, sondern wie etwas, um das ein Mensch tatsächlich seinen Alltag planen könnte – was, wie sich herausstellt, der ganze Sinn eines Kalenders ist.
stat: "3 Meetings/Woche" headline: "Runter von 12" source: "Der tatsächliche Kalender unseres Teams nach dem Wechsel zu Async-First"
Das, wovor niemand warnt
Der schwierige Teil von Async-First sind nicht die Kommunikationsnormen oder das Tool-Setup. Es ist die emotionale Anpassung. Als wir unser tägliches Standup abschafften, erwähnte einer unserer Ingenieure, dass er sich „seltsam schuldig" fühlte, um 10 Uhr morgens mit tiefer Arbeit zu beginnen, ohne sich zuerst bei jemandem einzuchecken. Ein anderer sagte, die Stille in Slack vor dem Mittag ließ es so aussehen, als würde niemand arbeiten – obwohl GitHub stündlich eingehende Commits zeigte.
Das ist der menschliche Teil des Problems, und er hat keine systemische Lösung. Was uns geholfen hat, war es, offen darüber zu sprechen. Wir sprachen darüber, dass Async manchmal einsam sein kann, und dass es in Ordnung ist, einfach anzurufen, weil man mit einem Menschen über das Problem sprechen möchte, an dem man gerade arbeitet. Die Norm lautet nicht „niemals anrufen" – sie lautet „keinen Anruf für Dinge verlangen, die keinen brauchen."
Einige Teammitglieder bevorzugen grundsätzlich mehr synchrone Interaktion, und das zu berücksichtigen ist kein Versagen der Async-First-Philosophie – es ist die Anerkennung, dass Kommunikationspräferenzen persönlich sind und das starre Festhalten an einem einzigen Modus seine eigene Art von Dysfunktion ist.
Das Schwierige ist nicht das Einrichten von Async-Workflows. Es ist, sich mit der Stille zwischen den Nachrichten abzufinden und darauf zu vertrauen, dass die Teammitglieder arbeiten, auch wenn man sie nicht dabei sieht. attribution: Ellis Keane
Damit es klappt: Die ersten 30 Tage
Wenn ihr ein bestehendes Team auf ein Async-First-Engineering-Team-Modell umstellt, ist der erste Monat entscheidend – dort schlägt es entweder Wurzeln oder bricht still wieder zusammen als „Lass uns einfach kurz sprechen." Hier ist, was bei uns funktioniert hat, als grobe Zeitleiste:
Woche 1: Kommunikationsnormen schriftlich festhalten. Wortwörtlich – ein einseitiges Dokument, das sagt: „So kommunizieren wir, das sind die erwarteten Antwortfenster, das rechtfertigt ein Meeting." Teilen, synchron besprechen (ja, die Ironie) und Zustimmung einholen.
Woche 2: Drei wiederkehrende Meetings absagen oder umwandeln. Wählt diejenigen, die am offensichtlichsten Status-Updates im Verkleid sind, und ersetzt sie durch ein schriftliches Format. Nicht alles auf einmal absagen – die Leute brauchen eine schrittweise Eingewöhnung, keinen Abgrund.
Woche 3: Tool-Hygiene prüfen. Sind die Linear-Issues wirklich aktuell? Sind die PR-Beschreibungen nützlich? Werden Entscheidungen an den Stellen festgehalten, wo die Arbeit stattfindet? Falls nicht, ist das die Woche, um diese Normen zu etablieren. Bestimmt jemanden als „Async-Champion", der sanft nachfragt, wenn eine Entscheidung mündlich getroffen, aber nicht schriftlich festgehalten wird.
Woche 4: Retrospektive (asynchron, natürlich). Schickt ein einfaches Formular raus: „Was funktioniert? Was nicht? Was vermisst du?" Die Antworten werden euch überraschen – einige werden die Stille lieben, andere werden zu kämpfen haben. Passt die Normen auf Basis echten Feedbacks an, nicht Theorie.
- [x] Kommunikationsnormen-Dokument schreiben
- [x] Antwortfenster für jeden Kanal definieren
- [ ] 3 Status-Meetings absagen oder umwandeln
- [ ] Tool-Hygiene prüfen (Issues, PRs, Entscheidungsdokumente)
- [ ] Async-Champion für die Umstellung bestimmen
- [ ] Asynchrone Retrospektive nach 30 Tagen durchführen
- [ ] Normen basierend auf Team-Feedback anpassen
Wann Async-First die falsche Wahl ist
Async-First passt in einigen häufigen Situationen nicht. Wenn euer Team aus drei Personen besteht, die im selben Büro sitzen, ist synchrone Kommunikation wahrscheinlich in Ordnung, und der Aufwand, Async-Normen zu formalisieren, würde ein Problem lösen, das ihr nicht habt. Ebenso, wenn euer Team in einer echten Krise steckt – die Produktion ist ausgefallen, ein kritischer Launch steht bevor oder ihr pivotiert die Produktausrichtung – das ist synchrones Terrain, und so zu tun, als wäre das nicht der Fall, wäre dogmatisch statt pragmatisch.
Async-First funktioniert am besten für Teams, die über Zeitzonen verteilt sind, für Teams mit mehr als etwa fünf Personen (wo die kombinatorische Explosion synchroner Koordination beginnt, wehzutun), und für Teams, die lieber Code shippen als in einem Meeting über das Gelieferte zu berichten. Wenn das auf euch zutrifft, amortisiert sich die Investition in Async-Normen innerhalb des ersten Monats – vor allem durch zurückgewonnene Engineering-Stunden, die früher im Meeting-Industriekomplex verschwunden sind.
Der Telegraf hat das persönliche Gespräch nicht abgeschafft – er hat nur die tägliche Kurierfahrt überflüssig gemacht. Das ist alles, was Async-First für ein Engineering-Team tut: Es zieht die Rituale in Rente, die nur existierten, weil die Tools noch nicht aufgeholt hatten, und schützt die Gespräche, die wirklich wichtig sind.
Häufig gestellte Fragen
Q: Wie geht ihr mit Code-Reviews in einem Async-First-Engineering-Team um? A: Legt eine explizite Review-SLA fest (bei uns ist es ein Werktag) und sorgt dafür, dass PR-Beschreibungen die Hauptarbeit leisten – erklärt nicht nur, was geändert wurde, sondern warum, verlinkt das relevante Issue und hebt hervor, worauf der Reviewer besonders achten sollte. Das größte Versagensmuster bei Async-Reviews ist ein PR, der drei Tage liegt, weil der Reviewer Kontext benötigt, der nur in jemandes Kopf existiert. Schreibt es auf – oder zahlt später den Preis.
Q: Hilft Sugarbug bei Async-First-Workflows? A: Es hilft bei dem spezifischen Problem, dass Kontext über Tools hinweg fragmentiert wird – eine Entscheidung in Slack, eine Aufgabe in Linear, ein Design-Kommentar in Figma. Sugarbug verbindet diese Signale, sodass der Status sichtbar ist, ohne dass jemand ihn in einem Meeting vorlesen muss. Es ist nicht die einzige Möglichkeit, dieses Problem zu lösen (man könnte auch sehr diszipliniert alles manuell verlinken), aber wir haben es gebaut, weil wir der manuellen Version überdrüssig wurden.
Q: Was ist der größte Fehler, den Teams beim Wechsel zu Async-First machen? A: Es als Richtlinienänderung statt als Gewohnheitsänderung zu behandeln. Man kann ein wunderschönes „Kommunikationsnormen"-Dokument schreiben – aber wenn die Leute ihre Linear-Issues nicht wirklich aktualisieren oder Entscheidungen nicht in PRs schreiben, hat man nur Meetings entfernt, ohne den Informationsfluss zu ersetzen. Die Normen müssen zum Muskelgedächtnis werden, was etwa einen Monat sanften, konsequenten Nachhakens braucht.
Q: Wie geht ihr mit dringenden Produktionsproblemen in einem Async-First-Team um? A: Solche Probleme werden nicht asynchron behandelt – das ist der ganze Sinn von „Async-First, nicht Async-Only." Definiert einen klaren Eskalationspfad: einen dedizierten Slack-Kanal oder PagerDuty für echte Notfälle, mit dem Verständnis, dass alles andere den normalen Antwortfenstern folgt. Der entscheidende Unterschied ist zwischen „dringend" (Produktion ist ausgefallen) und „ich will jetzt eine Antwort" (was meistens Ungeduld ist, keine echte Dringlichkeit).
Q: Kann Sugarbug Standup-Meetings vollständig ersetzen? A: Es kann den Teil des Informationssammelns ersetzen – das „Was hat gestern jeder gemacht?"-Ritual – denn dieser Kontext fließt bereits durch GitHub, Linear und Slack. Was es nicht ersetzen kann, ist der menschliche Verbindungsteil, weshalb wir noch immer einen kurzen wöchentlichen Sync für die Gespräche beibehalten, die davon profitieren, im selben (virtuellen) Raum zu sein.
Signalintelligenz direkt in dein Postfach.