Hauptgedanke

Ein Entwickler, der einen Coding-Agenten nutzt und dreimal so schnell ausliefert, wechselt deswegen noch nicht die Rolle. Hat er weder Zugang zu den Kunden noch zu den Nutzungsdaten, zum Geschäftskontext oder zu den Prioritätsabwägungen, gewinnt er vor allem Last: mehr Features, die er trägt, mehr Termindruck, mehr lokale Entscheidungen, die er im Ungewissen treffen muss – ohne die Produktmacht, die es ihm erlauben würde, mehr als nur Standardentscheidungen zu treffen.

Das ist der Unterschied zwischen dem, der einen Teil der Urteilskraft am Produkt ganz nah an den Bau trägt, und dem, der eine Produktionsmaschine steuert. Das Erste setzt einen Zugang voraus; das Zweite nur ein Werkzeug.

Eine Organisation, die ankündigt, das Produkt-Ownership an die weiterzugeben, die bauen, ohne zugleich den Zugang zu Kunden, Daten und Abwägungen zu öffnen, verteilt also die Verantwortung um und behält die Macht. Der Aufstieg in der Rolle bleibt nominell.

Warum das wichtig ist

Das liefert einen Test für jede angekündigte Umverteilung: Was darf die Person jetzt sehen und entscheiden, zusätzlich zu dem, was sie ausliefern darf?

Und es benennt das Risiko einer schleichenden Verschlechterung: Das Team ist produktiver, die Delivery-Kennzahlen verbessern sich, und die Arbeit wird für die, die sie machen, immer weniger tragbar.

Nuancen und Grenzen

Zugang allein genügt auch nicht. Kunden zu treffen, ohne Zeit zu haben, das Gehörte zu verarbeiten, oder bei Abwägungen dabei zu sein, ohne Gewicht zu haben, erzeugt denselben Effekt mit dem Anschein von Offenheit.

Und nicht alle Entwickler wünschen sich diese Verschiebung: Manche wollen bauen, nicht abwägen, und ihnen Produkt-Ownership aufzuzwingen verschlechtert die Arbeit, statt sie zu bereichern.

Offene Fragen

• Welches Maß an Zugang zu Kunden und Abwägungen reicht, damit das Ownership real wird, ohne das Entwicklungsteam in ein Discovery-Team zu verwandeln?