Shiny-Object-Syndrom verschwendet die Zeit und Energie Ihres Teams. So gehen Sie damit um.

Alles begann mit einem glänzenden neuen Launch. Google hatte gerade die multimodalen Funktionen von Gemini vorgestellt – eine Technologie, die vielversprechend genug schien, um Probleme in der Interaktion zwischen Mensch und Browser zu lösen. Das Engineering-Team dachte, es wäre ein schnelles, risikoarmes Experiment.

Ein Team probierte es aus. Dann ein weiteres. Dann ein drittes.

Aber so spannend das Konzept auch war, das eigentliche Tool war noch nicht ausgereift. Es befand sich noch im Anfangsstadium, war nicht reif für die Produktion und definitiv nicht auf den Anwendungsfall des Teams zugeschnitten.

„Es war eine Ablenkung, die den Fortschritt bei unseren bestehenden Prioritäten leicht hätte entgleisen lassen können, wenn wir nicht gebremst hätten,“ erinnert sich Anand Sainath, Leiter Engineering und Mitbegründer von 100x, der die Entscheidung traf, die Integration zu stoppen.

Andere hatten allerdings weniger Glück. Für viele Teams hat die Jagd nach dem „nächsten großen Ding“ nach und nach die Produkt-Roadmap gekapert. Zurück blieb ein Flickenteppich aus halbfertigen Tools und verpassten Prioritäten – etwas, das Sainath als die „leisen Kosten des Shiny Object Syndrome“ bezeichnet.

Was ist eigentlich das Shiny Object Syndrome?

Das Shiny Object Syndrome (SOS) tritt auf, wenn Teams sich von neuen Tools, Frameworks oder Technologien ablenken lassen – oft auf Kosten bestehender Prioritäten. 

„Wenn eine neue Technologie auftaucht, wie es heute bei KI der Fall ist, begeistert sich der Markt für ihre Anwendungen. Es kann Druck entstehen, sich dem Trend anzupassen, um der Konkurrenz voraus zu bleiben,“ sagt Raju Malhotra, CPTO bei Certinia.

Genau dann schleicht sich das „glänzende“ Tool oder Framework in deine Pläne ein und „zieht die Entwicklung weg von der Arbeit, die für die Kund:innen heute wirklich wichtig ist.“

Evernotes Geschichte ist ein Musterbeispiel für das Shiny Object Syndrome. Alle Zutaten waren vorhanden: treue Nutzer:innen, ein solides Produkt und eine klare Nische. Doch anstatt die Kernfunktionen auszubauen, wagte sich das Unternehmen an physische Produkte und veröffentlichte unfertige Features wie Work Chat.

Das Produkt wurde aufgebläht, die Performance ließ nach und die Nutzer:innen wanderten zu einfacheren Tools wie Notion und Google Keep ab. 2022 wurde Evernote übernommen, und Anfang 2023 wurden die meisten Mitarbeitenden entlassen.

SOS endet nicht immer in einer Pleite oder Kündigungswelle, aber fast immer entgleist dadurch das Momentum, etwa indem:

• Projekte sich verzögern: Häufige Wechsel zu neuen Technologien mitten im Projektablauf stören die Planung, unterbrechen Entwicklungszyklen und sorgen für einen aufgeblähten, nicht eingeplanten Scope. Genau das geschah beim Virtual Case File Projekt des FBI. Nach fünf Jahren und 170 Millionen Dollar wurde das Projekt eingestellt – mitverursacht durch ständige Richtungswechsel zwischen Behörden und Wirtschaft, wodurch der Liefer-Rhythmus immer wieder unterbrochen wurde.
• Höhere Entwicklungskosten: Ohne ein Framework zur Technologie-Bewertung führen Entscheidungen getrieben vom neuesten Trend häufig zu Tool-Chaos, technischer Schulden und steigenden Software-Entwicklungskosten. Teams investieren sogar Zeit in Prototypen, die nie veröffentlicht werden oder – noch schlimmer – eingesetzt und dann neu geschrieben werden.
• Produktivität der Entwickler:innen leidet: Jedes neue Tool bedeutet eine weitere Lernkurve, mehr Bugs und immer mehr „Quick Tests“, die selten wirklich schnell bleiben. Entwickler:innen werden so dünn verteilt, die Produktivität sinkt um bis zu 40%, was zu Ermüdung und ständigem Troubleshooting führt – Energie, die ins Kerngeschäft hätte fließen sollen.
• Vertrauen der Stakeholder schwindet: SOS sendet auch das falsche Signal an die Geschäftsleitung. Wenn Prioritäten allzu oft wechseln und Zeitpläne rutschen, beginnt das C-Level, an der Lieferfähigkeit des Engineerings zu zweifeln. Ist das Vertrauen einmal weg, lässt es sich nur schwer zurückgewinnen.

So stoppen Sie Shiny Object Reue: 3 Kontrollfragen für Ihr Team

Sie wissen, wie stark das Shiny Object Syndrome Ihr Team beeinträchtigen kann. Wie finden Sie also heraus, ob die neue Library, das SDK oder der Service es wert ist – bevor Zeit und Fokus flöten gehen? Unsere Expert:innen haben bewährte Kontrollmechanismen:

1. Ist es ein „Wrapper“ oder nur ein „Pflaster“?

Sainaths Kriterium im Umgang mit neuen Tools oder Technologien ist simpel: Löst es langfristig wichtige Probleme – oder ist es nur ein Pflaster?

„Ein Pflaster kaschiert nur kleine Spezialfälle oder kurzfristige Einschränkungen. Aber die Chancen stehen gut, dass ohnehin die nächste Modellversion das Problem löst. Dann ist das, was Sie gebaut haben, sofort veraltet.“

Er interessiert sich vielmehr für Wrapper – also saubere Schichten auf Basis-Modellen, die durch Design, Workflows oder Kontext echte Nutzbarkeit hinzufügen.

„Der Begriff LLM-Wrapper wurde anfangs fast schon abfällig verwendet, aber im Grunde genommen werden viele wertvolle Produkte auf zugrunde liegender Technologie aufgebaut.“ kommentiert Sainath. „Schauen Sie sich Cursor an. Man könnte argumentieren, dass es nur ein Wrapper ist, aber es bietet erheblichen, gezielten Mehrwert.“

Seiner Ansicht nach sind Pflasterlösungen nur Ablenkungen, die sich leicht zu glänzenden Objekten entwickeln können. Gut durchdachte Wrapper hingegen können zu Kernprodukten werden.

2. Was entscheiden wir nicht zu bauen?

Laut Malhotra ist es genauso wichtig, nachzuverfolgen, was das Team entscheidet, nicht zu bauen, wie das, was tatsächlich auf der Roadmap landet. „Es hält uns davon ab, Features hinterherzujagen, die in einer Demo gut aussehen, aber den Arbeitsalltag nicht wirklich verbessern,“ sagt er.

Auch wenn das Team nicht davon überzeugt ist, dass etwas für den breiteren Rollout bereit ist, wird es trotzdem mit Early Adopters getestet. „So bekommen wir Feedback, ohne die Roadmap zu gefährden.“

3. Welchen geschäftlichen Mehrwert schaffen wir? 

Für den VP of Engineering von Customer.io, Paul Senechko, ist das Verständnis des geschäftlichen Mehrwerts hinter Ingenieurleistungen der erste und wichtigste Filter. Wenn ein neues Tool oder System diesem Ziel nicht dient, sagt er, ist wahrscheinlich nicht der richtige Zeitpunkt dafür.

„Unser Leitprinzip im Unternehmen ist, dass wir die Kundenexperten sind,“ erklärt Senechko. „Dieses Prinzip nutzen wir, um unsere Investitionen in Technologie zu steuern und sicherzustellen, dass wir immer mit Blick auf Kunden und Unternehmen entwickeln.“

Um sein Team auf dem Boden zu halten, verlässt sich Senechko auf einige einfache, aber wirkungsvolle Fragen: Was kostet uns das an Zeit und Ressourcen? Verbessert es unser Produkt? Wird es unseren Kunden helfen, erfolgreicher zu sein?

Sainath bringt seine eigene Perspektive ein mit den sogenannten „Was wäre wenn“-Fragen: „Was passiert, wenn die zugrunde liegende Technologie sich um den Faktor 10 verbessert? Wird unser Produkt damit automatisch besser oder verliert es plötzlich seine Relevanz?“

Er prüft zudem den Aufwand, der für diese Verbesserungen nötig wäre: „Profitieren wir automatisch von diesen Fortschritten, oder wäre eine umfassende Umstrukturierung nötig, um Schritt zu halten?“

Das Durchspielen solcher Szenarien mit dem Team kann dabei helfen, die richtige Entscheidung zu treffen – ob man den glänzenden neuen Technologie-Stack priorisieren oder bei Altbewährtem bleiben sollte.

SOS-Absicherung Ihrer Roadmap (ohne Innovation zu ersticken) 

Wenn begeisternde neue Technologien aufkommen, sollte man sie mit einer Prise Skepsis betrachten und Innovation mit echtem Fortschritt abwägen.

So halten CTOs das FOMO in Schach und sorgen dafür, dass ihre Teams fokussiert und geerdet bleiben:

1. Definieren Sie Exit-Kriterien für Projekte von Anfang an

Viele „explorative“ Technologie-Experimente entwickeln sich zu langwierigen Nebenprojekten mit schleichender Ausweitung und wachsender technischer Schuld, vor allem weil niemand festlegt, wie oder wann sie enden. Gibt es keine klare Verantwortung, keinen Zeitplan oder keine Erfolgskriterien, ist es nur eine Frage der Zeit, bis das Shiny Object Syndrome das Ganze in den Sand setzt. Deshalb sollte jeder Technologietest wie ein Produktfeature behandelt werden: mit festem Umfang, zeitlichem Rahmen, eindeutigen Verantwortlichkeiten und einem echten Anwendungsfall. 

Wie Senechko es ausdrückt: „Erproben Sie an kleinen, aber realen Anwendungsfällen und erweitern Sie dann. Sobald wir uns entschließen, neue Trends auszuprobieren, achten wir darauf, einen kleinen oder gut abgegrenzten Bereich zu identifizieren, in dem wir testen und überprüfen können, ob es funktioniert. So können wir experimentieren und echte Erfahrung mit der Technologie sammeln, bevor wir große Wetten eingehen.“

Beziehen Sie für eine objektive Bewertung einen funktionsübergreifenden Prüfer (EM + PM + Staff Engineer) ein und erstellen Sie einen strukturierten Zeitplan, der Folgendes umfasst:

• Maximale Dauer: Auf 2 Sprints (+1 Puffer) begrenzen, um es schlank und testbar zu halten
• Go/No-Go-Meilensteine mit Exit-Bedingungen: Definieren Sie einen expliziten Prüfzeitpunkt, an dem das Team entscheidet, ob es weitermacht, iteriert oder aufhört (z. B. über 10 % Build-Fehlschläge oder fehlende Integration mit dem CI/CD-Tool). 

Senechko empfiehlt sogar, mit festen Zeitvorgaben und variablem Umfang zu experimentieren, wobei sein Team zunächst festlegt, wie viel Zeit sie aufwenden möchte, um dann innerhalb dieses Rahmens das wertvollste Ergebnis zu liefern. „Das hat uns ermöglicht, schnell zu innovieren – und schnell festzustellen, wenn neue Richtungen doch nicht sinnvoll erscheinen.“

2. Nutzen Sie Kennzahlen, um Erfolg zu messen

Sobald die technische Machbarkeit und der Engineering-Aufwand verstanden sind, definieren Sie, wie Erfolg aussieht. Das trennt einen disziplinierten Rollout von einem chaotischen Projekt mit ständig wachsendem Umfang. Entwickeln Sie ein Rahmenwerk, das Erfolg misst – und zwar über mehrere Dimensionen:

• Menschen: Produktivitätssteigerung der Entwickler, Zunahme von Deep-Work-Stunden
• Prozesse und Workflows: Geringere Laufzeit von Test-Suites, verminderte Rückfallraten (Regressionen), schlankere Deployment-Workflows, verkürzte Markteinführungszeit
• Kundenerfahrung: Bessere Seitenperformance, weniger UX-Beschwerden, verbesserte Reaktionszeiten
• Systemleistung: Schnellere Berechnungen, geringere Infrastrukturkosten, weniger Vorfälle oder Rollbacks

3. Kennen Sie Ihre Kunden

„Den Kurs zu halten, bedeutet, ehrlich darüber zu sein, wo der Kundennutzen wirklich entsteht“, behauptet Malhotra. „Trends mögen spannend klingen, aber sie werden schnell zu Ablenkungen, wenn sie Kunden nicht direkt helfen, besser oder schneller zu arbeiten.“

Dieses Prinzip sieht man daran, dass viele Teams heute Product und Engineering aktiv mit Customer Success für Live-Shadows kombinieren. Einige Entwickler nehmen an Support-Anrufen, Onboarding-Sessions oder Kunden-Check-ins teil, um reale, ungefilterte Rückmeldungen zu erhalten. Direkt zu hören, was Nutzer verwirrt, wo Fehler auftreten und was gelobt wird, fördert die Empathie und kann sogar die Priorisierung in Engineering-Teams schärfen. 

Doch Zuhören allein genügt nicht. Um herauszufinden, wo Kunden tatsächlich Probleme haben, ergänzen Sie qualitative Rückmeldungen durch Produkt-Telemetrie. Wahrscheinlich wird Ihr Analytics-Tool (PostHog, Amplitude, Heap) für diesen Zweck bisher zu wenig genutzt. Beginnen Sie zu verfolgen, wie Nutzer wirklich mit dem Produkt interagieren: durch Klicks, Umschalten, Navigationsschleifen und Fehlerrouten. 

Kombinieren Sie diese Verhaltensdaten mit Support-Tickets, um Muster zu erkennen. Wird eine Funktion ignoriert, weil sie schwer zu finden ist? Scheitern Nutzer daran, wichtige Workflows abzuschließen? Nutzen Sie diese Erkenntnisse als klare Auslöser für kundenzentrierte Pilotprojekte.

Mit der Zeit entsteht so organisch ein "Voice of the Customer"-Formular, in dem Kundenprobleme, Feedback, Freude und immer wiederkehrende Hürden direkt aus den Success-Teams in den Produkt- und Engineering-Entscheidungsprozess fließen. 

Das ist das gleiche System, das das Team von Senechko genutzt hat, um Aufgaben nach messbarem Kundennutzen zu priorisieren: „Ein großes Kundenvolumen und niedrige Latenzanforderungen haben unser Team dazu gebracht, Lösungen zu entwickeln, die Standardmethoden nicht leisten konnten. In unsere technische Plattform zu investieren ist Teil der DNA unseres Unternehmens, denn wir haben den Mehrwert für Kunden und das Business beim Umsetzen gesehen.“

Am Ende erzielt das Engineering echten Fortschritt, indem neue Fähigkeiten entwickelt werden, die bereits Funktionierendes erweitern – nicht, indem darum herum gebaut oder etwas völlig Neues angeflanscht wird. So entwickeln sich Teams weiter, ohne bewährte Systeme zu gefährden.

„Innovation muss nicht immer Disruption bedeuten. Sie sollte das stärken, was bereits funktioniert, und Kunden helfen, schneller und mit weniger Aufwand voranzukommen“, bringt Malhotra es auf den Punkt.

Mehr Einblicke wie diese? Abonnieren Sie den The CTO Club-Newsletter.