«Det er slik Google lager landingssider. Det er bransjestandarden.»
«Vi kan ikke levere tidligere enn august. Vi la sammen estimatene våre, og seks måneder var det vi kom frem til.»
«Bare vent to uker på den hasteløsningen. Vi kan ikke avbryte sprinten, ellers er vi ikke smidige.»
Alle disse påstandene er løgner teknologiteamet ditt forteller deg – og seg selv. Disse svært vanlige misforståelsene stammer fra en grunnleggende feil som er utbredt blant ingeniører: troen på «bedre».
Bedre er ikke bedre (for alle)
Inne i en datamaskin er det en verden av ettall og nuller. Det finnes ingen tvil eller usikkerhet rundt aritmetikk og logiske porter, og bortsett fra en sjelden kosmisk stråle er maskinen fullstendig deterministisk og følger den samme banen om og om igjen hver gang du gir den de samme inndataene.
Selv den tilsynelatende tilfeldigheten i spill eller simuleringer er egentlig en illusjon. Hvis du gir en spesifisert «pseudotilfeldig startverdi» til for eksempel Minecraft, får du nøyaktig den samme oppførselen hver gang du spiller. Det er nyttig å huske at alle medlemmene av IT-teamet ditt valgte et yrke som innebærer dette nivået av sikkerhet og forutsigbarhet; det er bokstavelig talt umulig å gjøre jobben deres uten å resonnere strengt ut fra grunnleggende prinsipper.
Men utenfor det datamaskinelle området møter vi uforutsigbare mennesker, og da er alle veddemål avslått. Ingen salgsteam ville engang vurdert å bruke den samme presentasjonen eller salgspitchen overfor alle potensielle kunder, og hver kundeservicesamtale er forskjellig og overraskende. Manus og opplæring hjelper de ansatte dine med å oppnå konsistens, riktignok, men det er avgjørende å variere fremgangsmåten slik at den passer til hver situasjon. Det oppdaget mange organisasjoner da de prøvde å innføre holakrati eller slanke metoder for å etterligne suksessen til Zappos og Toyota, og mislyktes fullstendig.
Dette gjelder like mye når man bygger programvare som innen drift, økonomi eller strategi: Det finnes ingen enkelt riktig måte å utforme et innloggingsskjermbilde, lage en rapport eller finne ut hvilke funksjoner kundene vil betale for på. Derfor har ingeniører utviklet et så svimlende mangfold av programvaremetodikker, som Scrum, Kanban, ShapeUp, Spotify-modellen, SAfE og hundre andre, som alle har vært vellykkede i noen tilfeller og katastrofale i andre.
Nå kan du se hvorfor vi teknologifolk går i fellen med å tro at bedre alltid er bedre. Hvem som helst av oss ville synes det var tiltalende å tro at det finnes en steintavle der ute med løsningen på problemene våre meislet inn i den, men sikkerhet er farlig forførende når du hver dag arbeider med verktøy og maskiner hvis drift avhenger av absolutt konsistens. Men hvordan bryter du vanen med binær tenkning?
Først: Still spørsmål uten å gi deg
For så mange av oss er teknologi bare svart magi. Ingeniørene mumler merkelige besvergelser om Kubernetes og zettabyte, og plutselig dukker det opp nettsteder, e-poster og kredittkortbetalinger ut av ingenting. Så når trollmennene forteller oss med autoritet at de følger «beste praksis», hvem er vi til å tvile på dem?
Svaret er DU! Akkurat som alle andre teammedlemmer trenger programvareutviklere tilbakemeldinger på om planene og leveransene deres følger selskapets strategi. Du trenger ikke bruke fagspråk for å gi dem reaksjonene og veiledningen din; det er deres jobb å lære nok om markedet og målene dine til at de på en effektiv måte kan holdes ansvarlige overfor deg ved hjelp av standard norsk. Ikke vær redd for å stille alle spørsmål du måtte ha om hva de prioriterer, hvorfor de velger den ene eller den andre teknologien, og særlig hvordan de forventer at resten av virksomheten skal dra nytte av det.
Jeg tror så sterkt på å stille spørsmål at jeg fikk trykket opp flotte sertifikater med bladgull som gir offisiell tillatelse til å spørre ingeniører om hva som helst, og jeg deler dem ut når jeg kan. Nedenfor ser du et eksempel. Hvis du vil ha et på veggen, kan du sende meg en e-post, så sender jeg deg ett (gratis!)
Deretter: Lek hvorfor-leken
Når du har overvunnet frykten for å stille spørsmål og lært mer om teknologiteamets fremgangsmåte, er det på tide å leke hvorfor-leken. Reglene er enkle og velkjente for alle femåringer: Først spør du hva en utvikler holder på med, og deretter spør du «hvorfor» gjentatte ganger.
«Jeg erstatter betalingssiden vår.»
«Hvorfor?»
«Fordi den er ineffektiv.»
«Hvorfor er den ineffektiv?»
«Vi utfører unødvendige kontroller som gjør responstidene våre lengre.»
«Hvorfor er hastighet viktig?»
«Fordi brukerne gir opp når de må vente for lenge med å betale.»
Signaleringspunktet for å stoppe er når du kommer til penger. Når du hører «fordi det vil øke konverteringene», «fordi flere kunder vil oppgradere» eller «fordi vi vil kutte forskningskostnadene», har du vunnet. Hvis du aldri kommer dit, og avslutter med «jeg vet ikke» eller «fordi Jane sa det», er det du (ikke ingeniøren) som har tapt «hvorfor»-spillet. Se etter måter å knytte teknologiteamet ditt mye tettere til forretningsresultatene på, slik at alle er vinnere neste gang dere spiller.
Etter noen runder med hvorfor-spørsmål vil du begynne å se mønstre og mangler. Jeg jobbet for eksempel med et team som var ekstremt fokusert på å øke konverteringsfrekvensen, men som fullstendig ignorerte kostnadene. Det var ikke overraskende at de gikk langt over budsjettet med hyperoptimaliserte strategier for annonsering i sosiale medier som var altfor kompliserte for en enkel julekampanje.
Joda, de intrikate algoritmene deres var «bedre» til å oppnå en liten prisfordel på enkelte søkeord, men Facebook-regningen ble en brutal realitetssjekk da den kom (inkludert kostnader for faktisk å ha overbelastet enkelte facebook.com annonseservere med for mange forespørsler!). Når du ser slike blindsoner, må du korrigere prioriteringene, avlyse det som er unødvendig, og forsterke budskapet om at teknologien må være tett knyttet til forretningsmålene dine.
Sørg til slutt for ansvarlighet
Nå som du har funnet og fjernet de «bedre» teknologiløsningene som faktisk ikke fungerer for deg, bør du gi ingeniørene enkle måter å vise at de holder seg på linje med målene og følger planen. Legg merke til at jeg ikke sa noe om å «holde teknologiteamet ansvarlig», en pekefingerorientert tilnærming som alltid får meg til å ville gjemme meg under nærmeste skrivebord. Gjør i stedet utviklerne i stand til å stå til ansvar overfor deg. Du kan for eksempel
- Planlegge en ukentlig demonstrasjon av IT-forbedringer, der teamlederne beskriver forretningsfordelene og innhenter tilbakemeldinger fra deg og andre.
- Sette opp et dashbord som viser viktige måltall, som systemoppetid eller besvarte samtaler, og be utviklerne forklare jevnlig hvordan tiltakene deres forbedrer resultatene.
- Opprette en fremdriftsplan for å følge utviklingen i viktige prosjekter og komme raskt tilbake på sporet når sentrale elementer blir forsinket.
En tydelig strategi for hyppige tilbakemeldinger og fokus på reelle, konkrete forretningsfordeler vil sikre at IT-investeringene dine ikke sløses bort på smarte, men ubrukelige «bedre» prosjekter. Og hvis du, som de fleste virksomhetene jeg jobber med, bruker millioner på teknologi med uklare resultater i beste fall, er det ikke verdt å måle avkastningen på denne enorme investeringen?
Abonner på nyhetsbrevet til The CTO Club for flere råd fra fellesskapet vårt.
