Jeg bygger en digital AI-agent for prosjektledelse, enten jeg liker det eller ikke

Galen Low: Fordømt hvis du gjør det, og fordømt hvis du ikke gjør det. Det har vært den generelle holdningen blant prosjektledere jeg har snakket med, som tar i bruk kunstig intelligens i arbeidet sitt. Men selv om det er lett å tenke på dette som at vi bygger våre egne erstattere og sender oss selv ut i ufrivillig førtidspensjon, kan det også finnes en enorm oppside.

Faktisk kan det gi oss en plass ved bordet når grensene mellom fagområder brytes ned og tverrfunksjonelt samarbeid blir nullstilt. For å utforske dette har jeg invitert en teknisk programleder innen SaaS, som har begynt å bygge AI-agenter, hovedsakelig av nødvendighet. Hun leder alene dusinvis av programmer på tvers av et team med 130 programmerere, dataanalytikere og andre tekniske spesialister, samtidig som hun betjener over 1 000 interne interessenter.

Hun skal dele sin tilnærming til å bygge med AI, ta oss gjennom teknologistakken hun brukte til å bygge en agent for mottak og sortering, som allerede sparer 15 timer i måneden, og fortelle hvordan hun mener at det å komme seg gjennom vår siste eksistensielle krise kan føre til bedre samarbeid, fellesskap og samhold i de tverrfunksjonelle teamene våre og videre.

Håper du liker episoden.

Velkommen til Digital Project Manager-podkasten – programmet som hjelper ledere for leveranser med å jobbe smartere, levere bedre og lede teamene sine med trygghet i AI-alderen. Jeg heter Galen, og hver uke går vi inn i strategier fra den virkelige verden, nye trender, velprøvde rammeverk og en og annen krigshistorie fra prosjektfronten. Enten du styrer omfattende transformasjonsprosjekter, håndterer AI-arbeidsflyter eller bare prøver å holde kaoset under kontroll, er du på rett sted. La oss sette i gang.

I dag skal vi snakke om dette dilemmaet: å bygge AI-agenter som kan gjøre prosjektstyringsarbeidet vi pleide å gjøre selv. Vi skal se nærmere på prosessen med å bygge AI-drevne prosjektstyringsverktøy og -agenter. Vi skal diskutere hvilke følger disse agentene får for tekniske prosjektteam ledet av mennesker, og vi skal ta opp noen nokså eksistensielle spørsmål rundt karriereveien innen prosjektledelse og hvordan vi kan bevare forstanden.

Med meg i dag har jeg Alla Tarasenko, Principal Technical Program Manager hos Gusto. Alla er en menneskesentrert teknologientusiast med erfaring fra tverrgående arbeid innen områder som data og analyse, infrastruktur, maskinlæring, sikkerhet og etterlevelse. Hun har også ledet store programmer og hatt ansvar for leveranseoperasjoner i over tretten år. Hun har arbeidet innen SaaS hos selskaper som Smartsheet, NerdWallet og Gusto for å lansere helt nye produkter, koordinere plattformmigreringer på tvers av selskaper, bygge team og arbeidsflyter fra grunnen av – og nå fornye måten tekniske programledere kan bruke AI til å øke kapasiteten sin på, uten å miste delene av jobben de setter pris på.

Hun brenner for å hjelpe tverrfunksjonelle teknologiteam med å samarbeide bedre, og som tittelen på denne episoden antyder, har hun begynt å bygge AI-agenter og integrere dem i arbeidet sitt, enten hun liker det eller ikke.

Alla, tusen takk for at du er her med meg i dag.

Alla Tarasenko: Takk, Galen. Jeg er veldig takknemlig for å bli invitert, og veldig spent.

Galen Low: Det er så flott å ha deg med i podkasten. Du og jeg har fulgt hverandre på LinkedIn i godt over et år, og jeg er glad for at vi endelig fikk kontakt. Jeg tenkte: «Herregud, noe av det du gjør, er akkurat det folk som lytter til denne podkasten trenger å høre.» Nemlig de helt konkrete realitetene ved å øke kapasiteten i prosjektlederteamet ved å lene seg på AI, bygge agenter og håndtere alle de filosofiske spørsmålene som følger med.

Jeg gleder meg virkelig til å gå i dybden, og helt ærlig vet jeg at vi sannsynligvis kan havne i en rekke interessante sidespor underveis. Men for sikkerhets skyld er dette planen jeg har skissert for oss i dag. Først ville jeg legge grunnlaget ved å stille deg et stort og vanskelig spørsmål som lytterne mine gjerne vil høre ditt syn på.

Deretter vil jeg zoome ut og snakke om tre ting. For det første vil jeg snakke om utfordringene du sto overfor, som fikk deg til å kaste deg ut i AI, og hvorfor du har valgt den løsningen du har. Så vil jeg løfte på lokket og se nærmere på hvordan du gikk frem for å bygge en AI-prosjektkoordinator – ikke bare teknologistakken, men også prosessen, tilbakeslagene og kanskje motstanden fra kolleger eller til og med din egen indre monolog.

Til slutt vil jeg gjerne høre hvordan du ser for deg at teamene dine skal arbeide med AI-prosjektkoordinatorer i nær fremtid, hva det betyr for tekniske programledere som deg, og hva som må skje for å komme dit. Det høres ambisiøst ut, men hva tenker du?

Alla Tarasenko: Ja, det var mye. Ja, la oss gjøre det.

Galen Low: Greit.

Flott. La oss sette i gang. Jeg tenkte å begynne med ett stort og vanskelig spørsmål. Du har jobbet målrettet med å bygge et sett med AI-agenter og verktøy som skal hjelpe tekniske ledere med å drive sine egne prosjekter, samtidig som de holder deg organisert. Men slik jeg kjenner deg, er du svært lidenskapelig opptatt av teknisk programledelse, og du er svært menneskesentrert i måten du utøver faget på.

Så det store spørsmålet mitt er: Ved å bygge et team av agentiske prosjektledere, gjør vi oss selv overflødige?

Alla Tarasenko: Ja, jeg elsker det spørsmålet, og det er … Som du sier, det er et stort og vanskelig spørsmål, og vi kan gå i mange retninger med det. Før jeg svarer, vil jeg bare anerkjenne at jeg vet vi snakket litt om dette da vi forberedte oss, men hver gang du sier «bygge agenter», får jeg bare en følelse av: «Å, hva er det han sier?

Handler det om meg?» Det er en enorm bedragersyndromfølelse, fordi jeg tror mange av oss som ikke er ingeniører, og som har begynt å utforske dette området det siste året eller den siste måneden, føler oss som studenter og nybegynnere i et rom som er ganske nytt for oss, og der det kommer en ny oppdagelse hver dag.

Så det er vanskelig å se seg selv på den måten ennå. Jeg ville ta det opp og anerkjenne det, fordi jeg tror at på grunn av all poseringen på nettet er det langt flere som føler det slik som meg, enn de som sier: «Jeg er kongen over all AI.» Du er ikke alene om det. Når det gjelder å gjøre oss selv overflødige, hvem vet hva som kommer til å skje?

Det finnes … Jeg vil bare anerkjenne at det er mange spådommer og mange påstander om at hvis du gjør dette, kommer det til å gå bra, og hvis du gjør det, blir du liggende igjen i støvet i den vakre fremtiden. Vi kan gjette. Jeg kan ikke forutsi det, men jeg tror at AI på dette tidspunktet – som du sa, enten vi liker det eller ikke – er et verktøy vi kommer til å arbeide med. Jeg tror ikke lenger jobben min eksisterer utenfor AI, ikke innenfor det området jeg jobber i.

Når det er sagt, tror jeg min spesifikke rolle, arbeidsplassen min og typen selskaper jeg jobber med, er svært gode eksempler på områder der jeg faktisk kan bruke all hjelpen jeg kan få. La meg forklare. De siste ti årene har jeg hovedsakelig jobbet i mellomstore selskaper, la oss si mellom 500 og 3 000 personer, eller alt imellom, mens de vokser fra det ene til det andre.

Trenden jeg har observert gjennom hele karrieren, har vært å redusere antallet operasjonelle roller og personer i teknisk programledelse i disse selskapene, og la dem bare dekke overordnede operasjonelle flyter, prosessarkitektur og store programmer. I min nåværende jobb er jeg den eneste tekniske programlederen i et team på 130 personer. I en annen jobb var forholdet mer som én til tusen.

Dette eksistensielle spørsmålet – trenger vi ikke lenger, hva er det egentlig vi gjør? – har jeg gått gjennom sammen med mange andre tekniske programledere, tror jeg, lenge før vi begynte å snakke om AI. Når du er teknisk programleder for et team på 130 personer, er det så mye du skulle ønske du kunne gjøre, og så mange arbeidsflyter og mennesker du skulle ønske du kunne hjelpe.

Du vil veilede, støtte ulike prosjekter, særlig når du ser nye ledere drive prosjekter, noen ganger for første gang i livet. Du vil forbedre prosesser. Du vil bli bedre på hvordan vi måler driften. Det er så mye du vil gjøre, og du må være svært selektiv med hva du fokuserer på.

Å kunne ta oppgaver som er rutinepregede og gjentakende, som ofte opptar en stor del av dagen, og sette dem ut til AI, er genuint verdifullt. Jeg vet at dette ofte er reklamen for AI: «Hvis du bruker AI, kan du gjøre mer meningsfulle ting.» For meg stemmer det faktisk, på grunn av det ganske ekstreme forholdet mellom støtte og behov som jeg og mange andre tekniske programledere i mellomstore selskaper arbeider under.

Så ja, det er i stor grad motivasjonen min – ikke bare å holde meg oppdatert innenfor teknologien vi har nå, men også å kunne fokusere på det jeg liker: prosessarkitektur, å veilede teamene og gjøre undersøkelser, uten å måtte flytte saker fysisk fra ett Jira-brett til et annet hver uke for å sortere dem, slik jeg gjorde for bare en måned siden.

Galen Low: Jeg liker innrammingen av at vi skal bygge med AI for å utvide kapasiteten vår. Det kommer til å endre jobbene våre, og hvem vet hva som skjer med vår fortsatte relevans i denne rollen? Men å la være virker absolutt som en større risiko når det gjelder å forbli relevant, jobbsikkerhet og rollens fremtid.

Svaret er sannsynligvis ikke å unngå AI. Og misforstå meg rett, jeg tror folk som lytter – og folk flest – forstår det. Men jeg tror du har rett i dette med poseringen. Du har rett i presset om å gjøre disse tingene, enten vi liker det eller ikke. Vi føler at vi blir tvunget til det.

Det virker som om man tenker: «Hvis jeg ikke er der for å flytte Jira-sakene, mister jeg jobben. Hva skal jeg gjøre?» Men du ga nettopp en hel rekke eksempler på hva vi kan gjøre i stedet. Hva skal du gjøre i stedet for å kopiere møtereferater fra ett sted til et annet? Og det jeg virkelig liker med AI, er …

Jeg mistet nesten pusten da du nevnte forholdstallene, fordi jeg jobber i et byrå. Kanskje vi driver fire til ti prosjekter med ulik kompleksitet, men vi er tolv personer i en organisasjon på hundre eller flere. Det var som om de fleste prosjekter hadde en prosjektleder. Men når du ser på skalaen til et team på 1 000 som driver flere prosjekter, og du er den eneste, eller et team på 130 som driver flere prosjekter, og du er den eneste, blir problemene dine annerledes.

Du tenker på operasjonell effektivitet og skala med et menneskelig perspektiv. Men svaret på spørsmålet «Hvordan skal vi klare å gjøre mer?» er ikke nødvendigvis «Ansett flere slik at hvert tiende prosjekt har en prosjektleder eller programleder». Det kan være å si: «Hvordan kan vi bygge prosesser? Hvordan kan vi utforme dem? Hvordan kan vi sette folk som skal lede prosjekter, men som kanskje ikke er utdannet programledere, i stand til å lykkes? Og hvordan kan vi legge til rette for at vi kan arbeide sammen?» Da blir du mer mentor og operatør. Du trenger den tankegangen, i stedet for å tenke at en samling på tolv prosjekter er babyene mine, og det er det jeg gjør.

Det er ganske annerledes. Noen som lytter, tenker kanskje: «Duh, Galen, det er åpenbart.» Men fra min bakgrunn, der hvert komplekst prosjekt vi leverer for en kunde bør ha en svært erfaren prosjektleder som kan ha kontakt med kunden, holde alt på skinner og håndtere prosjektets egen prosess, er dette veldig annerledes enn den operasjonelle tankegangen. Jeg synes det er svært interessant.

Alla Tarasenko: Ja. Og jeg tror det viktigste er at arbeidet fortsatt må gjøres. Det er noe jeg alltid kommer tilbake til når jeg hører folk si: «Vi trenger ikke prosjektledelse fordi …» Forbindelsen, limet, eller hva du enn inkluderer i det å faktisk få arbeidet gjort på tvers av ulike ferdigheter, team og synspunkter, må fortsatt være der.

Spørsmålet er hvem som gjør det, ikke sant? Og hvilken kombinasjon av mennesker og verktøy som ender opp med å gjøre det. Hvis jeg kan gi støtte i form av «Slik kan du se hvor prosjektene står», og «Slik starter du et prosjekt», eller gi deg en enkel veiviser som produserer dokumentene vi trenger for å kunne følge opp prosjektet, kan det gi folk en form for støtte og trygghet.

Og hvis beste praksis presenteres som en faktisk arbeidsflyt, kan det også hjelpe. For meg er håpet at jeg ikke er den eneste som ser på dagen sin og tenker: «Jeg skal gjøre denne store, kule tingen, bygge noe eller møte denne personen og lage denne strategien.» I stedet ligger du begravd i en milliard småting som du ikke engang ville klart å beskrive hvis noen spurte hva du hadde gjort hele dagen – og enda mindre når det gjelder hvilken effekt eller hvilket resultat det hadde.

Det er dette jeg prøver å forstå, og slik prøver jeg å velge hvilke bruksområder jeg skal fokusere på.

Galen Low: Jeg liker det. Selv om vi zoomer litt ut, leder du en avdeling for teknisk programledelse – eller egentlig en avdeling bestående av én person – hos Gusto. Dere lager HR-programvare, men slik jeg forstår det, er dere svært fremoverlente når det gjelder AI og svært dataorienterte. Det er et svært teknisk team som utvikler disse produktene.

Det gjenspeiles i tittelen din, ikke sant? Principal Technical Program Manager. Jeg sier sikkert tittelen din feil. Beklager. Men jeg er nysgjerrig på dette forholdstallet, og kanskje er svaret åpenbart: Når ble det tydelig for deg at du måtte bygge noe med AI, som en agentisk prosjektkoordinator, for at driften skulle kunne fortsette slik du ønsket?

Alla Tarasenko: Jeg skal være ærlig, og dette leder kanskje inn i et litt annet tema. Vi snakket litt på forhånd om hvordan tankesettet ditt påvirker dette. Hvis du er en person som i problemløsningen din går mot å samle mennesker, sørge for tydelig kommunikasjon og sikre at du har riktig struktur og rammeverk, er det faktisk ikke rett frem å endre tankegangen til «Å, kan jeg automatisere dette?» eller «Er dette noe jeg kan lage?»

Jeg skal være sårbar og si det her, selv om jeg kanskje ikke burde innrømme det. Det var ikke slik at jeg hadde en stor, tydelig tanke om at jeg virkelig trengte hjelp, og at hjelpen derfor kanskje burde komme fra AI.

Det handlet mer om konkrete smertepunkter. Det største konkrete smertepunktet for meg var mottak og sortering. Da jeg begynte på teamet, hadde vi ikke et strukturert mottak og en strukturert sortering. Det var litt ad hoc. Hvert team håndterte det på sin egen måte. Derfor satte jeg sammen en mer sentralisert arbeidsflyt gjennom kanalen og Jira, med sortering to ganger i uken.

Det var svært manuelt: hente inn sakene, diskutere dem og oppdatere dem i Jira. Det tok en absurd mengde tid. Men det var en viktig prosess å gå over til, slik at vi fikk en sentralisert tankegang. Det var bare så smertefullt at så snart disse verktøyene ble tilgjengelige, tenkte jeg: «Pokker, hadde det ikke vært deilig å slippe å gjøre dette?»

Deretter fulgte en interessant oppdagelsesreise i verktøyene, og mens jeg lærte om dem, endret og modnet de seg i løpet av en kort periode på to–tre måneder. Det gjorde faktisk visjonen min mulig. Denne prosessen, som var tungvint på inn-siden – vi henviste bare folk til Jira og brukte all tiden i etterkant – drives nå i stor grad av en Gumloop-agent som kobler sammen Slack og Jira.

Det høres ganske enkelt ut når jeg forteller det, ikke sant? Men mye skal til, fordi agenten må forstå konteksten: Hvor skal sakene sendes? Vi har flere ulike fagområder innen data, og dataforskere og data plattformingeniører gjør svært forskjellige ting. Agenten må forstå hvor presserende noe er og lage saker av høy kvalitet.

Vi vil ikke bare ha dårlige saker som vi må gå tilbake til folk med for å stille flere spørsmål. Agenten må kunne opprette sakene i riktig Jira-område, og alt dette må fungere. Det bygger seg opp, og jeg var svært spesifikk på hva jeg ønsket. Jeg prøvde andre verktøy også. Jeg skal ikke si hvilke, for jeg vil ikke henge ut noen, og de er gode verktøy for andre ting, men de hadde ikke funksjonene jeg ønsket.

Så oppdaget jeg Gumloop. Jeg deltok i et kull og prøvde det ut. På den tiden var de svært fokuserte på arbeidsflyter, og jeg begynte å bygge arbeidsflyten deres. Det var vanvittig. Kompleksiteten i arbeidsflyten for å gjøre det jeg prøvde å gjøre, var ikke forsvarlig. Mens jeg strevde med den og prøvde ulike ting, deltok jeg i et nytt kull hos dem. Det var da de gikk over til agenter.

Og som de sier: Alt endret seg. Det var da jeg tenkte: «Greit, nå kan det gjøre det jeg vil.» Nå hadde jeg en agent innebygd i en arbeidsflyt. Selv da måtte jeg vente på noen flere nye funksjoner eller oppdateringer som gjorde det jeg ønsket mulig. For eksempel noe så enkelt som at folk skulle kunne stille spørsmålet i Slack uten å nevne verktøyet, for du kan ikke lære opp over 90 personer – og det er mer enn 1 000 personer i kanalen – til å nevne det hver gang.

Selv slike ting måtte på plass. Jeg så mange mennesker få den samme opplevelsen: «Jeg hadde disse ideene, men nå kan jeg faktisk gjennomføre dem.» Og jeg tror det virkelig gikk opp for meg at AI ikke kommer til å være det samme om ett år som det er nå, akkurat som det ikke var det samme da jeg begynte å jobbe med dette verktøyet som da jeg var ferdig.

Og jeg har glemt hvilket spørsmål jeg svarte på, men …

Galen Low: Nei, dette var veldig bra, fordi jeg føler at du sa tre svært viktige ting. For det første ventet du bare på dagen da du kunne automatisere sorteringsprosessen. Hvis jeg forstår deg riktig, er det 1 000 interessenter og teamet ditt i denne kanalen, som legger inn forespørsler, observasjoner, feil og all mulig informasjon som du deretter må sortere, registrere i Jira og lage en plan for å løse eller levere. Det tok selvsagt mye tid.

Det er den typen ting som får dagen til å forsvinne, uten at det er særlig tilfredsstillende. Du ventet bare på at teknologien skulle bli tilgjengelig. Det andre jeg liker, er at teknologien kom, men det første du prøvde, fungerte ikke. Du måtte gå gjennom prosessen med å møte hindringer og tenke: «Vet du hva? Kanskje dette ikke er riktig verktøy.» Teknologien gjør mye og gjør mye bra, men akkurat som med alle produkter finnes det ett som passer, og mange som ikke gjør det. Du måtte kunne si: «Greit, jeg skal ikke slå hodet mot veggen lenger. La oss se om det finnes noe annet.»

Og det tredje jeg liker, er at teknologien endrer seg og beveger seg så raskt at den på en måte reagerer på vår felles frustrasjon og ønskeliste: «Om den bare kunne gjøre dette.» Vi har alle slike smertepunkter.

Jeg ser mange som avskriver det. De sier: «Nei, beklager, ChatGPT er bare ikke god på dette. Punktum. Derfor bruker vi det andre verktøyet.» Jeg sier: «Gjett hva? Vent en uke.» Det endrer seg så raskt at du må følge med. Det du sa, er svært viktig: Uansett hvordan det er i dag, kommer det til å se helt annerledes ut om ett år.

En del av det handler om å si: «Greit, hva kan vi løse med teknologien vi har i dag?» Og så må vi nesten tegne en vei videre og huske at dette ikke kommer til å være stabilt det neste tiåret. Dette gjelder nå og de neste ti månedene. Vi kan sannsynligvis gjøre dette, og enda tidligere enn det kommer det sannsynligvis en annen måte.

Alla Tarasenko: Jeg vet at folk snakker om dette: Hvordan isolerer vi kontaktene våre fra verktøyene våre, og hvordan beskytter vi oss? Jeg vet det er en klisjé, men jeg tenker på uttrykket om å bygge et fly mens man faller, eller mens man prøver å fly. Jeg tenker på det hver dag, fordi det ligner svært på det vi gjør.

Du prøver å skape noe, samtidig som du håndterer all endringsledelsen rundt det. Vi vet alle at jeg ikke bare leker med et lite verktøy. Dette ble lansert for mer enn 1 000 personer, så folk må venne seg til det, og det må fungere godt nok. Det er alle disse tingene. Samtidig kommer den underliggende teknologien til å endre seg, og evnen din til å lære og ta inn ny informasjon kommer til å endre seg.

Du må kanskje bytte til noe annet. Det er en kontinuerlig prosess du må holde deg oppdatert på. Og jeg tror vi alle på et tidspunkt må finne ut hvordan vi kan holde hodet samlet gjennom denne syklusen. Men det er en helt annen samtale.

Galen Low: Jeg tror det er dette skiftet i tankesett og denne ferdigheten. Å bygge et fly mens du flyr det, er ferdigheten. Og uten å bruke for mange metaforer i én setning: For prosjekt- og programledere ser vi ofte rollen vår som å holde hjulene på bussen. Nå er rollen å bygge en buss. Du nevnte skiftet i tankesett. Var det et stort sprang for deg å gå fra å drive ting og sørge for at driften fungerte smidig, til å bygge ting med lansering og endringsledelse, eller gikk de hånd i hånd?

Føltes det naturlig og organisk?

Alla Tarasenko: Jeg skal være ærlig, og igjen være sårbar her for alle som lytter og kanskje føler det samme, og som trenger øyeblikket der de kan si «det er ikke bare meg». Det var vanskelig. Det var vanskelig, også rent praktisk, fordi jeg forventet at jeg måtte sette meg ned og lage denne arbeidsflyten i Gumloop, eller koble alt til koden min eller hva det nå var, og at jeg trengte uavbrutt tid. Jeg strevde i flere uker med å finne den tiden jeg følte at jeg trengte.

I ettertid innså jeg at mye av dette handlet mindre om tid og mer om utsettelse på grunn av angst – ja, eller hva man nå skal kalle det. Det handlet om å gå inn i dette rommet og si: «Greit, dette er det jeg gjør nå. Jeg kan være dårlig på det, jeg vet ikke hva jeg kan forvente, jeg vet ikke hva som kobles til hva, og jeg vet ikke hvilket miljø jeg bør være i.

Jeg vet ikke hva jeg måler meg mot. Jeg vet ikke om jeg akkurat nå gjør meg selv overflødig.» Alle disse spørsmålene veier tungt. De kan gjøre de første stegene vanskeligere. Når du først tar dem og leverer noe, får du litt fremdrift, og det blir enklere. Men også da tror jeg overgangen fra «Jeg løser dette med mennesker, arbeidsflyt eller kommunikasjon» til «Jeg løser dette ved å bygge noe» kan være ny, særlig hvis du ikke har programmert på lenge.

Jeg vet at enkelte programledere allerede har arbeidet mye med automatisering, og for dem blir overgangen sannsynligvis enklere. Men selv en liten ting, som her om dagen da jeg ba teamet om støtte til stikkprøver under en brukerakseptansetest av en migrering av en kunnskapsbase, kan endre perspektivet. Jeg tenkte at jeg trengte fageksperter til å se på materiale de kjenner, slik at de kunne vurdere om det føltes riktig.

Det første spørsmålet fra utviklingslederen var: «Hvorfor kjører vi ikke kode mot det?» Jeg bare tenkte …

Galen Low: Den andre oppgaven de ventet på å kunne automatisere, kan automatiseres nå. Ja. «Hallo, vi vil ikke gjøre brukerakseptansetesten deres. La oss bare …» Men jeg synes det er et interessant skifte i tankesett, og jeg synes det er en av fordelene ved å jobbe i en organisasjon som er fremoverlent når det gjelder AI. Teamet ditt med programmerere, ingeniører og dataforskere blir også støttet og oppmuntret til å bruke AI, høres det ut som. De får fortsatt muligheten til å skape verdi, i den grad at de faktisk foreslår det.

De sier: «La oss gjøre dette først, og la oss bruke AI i prosessen.» Å være omgitt av det skaper i det minste en følelse av tilhørighet, selv om vi alle er i samme båt på vei mot fossen. Vi er i det minste her sammen og tenker på det på samme måte.

Mange som lytter, og mange jeg snakker med, opplever ikke dette. De arbeider i organisasjoner med ulike leirer, og det er vanskelig å ha en samtale om AI fordi noen er svært motvillige. Andre er kanskje overivrige. De sier: «Ja, la oss aldri jobbe igjen. Mai Tai på stranden», og alt imellom. Kulturelt skaper det en uenighet, mens jeg liker samtalen om «Hei, la oss løse dette på denne måten». Føler du at det å bygge med AI bringer deg nærmere teamene du arbeider med, som består av programmerere og dataforskere?

Alla Tarasenko: Å, jeg elsker det spørsmålet. Jeg har ikke tenkt på det, men det tror jeg. Det er et felles mål. Gusto er også svært fremoverlent når det gjelder AI. Det er mye oppmuntring og mange ressurser for å bruke AI. Du har stor frihet til å velge verktøy og god tilgang på opplæring og støtte.

Og det er det en god grunn til. Hvis vi ønsker at all kraften i AI skal være tilgjengelig for småbedriftskundene våre – virksomheter som virkelig kan ha nytte av all hjelpen de kan få, fordi de prøver å gjøre så mye med så lite – må vi også leve etter det. Vi kan ikke gjøre det uten å ta det i bruk internt.

Det jeg liker ved at dette bringer oss nærmere teamet, er at hvis teammedlemmene også er ikke-ingeniører, går dere gjennom mange av de samme tvilene, utfordringene, læringsprosessene og gleder. Jeg har hatt mange møter og samtaler med folk der jeg har vist frem verktøyet jeg har laget, og sett på det andre har laget.

Vi har hatt demonstrasjoner, og det har vært veldig morsomt. Du blir kjent med folk på en annen måte enn bare gjennom det dere snakker om, noe jeg alltid setter pris på. Men det handler også om krysspollinering av det vi gjør. La oss for eksempel si at dataforskerteamet arbeider med et verktøy som automatiserer noen av spørsmålene og svarene rundt data. Kan vi på et tidspunkt ta det inn i måten vi håndterer mottak på, slik at enkelte spørsmål kan besvares der?

Det var bare det første eksempelet jeg kom på, men det finnes sikkert mye mer. Eller hvis vi tar mottak og sortering som eksempel: Kan vi samarbeide med ingeniører som bruker AI-verktøy til å automatisere noen av akseptansekriteriene og forberede kodearbeidet, og gjøre dette til en del av hele prosessen for opprettelse av saker?

Jeg liker at vi kan samarbeide om ulike ting på en måte som sannsynligvis ikke var mulig tidligere.

Galen Low: Jeg liker det. Det er mer samarbeidsorientert. Det er ikke slik at jeg hjelper deg med å løse problemet ditt, eller at du hjelper noen andre med deres problem. Det er vårt problem. Vi kan arbeide sammen om det og ha en slags felles forståelse.

Det handler ikke bare om prosess eller tankesett, men om å si: «Greit, la oss bygge en liten maskin.» Og det er normalt for alle å høre og forstå nå, nikke og si: «La oss gjøre det», og være begeistret fordi det faktisk gir oss muligheten til å samarbeide på en annen måte. Jeg synes det er svært interessant.

Alla Tarasenko: Jeg vil skape noe sammen, der den spesifikke vinkelen, perspektivet og ferdighetene hver av oss bidrar med, gjør det bedre. Det er noe jeg tenker ganske mye på når vi snakker om alle disse eksistensielle spørsmålene: Hva er det? Etter alle årene vi har brukt i yrket, hva er det vi bidrar med i disse samtalene?

Hva tilfører jeg dette verktøyet som en ingeniør ikke kan, eller som en prosjektleder ikke kan? Hvilken visjon har jeg, eller hvilke hull kan jeg identifisere som andre kanskje ikke ser?

Galen Low: Jeg liker det veldig godt, fordi jeg ser det publisert ofte, og jeg vet hva folk mener. Jeg prøver ikke å skape bråk, men jeg ser innlegg på LinkedIn som sier: «Som programleder er jeg aldri eksperten.»

Jeg vet hva de mener. De mener at de kanskje ikke er fageksperter på programmering eller design. Men jeg liker måten du rammer det inn på: Jeg tilfører også noe. Det jeg alltid sier, er at vi faktisk er eksperter på leveranser. Vi er eksperter på å koordinere teamarbeid og skape resultater.

Og jeg tror det er noe viktig i det. Selv i eksempelet ditt er arbeidsflyten for sortering noe du kjenner ut og inn fra alles perspektiv, fordi du har vært nødt til det. Du vet hva den innebærer, hvilke kriterier som gjelder, og hvilken informasjon som må finnes i saken før den sendes videre, slik at vi ikke sløser med noens tid. Det er dette vi tilfører samtalen.

Jeg synes det er flott at vi får fremheve det. Forhåpentligvis ser folk det på samme måte.

Alla Tarasenko: Ja. Og det er absolutt noe man ender opp med å måtte gå tilbake til: historien sin, det man har gjort og det man har bidratt med, på en annen måte enn før. Vi har alle vært på jobbintervjuer der vi snakker om at vi leverte et prosjekt, gjorde dette og hint, og at det føltes tilstrekkelig.

Jeg leverte denne store tingen, den var vellykket og i tide. Jeg gjorde det en programleder skal gjøre. Men akkurat nå er definisjonen av hva vi leverer, hva som er nok, og hvordan bidraget vårt måles, i aktiv endring. Jeg liker å være en del av den samtalen, i det minste.

Galen Low: Nettopp. Jeg tror det handler om å forbli relevant og verdifull ved å fortsette å delta i samtalen.

Alla Tarasenko: Ja. For til syvende og sist lærer vi alle sammen og finner ut av ting sammen. Vi prøver å unngå store påstander eller å late som om vi vet hva som kommer til å skje, og det er helt legitimt.

Men hvis du er prosjektleder eller en annen ikke-ingeniør som nettopp har begynt å finne ut av dette, vil jeg virkelig anbefale å være minimalistisk og fokusert. Jeg møter folk som sier: «Jeg har så lyst til å prøve dette, men jeg har ikke begynt ennå, og jeg må ta disse ti kursene. Jeg har hørt om disse ti verktøyene.» De overvelder seg selv før de har gjort noe som helst.

Ingenting slår å sette seg ned med det verktøyet du har tilgang til og bare snakke med det om hva du ønsker å gjøre.

Galen Low: Enig.

Alla Tarasenko: Så begynn med det du har. Det du lærer, vil i det minste delvis kunne brukes andre steder.

Og hvis du er på jobb og prøver å bygge noe, må du gi deg selv litt spillerom og være raus med tiden. Ikke anta at du skal bygge noe på én dag. Delene du tror kan ta lang tid, kan være latterlig raske. Selve prosessen med å lage agenten, etter at all konteksten var bygget opp over flere måneder, tok bare noen minutter.

Men å håndtere alle problemene og rette dem, særlig infrastrukturarbeidet – «Vi kan ikke opprette saker i Jira uten en tjenestekonto» – og deretter få styring og sikkerhet til å vurdere om det er tillatt, tok uker.

Hvis du gjør noe nytt, blir det forhåpentligvis enklere når du gjentar det. Infrastruktur og forståelse av miljøet vil sannsynligvis ta lengre tid enn selve frem-og-tilbake-dialogen og byggingen med AI. Alle snakker om at AI ikke er deterministisk.

Det vet vi. Jeg tror det viser seg på frustrerende måter som du ikke alltid forventer. La oss si at agenten må svare på bestemte måter. Jeg har testet den, og den fungerer hver gang. Det finnes variasjon i hvordan den svarer, men den gjør det den skal.

Så går du inn en uke senere, og den gjør noe helt annet. Hvor kom det fra? Det krever en viss zen som jeg ønsker å utvikle: «Greit, dette skjer nå. Hvordan finner vi ut av det?»

La deg selv lære, og ikke bli overveldet. Du kommer alltid til å ha frykt for å gå glipp av noe. Du vil alltid føle at alle rundt deg allerede har laget hærer av agenter og kan alt. Prøv bare å løse de bruksområdene du har foran deg, som motiverer deg. Du vil raskt se om det fungerer eller ikke, og du vil lære av det.

Og prøv å være streng med omfanget. Det er generelt et godt råd for alle som arbeider med et produkt. Ikke prøv å gjøre for mye med en gang, særlig ikke hvis verktøyet er nytt for deg.

Galen Low: Det er morsomt, fordi jeg tipper at en hel rekke utviklere som lytter, sier: «Ser dere? Tingene dere ikke tror vil ta lang tid, tar lang tid, og tingene som vi … Derfor er estimatet vårt feil. Nå forstår dere det.» Og jeg tenker: «Ja, faktisk.» Det høres riktig ut. Hele poenget med å komme i gang er nesten utformet slik at du får umiddelbar tilfredsstillelse.

«Jeg vil bygge en ting.» Chat, chat, chat. «Jeg har en ting. Jeg har et fungerende nettsted, et dokument, dette.» Og du tenker: «Wow, kult.» Men så kommer du inn i infrastruktur, styring og etterlevelse. Du bygget en svært avgrenset løsning for sortering, og så lanserte du den for 1 000 personer.

På dette tidspunktet bygger du programvare, ikke sant? Med brukere og en brukerbase. Med feil som må løses og tilkoblinger som må vedlikeholdes. Det var ikke bare «prompt, prompt, prompt, ferdig». Du har skapt noe organisk og sannsynlighetsbasert som trenger vedlikehold og vil vokse over tid.

Du blir aldri ferdig. Det er som foreldre-fellen: «Kult, ferdig. Vent, nei, jeg er ikke ferdig.» Det var bare småbarnsårene, og det er fortsatt mye igjen.

Alla Tarasenko: Det var en god sammenligning. Ja, akkurat. Det er litt som en berg-og-dal-bane.

Galen Low: Jeg lurer på om vi kan gå litt inn i teknologistakken din.

Særlig fordi folk i fellesskapet mitt av digitale prosjektledere, som er vant til å arbeide med teknologi og tekniske team, er ferdige med AI-verktøy som bare tar notater. Greit, uansett. Hvordan kobler jeg disse tingene sammen? Det som slo meg, var det du sa tidligere: Du har ikke bare et apparat du plugger inn.

Det bor ikke alt sammen på ett sted. Du har koblet sammen flere plattformer, blant annet Gumloop, Slack og Jira, og sikkert mange flere. Så langt du kan dele, kan du fortelle oss om teknologistakken, flyten og hva som kobles til hva for å få denne mottaks- og valideringsflyten til å fungere?

Alla Tarasenko: Ja. Dette er noe som er i aktiv bruk på jobben min, så jeg skal ikke gå for dypt inn i det. Men jeg tror det er ganske likt det mange selskaper gjør. Vi har tilgang til en rekke virksomhetsverktøy som Claude og OpenAI, samt mer spesialiserte nisjeverktøy som Gumloop. Vi bruker MCP med RunLayer for å koble oss til andre verktøy i miljøet vårt, som Google Drive, Jira og Slack.

På den måten er det ganske rett frem. Tidligere hadde vi litt mer kompleksitet i oppsettet og måtte gå gjennom Bedrock, AWS og så videre. Det har blitt enklere den siste tiden, og jeg tror alle ikke-ingeniører er takknemlige for det. For noe som Gumloop er oppsettet i bakgrunnen nesten latterlig enkelt: Du legger bare Jira og Slack til arbeidsområdene dine, og verktøyet opererer innenfor dem.

Jeg bruker hovedsakelig MCP-er i kodeverktøyet mitt, som er det jeg bruker mest ved siden av Gumloop. For ting som skal kjøre etter en tidsplan, bruker jeg ting som webhooks.

Galen Low: Kan du ta meg gjennom arbeidsflyten? Noe lytter i Slack og identifiserer at «Dette er en forespørsel»?

Alla Tarasenko: Ja.

Galen Low: Og hvis det ikke er tydelig nok til å kunne sorteres inn i køen, hva skjer da, og hva håndterer hva?

Alla Tarasenko: Hvis vi bruker inntaksroboten som eksempel, finnes det i Gumloop i utgangspunktet to måter å utløse den på når noen stiller et spørsmål i Slack. Den ene er å bygge den inn og nevne den, noe som er raskere. Den andre, litt mindre raske, men mer naturlige måten, er gjennom en utløser som opprettes på siden av agenten.

Du kobler til kanalen og sier at når noe blir spurt der, og du kan legge inn begrensninger som at den ikke skal reagere på roboter, skal den starte. Personen stiller spørsmålet, og roboten svarer. I vårt tilfelle er den utformet for å ha en dialog med personen, fordi vi først ønsker å hente inn informasjon, eller noen ganger omdirigere personen hvis de tror spørsmålet er til oss, men det egentlig er til IT eller noen andre.

Hvis personen ikke blir omdirigert, stiller agenten flere spørsmål. Hver gang personen svarer, utløses en ny handling i tråden tilbake til agenten. Tråden lagres slik at agenten forstår at den fortsatt er del av samme samtale, og dette går gjennom arbeidsflyten. Til slutt ber den om bekreftelse.

Den forteller hvilket team saken skal sendes til, og etter bekreftelsen oppretter den en sak i Jira ved hjelp av Jira MCP og en tjenestekonto. Det er alltid én generell konto som oppretter sakene, men den kan fortsatt bruke verktøyene i Jira til å erstatte tjenestekontoens navn med navnet til personen. Det er bra av sikkerhetsmessige og andre grunner.

Det er både latterlig enkelt og imponerende, fordi den gjør bestemte ting svært godt, selv om den av og til har frustrerende problemer. Hvis en person for eksempel stiller to spørsmål etter hverandre, kan den noen ganger svare to ganger.

Galen Low: Nettopp.

Alla Tarasenko: Vi har prøvd ti ulike måter å løse dette på med arbeidsflyter, og det skjer fortsatt. Vi arbeider aktivt med det nå. Men noen ganger hopper flere personer inn i en tråd og har en samtale, og agenten håndterer det med en slik eleganse. Da tenker jeg: «Jeg er så stolt.»

Galen Low: En stolt forelder. Du tenker: «Se på deg, som håndterer alt dette komplekse språket og all kontorpolitikken.» Men alt skjer i denne Slack-tråden, noe jeg liker, fordi det er der arbeidet skjer og spørsmålet blir stilt. Når ser et menneske det neste gang?

Med andre ord: Saken er opprettet i Jira, tjenestekontoen er registrert, navnet til den som sendte inn saken, er på plass, og konteksten er allerede med. Agenten husker samtalen og har klart å hente inn mer informasjon. Gjør den sorteringen? Bestemmer den hvor presserende noe er, eller går det til et menneske – til deg – som skal si: «Hei, er dette nivå én, to eller tre? Jeg tror det er nivå tre. Hva tenker du?» Eller bare fortsetter den?

Alla Tarasenko: Det er et godt spørsmål. Den foreslår hvor presserende saken er på grunnlag av samtalen. Det er noe av det vi prøver å hente ut, blant annet hvilke forretningsmessige omstendigheter som gjelder. Men denne versjonen er spesifikt utformet for ikke å tildele saker på individnivå, bare på teamnivå.

Vi har flere fagområder innen data. Derfor handler beslutningen her om hvilket fagområde saken skal sendes til. Innenfor fagområdet har teamet en egen prosess for gjennomgang av etterslepet, eller noe lignende, der de tildeler saken og fører den videre. Det jeg ser på nå, er om dette skjer effektivt, og hvordan jeg kan hjelpe teamene med neste steg: Håndterer vi sakene i tide?

Har vi noe som blir hengende? Akkurat nå har jeg satt i gang et skript gjennom Claude Code som én gang i uken sender et sammendrag av hvilke saker som har kommende frister, hvor mange som er registrert, og hvor mange som har vært der i mer enn en uke. Nå skal jeg prøve å gjøre dette mer handlingsrettet.

I stedet for bare å ha en liste med statistikk og måltall for sakene, hvordan kan jeg få agenten til å foreslå noe, for eksempel å sende en direkte melding til lederne for de aktuelle teamene og si: «Hva med å gjøre dette med den saken og det med den andre?»

Galen Low: Ja. Her er det jeg generelt anbefaler at du gjør i dag. Et lite dytt.

Alla Tarasenko: Ja. Men det er mye som kan gjøres med dette verktøyet. Jeg har et veikart for fremtidige versjoner og for hvordan det kan bli mer nyttig, kanskje ved å håndtere flere spørsmål direkte uten at det er nødvendig å opprette saker i det hele tatt, og ved å gjøre rutingen mer presis – ikke bare på teamnivå, men også på underteamnivå og nivået under der igjen.

Det er mye å utforske. Men igjen: Vær streng med omfanget. Slik kan du få en fordel før du prøver å få enda flere fordeler.

Galen Low: Fortell meg om fordelene. Jeg vet ikke om dette er riktig mål, men hvor mye tid tror du at du sparer på dette? Eller hvordan måler du egentlig fordelen akkurat nå?

Og hvor dypt går kaninhullet når det gjelder produktivitet, effektivitet og at folk får gjøre ting de liker? Fortell meg om fordelene.

Alla Tarasenko: Herregud, det er et kjempegodt spørsmål. Og helt ærlig er det noe mange av oss kunne blitt mye bedre på: Hvordan måler vi dette?

For akkurat dette målte jeg omtrent hvor mye tid vi brukte på sorteringsmøter og manuelt arbeid. Det ble rundt 15–17 timer i måneden. Målet er å få det ned mot null. Vi er ikke helt der, fordi jeg fortsatt følger opp flyten og retter feil og slikt, men det er definitivt mye lettere.

En annen måte jeg måler suksessen på, er at jeg et par ganger i året gjennomfører holdningsundersøkelser om hvordan det er for våre felles interessenter å bruke Dataworks, altså de som bruker systemet vårt mye. I tillegg gjennomfører jeg interne undersøkelser av typen retrospektiv for sorteringsgruppen.

Galen Low: Det er morsomt, for vi snakket om et avgrenset omfang, og jeg sa: «Ja, du har valgt et svært avgrenset omfang.» Likevel slår det meg at du faktisk driver en liten produktvirksomhet, ikke sant? Du sender ut NPS-undersøkelser til kundene dine. Du har et veikart. Og selv om dette bare var en del av det du og teamet ditt gjør, er det for det første en svært grundig del, og for det andre er tidsbesparelsen betydelig.

Og jeg antar … Er det 15–17 timer per person som er involvert i løpet av en måned?

Alla Tarasenko: Nei, totalt.

Galen Low: Å, greit. Jeg tenkte: «Det er vilt.» Det er fortsatt en enorm forbedring.

Alla Tarasenko: Holdningen betyr også noe. Det er forskjell på å samhandle med en hjelpsom robot som leder deg gjennom prosessen, og bare å få en lenke til et skjema.

Folk kan ha problemer som: «Vi vet aldri hvor skjemaet havnet, eller hva som skjedde.» Her kan de i stedet få beskjed: «Her er saken din. La oss følge den opp.» Så brukerens opplevelse betyr noe, og da kommer vi inn på hvordan man måler dette generelt.

Jeg liker virkelig det du sa om at selv en liten agent som kutter 15 arbeidstimer, fortsatt er et lite produkt. Hvordan håndterer du lanseringen, kommunikasjonen og endringsledelsen rundt den? Hva skjer videre? Skal den vedlikeholdes? Skal du bidra mer til den? Hvem skal eie den? Og kanskje viktigst: Hvordan tar du på deg en tydeligere produkteierrolle?

Dette er noe jeg alltid har ment sterkt om. Hvis du arbeider med programledelse og drift – og i selskapstypene jeg har jobbet med, var de to ofte overlappende eller noe man gjorde samtidig – ønsker du nesten å lage prosesser med samme tilnærming som en produktleder. Du vil forstå hvor hullene er og hvordan du kan løse dem, i stedet for bare å lage løsninger basert på din egen idé om hvordan noe bør være.

Når vi i større grad går over til AI-drevne løsninger, blir dette enda tydeligere. Selv om du ikke tenkte slik tidligere, kommer du til å gjøre det nå. Jeg har begynt å bygge enkelte deler av støtten for programledelse som vi snakket om: oppstarten, dokumentene, verktøyene for å sende rapporter og for å hente informasjon fra arbeidsstyringsverktøyet.

Mens jeg holdt på med dette, innså jeg at jeg nå vil gå til teamet og menneskene, særlig folk som er nye i å lede et prosjekt, og finne ut om dette er nyttig. Eller enda viktigere: Hva er de største problemene deres? Du har for første gang blitt bedt om å være ansvarlig eller lede et program alene, så du er både ingeniør, produktleder og prosjektleder i én person for dette initiativet.

Hva tar knekken på deg? Hva holder deg våken om natten? Og er det noe jeg kan hjelpe med? Er det noe verktøyene kan hjelpe med? Jeg begynner en slik læringsrunde neste uke, og den vil påvirke mye av det som skjer med resten av disse agentene.

Galen Low: Med min definisjon av agentisk AI, sammenlignet med det jeg ser at folk tillater seg å kalle en agent, er det du gjør agentisk, proaktiv AI.

Den går inn, tar beslutninger og venter ikke på en melding. Det er derfor den for det første er svært effektiv, og for det andre en opplevelse – et produkt. Det er ikke bare en samtale, men mekanismer, kriterier og dine egne algoritmer som er bygget inn i den.

Og når vi går tilbake til det du sa i begynnelsen om hva jeg bidrar med som programleder, driftsansvarlig eller til og med produktperson, er noe av svaret nettopp dette: Evnen til å si «La oss undersøke brukerne. La oss forstå kravene. La oss prioritere kravene. La oss lage et veikart. La oss sende ut holdningsundersøkelser fra tid til annen.»

Den forståelsen av hvordan man lanserer noe eller leder endring, er noe vi tilfører, og den gjør det vi bygger, mer vellykket.

Jeg har snakket med folk som sier: «Jeg våknet en dag og innså at jeg hadde 700 funksjoner i skyen.» Jeg tenkte: «Jeg vet ikke engang hva de fleste av dem gjør.» Bygg en ting, kom til steg to, greit, jeg tror vi er ferdige, la oss gå videre til en annen ting.

Det er noe annet enn å ha dybden til å lansere noe, få tilbakemeldinger og forbedre det kontinuerlig. Jeg tror denne forståelsen er svært viktig når man bygger med AI.

Alla Tarasenko: Jeg liker at du nevnte endringsledelse. Jeg har tenkt mer og mer på at dette sannsynligvis blir en av de viktigste ferdighetene og rollene for oss.

Med AI finnes det både en forventning om å bevege seg raskt, eksperimentere og lansere ting som de er, og dette blir allerede overveldende for mange. Den ikke-deterministiske naturen til det som leveres, skaper enda et lag med kaos.

Det du leverer, kommer med mange fordeler, men også mye kaos og forvirring. Du må fortsatt drive endringsledelse og forstå hvor viktig det er, men selve aktivitetene du gjør, må kanskje endres. Kanskje endringen ikke bare handler om mer kommunikasjon, men om mer empatisk kommunikasjon, i mangel av et bedre ord.

Jo raskere informasjonen, robotene og samtalene beveger seg, desto mer savner vi et lite innslag av menneskelighet midt i det hele. Noen som sier: «Jeg vet at dette er litt sprøtt. Det gjør alle disse gode tingene. Dette er noe vi må venne oss til og arbeide oss gjennom en stund. Jeg er her for å støtte deg på disse måtene, og fortell meg hva mer du trenger.»

Det blir svært viktig.

Galen Low: Det har ikke gått meg hus forbi at mange av AI-direktørene og AI-sjefene jeg kjenner, har bakgrunn fra markedsføring. Ikke bare det å selge noe, men å forstå behov og levere og pakke inn noe på en empatisk måte som fokuserer på fordelene for mennesker. Jeg tror du har rett.

Og i høy hastighet er det dette som blir verdifullt. Vi kan skape så mye, men det er ikke nødvendigvis de beste ideene som kommer gjennom. Det er ideene folk faktisk bruker. Endringsledelsen må være empatisk og menneskelig, men også rask. Ellers bygger du noe på en uke, og så bruker noen 17 uker på å ta det i bruk. Det er sannsynligvis ikke det de fleste organisasjoner eller utviklere håper på.

Alla Tarasenko: Jeg ser dette innlegget, og jeg er sikker på at du også har sett det, om at AI om noen måneder vil kunne gjøre alt menneskene gjør, og at ingen lenger trenger å gjøre jobbene sine.

Uavhengig av om påstanden stemmer, tror jeg den store mangelen i samtalen er: Hva med innføringen? Innføringen går aldri like raskt som teknologien. Det gjelder på makronivå, men også internt i selskapet, enten det er verktøyet ditt eller noe annet.

Hvordan gjør du det enkelt å ta i bruk? Hvordan gjør du det slik at endringsledelsen kan begrenses? Hvis folk får mange verktøy og enormt mye kommunikasjon mot seg, kan det nesten virke mot sin hensikt i stedet for å hjelpe. Det er noe vi alle må finne ut av, men det er fascinerende å tenke på.

Galen Low: Den enkle løsningen er å kvitte seg med menneskene. Nei, jeg bare tuller. Kanskje dette er et godt sted å runde av. Takk for at du gikk så dypt inn i arbeidsflyten for sortering. Jeg vet at du utforsker hvordan du kan støtte ikke-prosjektledere i teamet ditt, altså de som blir utpekt til en rolle, og hva du kan gjøre for å hjelpe dem.

Jeg lurer på hva visjonen er for teamets fremtid. Hvordan ser det ut? Hvordan skal menneskene i teamet arbeide med AI og, i praksis, AI-kolleger? Og når blir AI-kompetanse avgjørende, hvis den ikke allerede er det?

Alla Tarasenko: Det er et godt spørsmål, og jeg tenker mye på dette.

Jeg tror vi alle gjør det. AI-kompetanse er allerede en stor del av rollene våre. Da vi begynte å snakke, nevnte du at det blir tatt valg. Jeg skrev nylig på LinkedIn at valget for meg ikke er om jeg skal gjøre arbeidet med AI eller uten AI. Valget er om jeg skal gjøre arbeidet, eller om jeg skal bo på en buss i en skog.

Arbeidet mitt, i hvert fall innenfor området og selskapstypene jeg støtter, eksisterer ikke uten AI lenger.

Og selv om jeg på en eller annen måte fant et selskap der AI ikke ble brukt, ville jeg vært lite attraktiv på arbeidsmarkedet etter at de hadde sagt meg opp.

Galen Low: Ja. Ja.

Alla Tarasenko: Dette betyr ikke at vi tvinger frem AI, men sannheten er at alle bruker AI i en eller annen grad. Det er i praksis universelt, og det kommer til å fortsette slik.

Det som gjør meg litt usikker når du spør hvordan fremtiden vil se ut, er at ting endrer seg så raskt. Vi snakker ikke om år, men om måneder og uker mellom det som ikke var mulig og det som nå er mulig. Jeg sliter med å forestille meg hvordan ting kommer til å se ut om ett år.

Forutsatt at vi fortsatt arbeider sammen, tror jeg det kommer til å bli mye mer krysspollinering. Det positive bildet jeg prøver å se for meg, er at vi får mange genuint nyttige verktøy som tar seg av mye irriterende arbeid, slik at vi kan lene oss tilbake og gjøre mer meningsfull strategisk tenkning, ha samtaler og samordne oss på tvers av team, ferdigheter og fagområder.

Jeg synes det alltid er interessant når mennesker med ulike perspektiver møtes, enten det skyldes jobbene de har eller noe annet. Da blir det mulig å koble sammen punkter som vanligvis ikke er koblet. Som mennesker som arbeider sammen, har vi ofte ikke rom til å gjøre dette kreativt.

Hvis vi kan skape dette rommet og etablere en vane for å diskutere ting sammen som løsninger, uavhengig av rollene våre, ville det vært fantastisk. Men vi får se. Jeg liker å være en forsiktig optimist, men akkurat nå prøver jeg egentlig bare å ta én dag av gangen, lære og knytte kontakt med folk.

Galen Low: Det er ærlig talt et forfriskende optimistisk og logisk syn. Vi spesialiserer oss av nødvendighet fordi vi ikke kan vite alt. Men jeg tror det har skapt mange siloer i arbeidet vårt. Du går ut av siloen og tenker: «Det er ikke mitt problem.»

Det er Als problem å levere en ting, eller noen andres problem å teste dataene. Nå har vi muligheten til å bryte ned siloene, samarbeide mer og snakke sammen, i stedet for å arbeide hver for oss, flytte saker fra ett sted til et annet og spørre om de er ferdige.

Ideelt sett er det dette som forsvinner, og vi begynner å samhandle mer. Vi får et felles språk og en felles forståelse. Det er nesten umulig å vite alt, men det er fortsatt mulig å lære mer og få hjelp av AI til å komme litt lenger.

Jeg liker tanken på at dette bringer oss nærmere hverandre og gjør at vi snakker mer. Vi ser ofte ordet «strategisk» brukt litt for mye, men jeg tror det er riktig: Vi kan planlegge og ta beslutninger sammen, med mer kunnskap om hva de andre gjør, slik at vi kan gå videre med de beste ideene. AI kommer til å være der, og det kan hjelpe oss å bli bedre til å arbeide sammen.

Jeg vet ikke om det er der jeg vil avslutte.

Alla Tarasenko: Det vet ikke jeg heller. Vi trodde sosiale medier skulle hjelpe oss å komme nærmere hverandre. Vi vet hvordan det endte. Men …

Galen Low: Bare vent til menneskene ødelegger noe som er bra.

Alla Tarasenko: Jeg liker å ha et forsiktig, optimistisk syn. Selvfølgelig har jeg mange andre visjoner i hodet også, slik mange av oss har. De kommer opp i mange samtaler med bransjen og kolleger, og folk har mange bekymringer og frykter.

Men vi får bare fortsette, lære og prøve å støtte hverandre, særlig i en tid med usikkerhet og endring, noe jeg har opplevd før. Jeg var ganske liten da Sovjetunionen brøt sammen. Det var en interessant lekse i hvordan ting kan falle fra hverandre under føttene på deg.

Det er ikke helt det samme, men merkelig nok tenker jeg ofte på det nå. Jeg tror mestringsmekanismen vår alltid var fellesskap og det å komme nærmere andre mennesker som var i samme båt. Jeg tror jeg heller mot det samme nå.

Galen Low: Jeg liker det. Selv om du ikke ønsket å trekke parallellene direkte, tror jeg mennesker generelt har vist motstandskraft gjennom ting som bryter sammen under oss. Jeg elsker tanken på at det er fellesskapet som holder oss sammen og hindrer oss i å falle.

Fantastisk. Alla, tusen takk for dette. Det har vært så morsomt. Du har hatt et par perioder der du har publisert hver dag på LinkedIn, noe jeg både beundrer og er imponert over. Hvis folk vil lære mer om deg, hvor kan de gå?

Alla Tarasenko: De bør gå til LinkedIn. Det er egentlig der jeg er. Jeg fjernet alle andre sosiale medier for å ta vare på den mentale helsen min, men jeg er fortsatt på LinkedIn, noe som er litt selvmotsigende. Navnet mitt på LinkedIn er Alla Tara, og så Senko i parentes. Jeg gjennomfører en utfordring i mai der jeg legger ut et innlegg hver dag. Det er litt krevende, fordi jeg faktisk glemte å publisere i går. Det trenger vi ikke snakke om.

Galen Low: Nå som vi vet at du er én teknisk programleder i et team på 130, med tusenvis av interessenter i Slack, er alt tilgitt.

Alla Tarasenko: Jeg liker å komme i kontakt med andre som arbeider med drift og programledelse, og jeg liker å møte nye mennesker, ta en kaffe og se hvordan alle har det i disse sprø tidene.

Galen Low: Flott. Jeg liker det. Jeg legger også en lenke til profilen din i shownotatene. Takk igjen. Takk for at du deler kunnskapen din, for at du er så ydmyk og menneskelig. Jeg lærte mye, og jeg håper lytterne mine gjør det samme.

Alla Tarasenko: Tusen takk, Galen. Takk for invitasjonen. Dette har vært en veldig, veldig morsom opplevelse.

Galen Low: Greit, folkens. Det var alt for dagens episode av Digital Project Manager-podkasten. Hvis du likte denne samtalen, må du abonnere der du lytter. Hvis du vil ha enda flere praktiske innsikter, casestudier og arbeidsbøker, kan du opprette en gratis konto hos thedigitalprojectmanager.com.

Til neste gang: Takk for at du lyttet.