In R&D-Organisationen dreht sich fast jede Diskussion um Technologie. Um Architektur, Tooling, die nächste Plattform, inzwischen um AI. Über die Kräfte, die im Hintergrund darüber entscheiden, warum dieselbe Organisation mit denselben fähigen Leuten plötzlich nicht mehr liefert, redet kaum jemand. Es sind selten technische Kräfte. Es sind organisatorische. Zehn davon tauchen so verlässlich auf, dass man sie fast wie Naturgesetze behandeln kann. Wer sie kennt, versteht sein Entwicklungssystem besser als mit jedem Tool.
Die folgenden zehn stammen aus ganz unterschiedlichen Ecken: aus der Informatik, der Warteschlangentheorie, der Psychologie, der Anthropologie, der Ökonomie. Keines wurde für R&D-Organisationen formuliert. Und trotzdem beschreibt jedes von ihnen erstaunlich präzise, was in Entwicklungsabteilungen täglich passiert.
Das Unangenehme an ihnen ist, dass man mit ihnen nicht verhandeln kann. Man kann sie ignorieren, doch auch dann wirken sie. Oder man richtet die Organisation so ein, dass sie auf der eigenen Seite stehen.
Melvin Conway formulierte 1967 eine Beobachtung, die bis heute fast trotzig ignoriert wird: Organisationen bauen Systeme, die ihre eigene Kommunikationsstruktur abbilden.
Wer eine Architektur entwirft, entwirft immer auch ein Abbild seiner Organisation. In R&D heisst das, dass die Schnittstellen im Produkt meistens genau dort liegen, wo die Schnittstellen zwischen den Teams liegen. Drei Teams, die an einem Modul arbeiten, produzieren am Ende drei Module. Kein Refactoring der Welt repariert eine Architektur, deren eigentliches Problem die Teamzuschnitte sind.
Wer die Architektur ändern will, muss zuerst die Organisation ändern. Das ist unbequem, weil es Verantwortlichkeiten verschiebt. Es ist aber der einzige Hebel, der wirklich greift.
Fred Brooks brachte es 1975 auf eine Formel, die jeder Projektleiter kennt und trotzdem regelmässig bricht: Wer einem verspäteten Projekt mehr Leute hinzufügt, macht es noch später.
Der Grund dafür ist simple Mathematik. Jede neue Person muss eingearbeitet werden, und jede neue Person erhöht die Zahl der Kommunikationswege überproportional. Bei fünf Leuten gibt es zehn Verbindungen, bei zehn bereits fünfundvierzig. In einem Entwicklungssystem, das ohnehin unter Termindruck steht, ist das genau die zusätzliche Last, die niemand gebrauchen kann.
Die Konsequenz ist für Manager, die unter Druck handeln wollen, schwer auszuhalten: Manchmal ist die schnellste Intervention, dem Team Ruhe zu geben statt Verstärkung.
Schon Ende des 19. Jahrhunderts liess Maximilien Ringelmann Menschen an einem Seil ziehen und mass mit, wie stark jeder Einzelne zog. Das Ergebnis: Je grösser die Gruppe, desto weniger gab der Einzelne. Niemand tat das absichtlich. Individuelle Leistung verschwimmt, sobald sie in der Masse nicht mehr sichtbar ist.
In R&D-Organisationen zeigt sich das überall dort, wo Verantwortung diffundiert. Grosse Projektgruppen, in denen niemand wirklich zuständig ist. Meetings mit zwölf Teilnehmern, in denen drei reden und neun warten. Der Output pro Kopf sinkt, während die Kostenstelle wächst.
Kleine Teams mit klarer Zuständigkeit schlagen grosse Gruppen mit verteilter Verantwortung fast immer. Sichtbarkeit und Accountability schlägt Masse.
Der Anthropologe Robin Dunbar fand einen Zusammenhang zwischen Hirngrösse und der Anzahl stabiler Beziehungen, die ein Primat pflegen kann. Für den Menschen liegt diese Zahl bei rund 150.
Das ist die Grenze, ab der informelle Koordination kippt. Bis dahin funktioniert eine Organisation über kurze Wege, gemeinsame Geschichte und die Tatsache, dass man sich kennt. Darüber hinaus reicht das nicht mehr. Wer in einer Entwicklungsabteilung mit 600 Leuten darauf hofft, dass sich die Dinge schon irgendwie von selbst abstimmen, wird verlässlich enttäuscht.
Ab einer gewissen Grösse muss Koordination bewusst gestaltet werden. Klare Rollen, explizite Entscheidungswege, definierte Schnittstellen. Das fühlt sich nach Bürokratie an, ist aber schlicht der Preis der Grösse.
John Little bewies mathematisch, was im Entwicklungsalltag täglich ignoriert wird: Die Durchlaufzeit einer Aufgabe hängt direkt davon ab, wie viel parallel offen ist. Mehr gleichzeitige Arbeit bedeutet längere Wartezeiten, keinen höheren Output.
Das ist der wunde Punkt vieler R&D-Organisationen. Die Auslastung liegt bei 95 Prozent, alle sind permanent beschäftigt, und trotzdem dauert alles ewig. Der Grund ist meist nicht mangelnder Einsatz. Es ist zu viel gleichzeitig im System. Jede Aufgabe wartet, weil alle anderen auch warten.
Wer die Time-to-Market verkürzen will, muss nicht schneller arbeiten, sondern weniger gleichzeitig machen. Work-in-Progress (WIP) zu begrenzen ist die unbeliebteste und die wirksamste Massnahme zugleich.
Cyril Northcote Parkinson formulierte 1955 halb satirisch, was sich längst als bitterer Ernst erwiesen hat: Arbeit dehnt sich genau so weit aus, wie Zeit für sie zur Verfügung steht.
Gib einem Team sechs Monate für eine Aufgabe, und es braucht sechs Monate. Der Grund liegt selten in der Aufgabe selbst. Gründlichkeit, Nebenschauplätze und Gold-Plating schieben sich in jede verfügbare Lücke. In regulierten Umfeldern, wo Sorgfalt ohnehin Pflicht ist, ist die Versuchung besonders gross jedes noch so kleine Risiko zu mitigieren oder doch noch diese kleine Funktionalität umzusetzen, die ein Kunde niemals bemerken wird..
Kürzere Zyklen und enge Timeboxes sind kein Misstrauensvotum gegenüber dem Team. Sie zwingen zur Priorisierung und machen sichtbar, was wirklich wesentlich ist.
Douglas Hofstadter formulierte ein Gesetz, das sich selbst auf die Schippe nimmt und beinahe absurd klingt: Es dauert immer länger als geplant, selbst wenn man Hofstadters Gesetz bereits einberechnet hat.
Jeder, der schon einmal einen Entwicklungs- oder Projektplan aufgestellt hat, kennt das Gefühl. Die Schätzung war optimistisch, die Realität war es nicht. Das ist kein Versagen einzelner Personen. Es ist ein systematischer Bias: Wir unterschätzen das Unbekannte, weil wir es ja per Definition gar nicht kennen (können).
Reife Organisationen behandeln Schätzungen als das, was sie sind: Wahrscheinlichkeiten, keine Versprechen. Sie planen mit Puffern und akzeptieren, dass ein Plan eine Hypothese ist, die sich an der Wirklichkeit überprüfen lassen muss.
Bereits 1908 zeigten die Psychologen Yerkes und Dodson, dass Druck und Leistung nicht linear zusammenhängen. Die Kurve steigt zunächst, kippt dann und fällt dann wieder ab. Etwas Druck steigert die Leistung. Zu viel Druck zerstört sie.
Genau hier verschätzen sich viele R&D-Organisationen. Sie fahren ihre Teams chronisch am oberen Ende der Belastungsgrenze, in der Annahme, maximaler Druck bringe maximalen Output. Das Gegenteil tritt in der Regel ein. Unter Dauerstress sinken Kreativität, Urteilsvermögen und Sorgfalt. In einem Umfeld, in dem ein übersehener Fehler ein Audit oder eine Zulassung kosten kann, wird das schnell teuer.
Leistung braucht Last, aber sie braucht auch Erholung. Ein bisschen Luft im System ist keine Verschwendung. Sie ist die Voraussetzung dafür, dass die Organisation überhaupt denken kann.
Charles Goodhart fasste in einem Satz zusammen, woran unzählige Steuerungssysteme scheitern: Sobald eine Kennzahl zum Ziel wird, taugt sie nicht mehr als Kennzahl.
In R&D lässt sich das in Echtzeit beobachten. Macht man Velocity zum Ziel, steigen die Story Points und nicht der gelieferte (Kunden-)Wert. Misst man die Zahl der Releases, wird häufiger releast und nicht besser. Menschen optimieren zuverlässig genau das, woran sie gemessen werden, auch wenn es mit dem eigentlichen Ziel wenig zu tun hat.
Kennzahlen sind nützlich, solange sie informieren. Gefährlich werden sie, sobald sie steuern. Eine gute Metrik ist ein Thermometer, kein Lenkrad.
1865 beobachtete der Ökonom William Stanley Jevons etwas Paradoxes: Als Dampfmaschinen effizienter wurden, sank der Kohleverbrauch nicht. Er stieg. Effizienz macht die Nutzung billiger, und billigere Nutzung erzeugt mehr Nutzung.
Dasselbe passiert mit Effizienzgewinnen in R&D. Bessere Tools, mehr Automatisierung, AI Agents: Die gewonnene Kapazität fliesst selten in kürzere Timelines. Sie wird sofort von neuem Scope, neuen Projekten, neuen Anforderungen aufgesogen. Ein Entwicklungsleiter brachte es einmal auf den Punkt: "Wie stellen wir sicher, dass die gewonnene Zeit wirklich für Innovation genutzt wird?"
Effizienz allein verkürzt nichts. Was mit der freigewordenen Kapazität geschieht, ist eine bewusste Entscheidung. Trifft man sie nicht, trifft der Scope (Creep) sie für einen.
Zehn Gesetze, ein gemeinsamer Nenner: Keines davon ist ein technisches Problem. Keines lässt sich mit einem besseren Framework, mehr Budget oder dem nächsten Tool aus der Welt schaffen. Sie alle wirken auf der Ebene der Organisation: wie Teams geschnitten sind, wie Arbeit fliesst, wie entschieden und wie gemessen wird.
Das ist eine schlechte Nachricht für alle, die auf eine technische Lösung hoffen, und die gute für alle anderen. Struktur, oder wie wir es nennen Verhältnisse, ist das, was sich tatsächlich gestalten lässt.
Man muss die Gesetze nicht "besiegen". Man muss die Verhältnisse so bauen, dass sie für einen arbeiten und nicht gegen einen.
Die meisten R&D-Organisationen kennen die Symptome längst. Die eigentliche Frage ist, ob sie bereit sind, an der Ursache zu arbeiten.