Idee

Steigt die Produktionsfähigkeit, wandert der Engpass zu dem, der entscheidet

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Hauptgedanke

Ein Entwickler mit einem Coding-Agenten schreibt nicht bloß seine Zeilen schneller: Er produziert mehr Optionen, mehr Varianten, mehr Prototypen, mehr kleine interne Werkzeuge, mehr Initiativen. Ein Team, dessen Delivery-Fähigkeit begrenzt war, erzeugt plötzlich sehr viel mehr, das getestet, gegengelesen, abgewogen und priorisiert werden will.

Die Entscheidungsfähigkeit dagegen steigt nicht im selben Tempo. Läuft weiterhin alles über den Product Manager – Priorisierung, Produktkohärenz, Prüfung des Kundensignals, Marktabwägungen, Umgang mit den Folgen –, wird er zum Sättigungspunkt des Systems. Die Organisation glaubt, ein Geschwindigkeitsproblem gelöst zu haben, weil die Entwickler mehr ausliefern; tatsächlich hat sie die Blockade nur von einer Stelle an eine andere verschoben.

Es gibt drei Antworten, und sie sind nicht gleichwertig. Zusätzliche Product Manager einzustellen fügt eine weitere Abwägungsschicht hinzu, ohne das Modell zu ändern. Den operativen Teil der Rolle zu automatisieren – Dokumentation, Release Notes, Launch-Unterlagen, Übersetzungen, Screenshots – schafft Stunden frei, ohne die eigentliche Frage zu berühren. Einen Teil des Produkt-Ownerships an die weiterzugeben, die bauen, ist die einzige, die an der Ursache ansetzt – und die, die die Rollen verschwimmen lässt.

Warum das wichtig ist

Das liefert einen Test, bevor man ein Team mit Werkzeugen ausstattet: Wohin wandert die Warteschlange, wenn sich die Produktion verdoppelt hat? Mehr Durchsatz vor einem einzigen Entscheidungspunkt wird zu Wartezeit, nicht zu Wert.

Und es erklärt, warum manche bestens ausgestatteten Teams die Beschleunigung als Verschlechterung erleben: Die Arbeit kommt schneller an einer Stelle an, deren Fähigkeit sich nicht verändert hat, und der Stau wird dort sichtbar – als Verzögerungen und als unentschiedene Themen.

Nuancen und Grenzen

Die Verschiebung ist nicht mechanisch. Ein Team, in dem die Entscheidung bereits verteilt ist – weil die Entwickler einen Teil ihres Zuständigkeitsbereichs selbst abwägen –, nimmt den Zuwachs auf, ohne jemanden zu überlasten.

Und die Sättigung kann von anderswo herrühren als von der Entscheidung: Support, Produktivsetzung oder die Fähigkeit des Markts, Neuerungen aufzunehmen, können noch vor dem Product Manager zum Engpass werden.

Offene Fragen

  • An welchem Signal erkennt ein Team, dass seine Warteschlange zur Entscheidung gewandert ist, bevor die Verzögerungen es offenlegen?