5 yleistä toimintamallia, jotka johtavat tekoälyn epäonnistumiseen

Adam Horner on rakentanut insinööritiimejä finanssiteknologian ja yritysohjelmistojen parissa. Nyt hän on The CTO Playbookin perustaja, jossa hän kouluttaa ja työskentelee osa-aikaisena CTO:na.

Tapasimme hänet selvittääksemme, millaisia malleja hän näkee tekoälyn käyttöönoton onnistumisten ja epäonnistumisten taustalla. Tässä on, mitä hän kertoi meille.

Jonkinlainen versio samasta haasteesta

Olen Adam Horner, CTO-valmentaja ja osa-aikainen CTO The CTO Playbookissa. Urani alkuvaiheessa työskentelin insinöörinä ja perustajana toimivana CTO:na sekä rakensin ja johdin insinööritiimejä finanssiteknologian ja yritysohjelmistojen parissa. Työskentelin useita vuosia myös Palantirilla yhtenä yhtiön ensimmäisistä työntekijöistä Isossa-Britanniassa.

Siirryin valmennukseen yksinkertaisen havainnon myötä: tehokkaaksi teknologiajohtajaksi kasvaminen on todella vaikeaa, ja useimmat joutuvat navigoimaan siinä ilman etenemissuunnitelmaa tai rinnallaan ketään, joka olisi käynyt saman läpi. Tätä työtä teen nyt auttaen CTO:ita ylittämään sen, mitä kutsun CTO-kuiluksi.

Tekoäly ei ole minulle erillinen aihealue. Se kulkee mukana lähes jokaisessa valmennuskeskustelussani, koska jokainen kanssani työskentelevä CTO selvittää jonkinlaista versiota samasta haasteesta: Miten johdat organisaation tämän mittakaavan muutoksen läpi juuri teidän tilanteessanne, juuri teidän tiimillänne, ja selviydytte siitä vahvempana yrityksenä?

Kasvukäyrän sekava keskivaihe

Oma organisaationi on pieni ja tarkoituksellisen kevyt. Perustajatiimimme koostuu neljästä henkilöstä, ja rakennamme kaiken alusta alkaen tekoäly edellä. Hyödynnämme tätä kokemusta pysyäksemme lähellä alkuvaiheen tuotekehityksen todellisuutta. Työskentelen myös osa-aikaisena CTO:na finanssiteknologia-alan startup-yrityksessä, joka on vielä ennen akkreditointia, ja navigoin sääntelyn alaisen tuotteen markkinoille viemisen erityispaineissa ulkoisen rakennustiimin kanssa.

Laajempi kuva ja todellinen organisaatioiden kanssa työskentelystä syntyvä syvyys tulevat kuitenkin CTO:ista, joita valmennan. Heitä on perustajatiimeistä ja varhaisvaiheen omarahoitteisista startup-yrityksistä nopeasti kasvaviin pääomasijoittajien ja buyout-sijoittajien tukemiin kasvuyrityksiin, todellista organisaation monimutkaisuutta hallitseviin keskisuuriin yrityksiin sekä aina laajassa mittakaavassa toimiviin moniosastoyrityksiin asti.

Vietän suurimman osan ajastani kasvukäyrän sekavassa keskivaiheessa, ja juuri siellä johtamisen haasteet ovat yleensä terävimmillään.

Miten tekoäly auttaa insinöörejä näkemään kokonaiskuvan

Minulle merkittävin muutos ei ole ollut työkalu tai prosessi, vaan odotus. Johtajana, kun annat tiimille luvan – ja vielä tärkeämpää, velvollisuuden – arvioida koko toimituksen elinkaari uudelleen alusta alkaen, tämän uudelleenarvioinnin laajuudella on merkitystä. Kyse ei ole vain siitä, miten koodia kirjoitetaan tai otetaan käyttöön, vaan kaikesta, mihin toimitusprosessi vaikuttaa: asiakastuesta, käyttäjälle tuotetusta arvosta ja tietyn työn taustalla olevasta liiketoimintatarkoituksesta.

Kun koodin kirjoittamisen ja ylläpidon kustannukset olivat korkeat, insinöörien pitäminen tiukasti tekniseen ongelmaan keskittyneinä oli tietyllä tavalla järkevää. Nyt tämä kustannus on romahtanut. Rajoittava tekijä ei enää ole se, kuinka nopeasti pystyt rakentamaan, vaan se, kuinka selkeästi kaikki mukana olevat ymmärtävät, mitä todella kannattaa rakentaa ja miksi.

Insinöörit, jotka ymmärtävät tuotteen, asiakkaan ja muutoksen taustalla olevat liiketoimintatavoitteet, voivat tehdä päätöksiä ja edetä tavoilla, jotka eivät aiemmin yksinkertaisesti olleet mahdollisia. Parantunut asia ei ollut mittari, vaan niiden kysymysten laatu, joita tiimi alkoi esittää ennen ensimmäisenkään koodirivin kirjoittamista.

Adamin ajatuksia

Rajoittava tekijä ei enää ole se, kuinka nopeasti pystyt rakentamaan, vaan se, kuinka selkeästi kaikki mukana olevat ymmärtävät, mitä todella kannattaa rakentaa ja miksi.

Miten ongelmien luokittelu- ja korjaussyklit voidaan lyhentää tekoälyn avulla

Yksi esimerkki liittyi siihen, miten asiakastuen ja tuotekehityksen välistä yhteistyötä vahvistettujen virheiden ympärillä alettiin ajatella uudelleen. Aiemmin ongelmien luokittelu- ja korjaussyklit kestivät päiviä tai viikkoja. Tukitiimit joutuivat hallitsemaan turhautuneita asiakkaita koko tämän ajan, ja insinöörit joutuivat muiden töidensä ohella kantamaan tuotannossa olevien ongelmien aiheuttaman häiriökuorman. Kun toimituksen elinkaari arvioitiin uudelleen tekoälyavusteinen kehitys huomioiden, korjaussyklit lyhenivät huomattavasti ja suuri osa prosessista automatisoitui.

Aluksi tämä lisäsi tukitoiminnon työmäärää, sillä ongelmat oli kirjattava ja luokiteltava selkeästi, mutta hyötynä oli ratkaisun saaminen tunneissa päivien sijaan. Insinöörit pystyivät keskittymään työhönsä. Asiakkaat saivat vastauksia nopeammin. Kahden toiminnon välinen rajapinta, jonka hitaus oli aiemmin vain hyväksytty tosiasia, osoittautui täysin uudelleen neuvoteltavaksi.

Miksi organisaatioiden ei pitäisi käyttää tekoälyä kaikkeen

Sen suhteen, mikä pitäisi olla ihmisen tehtävä ja mikä tekoälyn tehtävä, tilanne on erilainen jokaisessa organisaatiossa. Oikea lähtökohta ei ole luettelo toiminnoista, vaan selkeä ymmärrys siitä, missä arvosi syntyy ja mihin riskisi keskittyvät.

Prosessin osat, jotka ovat keskeisiä liiketoiminnan kannalta – logiikka, erottautumistekijät sekä alueet, joilla virheet näkyvät tai tulevat kalliiksi – edellyttävät ihmisen tuottamaa sisältöä ja ihmisen valvontaa. Kaikki muu sijoittuu jatkumolle.

Kyberturvallisuusyritys kohdistaa merkittävästi ihmisten huomiota koodinsa turvallisuusominaisuuksiin, koska kyse on sen liiketoiminnasta. Työnkulkujen automatisointiin keskittyvä yritys saattaa kohdistaa saman tarkkuuden kriittisen työnkulun sisäiseen päätöksentekologiikkaan ja samalla katsoa, että tekoäly pystyy hoitamaan turvallisuustyökalut riittävän hyvin.

Väärin on soveltaa kumpaankin suuntaan ulottuvaa yleispätevää käytäntöä. Kysymys ei ole "Pystyykö tekoäly tekemään tämän?" vaan "Mitä maksaa, jos tämä menee pieleen?"

Ja vielä yksi asia: Yllättävän suuri osa siitä monimutkaisuudesta, jota ihmiset haluavat automatisoida, on todellisuudessa ratkaisematta jäänyttä prosessivelkaa. Hoitakaa se ensin. Se tekee tekoälyn käyttöönotosta myöhemmin sujuvampaa ja edullisempaa.

Adam jakaa

Oikea lähtökohta ei ole luettelo toiminnoista, vaan selkeä ymmärrys siitä, missä arvosi syntyy ja mihin riskisi keskittyvät.

Miksi teknologiajohtajien on aloitettava toimitusten, ei koodin, automatisoinnista

Organisaatioiden tekoälytuloksia on aidosti vaikea vertailla, koska useimmilla johtajilla niin teknologia-alalla kuin laajemmin liiketoiminnassakin on edelleen vaikeuksia mitata tekoälyinvestointiensa vaikutusta ja sijoitetun pääoman tuottoa selkeästi. Ilman tätä on vaikea tietää, miltä hyvä käytännössä näyttää, ja vielä vaikeampaa perustella, miksi samaa pitäisi tehdä enemmän.

Kaiken kaikkiaan tekoälyn tulosten vaihteluväli on kuitenkin laaja. Yhtäällä olen työskennellyt organisaatioiden kanssa, jotka ovat käytännössä poistaneet tehtäväjononsa ja työskentelevät nyt suoraan asiakasarvon ja liiketoiminnan tavoitteiden pohjalta. Tämä merkitsee perustavanlaatuista muutosta siinä, miten ohjelmistokehitys liittyy muuhun liiketoimintaan.

Huomasin näissä organisaatioissa yhteisen toimintamallin: yksikään niistä ei aloittanut ohjelmistokehityksen elinkaaren vasemmasta reunasta. Ne eivät aloittaneet koodin generoinnista. Ne aloittivat oikealta: CI/CD-putkista, käyttöönoton varmuudesta ja automaattisesta koodintarkistuksesta. Toimitusprosessin loppupään tekeminen ensin vankaksi ja luotettavaksi loi edellytykset kaikelle muulle. Sen jälkeen huomio siirtyi testeihin, rajoitteisiin ja ennen generointia tehtäviin tarkistuksiin sekä nopeuden sijaan rakenteeseen.

Eniten edistyivät tiimit, jotka toimivat itsenäisimmin – eivät siksi, että ne olisivat poistaneet ihmisen harkinnan, vaan koska ne olivat sisällyttäneet sitä riittävästi prosessiinsa, jotta ne pystyivät ottamaan huomattavasti suurempia työosuuksia vastuulleen luottavaisin mielin. Tehtäväjono ei kadonnut siksi, että ne kirjoittivat koodia nopeammin. Se katosi, koska koko tavoitteen ja toimituksen välinen suhde muuttui yksiselitteiseksi.

Toisessa ääripäässä olen nähnyt todellista henkilöstön vaihtuvuutta, jota on ajanut tekoälyn avulla nopeasti etenevien ja muiden välille kasvava kuilu. Kun tekoälyn käyttöönotto alkaa, pieni ryhmä etenee lähes aina nopeasti ja suurempi ryhmä ei, ja luontainen vaisto on antaa nopeiden etenijöiden jatkaa. Tämä synnyttää hiljalleen ja nopeasti kitkaa, epäluottamusta ja epäilyksiä tiimien välille, mikä rapauttaa saavutetut hyödyt nopeammin kuin varhainen edistys ehtii niitä kerryttää. Neuvo, jonka annan nykyään jokaisen yhteistyön alussa, on aina sama: älä jätä ketään jälkeen. Käyttöönoton tahdin pitäisi määräytyä sen mukaan, kuinka nopeasti pystyt tuomaan koko organisaation mukaasi, ei sen mukaan, kuinka nopeasti innokkaimmat insinöörisi pystyvät etenemään yksin.

Kaksitahtinen organisaatio näyttää eturivistä katsottuna edistykselliseltä. Takaosasta katsottuna se tuntuu siltä, että sinut jätetään jälkeen, ja sillä tunteella on seurauksensa.

Miksi organisaation tietopohja on suunniteltava uudelleen tekoälyä varten

Selkein puute, jonka olen nähnyt tekoälyn kyvyissä, liittyy päätöksentekoon epävarmoissa tilanteissa.

Tekoäly on pohjimmiltaan ennustekone, eikä ennustaminen ole sama asia kuin harkinta. Sillä ei ole omaa panosta pelissä, käsitystä seurauksista eikä vastuuta lopputuloksesta. Sen odottaminen tekemään päätöksiä puolestasi voi olla korkeintaan yhtä hyvää kuin sen ennustuskyky, joka on aidosti epävarmoissa tai uudenlaisissa tilanteissa rajallinen. Organisaatiot, jotka ovat pettyneet tekoälyyn eniten, ovat yleensä niitä, jotka tukeutuivat siihen juuri tällaisissa tilanteissa.

Toinen alue, jolla vaikutukset jäävät odotettua pienemmiksi – hiljaisemmin mutta aivan yhtä merkittävästi – liittyy siihen, että konteksti-ikkunoiden vaikutuksia ei ymmärretä kunnolla. Syötä tekoälylle puutteellista tai huonosti jäsenneltyä kontekstia, ja se antaa silti itsevarman vastauksen. Hyvin perustellun tuotoksen ja uskottavalta kuulostavan tuotoksen erottaminen toisistaan edellyttää inhimillistä harkintaa, jota liian harvat tiimit ovat vielä kehittäneet.

Siksi organisaation tietopohja on ratkaisevan tärkeä. Tarkoitan sillä kaikkea sitä kontekstia, joka tällä hetkellä elää ihmisten mielissä: tapaa, jolla asiat on aina tehty, oletusmenettelyjä sekä organisaation todellisen toiminnan kirjoittamattomia sääntöjä. Tekoäly ei voi hyödyntää organisaation hiljaista tietoa, jota ei ole koskaan tuotu näkyväksi, ja useimmilla organisaatioilla sitä on valtava määrä.

Hyvä uutinen on, ettei tiedon esiin tuominen edellytä sen täydellistä jäsentämistä. Monimuotoinen tekoäly tarkoittaa, että videoesittely, karkea kaavio ja muokkaamaton asiakirja ovat kaikki merkityksellistä syötettä. Ensisijainen tavoite on tiedon tuominen näkyväksi ensin ja jäsentäminen vasta sen jälkeen.

Havaitsen jatkuvasti, että tämän kontekstin siirtäminen ihmisten mielistä mihin tahansa dokumentaation muotoon on itsessään arvokasta jo ennen kuin tekoäly koskee siihen lainkaan. Se tuo esiin ristiriitoja, paljastaa heikkoja oletuksia ja näyttää rikkinäiset työnkulut, joita kukaan ei ollut huomannut, koska ne olivat kaikille liian tuttuja.

Tämä perusta moninkertaistaa kaiken, mihin tekoäly pystyy myöhemmin. Se on yksi tehokkaimmin vipuvaikutteinen asia, johon teknologiajohtaja voi tällä hetkellä käyttää aikaansa, ja samalla yksi jatkuvasti unohdetuimmista, vaikka liiketoimintaprosessien automatisoinnin myyjät ovat kertoneet meille tästä jo vuosien ajan!

Miten skeptisiä kehittäjiä voidaan estää hidastamasta organisaatiota

Yleinen ongelma, jonka näen, ei oikeastaan ole tekoälyn epäonnistuminen. Kyse on käyttöönoton epäonnistumisesta, ja se noudattaa yleensä tunnistettavaa kaavaa.

Skeptinen kehittäjä – ja heitä on yllättävän paljon – tekee puolivillaisen yrityksen minimaalisella kontekstilla, saa heikon tuloksen ja esittää sen todisteena siitä, ettei tekoäly pysty hoitamaan tehtävää. Johtopäätös esitetään itsevarmasti. Menetelmää tarkastellaan harvoin. Se, mikä tekee tästä muutakin kuin yksilön turhautumista, on sen myöhempi vaikutus.

Tekoälyn integrointi tiimiin tai kehityksen elinkaareen on joukkuelaji, ja muutama insinööri, joita motivoi sen toimimattomuuden osoittaminen, voi hidastaa koko organisaatiota – ei vain omaa työpanostaan.

Tästä tekemäni johtopäätös ei koske tekoälyn rajoituksia. Kyse on siitä, että käyttöönotto on yhtä paljon johtamisen kuin tekniikan haaste. Tekoälyn tuottaman sisällön laatu on erottamattomasti sidoksissa sille tuomasi kontekstin ja tarkoituksen laatuun, ja tämän ymmärryksen rakentaminen koko tiimin keskuudessa edellyttää yhtä tietoista panostusta kuin mikä tahansa muu merkittävä muutos ihmisten työskentelytapoihin. Näin siirrämme käsityksen virheellisestä ”taikuudesta” käyttökelpoiseen ”edistykselliseen teknologiaan”.

Adamin jakamat ajatukset

Skeptinen kehittäjä tekee puolivillaisen yrityksen vähäisellä taustatiedolla, saa heikon tuloksen ja esittää sen todisteena siitä, ettei tekoäly pysty suoriutumaan tehtävästä. Johtopäätös esitetään itsevarmasti. Menetelmää tarkastellaan harvoin.

Miksi pienet tiimit ovat etu tekoälyn kanssa

Oletus siitä, että toimiva ja tuottava insinööritiimi tarvitsee tietyn määrän jäseniä voidakseen hallita riittävästi taustatietoa ja edetä merkityksellisellä vauhdilla, ei ole kestänyt kosketusta siihen, miten tekoälyavusteinen kehitys todellisuudessa toimii.

Tiimin rajoittava tekijä on aina ollut kognitiivinen: kuinka paljon taustatietoa kukin pystyy hallitsemaan, kuinka selkeästi hän pystyy välittämään sen ympärillään oleville ihmisille ja kuinka paljon energiaa tuo viestintä kuluttaa. Muuttunutta on se, että työtä tekevä yksikkö ei enää ole vain yksi ihminen. Jokainen tiimin jäsen käyttää useita agentteja, ja nämä agentit kantavat ja soveltavat taustatietoa tavoilla, jotka muuttavat laskelman kokonaan. Amazonin kahden pizzan sääntö oli järkevä nyrkkisääntö tekoälyä edeltäneessä maailmassa.

Tässä yksi esimerkki.

Eräs organisaatio, jonka kanssa työskentelen, oli aina halunnut alustalleen sisäisen hallintokäyttöliittymän, mutta ei koskaan pystynyt perustelemaan siihen tehtävää investointia. Aiemmin he olivat arvioineet sen useita kuukausia kestäväksi koko tiimin hankkeeksi. Sen sijaan he osoittivat siihen kaksi henkilöä: molemmilla oli syvällinen tuntemus liiketoiminnasta ja olemassa olevasta alustasta, suuri itsenäisyys sekä selkeä joukko rajoitteita, joiden puitteissa työskennellä. Kuusi viikkoa myöhemmin heillä oli toimiva ensimmäinen versio.

Näiden kahden henkilön liiketoimintatuntemus osoittautui yhtä tärkeäksi kuin tekoälytyökalut. Vähemmän kysymyksiä, vähemmän ylimääräistä työtä, nopeampia päätöksiä. Arvokkain lopputulos ei kuitenkaan ollut itse työkalu. Se oli se, mitä organisaatio oppi tällaisesta työskentelytavasta.

Tehokkaimmin toimivissa tiimeissä, joita nyt näen, on kahdesta kolmeen henkilöä, joista kukin käyttää useita agentteja, eikä tämä ole rajoite. Oikeanlaiseen työhön se on etu.

Miksi tiheä viestintä on ratkaisevan tärkeää tekoälyä hyödyntävissä työnkuluissa

Yhteistyö voi vaikeutua tekoälyn kanssa.

Viestintää tarvitaan paljon useammin, koska kaikki etenee nopeammin. Se on yksi syy siihen, miksi pienemmät tiimit toimivat tällä hetkellä paremmin.

Vaikuttaa yksinkertaisesti liian uuvuttavalta ylläpitää tilannekuvaa ja yhdenmukaisuutta suuressa tiimissä, jossa jokaisella henkilöllä on käynnissä useita rinnakkaisia agenttipohjaisia koodausprosesseja. Jotkin tiimit, joiden kanssa työskentelen, ovat siirtyneet kahteen päivittäiseen tilannekatsaukseen yhdenmukaisuuden ylläpitämiseksi.

Miksi teknologiajohtajien on valvottava varjoälyä

Varjoäly on aiemmin havaitun varjo-IT:n ongelma uudella budjetilla ja uudella nimellä.

Tekoälytyökalujen hallitsematon ja rajoittamaton käyttö koko organisaatiossa voi helposti lisätä tietojen ja immateriaalioikeuksien menettämisen riskejä — CISO:n käyttämää termiä lainaten ”ulosvuotoa” — usein käyttäjien täysin tahattomasti.

Useimmat organisaatiot siirtyvät nopeasti CMM:n vaiheesta 1 (”villin lännen” kokeiluvaiheesta) ottamalla käyttöön käytäntöjä ja teknisiä rajoitteita riskien vähentämiseksi.

Miksi teknologiajohtajien on keskityttävä omaan kehittymiseensä

Adamin ajatuksia

Tämän ajanjakson vahvimpina eivät välttämättä selviydy johtajat, joilla on parhaat työkalut tai suurimmat tiimit. Vahvimpia ovat ne, jotka kehittävät harkintakykyään, vaikutusvaltaansa ja ajattelunsa selkeyttä voidakseen johtaa hyvin silloin, kun kenelläkään ei ole selkeää karttaa.

Alalla on tällä hetkellä paljon huolta siitä, mitä tekoäly merkitsee insinööritiimeille, henkilöstömäärälle ja itse roolille.

Sillä, onko tämä huoli aiheellinen, ei ole juuri merkitystä. Tärkeää on, että elämme merkittävän ja nopean muutoksen aikaa, ja sen hyvä navigointi edellyttää johtajia, jotka kehittävät aktiivisesti omia kykyjään eivätkä vain hallitse ympärillään tapahtuvaa muutosta.

Minua yllättää edelleen kaiken tapahtuvan keskellä se, kuinka moni CTO ja teknologia-alan ylempi johtaja toimii ilman omiin kehittymistavoitteisiinsa kohdistuvaa suunnitelmallista panostusta. Ei valmentajaa, ei jäsenneltyä kehittymistä, ei ajattelukumppania. Tein itse tuon virheen kerran aiemmin, eivätkä tekemäni virheet ja menettämäni aika olleet väistämättömiä.

Tämän ajanjakson vahvimpina eivät välttämättä selviydy johtajat, joilla on parhaat työkalut tai suurimmat tiimit. Vahvimpia ovat ne, jotka kehittävät harkintakykyään, vaikutusvaltaansa ja ajattelunsa selkeyttä voidakseen johtaa hyvin silloin, kun kenelläkään ei ole selkeää karttaa.

Pysy mukana

Voit seurata Adam Hornerin työtä LinkedInissä. Yksilövalmennusta, ryhmäkursseja ja podcastin löydät osoitteesta The CTO Playbook. Jos olet varhaisen vaiheen teknologiajohtaja ja haluat ilmaisen viisipäiväisen sähköpostikurssin, siirry osoitteeseen Early CTO Map.

Lisää asiantuntijahaastatteluja on tulossa The CTO Clubiin!