“Sådan laver Google landingssider. Det er branchestandarden.”
“Vi kan ikke levere tidligere end august. Vi lagde vores estimater sammen, og seks måneder var det, vi nåede frem til.”
“Vent bare to uger på den akutte rettelse. Vi kan ikke bryde sprinten, ellers er vi ikke agile.”
Alle disse udsagn er løgne, som dit teknologiteam fortæller dig – og sig selv. Disse meget almindelige misforståelser udspringer af en grundlæggende fejl, der er udbredt blandt ingeniører: troen på “det bedre”.
Det bedre er ikke bedre (for alle)
Inde i en computer er det en verden af ettaller og nuller. Der er ingen tvivl eller usikkerhed ved aritmetik og logiske porte, og bortset fra den sjældne kosmiske stråle er maskinen fuldstændig deterministisk og følger den samme vej igen og igen, hver gang du giver den de samme input.
Selv den tilsyneladende tilfældighed i spil eller simuleringer er faktisk en illusion. Hvis du giver en bestemt “pseudotilfældig startværdi” til for eksempel Minecraft, får du præcis den samme adfærd ved hver gennemspilning. Det er nyttigt at huske, at hvert medlem af dit IT-team valgte et erhverv, der indebærer dette niveau af sikkerhed og forudsigelighed; det er bogstaveligt talt umuligt at udføre deres arbejde uden at ræsonnere stringent ud fra grundprincipper.
Men uden for den beregningsmæssige verden møder vi uforudsigelige mennesker, og så gælder alle væddemål ikke længere. Intet salgsteam ville overveje at bruge den samme præsentation eller salgstale til alle potentielle kunder, og alle kundeservicesamtaler er forskellige og overraskende. Manuskripter og træning hjælper ganske vist dit personale med at opnå ensartethed, men det er afgørende at variere tilgangen, så den passer til hver situation, som så mange organisationer erfarede, da de forsøgte at indføre holokrati eller lean-metoder for at efterligne Zappos' og Toyotas succes – og faldt helt igennem.
Det er lige så sandt, når man bygger software, som det er inden for drift, økonomi eller strategi: Der findes ikke én rigtig måde at designe en login-skærm, lave en rapport eller finde ud af, hvilke funktioner kunderne vil betale for. Det er derfor, ingeniører har udviklet et så svimlende udvalg af softwaremetoder, såsom Scrum, Kanban, ShapeUp, Spotify-modellen, SAfE og hundrede andre, som alle er succesfulde i nogle tilfælde og katastrofale i andre.
Nu kan du se, hvorfor vi teknikere bliver ofre for bedreisme-fælden. Enhver af os ville finde det tiltalende at tro, at der findes en stentavle derude med svaret på vores problemer mejslet ind i den, men sikkerhed er farligt forførende, når man hver dag arbejder med værktøjer og maskiner, hvis funktion afhænger af absolut ensartethed. Men hvordan bryder man vanen med binær tænkning?
For det første: Spørg ubønhørligt
For så mange af os er teknologi ren sort magi. Ingeniørerne mumler mærkelige besværgelser om Kubernetes og zettabytes, og ud af det blå dukker websteder, e-mails og kreditkortbetalinger op. Så når troldmændene med autoritet fortæller os, at de følger “bedste praksis”, hvem er vi så til at tvivle på dem?
Svaret er DIG! Ligesom alle andre teammedlemmer har softwareudviklere brug for tilbagemeldinger om, hvorvidt deres planer og leverancer følger virksomhedens strategi. Du behøver ikke bruge nørdesprog for at give dine reaktioner og din vejledning; det er deres opgave at lære nok om dit marked og dine mål til effektivt at kunne stå til ansvar over for dig på almindeligt dansk. Vær ikke bange for at stille alle de spørgsmål, du kan, om hvad de prioriterer, årsagerne til at vælge den ene eller den anden teknologi og især hvordan de forventer, at resten af virksomheden vil drage fordel.
Jeg tror så stærkt på at stille spørgsmål, at jeg fik trykt fornemme certifikater med guldfolie, der giver officiel tilladelse til at spørge ingeniører om hvad som helst, og jeg deler dem ud, når jeg kan. Nedenfor er et eksempel. Hvis du gerne vil have et på din væg, så send mig en e-mail, og jeg sender dig et (gratis!)
Dernæst: Leg hvorfor-legen
Når du har overvundet frygten for at stille spørgsmål og lært mere om dit teknologiteams tilgang, er det tid til at lege 'hvorfor'-legen. Reglerne er enkle og velkendte for alle femårige: Først spørger du, hvad en udvikler laver, og derefter spørger du gentagne gange “hvorfor”.
“Jeg udskifter vores betalingsside.”
“Hvorfor?”
"Fordi den er ineffektiv.”
“Hvorfor er den ineffektiv?”
“Vi foretager overflødige kontroller, som gør vores svartider længere.”
“Hvorfor er hastighed vigtig?”
"Fordi brugerne giver op, når de skal vente for længe på at betale.”
Signalet til at stoppe kommer, når du når frem til penge. Når du hører: “fordi det vil øge konverteringerne”, “fordi flere kunder vil opgradere”, eller “fordi vi vil skære ned på analyseomkostningerne”, har du vundet. Hvis du aldrig når dertil og afslutter med “Jeg ved det ikke” eller “fordi Jane siger det,”, har du (ikke ingeniøren) tabt 'hvorfor'-spillet. Find måder at knytte dit teknologiteam meget tættere til forretningsresultaterne på, så alle er vindere, næste gang I spiller.
Efter et par runder med hvorfor-spørgsmål begynder du at se mønstre og huller. Jeg arbejdede for eksempel med et team, der var fuldstændig fokuseret på at øge deres konverteringsrate, men som helt ignorerede omkostningerne. Det er ikke overraskende, at de overskred budgettet betydeligt med hyperoptimerede strategier for sociale annoncer, der var alt for komplicerede til en simpel julekampagne.
Deres indviklede algoritmer var ganske vist “bedre” til at opnå en minimal prisfordel på bestemte søgeord, men Facebook-regningen var en barsk realitetskontrol, da den kom (inklusive gebyrer for faktisk at få nogle facebook.com annonceservere til at bryde sammen med for mange forespørgsler!). Når du ser blinde vinkler som disse, skal du korrigere prioriteterne, annullere det unødvendige og understrege, at teknologien skal være tæt afstemt med dine forretningsmål.
Sørg til sidst for ansvarlighed
Nu hvor du har fundet og fjernet de “bedre” teknologiløsninger, der faktisk ikke fungerer for dig, skal du give ingeniørerne enkle måder at vise dig, at de fortsat er afstemt og holder kursen. Bemærk, at jeg ikke sagde noget om at “holde teknologiteamet ansvarligt”, en anklagende tilgang, der altid får mig til at ville gemme mig under det nærmeste skrivebord. Gør i stedet dine udviklere i stand til at stå til ansvar over for dig. For eksempel,
- Planlæg en ugentlig demonstration af IT-forbedringer, hvor teamlederne beskriver forretningsfordelene og modtager tilbagemeldinger fra dig og andre.
- Opsæt et kontrolpanel, der viser vigtige målepunkter som systemets oppetid eller besvarede opkald, og bed ofte udviklerne om at forklare, hvordan deres handlinger forbedrer resultaterne.
- Opret en udviklingssti til at følge fremskridtene i vigtige projekter og hurtigt komme tilbage på sporet, når centrale elementer bliver forsinkede.
En klar strategi for hyppige tilbagemeldinger og fokus på reelle, håndgribelige forretningsfordele vil sikre, at dine IT-udgifter ikke spildes på smarte, men ubrugelige “bedre” projekter. Og hvis du, ligesom de fleste virksomheder jeg arbejder med, kaster millioner efter teknologi med uklare resultater i bedste fald, er det så ikke værd at måle afkastet af den enorme investering?
Abonnér på The CTO Clubs nyhedsbrev for at få flere råd fra vores fællesskab.
