Glänsande föremål-syndromet slösar bort teamets tid och energi. Så här gör du.

”Det var en distraktion som lätt kunde ha spårat ur och bromsat framstegen inom våra befintliga prioriteringar om vi inte hade tryckt på bromsen”, minns Anand Sainath, teknikchef och medgrundare på 100x, som fattade beslutet att stoppa integrationen.

Andra har dock inte haft samma tur. För många team kapade jakten på ”nästa stora grej” gradvis produktfärdplanen. Kvar blev ett lapptäcke av halvfärdiga verktyg och missade prioriteringar– något som Sainath kallar den dolda kostnaden för syndromet med glänsande objekt.

Vad sjutton är egentligen syndromet med glänsande objekt?

Syndromet med glänsande objekt (SOS) uppstår när team distraheras av nya verktyg, ramverk eller tekniker, ofta på bekostnad av befintliga prioriteringar. 

”När en ny teknik dyker upp, vilket är fallet med AI idag, blir marknaden entusiastisk över dess tillämpningar. Det kan uppstå ett tryck att ställa om mot trenden för att ligga steget före konkurrenterna”, säger Raju Malhotra, CPTO på Certinia.

Det är då det ”glänsande” verktyget eller ramverket börjar smyga sig in i dina planer och ”leder ingenjörerna bort från det arbete som faktiskt är viktigt för kunderna idag.”

Evernotes historia prickar in varje ruta på bingobrickan för syndromet med glänsande objekt. Företaget hade alla rätta ingredienser: lojala användare, en stabil produkt och en tydlig nisch. I stället för att satsa ännu mer på sina kärnfunktioner breddade företaget verksamheten till fysiska produkter och lanserade halvfärdiga produktfunktioner som Work Chat. 

Produkten blev uppblåst, prestandan försämrades och användarna gick över till enklare verktyg som Notion och Google Keep. År 2022 förvärvades Evernote, och i början av 2023 hade merparten av personalen sagts upp. 

SOS slutar inte alltid med konkurs eller uppsägningar, men det leder nästan alltid till att framåtdriften spårar ur genom att: 

• Försena projektleveranser: Frekventa byten till ny teknik mitt i projekt kan kullkasta planeringen, störa genomförandecyklerna och skapa ett uppblåst, oplanerat omfång. Det var precis vad som hände med FBI:s projekt Virtual Case File. Efter fem år och $170 miljoner i kostnader övergavs projektet, delvis eftersom den föränderliga byråkratiska och affärsmässiga samordningen gång på gång bröt leveransrytmen.
• Öka ingenjörskostnaderna: Utan ett ramverk för att utvärdera ny teknik leder beslut som drivs av glänsande objekt ofta till en överbelastning av verktyg, teknisk skuld och höga kostnader för programvaruutveckling. Team lägger till och med tid på prototyper som aldrig lanseras eller, ännu värre, distribueras för att sedan skrivas om.
• Döda utvecklarnas produktivitet: Varje nytt verktyg innebär en ny inlärningskurva, fler buggar och fler ”snabba tester” som sällan förblir snabba. Det sprider ut ingenjörerna, minskar produktiviteten med så mycket som 40% och leder till trötthet och ständig brandkårsutryckning– energi som i stället hade kunnat läggas på att bygga centrala produktfunktioner.
• Urholka intressenternas förtroende: SOS skickar också fel signal till företagsledningen. När prioriteringarna ändras för ofta och tidsplanerna spricker kan företagsledningen börja ifrågasätta ingenjörsteamets förmåga att leverera. När förtroendet väl är förlorat är det svårt att återvinna det.

Stoppa ångern över glänsande objekt: 3 kontrollfrågor för ditt team

Du vet vilken typ av kaos syndromet med glänsande objekt kan orsaka i ditt team. Så hur avgör du om det nya biblioteket, SDK:t eller tjänsten är värt det–innan det slukar tid och fokus? Våra experter har några standardkontroller:

1. Är det en ”omslutning” eller ett ”plåster”?

Sainaths filter när han hanterar nya, glänsande verktyg och tekniker är enkelt: Löser det här något som är viktigt på lång sikt, eller är det bara ett plåster?

”Ett plåster täcker bara över mindre specialfall eller kortsiktiga begränsningar. Men sannolikheten är stor att nästa version av modellen löser det ändå. Vad du har byggt blir då omedelbart föråldrat.”

Han är mer intresserad av att bygga omslutningar– rena lager ovanpå grundmodeller som tillför faktisk användbarhet genom design, arbetsflöden eller kontext.

”Termen LLM-omslag användes nästan nedsättande i början, men i grunden bygger många värdefulla produkter på underliggande teknik,” kommenterar Sainath. ”Titta på Cursor. Man skulle kunna hävda att det bara är ett omslag, men det ger ett betydande och fokuserat värde.”

Enligt honom är plåsterlösningar distraktioner som lätt kan förvandlas till glänsande objekt. Väl genomtänkta omslag kan däremot bli kärnprodukter.

2. Vad väljer vi att inte bygga?

Enligt Malhotra är det lika viktigt att följa upp vad teamet väljer att inte bygga som vad som hamnar i färdplanen. ”Det hindrar oss från att jaga funktioner som kanske ser bra ut i en demonstration men faktiskt inte förbättrar det dagliga arbetet,” säger han.

Även när teamet inte är säkert på att något är redo för en bredare lansering testar de det ändå med tidiga användare. ”Det ger oss återkoppling utan att störa färdplanen.”

3. Vilket är affärsvärdet? 

För Customer.ios teknikchef, Paul Senechko, är förståelsen för affärsvärdet bakom tekniska insatser det första och viktigaste filtret. Om ett nytt verktyg eller system inte tjänar något av dessa syften, säger han, är det förmodligen inte rätt tid för det.

”Vår företagsledande princip är att vi är kundexperter,” förklarar Senechko. ”Vi använder denna princip för att vägleda våra investeringar i teknik och säkerställa att vi bygger med kunden och verksamheten i åtanke.”

För att hålla teamet förankrat förlitar sig Senechko på några enkla men kraftfulla frågor: Vad kostar detta oss i tid och resurser? Förbättrar det vår produkt? Kommer det att hjälpa våra kunder att bli mer framgångsrika?

Sainath tillför sitt eget perspektiv med det han kallar ”tänk om”-frågorna: ”Vad händer om den underliggande tekniken blir tio gånger bättre? Blir vår produkt automatiskt bättre, eller blir den plötsligt irrelevant?”

Han undersöker också vilken insats som krävs för att förverkliga dessa förbättringar: ”Kommer vi automatiskt att dra nytta av dessa framsteg, eller kommer det att krävas en omfattande omarkitektur för att komma ikapp?”

Genom att spela upp dessa scenarier tillsammans med teamet kan ni fatta beslutet om huruvida ni ska prioritera den nya glänsande teknikstacken eller hålla fast vid det som redan fungerar.

Skydda färdplanen mot SOS (utan att döda innovationen) 

När spännande ny teknik går sönder behöver du ta den med en nypa salt och balansera innovation med faktiska framsteg.

Så här hanterar CTO:er rädslan att missa något och håller sina team förankrade och fokuserade:

1. Definiera avslutskriterier för projekt innan ni börjar

Många ”utforskande” teknikförsök förvandlas till långvariga sidoprojekt med växande omfattning och återkommande teknisk skuld, främst eftersom ingen definierar hur eller när de ska avslutas. Om det saknas ansvar, tidsplan eller framgångskriterier är det bara en tidsfråga innan syndromet med glänsande objekt kör hela projektet i botten. För att undvika det bör ni behandla varje teknikförsök som en produktfunktion: avgränsad, tidsbegränsad, ägd och driven av ett verkligt användningsfall. 

Som Senechko uttrycker det: ”Tillämpa det på små men verkliga användningsfall och gå sedan vidare därifrån. När vi beslutar oss för att experimentera med nya trender ser vi till att identifiera ett litet eller väl avgränsat område där vi kan testa och verifiera att det fungerar. På så sätt kan vi experimentera och skaffa oss verklig erfarenhet av tekniken innan vi satsar stort på den.”

Involvera en tvärfunktionell granskare (EM + PM + senior ingenjör) för en objektiv utvärdering och skapa en strukturerad tidsplan som inkluderar:

• Maximal varaktighet: Begränsa till 2 sprintar (+1 buffert) för att hålla det enkelt och testbart
• Milstolpar för fortsättning/avbrytande med avslutningsvillkor: Definiera ett uttryckligt granskningsögonblick där teamet beslutar om det ska fortsätta, iterera eller avsluta (över 10 % av byggena misslyckades eller integration med CI/CD-verktyget saknas). 

Senechko föreslår till och med att team experimenterar med tidsbestämda initiativ med varierande omfattning, där hans team fastställer en inledande ”aptit” för hur mycket tid de är villiga att lägga och siktar på att leverera det mest värdefulla resultatet inom den tidsramen. ”Detta har gjort det möjligt för oss att innovera och misslyckas snabbt när de nya riktningarna inte verkar leda åt rätt håll.”

2. Använd mätvärden för att mäta framgång

När den tekniska genomförbarheten och teknikinsatsen är klarlagda ska du definiera hur framgång ser ut. Det är skillnaden mellan en disciplinerad utrullning och ett SOS-projekt vars omfattning hela tiden växer. Bygg ett ramverk som mäter framgång utifrån flera dimensioner:

• Människor: Ökad produktivitet bland utvecklare, fler timmar med fördjupat arbete
• Processer och arbetsflöden: Kortare körtid för testsviter, färre regressioner, smidigare arbetsflöden för driftsättning, kortare tid till marknaden
• Kundupplevelse: Bättre sidprestanda, färre UX-klagomål, förbättrade svarstider
• Systemprestanda: Snabbare beräkningar, lägre infrastrukturkostnader, färre incidenter eller återställningar

3. Lär känna dina kunder

”Att hålla sig på rätt spår handlar om att vara ärlig med var kundvärdet skapas,” hävdar Malhotra. ”Trender kan låta spännande, men de kan snabbt bli distraktioner om de inte direkt hjälper kunderna att utföra sitt arbete bättre eller snabbare.”

Den principen syns i hur många team numera låter produkt- och teknikavdelningar samarbeta med kundframgångsteam vid direkt observation av kunder. Några utvecklare deltar i supportsamtal, introduktionsmöten eller kundavstämningar för att få verklig, ofiltrerad feedback. Att höra direkt vad som förvirrar användarna, vad som går sönder och vad som får beröm skapar empati och kan till och med vässa prioriteringen i teknikteam. 

Men det räcker inte att bara lyssna. För att identifiera var kunderna faktiskt stöter på problem bör du komplettera kvalitativ feedback med produkttelemetri. Det är troligt att ditt analysverktyg (PostHog, Amplitude, Heap) inte används tillräckligt för detta ändamål. Börja följa hur användarna verkligen interagerar med produkten: ända ned på klick, reglage, navigeringsloopar och felvägar. 

Kombinera dessa beteendedata med supportärenden för att upptäcka mönster. Ignoreras en funktion för att den är svår att hitta? Misslyckas användarna med att slutföra kritiska arbetsflöden? Använd detta som tydliga signaler för pilotprojekt med kunden i centrum.

Med tiden bygger du organiskt upp en struktur för ”kundens röst” med kundernas problem, feedback, positiva upplevelser och återkommande hinder, som förs vidare från kundframgångsteamen till beslut inom produkt- och teknikavdelningarna. 

Det är samma system som Senechkos team använde för att prioritera arbete utifrån mätbart kundvärde: ”En stor mängd kunder och krav på låg fördröjning har drivit vårt team att uppfinna lösningar som standardtekniker inte kunde åstadkomma. Att investera i vår tekniska plattform är en del av vårt företags DNA, eftersom vi har sett nyttan för både kunderna och verksamheten.”

I slutändan kommer verkliga framsteg inom teknik att skapas genom att utforma nya funktioner som vidareutvecklar det som redan fungerar, inte genom att bygga runt det eller lägga till något helt nytt ovanpå. Det är så team utvecklas utan att välbeprövade system går sönder.

”Innovation behöver inte innebära omvälvning. Den bör förstärka det som redan fungerar och hjälpa kunderna att arbeta snabbare med mindre ansträngning,” uttrycker Malhotra det enkelt.

Vill du ha fler insikter som denna? Prenumerera på The CTO Clubs nyhetsbrev.