← Zurück zum Blog

Wenn das Team schneller wächst als das System

Das Investment ist abgeschlossen. Der Einstellungsplan läuft. Jede Woche fangen neue Leute an. Und irgendwo zwischen dem dritten und dem zehnten Hire taucht eine Frage auf, auf die kein Pitch Deck vorbereitet hat: Wie funktioniert das alles eigentlich zusammen?

Was nie erklärt werden musste

Ein Solo-Gründer oder ein kleines Gründungsteam arbeitet auf eine Art, die mühelos wirkt — nicht weil es einfach ist, sondern weil es so oft wiederholt wurde, dass es unsichtbar geworden ist. Wie ein Feature von der Idee bis zum Release kommt. Wie eine Kundenanfrage zu einer Entscheidung wird. Wie Qualität gewahrt bleibt, ohne dass jemand es aufschreibt. Der gesamte Lebenszyklus — vom Erstkontakt bis zum gelieferten Produkt — läuft auf Wissen, das nie explizit gemacht wurde, weil es nie jemanden gab, dem man es hätte erklären müssen.

Die Forscher Nonaka und Takeuchi nennen das implizites Wissen — Wissen, das im Handeln existiert, im Urteilsvermögen, in der Art wie Dinge getan werden, sich aber dagegen sträubt, in Worte gefasst zu werden. In einem Gründungsteam überträgt sich dieses Wissen auf natürliche Weise durch Nähe: Man arbeitet Seite an Seite, sieht wie Entscheidungen getroffen werden, nimmt die Muster auf. Der Prozess hat sich durch Wiederholung in der Startphase geformt, über Hunderte von Iterationen verfeinert. Er funktioniert. (Nonaka & Takeuchi: The Knowledge-Creating Company)

Dann wächst das Team von drei auf fünfzehn.

Die Management-Herausforderung

Fred Brooks beobachtete 1975, was jedes wachsende Team für sich selbst entdeckt: Der Kommunikationsaufwand wächst nicht linear mit der Teamgröße. Er wächst exponentiell. Drei Personen haben drei Kommunikationspfade untereinander. Fünf haben zehn. Zehn haben fünfundvierzig. Fünfzehn haben einhundertfünf. (Fred Brooks: The Mythical Man-Month)

George Millers Forschung zeigte, dass Menschen etwa sieben Elemente gleichzeitig im Arbeitsgedächtnis halten können — ein Limit, das nicht nur für Informationen gilt, sondern auch für die Anzahl an Arbeitsbeziehungen, die ein Team ohne Struktur aufrechterhalten kann. Der Scrum Guide greift dies auf, wenn er Teams von zehn oder weniger empfiehlt. Forschungen zu Softwareteams fanden das Optimum sogar noch niedriger: bei etwa fünf, wobei größere Teams deutlich mehr Fehler bei einem Vielfachen der Kosten produzierten.

Aber der eigentliche Wandel dreht sich nicht um eine Zahl. Es geht darum, was sich in der Zusammenarbeit verändert. In einem Gründungsteam ist Kommunikation ambient. Man bekommt eine Entscheidung mit. Man sieht, wie ein Problem gelöst wird. Man nimmt Kontext auf, ohne dass jemand ihn bewusst übermitteln muss. Jedes Missverständnis taucht innerhalb von Minuten auf, weil man nebeneinander sitzt.

Ab der Schwelle bricht dieser ambienter Kanal zusammen. Jede Annahme, die sich durch Nähe übertrug, muss jetzt explizit ausgesprochen werden. Jede Entscheidung, die mit einem Blick über den Schreibtisch passierte, braucht jetzt ein Meeting. Und jedes Missverständnis — die Art, die sich früher innerhalb von Stunden von selbst korrigierte — kann jetzt Tage oder Wochen reisen, bevor es jemand bemerkt.

Die Kosten später Sichtbarkeit

Hier verstecken sich die echten Kosten. Nicht in Gehältern, nicht in Tools — in der Distanz zwischen einem Missverständnis und seiner Entdeckung.

Stellen Sie sich vor, was passiert, wenn zwei Menschen zusammenarbeiten. Einer kommuniziert eine Absicht. Der andere interpretiert. Er produziert etwas basierend auf dieser Interpretation. Der Erste prüft es und entdeckt eine Lücke — nicht weil die Arbeit schlecht war, sondern weil etwas von der Absicht nicht vollständig übertragen wurde. Feedback wird gegeben. Die Arbeit wird angepasst. Der Kreis schließt sich.

Das ist die fundamentale Schleife aller kollaborativen Arbeit. Und ihre Kosten hängen fast ausschließlich von ihrer Länge ab. Barry Boehms Forschung zu den Kosten von Änderungen, validiert über Jahrzehnte in Softwareprojekten, zeigt: Eine Fehlausrichtung, die während der Planung erkannt wird, kostet einen Bruchteil dessen, was dieselbe Fehlausrichtung kostet, wenn sie erst in der Produktion entdeckt wird — manchmal das Hundertfache weniger. (Examining the Cost of Change Curve)

In einem Gründungsteam ist diese Schleife kurz. Man versteht etwas falsch, entdeckt es in Stunden, korrigiert es. Die Kosten sind vernachlässigbar. In einem Team von fünfzehn ohne Struktur kann dasselbe Missverständnis einen gesamten Entwicklungszyklus durchlaufen — durch Design, Implementierung, Testing — bevor es auftaucht. Dann sind die Kosten nicht nur die Nacharbeit. Es sind die kaskadierenden Entscheidungen, die auf der falschen Annahme aufgebaut wurden.

Die Frage ist nicht, ob Missverständnisse passieren. Sie passieren immer. Die Frage ist: Wie schnell werden sie sichtbar?

Wo das praktisch wird

Die Frameworks gibt es — Scrum, Kanban, ein Dutzend Varianten. Die Prinzipien sind gut dokumentiert. Aber sie in Ihrer spezifischen Umgebung zu implementieren, mit Ihrem Team, Ihrem Produkt und den Mustern, die Sie bereits aufgebaut haben — das ist eine völlig andere Herausforderung.

Hier arbeite ich. Ich komme in eine wachsende Organisation und beginne damit zu beobachten, was schon da ist. Nicht um zu urteilen, sondern um zu sehen. Denn jedes Unternehmen hat bereits ein System, auch wenn es nie als solches entworfen wurde. Die Gründer haben es über Jahre der Wiederholung aufgebaut. Teile davon sind hervorragend. Andere Teile sind unsichtbare tragende Wände — und sie werden erst sichtbar, wenn sie unter dem Gewicht des wachsenden Teams Risse bekommen.

Mein Ansatz beginnt mit Stabilität. Ich bringe Prozess ins Team — zugeschnitten auf den Punkt, an dem Sie tatsächlich stehen, nicht dort, wo ein Lehrbuch sagt, dass Sie sein sollten. Wir machen sichtbar, was Reibung verursacht: wo Entscheidungen steckenbleiben, wo Information verloren geht, wo dieselben Missverständnisse immer wieder auftreten. Sobald die Auswirkungen klar sind, gehen wir sie an. Schrittweise. Ohne zu zerstören, was bereits funktioniert.

Von dieser stabilen Basis aus entwickelt das Team die Fähigkeit, die am meisten zählt: die eigene Kommunikation zu beobachten, die eigenen Annahmen, den eigenen Prozess. Darüber zu sprechen, was sie sehen. Zu entscheiden, was geändert werden soll. Zu handeln. Und aus dem Ergebnis zu lernen. Nicht als einmaliger Eingriff, sondern als dauerhafte Fähigkeit, die der Organisation gehört.

Und wenn Sie früher in der Reise sind — Team wächst, Investment gesichert, System noch nicht unter Druck — ist das oft der beste Zeitpunkt, um anzufangen. Das Betriebssystem gemeinsam mit dem Team von Anfang an aufzubauen kostet einen Bruchteil dessen, was der Umbau unter Belastung kostet.

Weiterführende Literatur

Für alle, die tiefer in die im Artikel referenzierten Konzepte einsteigen möchten:

• Brooks’s Law — The Mythical Man-Month — Fred Brooks. Warum das Hinzufügen von Personen zu einem Team den Kommunikationsaufwand exponentiell erhöht.
• Examining the Cost of Change Curve — Scott Ambler. Wie die Kosten für die Behebung von Fehlausrichtungen mit der Distanz zu ihrem Ursprung wachsen.
• The Scrum Guide — Schwaber & Sutherland. Das definitive Framework für empirische Produktentwicklung.
• Nonakas SECI-Modell — Wie implizites Wissen durch Zyklen von Lernen und Arbeiten zu organisationalem Wissen wird.