Het syndroom van steeds nieuwe dingen verspilt de tijd en energie van je team. Dit kun je eraan doen.

“Het was een afleiding die de voortgang op bestaande prioriteiten gemakkelijk had kunnen ontsporen als we niet op de rem hadden getrapt,” herinnert Anand Sainath, hoofd engineering en medeoprichter van 100x, zich. Hij nam het besluit om de integratie stop te zetten.

Anderen hadden echter minder geluk. Voor veel teams kaapte de jacht op “het volgende grote ding” langzaam de productroadmap. Wat overbleef, was een lappendeken van halfafgemaakte tools en gemiste prioriteiten – iets wat Sainath de stille kosten van het-syndroom-van-het-glimmende-object noemt.

Wat is het syndroom van het glimmende object eigenlijk?

Het syndroom van het glimmende object (SOS) ontstaat wanneer teams worden afgeleid door nieuwe tools, frameworks of technologieën, vaak ten koste van bestaande prioriteiten. 

“Wanneer er een nieuwe technologie opduikt, zoals vandaag het geval is met AI, raakt de markt enthousiast over de toepassingen ervan. Er kan druk ontstaan om richting de trend te bewegen en de concurrentie voor te blijven,” zegt Raju Malhotra, CPTO bij Certinia.

Dat is het moment waarop de “glimmende” tool of het framework zich in je plannen begint te nestelen en “engineering weghaalt bij het werk dat vandaag daadwerkelijk belangrijk is voor klanten.”

Het verhaal van Evernote voldoet aan elk vakje op de bingokaart van het syndroom van het glimmende object. Het had alle juiste ingrediënten: loyale gebruikers, een solide product en een duidelijke niche. In plaats van verder te bouwen op de kernfuncties, breidde het bedrijf uit naar fysieke producten en lanceerde het onvoldragen productfuncties zoals Work Chat. 

Het product werd log en opgeblazen, de prestaties gingen achteruit en gebruikers stapten over naar eenvoudigere tools zoals Notion en Google Keep. In 2022 werd Evernote overgenomen en begin 2023 was het merendeel van het personeel ontslagen. 

SOS eindigt niet altijd in een faillissement of ontslagen, maar het ontspoort bijna altijd het momentum door: 

• Het uitstellen van projectopleveringen: Regelmatige overstappen naar nieuwe technologieën halverwege een project kunnen de planning verstoren, uitvoeringscycli onderbreken en leiden tot een opgeblazen, ongeplande scope. Dat is precies wat er gebeurde met het Virtual Case File-project van de FBI. Na vijf jaar en een investering van $170 miljoen werd het project stopgezet, deels omdat de veranderende bureaucratisch-zakelijke afstemming het opleveringsritme steeds opnieuw verstoorde.
• Het verhogen van engineeringkosten: Zonder een raamwerk om nieuwe technologieën te evalueren, leiden beslissingen die door glimmende objecten worden gedreven vaak tot een overdaad aan tools, technische schuld en hoge kosten voor softwareontwikkeling. Teams steken zelfs tijd in prototypes die nooit worden uitgebracht of, erger nog, worden uitgerold en daarna opnieuw worden geschreven.
• Het verminderen van de productiviteit van ontwikkelaars: Elke nieuwe tool betekent weer een leercurve, meer bugs en meer “snelle tests” die zelden snel blijven. Het spreidt engineers te dun uit, verlaagt de productiviteit met wel 40% en leidt tot vermoeidheid en voortdurend brandjes blussen – energie die had kunnen worden ingezet voor het bouwen van belangrijke productfuncties.
• Het ondermijnen van het vertrouwen van belanghebbenden: SOS geeft bedrijfsleiders ook het verkeerde signaal. Wanneer prioriteiten te vaak verschuiven en tijdlijnen uitlopen, kan de C-suite het vermogen van engineering om te leveren in twijfel gaan trekken. Zodra het vertrouwen verloren is, is het moeilijk om het terug te winnen.

Voorkom spijt van glimmende objecten: 3 controlevragen voor je team

Je weet welk soort ravage het syndroom van het glimmende object in je team kan aanrichten. Maar hoe bepaal je of die nieuwe bibliotheek, SDK of service de moeite waard is – voordat deze tijd en focus opslokt? Onze experts hebben enkele vaste controlevragen:

1. Is het een “omhulsel” of een “pleister”?

De filter van Sainath bij het omgaan met glimmende nieuwe tools/technologie is eenvoudig: lost dit iets op dat op de lange termijn belangrijk is, of is het slechts een pleister?

“Een pleister maskeert slechts kleine randgevallen of verhult beperkingen op de korte termijn. Maar de kans is groot dat de volgende versie van het model dat probleem toch oplost. En wat je hebt gebouwd, is dan onmiddellijk verouderd.”

Hij is meer geïnteresseerd in het bouwen van omhulsels – nette lagen bovenop basismodellen die daadwerkelijk bruikbaarheid toevoegen via ontwerp, workflows of context.

“De term LLM-omhulsel werd in het begin bijna denigrerend gebruikt, maar fundamenteel gezien zijn veel waardevolle producten gebouwd op onderliggende technologie,” merkt Sainath op. “Kijk naar Cursor. Je zou kunnen beweren dat het slechts een omhulsel is, maar het biedt aanzienlijke, gerichte waarde.”

Volgens hem zijn lapmiddelen afleidingen die gemakkelijk kunnen veranderen in glimmende objecten. Goed ontworpen omhulsels kunnen daarentegen uitgroeien tot kernproducten.

2. Wat kiezen we ervoor niet te bouwen?

Volgens Malhotra is het bijhouden van wat het team ervoor kiest niet te bouwen net zo belangrijk als wat op de roadmap terechtkomt. “Het voorkomt dat we achter functies aan gaan die er in een demo misschien goed uitzien, maar het dagelijkse werk niet daadwerkelijk verbeteren,” zegt hij.

Zelfs wanneer het team er niet zeker van is dat iets klaar is voor bredere uitrol, testen ze het toch met vroege gebruikers. “Dat geeft ons feedback zonder de roadmap te verstoren.”

3. Wat is de bedrijfswaarde? 

Voor de VP engineering van Customer.io, Paul Senechko, is inzicht in de bedrijfswaarde achter engineeringinspanningen het eerste en belangrijkste filter. Als een nieuwe tool of een nieuw systeem geen van beide dient, zegt hij, is het waarschijnlijk niet het juiste moment ervoor.

“Ons leiderschapsprincipe als bedrijf is dat we experts op het gebied van klanten zijn,” legt Senechko uit. “We gebruiken dit principe om onze investeringen in technologie te sturen en ervoor te zorgen dat we bouwen met de klant en het bedrijf in gedachten.”

Om zijn team met beide benen op de grond te houden, vertrouwt Senechko op een paar eenvoudige maar krachtige vragen: Wat kost dit ons in tijd en middelen? Verbetert het ons product? Zal het onze klanten helpen succesvoller te zijn?

Sainath voegt zijn eigen perspectief toe met wat hij de “wat als”-vragen noemt: “Wat gebeurt er als de onderliggende technologie 10 keer beter wordt? Wordt ons product dan inherent beter, of wordt het plotseling irrelevant?”

Hij onderzoekt ook de inspanning die nodig is om die verbeteringen te realiseren: “Profiteren we automatisch van die verbeteringen, of is een ingrijpende herarchitectuur nodig om bij te blijven?”

Door deze scenario’s met je team uit te werken, kun je bepalen of je die glimmende nieuwe technologiestack prioriteit moet geven of moet vasthouden aan wat al werkt.

Je roadmap SOS-bestendig maken (zonder innovatie om zeep te helpen) 

Wanneer opwindende nieuwe technologie faalt, moet je die met een korreltje zout nemen en innovatie in balans brengen met daadwerkelijke vooruitgang.

Zo beheren CTO’s de FOMO en houden ze hun teams gefocust en met beide benen op de grond:

1. Definieer exitcriteria voor projecten voordat je begint

Veel “verkennende” technologietests veranderen in langdurige nevenprojecten met een steeds grotere scope en terugkerende technische schuld, vooral omdat niemand bepaalt hoe of wanneer ze eindigen. Als er geen eigenaarschap, tijdlijn of succescriteria zijn, is het slechts een kwestie van tijd voordat het syndroom van het glimmende object het geheel de grond in boort. Behandel daarom elke technologietest als een productfunctie: afgebakend, beperkt in tijd, toegewezen aan een verantwoordelijke en gebaseerd op een echte gebruikssituatie. 

Zoals Senechko het verwoordt: “Pas het toe op kleine maar echte gebruikssituaties en ga van daaruit verder. Zodra we besluiten te experimenteren met nieuwe trends, zorgen we ervoor dat we een kleine of goed afgebakende plek identificeren waar we kunnen testen en verifiëren dat dit werkt. Op deze manier kunnen we experimenteren en echte ervaring opdoen met de technologie voordat we er een grote inzet op doen.”

Betrek een multidisciplinaire beoordelaar (EM + PM + stafengineer) voor een objectieve evaluatie en maak een gestructureerde tijdlijn met:

• Maximale duur: Beperk dit tot 2 sprints (+1 buffer) om het slank en testbaar te houden
• Mijlpalen voor doorgaan of stoppen met exitvoorwaarden: Definieer een expliciet beoordelingsmoment waarop het team beslist om door te gaan, te itereren of te stoppen (meer dan 10% van de builds mislukt of er is geen integratie met de CI/CD-tool). 

Senechko stelt zelfs voor dat teams experimenteren met initiatieven met een vaste tijdsduur en variabele scope, waarbij zijn team vooraf bepaalt hoeveel tijd ze eraan willen besteden en ernaar streeft om binnen dat tijdsbestek de meest waardevolle uitkomst te leveren. “Hierdoor konden we snel innoveren en falen wanneer die nieuwe richtingen niet de goede kant op leken te gaan.”

2. Gebruik statistieken om succes te meten

Zodra de technische haalbaarheid en de benodigde engineeringinspanning duidelijk zijn, definieer je hoe succes eruitziet. Dat is het verschil tussen een gedisciplineerde uitrol en een SOS-project waarvan de scope steeds verder uitdijt. Bouw een raamwerk dat succes meet op meerdere dimensies:

• Mensen: Verbeterde productiviteit van ontwikkelaars, meer uren voor diepgaand werk
• Processen en werkstromen: Kortere uitvoertijd van testsuites, minder regressies, slankere implementatiewerkstromen, kortere doorlooptijd tot marktintroductie
• Klantervaring: Betere paginaprestaties, minder UX-klachten, verbeterde responstijden
• Systeemprestaties: Snellere berekeningen, lagere infrastructuurkosten, minder incidenten of terugdraaiingen

3. Ken je klanten

“Op koers blijven draait om eerlijk zijn over waar klantwaarde wordt gecreëerd,” beweert Malhotra. “Trends kunnen spannend klinken, maar ze kunnen snel afleiden als ze klanten niet rechtstreeks helpen hun werk beter of sneller te doen.”

Dat principe komt tot uiting in de manier waarop veel teams productontwikkeling en techniek nu koppelen aan klantensucces voor live meeloopsessies. Een paar engineers nemen deel aan supportgesprekken, onboardingsessies of klantgesprekken om echte, ongefilterde feedback te ontvangen. Uit de eerste hand horen wat gebruikers in verwarring brengt, wat niet werkt en wat wordt gewaardeerd, kweekt empathie en kan zelfs de prioritering binnen engineeringteams aanscherpen. 

Maar alleen luisteren is niet genoeg. Om vast te stellen waar klanten daadwerkelijk vastlopen, combineer je kwalitatieve feedback met producttelemetrie. De kans is groot dat je analysetool (PostHog, Amplitude, Heap) hiervoor onderbenut wordt. Begin bij te houden hoe gebruikers daadwerkelijk met het product omgaan: tot op het niveau van klikken, schakelaars, navigatielussen en foutpaden. 

Combineer deze gedragsgegevens met supporttickets om patronen te ontdekken. Wordt een functie genegeerd omdat deze moeilijk te vinden is? Slagen gebruikers er niet in kritieke werkstromen te voltooien? Gebruik deze signalen met een hoge informatiewaarde als aanleiding voor klantgerichte pilotprojecten.

Na verloop van tijd bouw je organisch een overzicht van de “stem van de klant” op, met pijnpunten, feedback, positieve ervaringen en terugkerende blokkades van klanten die vanuit klantensuccesteams doorstromen naar product- en engineeringbeslissingen. 

Het is hetzelfde systeem dat het team van Senechko gebruikte om werk te prioriteren op basis van meetbare klantwaarde: “Een groot aantal klanten en strenge eisen op het gebied van latentie hebben ons team ertoe aangezet oplossingen te bedenken die kant-en-klare technieken niet konden realiseren. Investeren in ons technische platform maakt deel uit van het DNA van ons bedrijf, omdat we hebben gezien welke voordelen dit oplevert voor klanten en het bedrijf.”

Uiteindelijk zal echte vooruitgang voor engineering voortkomen uit het ontwerpen van nieuwe mogelijkheden die uitbreiden wat al werkt, niet uit het eromheen bouwen of het volledig nieuw toevoegen van iets. Zo ontwikkelen teams zich zonder bewezen systemen te breken.

“Innovatie hoeft geen ontwrichting te betekenen. Het moet versterken wat al werkt en klanten helpen sneller te werken met minder inspanning,” vat Malhotra het eenvoudig samen.

Wil je meer inzichten zoals deze? Abonneer je op de nieuwsbrief van The CTO Club.