5 vanlige mønstre som fører til KI-svikt

Adam Horner har bygget ingeniørteam innen fintech og bedriftsprogramvare. Nå er han grunnleggeren av The CTO Playbook, der han underviser og jobber som deltids-CTO.

Vi satte oss ned med ham for å lære hvilke mønstre han ser bak suksessene og fiaskoene innen AI-integrasjon. Her er det han fortalte oss.

En variant av den samme utfordringen

Jeg heter Adam Horner og er CTO-coach og deltids-CTO i The CTO Playbook. Den første delen av karrieren min tilbrakte jeg som ingeniør og medgrunnleggende CTO, der jeg bygget og ledet ingeniørteam innen fintech og bedriftsprogramvare, inkludert flere år i Palantir som en av deres første ansatte i Storbritannia.

Overgangen til coaching kom av en enkel observasjon: Det er genuint vanskelig å bli en effektiv teknologileder, og de fleste navigerer dette uten et veikart eller noen på sin side som har vært gjennom det før. Det er dette jeg jobber med nå, ved å hjelpe CTO-er med å krysse det jeg kaller CTO-kløften.

AI-perspektivet er ikke en separat tråd for meg. Det går gjennom nesten alle coachesamtalene mine, fordi alle CTO-ene jeg jobber med navigerer en variant av den samme utfordringen: Hvordan leder du en organisasjon gjennom en transformasjon av denne størrelsesordenen, på ditt spesifikke stadium, med ditt spesifikke team, og kommer ut av det med en sterkere virksomhet?

Den uoversiktlige midten av vekstkurven

Min egen organisasjon er liten og bevisst slank, et grunnleggerteam på fire som bygger utelukkende med AI først, der vi bruker denne erfaringen til å holde oss tett på realitetene ved produktutvikling i tidlig fase. Jeg jobber også som deltids-CTO for en fintech-oppstartsbedrift som ennå ikke er akkreditert, der jeg navigerer i det spesielle presset ved å få et regulert produkt ut på markedet med et eksternt utviklingsteam.

Men det bredere bildet, og der den virkelige bredden i organisasjonseksponeringen kommer fra, er CTO-ene jeg coacher. Det spenner fra grunnleggerteam og tidlige oppstartsbedrifter som er bygget med egne midler, via raskt voksende oppskaleringsselskaper støttet av venturekapital og private equity, til mellomstore virksomheter som håndterer reell organisatorisk kompleksitet, og videre til virksomheter med flere avdelinger som opererer i stor skala.

Den uoversiktlige midten av vekstkurven er der jeg tilbringer mesteparten av tiden min, og det er der lederutfordringene pleier å være skarpest.

Hvordan AI lar ingeniører se det større bildet

For meg har den viktigste endringen ikke vært et verktøy eller en prosess, men en forventning. Som leder, når du gir teamet tillatelse – og enda viktigere, forpliktelsen – til å revurdere hele leveranselivssyklusen fra grunnen av, er omfanget av denne revurderingen viktig. Ikke bare hvordan kode skrives eller distribueres, men alt leveranseprosessen berører: kundestøtte, brukerverdi og forretningsintensjonen bak ethvert arbeid.

Da kostnadene ved å skrive og vedlikeholde kode var høye, ga det en viss mening å holde ingeniørene tett fokusert på det tekniske problemet. Men denne kostnaden har falt dramatisk. Den begrensende faktoren er ikke lenger hvor raskt du kan bygge, men hvor tydelig alle involverte forstår hva det faktisk er verdt å bygge, og hvorfor.

Ingeniører som forstår produktet, kunden og forretningsmålene bak en endring, kan ta beslutninger og bevege seg på måter som ganske enkelt ikke var mulige før. Det som ble bedre, var ikke en måleenhet. Det var kvaliteten på spørsmålene teamet begynte å stille før de skrev en eneste linje.

Adams tanker

Den begrensende faktoren er ikke lenger hvor raskt du kan bygge, men hvor tydelig alle involverte forstår hva det faktisk er verdt å bygge, og hvorfor.

Hvordan feilsorterings- og utbedringssykluser kan forkortes med AI

Et eksempel handlet om å tenke nytt rundt hvordan kundestøtte og ingeniørteam samarbeidet om bekreftede feil. Tidligere ble feilsorterings- og utbedringssyklusene målt i dager eller uker, mens kundestøtteteam håndterte frustrerte kunder underveis, og ingeniørene tok belastningen ved avbrudd fra aktive problemer i tillegg til det øvrige arbeidet. Da leveranselivssyklusen ble revurdert med AI-assistert utvikling i bildet, ble utbedringssyklusene dramatisk forkortet, og store deler av prosessen ble automatisert.

Det la mer arbeid på kundestøttefunksjonen i forkant, ved å registrere og kategorisere problemer tydelig, men gevinsten var løsning i løpet av timer i stedet for dager. Ingeniørene kunne holde fokus. Kundene fikk svar raskere. Grensesnittet mellom to funksjoner som alltid bare hadde blitt akseptert som trege, viste seg å kunne reforhandles fullstendig.

Hvorfor organisasjoner ikke bør bruke AI på alt

Når det gjelder hva som bør være en menneskelig oppgave kontra en AI-oppgave, er det forskjellig for hver organisasjon. Det riktige utgangspunktet er ikke en liste over aktiviteter, men en tydelig forståelse av hvor verdien deres ligger, og hvor risikoen er konsentrert.

Delene av prosessen som er kjernen i det virksomheten gjør — logikken, differensieringen og områdene der feil er synlige eller kostbare — bør utføres av mennesker og være underlagt menneskelig tilsyn. Alt annet befinner seg på et spekter.

Et cybersikkerhetsselskap vil vie betydelig menneskelig oppmerksomhet til sikkerhetsegenskapene i koden sin, fordi det er selve virksomheten. Et selskap som automatiserer arbeidsflyter, kan rette den samme grundigheten mot beslutningslogikken i en kritisk arbeidsflyt, samtidig som det behandler sikkerhetsverktøy som noe AI kan håndtere på en tilfredsstillende måte.

Det som er feil, er å anvende en generell policy i den ene eller den andre retningen. Spørsmålet man bør stille, er ikke «Kan AI gjøre dette?» Det er «Hva er kostnaden hvis dette går galt?»

Og her er en annen ting: En overraskende stor del av kompleksiteten folk ønsker å automatisere, er faktisk uløst prosessgjeld. Få orden på det først. Det vil gjøre det enklere og billigere å ta i bruk AI senere.

Adam deler

Det riktige utgangspunktet er ikke en liste over aktiviteter, men en tydelig forståelse av hvor verdien deres ligger, og hvor risikoen er konsentrert.

Hvorfor CTO-er må begynne med å automatisere leveransen, ikke koden

Det er genuint vanskelig å sammenligne AI-resultater på tvers av organisasjoner fordi de fleste ledere, både innen teknologi og i virksomheten for øvrig, fortsatt sliter med å måle effekten og avkastningen på investeringene sine i AI på en tydelig måte. Uten dette er det vanskelig å vite hvordan et godt resultat faktisk ser ut, og enda vanskeligere å argumentere for å gjøre mer av det.

Men samlet sett er variasjonen i AI-resultater stor. I den ene enden har jeg jobbet med organisasjoner som i praksis har eliminert etterslepet sitt og nå arbeider direkte ut fra kundeverdi og virksomhetens intensjon. Dette representerer en grunnleggende endring i hvordan utvikling forholder seg til resten av virksomheten.

Jeg la merke til et felles mønster i organisasjonene som oppnådde dette: Ingen av dem startet på venstresiden av livssyklusen for programvareutvikling. De begynte ikke med kodegenerering. De startet til høyre: CI/CD-pipelines, trygghet rundt utrulling og automatisert kodegjennomgang. Det var det å gjøre leveransedelen av prosessen robust og pålitelig først som skapte forutsetningene for alt annet. Derfra ble fokuset flyttet til tester, begrensninger og kontroller før generering, samt til struktur fremfor hastighet.

Teamene som gjorde størst fremgang, var de som arbeidet mest autonomt – ikke fordi de hadde fjernet menneskelig dømmekraft, men fordi de hadde bygget inn nok av den i prosessen til at de trygt kunne ta på seg betydelig større arbeidsoppgaver. Etterslepet forsvant ikke fordi de skrev kode raskere. Det forsvant fordi hele forholdet mellom intensjon og levering ble entydig.

I den andre enden har jeg sett reell avgang blant ansatte drevet av det økende gapet mellom dem som beveger seg raskt med AI, og dem som ikke gjør det. Når AI-bruken begynner, finnes det nesten alltid en liten gruppe som beveger seg raskt, og en større gruppe som ikke gjør det. Det naturlige instinktet er å la de raskeste få løpe. Det dette skaper, stille og raskt, er friksjon, mistillit og mistenksomhet mellom teamene, noe som bryter ned gevinstene raskere enn den tidlige fremgangen rekker å bygge dem opp. Rådet jeg nå gir i starten av hvert oppdrag, er det samme: Ikke la noen bli hengende etter. Tempoet i innføringen bør bestemmes av hvor raskt du kan få med deg hele organisasjonen, ikke av hvor raskt de mest entusiastiske utviklerne dine kan bevege seg individuelt.

En organisasjon med to hastigheter føles som fremgang sett forfra. Sett bakfra føles det som å bli forlatt, og den følelsen får konsekvenser.

Hvorfor en organisasjons kunnskapsbase må redesignes for AI

Det tydeligste gapet jeg har sett i AIs evner er innen beslutningstaking under usikkerhet.

AI er i bunn og grunn en prediksjonsmotor, og prediksjon er ikke det samme som dømmekraft. Den har ingen egeninteresse i utfallet, ingen forståelse av konsekvenser og ikke noe eierskap til resultatet. Å forvente at den skal ta beslutninger på dine vegne, vil aldri være bedre enn dens evne til å forutsi, noe som er begrenset i genuint usikre eller nye situasjoner. Organisasjonene som har blitt mest skuffet over AI, er vanligvis de som lente seg på den nettopp i slike øyeblikk.

Det andre området der effekten ikke strekker til, mer stillegående, men like betydelig, er der konsekvensene av kontekstvinduer er dårlig forstått. Gi en AI ufullstendig eller dårlig strukturert kontekst, og den vil likevel gi deg et selvsikkert svar. Å vite forskjellen mellom et velinformert resultat og et som bare høres plausibelt ut, krever menneskelig dømmekraft som ikke nok team har utviklet ennå.

Derfor er en organisasjons kunnskapsbase avgjørende. Med det mener jeg all konteksten som i dag finnes i hodene til folk: måten ting alltid har blitt gjort på, standardtilnærmingene og de uskrevne reglene for hvordan organisasjonen faktisk fungerer. AI kan ikke arbeide med organisasjonskunnskap som aldri har blitt gjort eksplisitt, og de fleste organisasjoner sitter på enorme mengder av den.

Den gode nyheten er at det ikke er nødvendig å strukturere alt perfekt for å få det ut. Multimodal AI betyr at en videogjennomgang, en grov skisse og et uredigert dokument alle er verdifulle inndata. Prioriteten er å gjøre kunnskapen eksplisitt først og strukturere den etterpå.

Det jeg stadig finner, er at selve arbeidet med å få denne konteksten ut av hodene til folk og inn i en eller annen form for dokumentasjon, er verdifullt i seg selv, før AI i det hele tatt berører den. Det avdekker avvik, synliggjør dårlige antakelser og avslører ødelagte arbeidsflyter som ingen hadde lagt merke til fordi de var for tett integrert i dem.

Dette grunnlaget mangedobler deretter alt AI kan gjøre. Det er noe av det mest verdifulle en teknologidirektør kan bruke tid på akkurat nå, og samtidig noe av det som oftest blir oversett, til tross for at selgere innen automatisering av forretningsprosesser har fortalt oss dette i årevis!

Hvordan hindre skeptiske utviklere i å bremse en organisasjon

Et vanlig problem jeg ser, er egentlig ikke en svikt ved AI. Det er en svikt i innføringen, og den følger ofte et gjenkjennelig mønster.

En skeptisk utvikler – og det finnes overraskende mange av dem – gjør et halvhjertet forsøk med minimal kontekst, får et dårlig resultat og presenterer dette resultatet som bevis på at AI ikke kan gjøre jobben. Konklusjonen fremsettes med selvsikkerhet. Metoden blir sjelden undersøkt. Det som gjør dette til mer enn bare individuell frustrasjon, er følgeeffekten.

AI-integrasjon i et team eller en utviklingslivssyklus er en lagidrett, og noen få ingeniører som er motivert for å demonstrere at det ikke fungerer, kan bremse hele organisasjonen, ikke bare sin egen produksjon.

Lærdommen jeg trekker av dette, handler ikke om AIs begrensninger. Den er at innføring er like mye en lederutfordring som en teknisk utfordring. Kvaliteten på det AI produserer, kan ikke skilles fra kvaliteten på konteksten og intensjonen du tilfører, og å bygge denne forståelsen på tvers av et team krever den samme bevisste innsatsen som enhver annen betydelig endring i hvordan folk arbeider. Det er slik vi endrer oppfatningen fra feilslått «magi» til anvendelig «avansert teknologi».

Adam deler

En skeptisk utvikler gjør et halvhjertet forsøk med minimal kontekst, får et dårlig resultat og presenterer resultatet som bevis på at AI ikke kan gjøre jobben. Konklusjonen fremmes med sikkerhet. Metoden blir sjelden undersøkt.

Hvorfor små team er en fordel med AI

Antakelsen om at et fungerende og produktivt utviklingsteam måtte ha et visst antall medarbeidere for å kunne håndtere tilstrekkelig kontekst og holde et meningsfylt tempo, har ikke overlevd møtet med hvordan AI-assistert utvikling faktisk fungerer.

Den begrensende faktoren i ethvert team har alltid vært kognitiv: hvor mye kontekst hver person kan holde, hvor tydelig de kan kommunisere den til menneskene rundt seg, og hvor mye energi denne kommunikasjonen krever. Det som har endret seg, er at enheten som utfører arbeidet, ikke lenger bare er en person. Hver person i teamet kjører flere agenter, og disse agentene bærer og anvender kontekst på måter som endrer regnestykket fullstendig. Amazons to-pizza-regel var en rimelig tommelfingerregel i en verden før AI.

Her er et eksempel.

En organisasjon jeg jobber med, hadde alltid ønsket seg et internt administrasjonsgrensesnitt for plattformen sin, men kunne aldri forsvare investeringen. Tidligere hadde de beregnet det som et prosjekt for hele teamet over flere måneder. I stedet satte de to personer på oppgaven: Begge hadde inngående kjennskap til virksomheten og den eksisterende plattformen, høy grad av selvstendighet og et tydelig sett med rammer å arbeide innenfor. Seks uker senere hadde de en fungerende første versjon.

Disse to personenes kjennskap til virksomheten viste seg å være like viktig som AI-verktøyene. Færre spørsmål, mindre overstyring, raskere beslutninger. Men det mest verdifulle resultatet var ikke selve verktøyet. Det var det organisasjonen lærte om hvordan man kan arbeide på denne måten.

Teamene jeg nå ser fungere mest effektivt, består av mellom to og tre personer, der hver person kjører flere agenter, og det er ikke en begrensning. For den riktige typen arbeid er det en fordel.

Hvorfor hyppig kommunikasjon er avgjørende i AI-drevne arbeidsflyter

Samarbeid kan bli vanskelig med AI.

Det er nødvendig med mye hyppigere kommunikasjon fordi alt går raskere. Det er en av grunnene til at mindre team fungerer bedre slik situasjonen er akkurat nå.

Det virker rett og slett for utmattende å opprettholde status og konsistens i et stort team med flere parallelle agentbaserte kodeprosesser per person. Noen team jeg jobber med, har gått over til to daglige standuper for å opprettholde konsistensen.

Hvorfor CTOs må være oppmerksomme på skygge-AI

Skygge-AI er det tidligere observerte problemet med skygge-IT, men med et nytt budsjett og et nytt navn.

Ukontrollert og ubegrenset bruk av AI-verktøy på tvers av virksomheten kan lett øke risikoen for tap av data og immaterielle rettigheter — «eksfiltrering», som CISO-en kaller det — ofte helt utilsiktet fra brukernes side.

De fleste organisasjoner beveger seg raskt ut av trinn 1 i CMM (eksperimenteringsfasen i «ville vesten») for å innføre retningslinjer og tekniske begrensninger som reduserer risikoen.

Hvorfor CTOs må fokusere på sin egen utvikling

Adams tanker

Lederne som kommer sterkest ut av denne perioden, er ikke nødvendigvis de som har de beste verktøyene eller de største teamene. Det er de som bygger opp dømmekraften, innflytelsen og klarheten i tenkningen som skal til for å lede godt når ingen har et tydelig kart.

Det er mye uro i bransjen akkurat nå rundt hva AI betyr for utviklingsteam, for antall medarbeidere og for selve rollen.

Om denne uroen er berettiget, er nesten ikke poenget. Det som betyr noe, er at vi befinner oss i en periode med betydelige og raske endringer, og at det å navigere godt gjennom den krever ledere som aktivt utvikler sine egne evner, ikke bare håndterer endringene rundt seg.

Det som fortsatt overrasker meg, med tanke på alt som skjer, er hvor mange CTOs og seniorledere innen teknologi som opererer uten noen dedikert investering i egen vekst. Ingen coach, ingen strukturert utvikling, ingen å tenke sammen med. Jeg gjorde den feilen en gang tidligere, og feilene jeg gjorde og tiden jeg mistet, var ikke uunngåelige.

Lederne som kommer sterkest ut av denne perioden, er ikke nødvendigvis de som har de beste verktøyene eller de største teamene. Det er de som bygger opp dømmekraften, innflytelsen og klarheten i tenkningen som skal til for å lede godt når ingen har et tydelig kart.

Følg med

Du kan følge arbeidet til Adam Horner på LinkedIn. For 1:1-veiledning, kohortkurs og podkasten kan du gå til The CTO Playbook. Og for et gratis 5-dagers e-postkurs for CTO-er i tidlig fase kan du gå til Early CTO Map.

Flere ekspertintervjuer kommer på CTO-klubben!