3 lögner som ditt teknikteam berättar för dig (och sig själva)

Allt detta är lögner som ditt teknikteam berättar för dig – och för sig själva. Dessa mycket vanliga missuppfattningar bottnar i ett grundläggande misstag som är utbrett bland ingenjörer: tron på ”bättre”.

Bättre är inte bättre för alla

Inuti en dator är det ett land av ettor och nollor. Det råder inget tvivel eller någon osäkerhet kring aritmetik och logiska grindar, och bortsett från den enstaka kosmiska strålen är maskinen helt deterministisk och följer samma väg om och om igen varje gång du matar in samma värden. 

Även den uppenbara slumpmässigheten i spel eller simuleringar är egentligen en illusion. Om du anger ett specifikt ”pseudoslumptalfrö” till exempelvis Minecraft, får du exakt samma beteende vid varje genomspelning. Det är bra att komma ihåg att alla medlemmar i ditt IT-team valde ett yrke som innebär den här graden av säkerhet och förutsägbarhet; det är bokstavligen omöjligt att utföra deras arbete utan att resonera rigoröst utifrån grundläggande principer.

Men utanför den beräkningsmässiga världen möter vi oförutsägbara människor, och där gäller inga garantier. Inget säljteam skulle ens överväga att använda samma presentation eller säljargument för varje potentiell kund, och varje samtal med kundtjänsten är annorlunda och överraskande. Manus och utbildning hjälper visserligen personalen att uppnå konsekvens, men det är avgörande att variera tillvägagångssättet för att passa varje situation – något många organisationer upptäckte när de försökte införa holokrati eller lean-metoder för att efterlikna Zappos och Toyotas framgångar och misslyckades totalt.

Detta är lika sant när man bygger programvara som inom verksamhet, ekonomi eller strategi: det finns inget enda rätt sätt att utforma en inloggningssida, skapa en rapport eller upptäcka vilka funktioner kunder är villiga att betala för. Därför har ingenjörer utvecklat en så svindlande mängd programvarumetoder, som Scrum, Kanban, ShapeUp, Spotify-modellen, SAfE och hundratals andra – alla framgångsrika i vissa fall och katastrofala i andra.

Nu kan du se varför vi teknikmänniskor faller offer för bättreismfällan. Vem som helst av oss skulle tycka att det vore attraktivt att tro att det finns en stentavla där ute med lösningen på våra problem inhuggen i den, men visshet är farligt förförisk när man varje dag arbetar med verktyg och maskiner vars funktion i sig bygger på absolut konsekvens. Men hur bryter man vanan att tänka binärt?

För det första: ifrågasätt obevekligt

För så många av oss är teknik ren svartkonst. Ingenjörerna mumlar märkliga besvärjelser om Kubernetes och zettabyte, och ur tomma intet dyker webbplatser, e-postmeddelanden och kreditkortsbetalningar upp. Så när trollkarlarna med auktoritet berättar för oss att de följer ”bästa praxis”, vilka är vi då att tvivla på dem?

Svaret är DU! Precis som alla andra teammedlemmar behöver programvaruutvecklare återkoppling om huruvida deras planer och leveranser ligger i linje med företagets strategi. Du behöver inte använda teknikspråk för att ge dina reaktioner och din vägledning; det är deras uppgift att lära sig tillräckligt om din marknad och dina mål för att kunna stå till svars inför dig på vanlig svenska. Var inte rädd för att ställa alla tänkbara frågor om vad de prioriterar, varför de väljer en viss teknik framför en annan och särskilt hur de förväntar sig att resten av verksamheten kommer att gynnas. 

Jag tror så starkt på att ställa frågor att jag tryckte upp eleganta certifikat med guldfoliering som ger officiellt tillstånd att fråga ingenjörer om vilket ämne som helst, och jag delar ut dem närhelst jag kan. Nedan ser du ett exempel. Om du vill ha ett på väggen, skicka ett mejl till mig så skickar jag ett (gratis!) 

Därefter: lek varför-leken

När du väl har övervunnit rädslan för att ställa frågor och lärt dig mer om ditt teknikteams arbetssätt är det dags att leka ”varför”-leken. Reglerna är enkla och välbekanta för alla femåringar: först frågar du vad en utvecklare gör och därefter frågar du upprepade gånger ”varför”. 

”Jag ersätter vår betalningssida.”

”Varför?”

”För att den är ineffektiv.”

”Varför är den ineffektiv?”

”Vi gör onödiga kontroller som gör våra svarstider längre.”

”Varför är snabbhet viktigt?”

”För att användare ger upp när de måste vänta för länge på att betala.”

Signalen att sluta är när du kommer till pengar. När du hör ”eftersom det kommer att öka konverteringarna”, ”eftersom fler kunder kommer att uppgradera” eller ”eftersom vi kommer att kapa kostnaderna för research”, har du vunnit. Om du aldrig kommer dit och avslutar med ”Jag vet inte” eller ”för att Jane sa det”, är det du (inte ingenjören) som har förlorat ”varför”-spelet. Leta efter sätt att knyta ditt teknikteam mycket närmare affärsresultaten, så att alla är vinnare nästa gång ni spelar.

Efter några omgångar av ”varför” börjar du se mönster och luckor. Jag arbetade till exempel med ett team som var helt fokuserat på att förbättra sin konverteringsgrad men helt ignorerade kostnaderna. Det är inte förvånande att de gick långt över budget med hyperoptimerade strategier för annonser i sociala medier som var alldeles för komplicerade för en enkel julkampanj.

Visst var deras avancerade algoritmer ”bättre” på att få en liten prisfördel för vissa sökord, men Facebook-fakturan blev en bister verklighetskontroll när den kom (inklusive avgifter för att faktiskt ha kraschat vissa facebook.com annonsservrar med för många förfrågningar!). När du upptäcker sådana blinda fläckar ska du korrigera prioriteringarna, avbryta det som är onödigt och förstärka budskapet att tekniken måste vara tätt anpassad till dina affärsmål.

Säkerställ slutligen ansvarstagande

Nu när du har hittat och rensat bort de ”bättre” tekniska lösningar som faktiskt inte fungerar för dig, ska du ge ingenjörerna enkla sätt att visa att de håller sig anpassade och på rätt spår. Lägg märke till att jag inte sa något om att ”hålla teknikteamet ansvarigt”, ett skuldbeläggande förhållningssätt som alltid får mig att vilja gömma mig under närmaste skrivbord. Gör i stället dina utvecklare ansvariga inför dig. Till exempel:

• Planera en veckovis demonstration av IT-förbättringar, där teamledarna beskriver affärsnyttan och tar emot feedback från dig och andra.
• Skapa en instrumentpanel som visar viktiga mätvärden, till exempel systemets drifttid eller antal besvarade samtal, och be utvecklarna att ofta förklara hur deras åtgärder förbättrar resultaten.
• Skapa en färdplan för att följa framstegen i viktiga projekt och snabbt återhämta er när centrala delar blir försenade.

En tydlig strategi för frekvent feedback och fokus på verkliga, konkreta affärsnyttor säkerställer att dina IT-utgifter inte slösas bort på smarta men oanvändbara ”bättre” projekt. Och om du, liksom de flesta företag jag arbetar med, lägger miljoner på teknik med otydliga resultat i bästa fall, är det då inte värt att mäta avkastningen på den enorma investeringen?

Prenumerera på The CTO Clubs nyhetsbrev för fler råd från vår community.