Wenn in Unternehmen der Ruf nach mehr Geschwindigkeit laut wird, ist dies oft der Beginn einer gefährlichen Abwärtsspirale. Die reflexartige Reaktion der Führungsebene — mehr Prozesse einzuführen, mehr Personal einzustellen oder den Druck zu erhöhen — verschlimmert die Situation häufig noch. Wie Marty Cagan treffend bemerkt:
The biggest mistake I see when teams are perceived as too slow is the rush to add more process or more people — which usually makes things even worse.
Diese oberflächliche Herangehensweise übersieht die tieferliegenden Ursachen und führt zu einer Verschärfung der eigentlichen Probleme.
1. Die Geschwindigkeits-Falle
Der erste fundamentale Fehler liegt bereits in der Diagnose selbst. Die Wahrnehmung, dass ein Team zu langsam sei, basiert meist auf oberflächlichen Beobachtungen und falschen Metriken. In vielen Unternehmen wird Geschwindigkeit fälschlicherweise mit der Anzahl ausgelieferter Features gleichgesetzt. Doch wie Cagan betont:
Velocity is not about how many features you can push out — it’s about how quickly you can deliver value to customers.
Diese fundamentale Verwechslung von Aktivität mit Wertschöpfung ist besonders in der deutschen Unternehmenslandschaft weit verbreitet. Hier herrscht oft noch eine traditionelle, industriell geprägte Denkweise vor, die Software-Entwicklung wie eine Fließbandproduktion behandelt. Dabei wird übersehen, dass Produktentwicklung ein kreativer, iterativer Prozess ist, bei dem reine Geschwindigkeit sogar kontraproduktiv sein kann.
Die wahre Herausforderung liegt nicht darin, mehr Features schneller zu entwickeln, sondern die richtigen Dinge auf die richtige Weise zu tun. Daniel Pink formuliert es in seinem Buch Drive prägnant:
The problem with making an extrinsic reward the only destination that matters is that some people will choose the quickest route there, even if it means taking the low road.
Diese Erkenntnis ist besonders relevant in einer Zeit, in der viele Unternehmen versuchen, durch aggressive Zielvorgaben und ständigen Zeitdruck ihre Teams zu höherer Geschwindigkeit anzutreiben.
2. Die wahren Bremsen: Eine systemische Analyse
Die Ursachen für eine als zu niedrig empfundene Geschwindigkeit sind meist vielschichtig und tief in der Organisationsstruktur verwurzelt. In seiner jahrelangen Arbeit mit Produktteams hat Marty Cagan wiederholt beobachtet, dass die wahren Hindernisse selten an der Oberfläche liegen. Besonders in deutschen Unternehmen, die oft noch stark von hierarchischen Strukturen und traditionellen Managementansätzen geprägt sind, zeigen sich charakteristische Muster, die Teams ausbremsen.
2.1 Die Produkt-Discovery-Falle
Eines der häufigsten und gleichzeitig am meisten unterschätzten Probleme ist die fehlende oder mangelhafte Produkt-Discovery. In vielen Organisationen werden Entwicklungsteams in eine reine Umsetzungsrolle gedrängt, während die eigentliche Produktentwicklung in vorgelagerten Prozessen stattfindet.
When teams are just implementing pre-defined features, they’re not really doing product — they’re just coding,
Diese künstliche Trennung von Denken und Handeln hat weitreichende Konsequenzen für die Effektivität der Teams.
Wenn Entwickler erst spät in den Prozess einbezogen werden, fehlt ihnen das tiefere Verständnis für die Kundenbedürfnisse und den geschäftlichen Kontext. Dies führt zwangsläufig zu suboptimalen Lösungen und zeitraubenden Nachbesserungen. Die Teams verlieren nicht nur wertvolle Zeit durch mangelndes Kontextwissen, sondern auch ihre intrinsische Motivation. Statt als kreative Problemlöser agieren sie als reine Befehlsempfänger, was besonders bei hochqualifizierten Fachkräften zu Frustration und sinkendem Engagement führt.
2.2 Das Autonomie-Paradoxon
Ein weiteres fundamentales Problem liegt in der widersprüchlichen Erwartungshaltung vieler Organisationen. Daniel Pink betont in Drive die zentrale Bedeutung von Autonomie für die Motivation und Leistungsfähigkeit von Wissensarbeitern. Doch die Realität in vielen Unternehmen sieht anders aus: Teams sollen zwar schnell liefern, werden aber durch enge Vorgaben und übermäßige Kontrolle in ihrer Handlungsfähigkeit eingeschränkt.
Dieses Paradoxon manifestiert sich in endlosen Abstimmungsschleifen, überbordender Dokumentation und einer Kultur der Absicherung. Selbst kleine Entscheidungen müssen oft durch mehrere Hierarchieebenen abgesegnet werden, was nicht nur Zeit kostet, sondern auch die Eigeninitiative und Kreativität der Teams erstickt. Die Angst vor Fehlern führt zu einer defensiven Haltung, bei der Teams lieber auf Nummer sicher gehen und zusätzliche Abstimmungen einholen, als eigenständig Entscheidungen zu treffen.
2.3 Die technische Schulden-Spirale
Ein besonders tĂĽckisches Problem in der Produktentwicklung ist die schleichende Akkumulation technischer Schulden.
Technical debt is like a mortgage — but one where you don’t know the interest rate, and it can change at any time.
Der konstante Druck zur schnellen Lieferung verfĂĽhrt Teams dazu, technische Kompromisse einzugehen, die sich langfristig als kostspielige Fallen erweisen.
Die Dynamik ist dabei fast immer dieselbe: Unter dem Vorwand der Geschwindigkeit werden zunächst kleine Abkürzungen genommen. Ein schneller Fix hier, eine provisorische Lösung dort — jede einzelne Entscheidung erscheint im Moment vertretbar. Doch diese kleinen Kompromisse summieren sich nicht linear, sondern exponentiell. Was anfangs noch als cleverer Weg erschien, Zeit zu sparen, entwickelt sich zu einem massiven Hindernis für die zukünftige Entwicklung.
Die Auswirkungen dieser technischen Schulden zeigen sich oft erst mit Verzögerung, sind dann aber umso gravierender. Die Codebasis wird zunehmend komplexer und schwerer wartbar. Selbst kleine Änderungen erfordern immer größeren Aufwand, da Entwickler durch ein Labyrinth von Abhängigkeiten und historisch gewachsenen Strukturen navigieren müssen. Die ursprüngliche Architektur, die vielleicht für einen bestimmten Funktionsumfang gedacht war, ächzt unter der Last neuer Anforderungen.
3. Der Weg zur echten Geschwindigkeit
Die Lösung dieser vielschichtigen Probleme liegt nicht in oberflächlichen Maßnahmen wie mehr Überstunden oder zusätzlichem Personal. Stattdessen braucht es einen fundamentalen Wandel in der Art, wie wir über Produktentwicklung denken und diese organisieren. Dieser Wandel muss auf mehreren Ebenen gleichzeitig stattfinden und erfordert ein tiefes Verständnis für die Mechanismen erfolgreicher Produktentwicklung.
Zunächst muss das Verständnis von Führung grundlegend überdacht werden.
The job of management is not to control the team, but to enable the team.
Dies bedeutet einen radikalen Bruch mit traditionellen Managementansätzen, die auf Kontrolle und Mikromanagement setzen. Stattdessen muss Führung als enabler verstanden werden, der Teams die Rahmenbedingungen für Höchstleistungen schafft.
Diese Neuausrichtung bedeutet auch, dass Teams echte Entscheidungskompetenzen erhalten müssen. Nicht nur in der technischen Umsetzung, sondern auch in der Frage, welche Probleme sie wie lösen. Der Fokus verschiebt sich dabei von reinem Output — der Anzahl der Features — hin zu Outcomes, also der tatsächlichen Wertschöpfung für Kunden und Unternehmen. Diese Verschiebung erfordert Mut von beiden Seiten: Von der Führung, loszulassen und Kontrolle abzugeben, und von den Teams, diese Verantwortung auch wirklich anzunehmen.
3.1 Die Vereinigung von Discovery und Delivery
Eine der wichtigsten Transformationen auf dem Weg zu echter Geschwindigkeit ist die Überwindung der künstlichen Trennung zwischen Produktentdeckung und -entwicklung. In vielen Organisationen existiert noch immer ein sequentieller Prozess, bei dem erst gedacht, dann geplant und schließlich entwickelt wird. Diese Wasserfallmentalität, die sich trotz aller agilen Transformationsbemühungen hartnäckig hält, ist einer der Hauptgründe für die gefühlte Langsamkeit vieler Teams.
Die Integration von Discovery und Delivery bedeutet weit mehr als nur die frühe Einbindung von Entwicklern in Produktentscheidungen. Es geht um eine fundamentale Neugestaltung des Produktentwicklungsprozesses, bei der Denken und Handeln parallel stattfinden. Teams müssen die Möglichkeit haben, Annahmen kontinuierlich zu validieren und ihre Erkenntnisse direkt in die Entwicklung einfließen zu lassen. Diese enge Verzahnung von Hypothesenbildung, Validierung und Umsetzung ermöglicht es, schnell auf neue Erkenntnisse zu reagieren und Fehlentwicklungen frühzeitig zu korrigieren.
Besonders in der deutschen Unternehmenslandschaft, die traditionell stark von Planungsdenken geprägt ist, stößt dieser iterative Ansatz oft auf Widerstand. Die Vorstellung, dass man etwas entwickeln könnte, ohne vorher alle Details festzulegen, erscheint vielen Führungskräften befremdlich. Doch gerade in der Produktentwicklung, wo Unsicherheit und Komplexität an der Tagesordnung sind, ist diese Flexibilität entscheidend für den Erfolg.
3.2 Die Bedeutung technischer Exzellenz
Moving fast doesn’t mean being reckless
betont Cagan immer wieder, und dieser Grundsatz ist besonders im Kontext technischer Entwicklung von zentraler Bedeutung. Echte Geschwindigkeit in der Produktentwicklung basiert auf einem soliden technischen Fundament. Dies bedeutet nicht nur sauberen Code und moderne Architekturen, sondern vor allem die Fähigkeit, nachhaltig und mit konstanter Geschwindigkeit Wert zu liefern.
Die Investition in technische Exzellenz mag zunächst wie eine Verlangsamung erscheinen. Wenn Teams Zeit in Automatisierung, Refactoring oder die Verbesserung ihrer Entwicklungsinfrastruktur investieren, entstehen in diesem Moment keine neuen Features. Doch diese vermeintliche Verlangsamung ist eine Investition in zukünftige Geschwindigkeit. Automatisierte Tests, gut strukturierter Code und effiziente Deployment-Prozesse sind die Grundlage für schnelle und sichere Produktiteraktionen.
Besonders wichtig ist dabei das Verständnis, dass technische Exzellenz kein einmaliges Projekt, sondern eine kontinuierliche Aufgabe ist. Teams müssen die Zeit und den Raum haben, ihre technische Infrastruktur ständig zu verbessern und an neue Anforderungen anzupassen. Dies erfordert ein Management, das den Wert dieser unsichtbaren Arbeit versteht und aktiv unterstützt.
3.3 Die transformative Rolle der FĂĽhrung
Die Transformation hin zu echter Geschwindigkeit kann nur gelingen, wenn die FĂĽhrungsebene ihre Rolle fundamental neu definiert. Wie Pink in Drive eindringlich beschreibt:
The best leaders don’t create followers, they create more leaders.
Diese Erkenntnis hat weitreichende Implikationen für die Art und Weise, wie Führungskräfte ihre Teams unterstützen und entwickeln sollten.
In der Praxis bedeutet dies zunächst die Schaffung eines sicheren Umfelds, in dem Teams experimentieren und aus Fehlern lernen können. Die Angst vor Fehlschlägen ist einer der größten Geschwindigkeitskiller in der Produktentwicklung. Wenn Teams ständig befürchten müssen, für Misserfolge bestraft zu werden, werden sie zwangsläufig den sichersten — und damit oft langsamsten — Weg wählen. Führungskräfte müssen daher aktiv eine Kultur etablieren, in der Fehler als wertvolle Lernchancen verstanden werden.
Diese Kulturveränderung beginnt bei der Führungskraft selbst. Manager müssen lernen, ihre eigene Rolle weniger als Kontrollinstanz und mehr als Enabler zu verstehen. Dies bedeutet, den Teams den Kontext und die Ressourcen zur Verfügung zu stellen, die sie für autonome Entscheidungen benötigen. Es bedeutet auch, unbequeme Fragen zuzulassen und aktiv nach kritischem Feedback zu suchen, statt eine Kultur der vorauseilenden Zustimmung zu fördern.
4. Der nachhaltige Weg nach vorne
Die Transformation von einem als langsam wahrgenommenen zu einem wirklich effektiven Team ist kein Sprint, sondern ein Marathon. Es erfordert Geduld, Ausdauer und vor allem ein tiefes Verständnis dafür, dass echte Geschwindigkeit nicht durch oberflächliche Maßnahmen erreicht werden kann. Wie Cagan treffend bemerkt:
The irony is that by slowing down just enough to do things right, teams actually move much faster.
Diese scheinbar paradoxe Erkenntnis zeigt sich besonders deutlich in der Praxis der erfolgreichsten Produktorganisationen. Teams, die sich die Zeit nehmen, Probleme wirklich zu verstehen, die in ihre technische Infrastruktur investieren und die ihre Annahmen sorgfältig validieren, liefern langfristig mehr Wert als solche, die unter konstantem Zeitdruck von Feature zu Feature hetzen.
Der Schlüssel liegt in der Etablierung nachhaltiger Praktiken, die es Teams ermöglichen, ihr Tempo über lange Zeit aufrechtzuerhalten. Dies bedeutet eine ausgewogene Balance zwischen kurzfristigen Lieferanforderungen und langfristiger Entwicklung, zwischen Feature-Entwicklung und technischer Verbesserung, zwischen schnellen Experimenten und gründlicher Validierung.
Besonders in der deutschen Unternehmenslandschaft, die oft noch von kurzfristigem Quartalsdenken geprägt ist, erfordert dieser Ansatz ein grundlegendes Umdenken. Es geht nicht darum, möglichst viele Features in möglichst kurzer Zeit zu entwickeln, sondern darum, nachhaltig Wert für Kunden und Unternehmen zu schaffen. Dies erfordert Mut von allen Beteiligten — Mut, etablierte Praktiken zu hinterfragen, Mut, neue Wege zu gehen, und vor allem Mut, für langfristige Qualität einzustehen, auch wenn der kurzfristige Druck in eine andere Richtung weist.
4.1 Die praktische Umsetzung: Von der Theorie zur gelebten Realität
Die Transformation hin zu echter Geschwindigkeit erfordert mehr als nur strukturelle Änderungen. Sie verlangt eine fundamentale Neuausrichtung der täglichen Zusammenarbeit und der Art und Weise, wie Teams ihre Arbeit organisieren. Ein besonders kritischer Aspekt, der in vielen Organisationen noch zu wenig Beachtung findet, ist die frühe und kontinuierliche Integration aller relevanten Disziplinen in den Entwicklungsprozess.
Die traditionelle Trennung zwischen UX-Design, technischer Entwicklung und Business-Perspektive ist in vielen Unternehmen noch tief verwurzelt. Designer erstellen Mockups, die dann an Entwickler weitergereicht werden, während Business-Anforderungen oft als unveränderliche Vorgaben von oben kommen. Diese sequenzielle Arbeitsweise mag auf den ersten Blick geordnet und effizient erscheinen, erweist sich in der Praxis jedoch als großes Hindernis für echte Innovation und Geschwindigkeit. Wenn UX, Tech und Business von Anfang an zusammenarbeiten, entstehen nicht nur bessere Lösungen, sondern diese werden auch schneller entwickelt, da Missverständnisse und späte Korrekturen vermieden werden.
Die Automatisierung repetitiver Aufgaben ist ein weiterer Schlüssel zur nachhaltigen Geschwindigkeit, der oft unterschätzt wird. Viele Teams verbringen einen erheblichen Teil ihrer Zeit mit manuellen, sich wiederholenden Tätigkeiten — vom Code-Deployment über das Testen bis hin zur Dokumentation. Diese versteckte Zeitverschwendung summiert sich über Wochen und Monate zu einem erheblichen Produktivitätsverlust. Die Investition in Automatisierung mag zunächst wie ein Zeitaufwand erscheinen, zahlt sich aber schnell durch erhöhte Effizienz und reduzierte Fehlerquoten aus. Moderne CI/CD-Pipelines, automatisierte Testsuiten und selbstdokumentierende Systeme sind keine optionalen Extras, sondern fundamentale Voraussetzungen für hochperformante Teams.
Besonders wichtig ist dabei die Rolle der Führungskräfte als aktive Vorbilder der gewünschten Kultur. Es reicht nicht, von Vertrauen und Empowerment zu sprechen — diese Werte müssen täglich gelebt werden. Führungskräfte müssen den Mut haben, selbst Unsicherheit zuzugeben, aus Fehlern zu lernen und transparent über Herausforderungen zu kommunizieren. Wenn ein Manager in einem Review-Meeting zugibt, dass eine seiner Annahmen falsch war, oder aktiv nach kritischem Feedback fragt, setzt dies ein powerful Signal für das gesamte Team.
Die praktische Umsetzung dieser Prinzipien erfordert auch ein neues Verständnis von Meetings und Zusammenarbeit. Statt endloser Status-Updates und PowerPoint-Präsentationen braucht es intensive Arbeits-Sessions, in denen UX-Designer, Entwickler und Product Owner gemeinsam Probleme lösen. Diese kollaborativen Formate, oft als Design Studios oder Tech Spikes bezeichnet, ermöglichen es Teams, schnell verschiedene Lösungsansätze zu explorieren und dabei alle relevanten Perspektiven zu berücksichtigen.
Die kontinuierliche Weiterentwicklung der technischen Infrastruktur muss dabei als strategische Priorität verstanden werden. Teams brauchen dedicated Zeit für Refactoring, Architektur-Verbesserungen und die Einführung neuer Tools und Technologien. Diese Investitionen in die technische Exzellenz sind keine Nice-to-haves, sondern essenzielle Voraussetzungen für langfristige Geschwindigkeit. Führungskräfte müssen verstehen, dass die Vernachlässigung dieser Aspekte zu einer schleichenden Verlangsamung führt, die sich oft erst zeigt, wenn es schon zu spät ist.
5. Fazit: Reorganisation als Scheinlösung
Die kürzlich angekündigte Reorganisation unserer Teams in meinem jetzigen Unternehmen folgt einem bekannten, aber problematischen Muster: Wenn Teams als zu langsam wahrgenommen werden, erscheint eine Umstrukturierung oft als naheliegende Lösung. Doch die geplante Durchmischung der Teams und Neuverteilung der Aufgaben ignoriert fundamentale Erkenntnisse über erfolgreiche Produktentwicklung.
Die Auswirkungen dieser Reorganisation werden voraussichtlich gravierend sein. Bestehende Teams, die über Monate hinweg effektive Arbeitsweisen entwickelt haben, werden auseinandergerissen. Die gewachsenen Beziehungen und das aufgebaute Vertrauen, die für schnelle und effektive Zusammenarbeit essentiell sind, gehen verloren. Wie die Erfahrung zeigt, benötigen neue Teams erhebliche Zeit für die Forming- und Norming-Phase, was zunächst zu einer deutlichen Verlangsamung führt.
Besonders kritisch ist der Zeitpunkt: Die Reorganisation erfolgt, ohne dass die eigentlichen Ursachen für die wahrgenommene Langsamkeit analysiert wurden. Technische Schulden, unklare Produktvisionen und ineffiziente Entscheidungsprozesse — die wahren Bremsen unserer Entwicklung — werden durch eine Umstrukturierung nicht adressiert. Im Gegenteil: Die zusätzliche Komplexität und der Verlust von Kontextwissen in den neu gemischten Teams werden diese Probleme wahrscheinlich noch verschärfen.
Die fehlende Einbindung der Teams in den Entscheidungsprozess ist ein weiteres Warnsignal. Statt die Erfahrung und das Wissen der Mitarbeiter über tatsächliche Hindernisse und mögliche Lösungen zu nutzen, wird die Reorganisation von oben verordnet. Dies untergräbt nicht nur die Motivation, sondern ignoriert auch wertvolle Einblicke in die wirklichen Probleme unserer Entwicklungsprozesse.
Ein konstruktiverer Ansatz wäre es, zunächst eine gründliche Analyse der aktuellen Situation durchzuführen:
- Welche konkreten Dependencies zwischen Teams bremsen uns?
- Wo entstehen die größten Zeitverluste in unseren Prozessen?
- Welche technischen Schulden müssen prioritär adressiert werden?
- Wie können wir Entscheidungsprozesse beschleunigen?
Statt einer pauschalen Neuordnung bräuchte es gezielte Maßnahmen:
- Stärkung der Team-Autonomie durch klare Verantwortungsbereiche
- Investition in technische Exzellenz und Abbau technischer Schulden
- Verbesserung der Produkt-Discovery-Prozesse
- Aufbau einer Kultur des Vertrauens und der kontinuierlichen Verbesserung
Die geplante Reorganisation mag gut gemeint sein, wird aber mit hoher Wahrscheinlichkeit das Gegenteil des Beabsichtigten bewirken: Eine weitere Verlangsamung statt der erhofften Beschleunigung. In einer Zeit, in der wir eigentlich Stabilität und Fokus bräuchten, um unsere grundlegenden Herausforderungen anzugehen, riskieren wir durch diese Umstrukturierung nicht nur kurzfristige Produktivitätseinbußen, sondern auch langfristige Motivationsverluste.