Die verborgenen Kosten des operativen Overheads in Startups
Wie operativer Overhead in Startups von Anfang an, Stufe für Stufe, leise anwächst, bis das Team mehr Zeit mit Koordination als mit Entwicklung verbringt.
By Ellis Keane · 2026-04-02
Es ist 16:47 Uhr an einem Donnerstag, und Ihr Lead-Engineer hat gerade den Slack-Kanal mit einer Massennachricht bombardiert, um zu fragen, ob die API-Spezifikation aus dem Meeting am Montag jemals finalisiert wurde – denn er hat drei Tage lang gegen Annahmen entwickelt, und niemand hat ihm gesagt, dass die Produktleiterin die Payload-Struktur am Dienstagnachmittag in einem Notion-Dokument geändert hat, das (liebenswürdigerweise) null Personen abonniert hatten. Die Produktleiterin ihrerseits dachte wirklich, sie hätte es im Standup erwähnt. Wahrscheinlich hat sie es sogar – aber das Standup war achtzehn Stunden und siebenundvierzig Slack-Threads entfernt, und der Engineer war an jenem Morgen fünf Minuten zu spät, weil sein Kind wegen Socken einen Zusammenbruch hatte.
Das ist keine Katastrophe. Niemand wurde entlassen, nichts steht in Flammen, die drei Tage Arbeit sind nicht vollständig verschwendet. Aber das ist die Art von Dingen, die ständig, unsichtbar, in jedem wachsenden Startup passiert, und das kumulative Gewicht davon ist erschütternd, sobald man anfängt aufzupassen.
So passiert es, Stufe für Stufe.
Stufe Eins: Das Drei-Personen-Paradies (Monate 1–6)
Wenn drei von Ihnen in einem Raum sind – oder realistischer in 2026: drei von Ihnen in einem dauerhaften Videoanruf und einem einzigen Slack-Kanal – existiert operativer Overhead in Startups kaum als Konzept. Sie hören alles mit. Wenn jemand eine Entscheidung ändert, erfahren Sie davon, weil Sie wahrscheinlich im Gespräch waren oder zumindest in der Nähe. Es gibt keinen Prozess, weil es keinen Prozess geben muss. Kontext ist allgegenwärtig.
Das ist der Teil, über den die Leute später nostalgisch werden, und ehrlich gesagt ist es das wert. Es ist eine wunderbare Art zu arbeiten. Das Problem ist, dass die Leute das für ein System halten, anstatt für das, was es tatsächlich ist – eine vorübergehende Konsequenz des Kleinseins. Wenn alles in einem Raum Platz findet, ist Koordination kostenlos. Aber Koordination war nie kostenlos – der Raum hat die Arbeit nur für Sie erledigt.
Und hier ist der menschliche Teil, der wichtig ist: Weil sich Koordination in dieser Phase mühelos anfühlte, entwickeln die drei Gründer einen tiefen, weitgehend unbewussten Glauben daran, dass Prozess unnötig ist, dass das Hinzufügen von Struktur bürokratisch ist, dass die richtigen Personen immer einfach wissen werden, was vor sich geht. Dieser Glaube wird sie die nächsten zwei Jahre verfolgen.
Stufe Zwei: Die schwierige Mitte (Monate 7–14, Personen 4–8)
Sie stellen Ihre vierte Person ein, dann Ihre fünfte. Einen Designer, vielleicht einen zweiten Engineer, jemanden für Kundengespräche. Und für eine Weile fühlt es sich noch gut an, weil vier Personen in einem Slack-Kanal nicht bedeutend anders ist als drei Personen in einem Slack-Kanal.
Aber dann verschiebt sich etwas subtil. Sie beginnen, Meetings zu haben, an denen nicht alle teilnehmen. Entscheidungen werden in DMs getroffen. Jemand erstellt einen zweiten Slack-Kanal. Der Notion-Workspace, der als eine einzelne Seite mit einigen Aufzählungspunkten begann, hat jetzt siebenundvierzig Seiten in sechs Abschnitten, und niemand kann sich einigen, wo die Produkt-Roadmap eigentlich lebt (die Antwort ist, amüsanterweise, dass es drei Teilversionen an drei verschiedenen Orten gibt, jede auf eine leicht andere Weise veraltet).
title: "Ein typischer Dienstag in einem 8-köpfigen Startup" 9:00 AM|ok|Standup: Die Designerin erwähnt, dass sie auf Texte vom Gründer wartet 9:03 AM|ok|Der Gründer sagt: „Ich schicke sie dir bis zum Mittagessen" 10:14 AM|amber|Der Gründer wird in ein Kundengespräch gezogen, das 90 Minuten dauert 11:45 AM|amber|Die Designerin schreibt dem Gründer in Slack – keine Antwort (noch im Gespräch) 12:30 PM|missed|Der Gründer isst zu Mittag und vergisst die Texte tatsächlich 1:15 PM|ok|Die Designerin fängt an, an etwas anderem zu arbeiten 3:00 PM|missed|Der Gründer erinnert sich an die Texte, schreibt sie, legt sie in ein Google Doc, schickt sie per DM an die falsche Designerin (letzte Woche wurde eine zweite eingestellt) 4:30 PM|missed|Die ursprüngliche Designerin verlässt das Büro, wartet noch immer
Niemand in diesem Ablauf ist inkompetent oder unachtsam. Jede einzelne Person hat bei jedem einzelnen Schritt etwas Vernünftiges getan. Der Gründer hat einen wichtigen Kundentermin wahrgenommen! Die Designerin hat mit anderen Aufgaben weitergemacht, statt untätig zu sitzen! Das sind alles korrekte individuelle Entscheidungen, die ein kollektiv schlechtes Ergebnis produziert haben – und das ist der ganze Punkt: Operativer Overhead in Startups wird nicht durch schlechte Menschen verursacht, sondern durch gute Menschen, die in einem System operieren, das seinen Koordinationsmechanismen entwachsen ist.
Stufe Drei: Die Prozesspanik (Monate 15–22, Personen 9–15)
Hier wird es kostspielig, und hier tritt der menschliche Bösewicht wirklich in den Vordergrund. Denn um Person neun oder zehn herum wird der Schmerz unmöglich zu ignorieren. Dinge fallen durch. Keine riesigen Dinge (na ja, manchmal riesige Dinge), aber ein stetiger Nieselregen aus verpassten Aufgaben, doppelter Arbeit, veralteten Informationen und Meetings, die ausschließlich existieren, damit sich die Leute Dinge erzählen können, die sie aus einem gemeinsamen Dokument hätten lernen können, wenn das gemeinsame Dokument existiert hätte und tatsächlich geteilt worden wäre.
stat: "25–45%" headline: "Der Arbeitszeit, die bei 10–20-Personen-Teams durch Koordinations-Overhead verloren geht" source: "Asana Anatomy of Work 2023; Microsoft Work Trend Index 2023; Clockwise Engineering-Daten"
Die Zahlen sind tatsächlich schlimmer als die meisten Gründer erwarten. Asanas Anatomy of Work Report (n=9.615 über sechs Länder) ergab, dass 58 % des Tages eines durchschnittlichen Wissensarbeiters für „Arbeit über Arbeit" draufgeht – Koordination, Statusverfolgung, Informationssuche, Wechsel zwischen Tools. Microsofts Work Trend Index landete bei nahezu identischen 57 %. Selbst Clockwises Engineering-spezifische Daten – die eher zu kleineren, schlankeren Unternehmen tendieren – zeigten, dass Ingenieure allein 9,7 Stunden pro Woche in Meetings verbringen, bevor man das Slack-Hinterherjagen, die Dokumentensuche und das erneute Erklären dazurechnet.
Für ein Startup im Bereich von 10–20 Personen ist eine konservative Schätzung, dass 25–45 % der Arbeitszeit für reinen Koordinations-Overhead draufgehen. Was das in harter Währung kostet, hängt vollständig davon ab, wo Ihr Team sitzt:
| Standort | Kombinierter Stundensatz | Jährlicher Overhead pro Person (bei 30 %) | |---|---|---| | San Francisco | ~$134/hr | ~$72,000 | | Manhattan, NY | ~$116/hr | ~$63,000 | | Baden-Württemberg | ~€54/hr (~$59) | ~€29,000 (~$32,000) | | Tokyo | ~¥5,056/hr (~$34) | ~¥2.7M (~$18,000) | | Shenzhen | ~¥289/hr (~$40) | ~¥155K (~$21,000) |
Diese kombinierten Sätze beinhalten Sozialleistungen und Arbeitgebersteuern zusätzlich zum Grundgehalt. Die „30 %"-Spalte ist der Mittelwert des 25–45 %-Bereichs – und wenn Sie ehrlich zu sich selbst sind, liegt Ihr Team wahrscheinlich näher am oberen Ende. Selbst bei der konservativen Schätzung verbrennt ein Zwölf-Personen-Startup in San Francisco grob $860.000 pro Jahr für Koordination, die kein Produkt baut. In Stuttgart sind es eher €350.000. In Tokyo etwa ¥33 Millionen. Die absoluten Zahlen variieren, aber der Anteil Ihrer Burn Rate, der darauf entfällt, dass Leute anderen Leuten erzählen, was sie tun, anstatt es zu tun, ist bemerkenswert konsistent über Geographien hinweg.
Und hier ist, was als nächstes passiert, denn es passiert jedes Mal: Jemand – meistens ein Gründer, manchmal eine neu eingestellte Operations-Person – erklärt, dass das Team Prozess braucht. Großes P. Sie führen ein Projektmanagement-Tool ein, oder ein zweites Projektmanagement-Tool, oder ein wöchentliches Planungsmeeting, oder ein tägliches schriftliches Check-in, oder ein aufwändiges Notion-Vorlagensystem mit siebzehn Eigenschaften pro Seite. Die Absicht ist gut! Die Ausführung ist manchmal sogar gut! Aber das grundlegende Problem ist, dass das Hinzufügen von Prozessen zu einem Team, das achtzehn Monate damit verbracht hat, eine Identität rund um keinen Prozess zu brauchen aufzubauen, ist wie das Installieren einer Sprinkleranlage in einem Haus, in dem alle glauben, feuerfest zu sein.
Die Leute füllen die Statusfelder nicht aus. Sie vergessen, das Ticket zu aktualisieren, wenn sich der Umfang ändert. Sie führen das wichtige Gespräch in einem DM und posten es dann nicht im Kanal. Nicht weil sie etwas sabotieren – sondern weil sie Menschen mit begrenzter Aufmerksamkeit und tief verwurzelten Gewohnheiten sind, und die Gewohnheiten, die sie im Drei-Personen-Paradies aufgebaut haben, sind genau die Gewohnheiten, die das Fünfzehn-Personen-Unternehmen zum Scheitern bringen.
Die Compounding-Mathematik des operativen Overheads in Startups
Die Zahlen sind schlimmer als die meisten Leute erwarten, weil operativer Overhead in Startups nicht linear wächst, wenn das Unternehmen wächst.
Angenommen, Sie haben acht Personen und Ihr Koordinations-Overhead beträgt moderate 20 % – etwa 32 Stunden pro Person pro Monat kollektiv, oder 256 Personenstunden über das gesamte Team. Lästig, aber handhabbar – Sie sind ein Startup, Sie arbeiten hart, Sie absorbieren es.
Jetzt stellen Sie in einem Quartal vier weitere Personen ein. Sie sind bei zwölf. Aber Koordinations-Overhead skaliert nicht linear mit der Anzahl der Mitarbeiter – er skaliert mit der Anzahl der Kommunikationspfade, was ungefähr n(n-1)/2 ist. Der Übergang von 8 auf 12 Personen erhöht Ihre Kommunikationspfade von 28 auf 66 – mehr als eine Verdopplung. Ihr Overhead pro Person bleibt nicht bei 20 %; Forschung zeigt konsistent, dass er bei dieser Größe auf 30–35 % klettert, weil es einfach mehr Personen gibt, mit denen man koordinieren muss, mehr Kanäle zum Überwachen, mehr Meetings, an denen man teilnehmen muss, und mehr Möglichkeiten für die Art von harmlosem Informationsverlust, den wir in der obigen Dienstag-Zeitleiste gesehen haben.
Sie haben also 12 Personen mal ungefähr 50 Stunden pro Monat Koordinations-Overhead, was 600 Personenstunden ergibt – mehr als doppelt so viel wie bei acht Personen, obwohl Ihr Team nur um 50 % gewachsen ist. Diese 600 Stunden pro Monat repräsentieren ungefähr dreieinhalb Vollzeit-Ingenieure, die im Endeffekt daran arbeiten, das Team koordiniert zu halten, anstatt das zu bauen, was das Team eigentlich bauen soll. Rob Cross' Forschung an der UVA, veröffentlicht in Harvard Business Review, ergab, dass kollaborative Aktivitäten bei vielen Unternehmen auf 80 % oder mehr der Arbeitszeit der Mitarbeiter angeschwollen sind – und obwohl diese Zahl eher zu größeren Organisationen tendiert, beginnt die Entwicklung hier, genau an diesem Wendepunkt.
Operativer Overhead in Startups wächst nicht linear mit der Mitarbeiterzahl. Er wächst mit der Anzahl der Beziehungen und Informationsflüsse zwischen Personen – was bedeutet, dass jede Neueinstellung das Problem überproportional verschlimmert, wenn man nicht aktiv in die Reduzierung der Koordinationssteuer investiert. Der Bösewicht sind nicht Ihre Tools, Ihr Prozess oder Ihre Organisationsstruktur – es ist die völlig natürliche menschliche Tendenz anzunehmen, dass das, was bei drei Personen funktioniert hat, auch bei fünfzehn funktioniert.
Was wirklich hilft (und was nicht)
Der Instinkt der meisten Teams – ein besseres Projektmanagement-Tool kaufen, eine Operations-Person einstellen, mehr Meetings hinzufügen – ist nicht falsch, aber unvollständig, weil er das Symptom behandelt (die Leute wissen nicht, was vor sich geht), ohne die Ursache anzugehen (Informationen sind über ein Dutzend Tools verteilt und niemand hat die Kapazität, alles manuell zu synthetisieren).
Was wirklich den Ausschlag gibt, ist laut unserer Erfahrung, die Kosten der Ambient Awareness zu senken. Wenn die Leute mühelos auf dem Laufenden bleiben könnten, was in den Tools passiert, die sie bereits verwenden – ohne manuell Linear zu prüfen, dann GitHub, dann Slack, dann Notion, dann den Kalender, dann wieder zurück zu Slack – würde ein großer Teil des Koordinations-Overheads einfach verschwinden, weil die eigentliche Ursache der meisten verpassten Aufgaben nicht ist, dass sich die Leute nicht kümmern, sondern dass sie es nicht wussten.
Das ist – transparent gesagt – das Problem, für das Sugarbug entwickelt wurde. Es verbindet sich über API mit den Tools, die Ihr Team bereits verwendet, und baut aus allen Signalen, die diese Tools generieren, einen Wissensgraph auf, sodass wenn Ihr Engineer gegen eine veraltete Spezifikation entwickelt, die Tatsache, dass sich die Spezifikation in einem Notion-Dokument am Dienstag geändert hat, tatsächlich vom System sichtbar gemacht wird, anstatt davon abzuhängen, dass ein Mensch daran denkt, es im Standup zu erwähnen. Wir ersetzen nicht Ihre Tools oder Ihre Prozesse (ehrlich gesagt sollten Sie immer noch gute Prozesse haben), aber wir versuchen, den Informationsfluss zwischen all diesen Tools weniger abhängig von jemandes Gedächtnis und Aufmerksamkeitsspanne zu machen.
Abgesehen davon möchte ich ehrlich darüber sein, was nicht hilft, obwohl das Startup-Ops-Beratungsökosystem es gerne empfiehlt. Einen „Chief of Staff" oder „Head of Ops" bei zwölf Personen einzustellen ist nach unserer Erfahrung verfrüht – Sie fügen einem bereits überlasteten Netzwerk einen weiteren Kommunikationsknoten hinzu, und der gesamte Job dieser Person wird manuell das zu tun, was Software automatisch tun sollte. Ebenso ist ein wöchentliches „All-Hands"-Statusmeeting, bei dem fünfzehn Personen in einem Raum sitzen und der Reihe nach ihre Updates vorlesen, eine der – um ehrlich zu sein – ineffizientesten Nutzungen kollektiver Zeit, die je erfunden wurden, und ich sage das als jemand, der ungefähr vierhundert davon mitgemacht hat.
Der echte Bösewicht sind Sie (genauer gesagt, Ihre Gewohnheiten)
Ich möchte auf das menschliche Framing zurückkommen, weil ich denke, dass es die wichtigste Erkenntnis dieses gesamten Artikels ist. Wenn operativer Overhead in Startups Ihre Velocity zu zerquetschen beginnt, ist die Versuchung groß, nach etwas Externem zu suchen, dem man die Schuld geben kann – die Tools sind falsch, der Prozess ist kaputt, die Org-Struktur ist schlecht. Und manchmal stimmt das! Aber häufiger ist das grundlegende Problem, dass die Leute im Team genau das tun, was sich im Moment natürlich, vernünftig und effizient anfühlt, und der aggregierte Effekt all dieser individuell vernünftigen Entscheidungen ist eine Organisation, die 25 % ihrer Kapazität für Koordination statt für Schöpfung aufwendet.
Ihre Designerin aktualisiert das Figma-Statusfeld nicht, weil es fünfzehn Sekunden dauert und sie zwölf andere Dinge im Kopf hat. Ihr Engineer postet das DM-Gespräch nicht im Kanal, weil es redundant erscheint (die Person, die es wissen musste, war ja im DM, oder?). Ihr Gründer schreibt die Entscheidung aus dem Kundengespräch nicht auf, weil sie bereits zum nächsten Ding weitergegangen ist und es außerdem morgen erwähnen wird. Jede einzelne davon ist eine rationale individuelle Entscheidung, und jede einzelne trägt zur langsamen, unsichtbaren Anhäufung von Koordinationsschulden bei, die ein Zwölf-Personen-Team letztendlich langsamer macht als bei sechs Personen.
Die Lösung ist nicht, die Leute schlecht fühlen zu lassen dafür, dass sie Menschen sind. Die Lösung ist, Systeme aufzubauen – ob das kulturelle Gewohnheiten, Prozessnormen oder (hoffentlich) Software sind, die es automatisch erledigt – die die richtigen Informationen den richtigen Personen zur Verfügung stellen, ohne dass alle ein perfektes Gedächtnis und unendliche Aufmerksamkeit haben müssen.
Wenn dieser Artikel Sie angesprochen hat und Sie sehen möchten, wie Sugarbug's Wissensgraph die Koordinationssteuer in Ihrem Team reduzieren kann, melden Sie sich für den Frühzugang an – wir starten mit Teams im Bereich von 5 bis 30 Personen und würden Ihnen gerne zeigen, wie Ambient Awareness in der Praxis aussieht.
Häufig gestellte Fragen
Q: Was ist operativer Overhead in Startups? A: Operativer Overhead in Startups ist die gesamte Zeit, Energie und das Geld, die Ihr Team für Koordination statt für Entwicklung aufwendet – Status-Meetings, das Hinterherjagen von Updates über verschiedene Tools, das erneute Erklären von Kontext, den jemand verpasst hat, die Suche nach der maßgeblichen Version eines Dokuments und das Abgleichen widersprüchlicher Informationen, die an sechs verschiedenen Orten gespeichert sind. Es ist die Steuer, die Sie dafür zahlen, dass mehr als eine Person an derselben Sache arbeitet, und sie wächst schneller als die meisten Gründer erwarten, wenn das Team skaliert.
Q: Wie hilft Sugarbug dabei, den operativen Overhead in Startups zu reduzieren? A: Sugarbug verbindet sich über API mit den Tools, die Ihr Team bereits verwendet – Linear, GitHub, Slack, Notion, Google Calendar, Figma und andere – und baut aus allen Signalen, die diese Tools erzeugen, einen lebendigen Wissensgraph auf. Wenn sich eine Spezifikation in Notion ändert, ein PR in GitHub landet oder ein Meeting im Kalender verschoben wird, stellt Sugarbug diese Updates im Kontext bereit, damit Ihr Team Informationen nicht manuell über ein Dutzend Tabs verfolgen muss. Es ersetzt nicht Ihre Tools; es stellt sicher, dass die wichtigen Signale, die durch sie fließen, nicht verloren gehen.
Q: Ab welcher Teamgröße wird der operative Overhead zu einem ernsthaften Problem? A: Die meisten Teams beginnen, wirklichen Schmerz um 8–12 Personen zu spüren – das ist der Punkt, an dem informelle Koordination (Dinge mithören, in allen denselben Kanälen sein, Kontext im Kopf behalten) zusammenbricht, aber formale Prozesse entweder noch nicht existieren oder noch nicht konsequent eingeführt wurden. Der Overhead akkumulierte sich schon vor dieser Schwelle – er war nur nicht schmerzhaft genug, um bemerkt zu werden.
Q: Kann Sugarbug Projektmanagement-Tools wie Linear oder Asana ersetzen? A: Nein, und das ist so beabsichtigt. Sugarbug sitzt neben Ihrem bestehenden Stack und liest daraus, wobei es einen Wissensgraph aufbaut, der Informationen über Tools hinweg verbindet. Ihr Projekttracker ist nach wie vor der Ort, an dem Sie Arbeit planen und verfolgen; Sugarbug ist die Schicht, die sicherstellt, dass eine Entscheidung in Slack, eine Umfangsänderung in Notion und ein blockierter PR in GitHub alle miteinander verbunden werden, damit nichts durch die Ritzen fällt. Betrachten Sie es als das Bindegewebe zwischen Ihren Tools, nicht als Ersatz für eines davon.