Jeg bygger en digital AI-agent til projektledelse, uanset om jeg vil det eller ej

Galen Low: Fordømt, hvis du gør det, og fordømt, hvis du ikke gør det. Det har været den generelle holdning blandt de projektledere, jeg har talt med, som tager AI i brug i deres arbejde. Men selv om det er let at se det som en måde at bygge vores afløsere på og sende os selv på ufrivillig førtidspension, kan der være en massiv fordel ved det hele.

Faktisk kan det give os en plads ved bordet, mens murene mellem fagområder bryder sammen, og tværfagligt samarbejde bliver nulstillet. For at udforske det har jeg inviteret en teknisk programleder fra SaaS-verdenen, som er begyndt at bygge AI-agenter, primært af nødvendighed, eftersom hun som den eneste leder dusinvis af programmer på tværs af et team med 130 programmører, dataanalytikere og andre tekniske specialister, samtidig med at hun understøtter mere end 1.000 interne interessenter.

Hun vil fortælle om sin tilgang til at bygge med AI, tage os gennem den teknologistak, hun brugte til at bygge en agent til modtagelse og triagering, som allerede sparer 15 timer om måneden, og dele sit syn på, hvordan det at arbejde sig gennem vores seneste eksistentielle krise kan føre til bedre samarbejde, fællesskab og sammenhold i vores tværfunktionelle teams og videre endnu.

Jeg håber, du vil nyde episoden.

Velkommen til Digital Project Manager Podcast – programmet, der hjælper ledere med leverancer med at arbejde smartere, levere mere gnidningsfrit og lede deres teams med selvtillid i AI-alderen. Jeg hedder Galen, og hver uge dykker vi ned i strategier fra den virkelige verden, nye tendenser, gennemprøvede rammeværk og en lejlighedsvis beretning fra projektfrontlinjen. Uanset om du styrer massive transformationsprojekter, håndterer AI-arbejdsgange eller bare forsøger at holde kaos under kontrol, er du kommet til det rette sted. Lad os komme i gang.

I dag taler vi om dilemmaet ved at bygge AI-agenter til at udføre det projektledelsesarbejde, vi plejede at udføre. Vi skal se nærmere på processen med at bygge AI-drevne projektledelsesværktøjer og -agenter. Vi skal diskutere, hvad disse agenter betyder for menneskeledede tekniske projektteams, og vi skal tage fat på nogle mere eller mindre eksistentielle spørgsmål om karrierevejen inden for projektledelse, og hvordan vi kan bevare vores fornuft.

Med mig i dag er Alla Tarasenko, ledende teknisk programleder hos Gusto. Alla er en menneskecentreret teknologinørd med erfaring på tværs af områder som data og analyse, infrastruktur, maskinlæring, sikkerhed og compliance. Hun har også stået i spidsen for store programmer og overvåget leveranceoperationer i mere end 13 år. Hun har arbejdet i SaaS-branchen hos virksomheder som Smartsheet, NerdWallet og Gusto med at lancere helt nye produkter, koordinere virksomhedsomspændende platformsmigreringer, opbygge teams og arbejdsgange fra bunden og nu nytænke, hvordan tekniske programledere kan bruge AI til at øge deres kapacitet uden at miste de dele af jobbet, de holder af.

Hun er fortaler for at hjælpe tværfunktionelle teknologiteams med at arbejde bedre sammen, og som titlen på denne episode antyder, er hun begyndt at bygge AI-agenter og integrere dem i sin drift, uanset om hun vil det eller ej.

Alla, mange tak, fordi du er med i dag.

Alla Tarasenko: Tak, Galen. Jeg er meget taknemmelig for invitationen og meget begejstret.

Galen Low: Det er så fedt at have dig med i podcasten. Du og jeg har krydset hinandens veje på LinkedIn i størstedelen af et år, og jeg er glad for, at det endelig lykkedes os at få kontakt. Jeg tænkte: "Hold da op, noget af det, du laver, er præcis det, som nogle af dem, der lytter til denne podcast, har brug for at høre." Nemlig de helt konkrete realiteter ved at øge et projektledelsesteams kapacitet ved at læne sig op ad AI, bygge agenter og håndtere alle de filosofiske spørgsmål, der følger med.

Jeg glæder mig virkelig til at dykke ned i det, og helt ærligt ved jeg, at vi sikkert kan ende i alle mulige interessante afstikkere undervejs. Men for en sikkerheds skyld får du her den køreplan, jeg har skitseret for os i dag. Til at begynde med ville jeg sætte scenen ved at stille dig et stort og vanskeligt spørgsmål, som mine lyttere gerne vil høre dit syn på.

Derefter vil jeg gerne zoome ud og måske tale om tre ting. For det første vil jeg tale om de udfordringer, du stod over for, som fik dig til at kaste dig hovedkulds ud i AI, og hvorfor du har grebet løsningen an på den måde, du har. Derefter vil jeg gerne løfte låget på din tilgang til at bygge en AI-projektkoordinator – ikke bare teknologistakken, men også processen, tilbageslagene og måske modstanden fra kolleger eller endda din egen indre monolog.

Og til sidst vil jeg gerne høre dit syn på, hvordan du forestiller dig, at dine teams kommer til at arbejde med AI-projektkoordinatorer i den nærmeste fremtid, hvad det betyder for TPM'er som dig selv, og hvad der skal til for at nå dertil. Det lyder ambitiøst, men hvad siger du til det?

Alla Tarasenko: Ja, det er meget. Lad os gøre det.

Galen Low: Fint.

Lad os gå i gang. Jeg tænkte, at jeg ville begynde med ét stort og vanskeligt spørgsmål. Du har målrettet bygget en række AI-agenter og værktøjer, der skal hjælpe tekniske ledere med at drive deres egne projekter og samtidig holde dig organiseret. Men sådan som jeg kender dig, er du meget passioneret omkring teknisk programledelse, og du har en meget menneskecentreret tilgang til dit fag.

Så mit store spørgsmål er: Når vi bygger et team af agentiske projektledere til os selv, arbejder vi så ikke os selv ud af et job?

Alla Tarasenko: Ja, jeg elsker det spørgsmål, og det er … Som du siger, er det så stort og vanskeligt, og vi kan gå i mange forskellige retninger med det. Før jeg svarer, vil jeg dog gerne anerkende, at vi talte lidt om det under forberedelserne, men hver gang du siger "bygge agenter", får jeg bare følelsen: "Åh nej, hvad er det, han siger? Er det om mig?" Der er et kæmpe bedragersyndrom i gang, fordi jeg tror, at mange af os, som ikke er ingeniører og først er begyndt at bevæge os ind på dette område inden for den seneste måned eller det seneste år, føler os meget som studerende og lærende mennesker, der befinder sig i et område, som er forholdsvis nyt for os, og hvor der kommer en ny opdagelse hver dag.

Så det er svært endnu at se sig selv i det lys. Og jeg ville gerne nævne det og anerkende det, fordi jeg tror, at med al den poseren online er der langt flere, der føler som mig, end dem, der siger: "Jeg er nærmest AI's konge," og du er ikke alene om det. Hvad angår spørgsmålet om, hvorvidt vi arbejder os selv ud af vores job, hvem ved, hvad der kommer til at ske?

Der er … Jeg vil bare anerkende, at der er mange forudsigelser, og at der er mange, der siger, at hvis du gør dette, skal det nok gå, og hvis du gør hint, bliver du efterladt i støvet af den smukke fremtid. Vi kan gætte. Jeg kan ikke forudsige det, men jeg tror på, at AI på dette tidspunkt – som du siger, uanset om man vil det eller ej – er et værktøj, vi kommer til at arbejde med, og jeg tror ikke længere, at mit job eksisterer uden for AI, ikke inden for det område, jeg arbejder i.

Når det er sagt, tror jeg, at min specifikke rolle, mit arbejdssted og den type virksomheder, jeg arbejder med, er meget gode eksempler på steder, hvor jeg faktisk kan bruge al den hjælp, jeg kan få. Lad mig forklare, hvad jeg mener. I de seneste cirka 10 år har jeg primært arbejdet i mellemstore virksomheder, lad os sige 500 til 3.000 medarbejdere eller alt derimellem, hvor virksomhederne er vokset fra det ene til det andet.

Den tendens, jeg i hvert fald har observeret gennem min karriere, har hele tiden været at reducere antallet af drifts- og TPM-lignende personer i virksomhederne og kun lade dem dække overordnede driftsflow, procesarkitektur og større programmer. I mit nuværende job er jeg den eneste TPM i et team på 130 personer. I et andet job var forholdet mere sådan én til 1.000.

Så dette eksistentielle spørgsmål om, hvorvidt der ikke længere er brug for os, og hvad vi overhovedet laver, har jeg gennemgået sammen med mange andre TPM'er, formoder jeg, i meget længere tid, end vi har talt om AI. Når du er TPM og understøtter et team på 130 personer, er der så meget, du gerne vil kunne gøre, og så mange arbejdsgange og mennesker, du gerne vil kunne hjælpe.

Du vil gerne coache, støtte forskellige projekter, især når du ser nye ledere drive projekter, nogle gange for første gang i deres liv. Du vil forbedre processer. Du vil blive bedre til at måle vores drift. Der er så meget, du gerne vil, og du er nødt til at være meget selektiv med hensyn til, hvad du fokuserer på.

Og hvis du i det mindste kan tage de opgaver, der er rutineprægede og gentagende, og som har en tendens til at optage en stor del af dagen, og overlade dem til AI, så er det oprigtigt noget, jeg ved, ofte bruges som reklame for AI: "Hvis du bruger AI, kan du lave mere meningsfulde ting i stedet." For mig er det faktisk sandt på grund af det vilde forhold mellem støttebehov og ressourcer, som jeg og mange andre TPM'er i mellemstore virksomheder arbejder under.

Så ja, det er i høj grad min motivation – ikke bare at holde mig ajour med den teknologiske udvikling, vi befinder os i lige nu, men også at kunne fokusere på de ting, jeg elsker: procesarkitektur, at coache teams og udforske muligheder, uden at skulle gøre noget som fysisk at flytte sager fra ét Jira-board til et andet hver uge, så vi kan triagere dem, hvilket jeg gjorde indtil for en måned siden.

Galen Low: Jeg kan godt lide den måde, du indrammer det på: Ja, vi kommer til at bygge med AI for at udvide vores kapacitet, og det kommer til at ændre vores jobs. Hvem ved, hvad der sker med vores fortsatte relevans i denne rolle? Men ikke at gøre det virker bestemt som en større risiko, når det gælder om at forblive relevant, jobsikkerhed og rollens fremtid.

Svaret er nok ikke bare at undgå AI. Og misforstå mig ikke, jeg tror, at dem, der lytter, og folk generelt, forstår det, men jeg tror, du har ret i forhold til poseringen. Du har ret i forhold til presset for at gøre de her ting, uanset om vi vil det eller ej. Vi føler, at vi bliver tvunget til det.

Det virker som om, man tænker: "Hvis jeg ikke er der til at flytte Jira-sagerne, så mister jeg mit job. Hvad skal jeg så lave?" Men jeg synes, du lige gav en hel masse eksempler på, hvad vi i stedet kan lave. Hvad skal du lave i stedet for at kopiere mødereferater fra ét sted til et andet? Og det, jeg virkelig godt kan lide ved AI …

Jeg tabte næsten kæben, da du nævnte forholdstallene, fordi jeg arbejder i et bureau. Måske driver vi fire til 10 projekter med varierende kompleksitet, men vi er 12 personer i en organisation på 100 eller flere. De fleste projekter havde en projektleder. Men når man ser på skalaen af et team på 1.000, der driver flere projekter, hvor du er den eneste, eller et team på 130, der driver flere projekter, hvor du er den eneste, bliver problemstillingen anderledes.

Du tænker i operationel effektivitet og skala med et menneskeligt perspektiv. Men svaret på spørgsmålet om, hvordan vi kan nå mere, er ikke nødvendigvis: "Okay, ansæt flere mennesker, så hvert tiende projekt har en projekt- eller programleder." Det er snarere: "Hvordan kan vi bygge processer? Hvordan kan vi designe dem? Hvordan kan vi give mennesker, der skal lede projekter, mulighed for at lykkes, selv om de ikke er uddannet programledere? Og hvordan kan vi indrette os, så vi kan arbejde sammen?" Så bliver du i højere grad mentor og driftsansvarlig. Du har brug for den tankegang i stedet for en samling på et dusin projekter, der er dine, og som du tager dig af.

Det er ret anderledes. Jeg ved, at nogle lyttere måske tænker: "Galen, det er da indlysende." Men med min baggrund, hvor ethvert komplekst projekt, vi leverer for en kunde, bør have en meget erfaren projektleder, som kan kommunikere med kunden, holde alt på sporet og styre projektets egen proces, er det meget anderledes end den operationelle tankegang. Jeg synes, det er virkelig interessant.

Alla Tarasenko: Ja. Og jeg tror, at det vigtigste er, at arbejdet stadig skal udføres. Det er noget, jeg altid vender tilbage til, når jeg hører folk sige: "Vi har ikke brug for projektledelse, fordi …" Forbindelsen, limen eller hvad man nu kalder det, der faktisk får arbejdet udført på tværs af forskellige kompetencer, teams og synspunkter, skal stadig være der.

Spørgsmålet er, hvem der gør det, ikke? Og hvilken kombination af mennesker og værktøjer der ender med at gøre det. Hvis jeg kan yde støtte i form af: "Sådan kan du se, hvor projekterne står, og sådan starter du et projekt. Her er en enkel guide, som giver dig de artefakter, vi har brug for for at kunne følge det," så giver det mennesker en form for støtte og selvtillid.

Og her er nogle bedste praksisser, præsenteret som et konkret flow. Det giver folk en form for støtte og tryghed. For mig er håbet, at jeg ikke er den eneste, der ser på sin dag og tænker: "Jeg vil lave denne store, spændende ting, bygge noget eller mødes med denne person og udvikle denne strategi." Og i stedet ligger man begravet i en million småting, som man ikke engang ville kunne beskrive, hvis nogen spurgte, hvad man havde lavet hele dagen – og slet ikke med hensyn til effekt eller resultat.

Det er reduktionen af det, jeg prøver at forstå, og sådan forsøger jeg at vælge de anvendelsesområder, jeg vil fokusere på.

Galen Low: Det kan jeg godt lide. Selv hvis vi zoomer lidt ud, leder du en teknisk programledelsesafdeling på én person hos Gusto. I laver HR-software, men sådan som jeg forstår det, er I meget AI-orienterede og datafokuserede. Det er et meget teknisk team, der bygger disse produkter.

Det afspejles i din titel, ikke? Ledende teknisk programleder. Jeg har sikkert fået din titel forkert. Det må du undskylde. Men jeg er nysgerrig på forholdstallet, og måske er svaret indlysende: Hvornår stod det klart for dig, at du var nødt til at bygge noget med AI, for eksempel en agentbaseret projektkoordinator, for at driften kunne fortsætte på den måde, du ønskede?

Alla Tarasenko: Jeg vil være ærlig over for dig. Og jeg tror, det leder over i et lidt andet emne, men vi talte før om, hvordan ens tankegang ændrer sig. Hvis du er typen, der løser problemer ved at samle mennesker, sikre tydelig kommunikation og sørge for, at du har den rigtige struktur og det rigtige rammeværk og alt det gode.

At ændre sin tankegang til: "Åh, det her kan jeg automatisere" eller: "Er det noget, jeg kan skabe?" er faktisk ikke ligetil. Og igen vil jeg være sårbar og sige det her, selv om jeg nok ikke burde indrømme det. Det var ikke sådan, at jeg havde denne store åbenbaring: "Ja, jeg har virkelig brug for hjælp, så hjælpen bør måske komme fra AI."

Det handlede meget mere om specifikke smertepunkter. For mig var det store specifikke smertepunkt modtagelse og triagering. Da jeg kom ind på teamet, havde vi ikke en struktureret proces for modtagelse og triagering. Det var lidt ad hoc. Hvert team håndterede det forskelligt. Så jeg samlede et mere centraliseret flow gennem kanalen og Jira med triageringer to gange om ugen.

Det var meget manuelt: at hente sagerne, diskutere dem og opdatere dem i Jira. Det tog absurd lang tid. Men det var en vigtig proces at skifte til, så vi fik den centraliserede tankegang. Det var bare så smertefuldt, at så snart de her værktøjer blev tilgængelige, tænkte jeg: "Hold da op, ville jeg ikke gerne slippe for at gøre det her?"

Derefter fulgte en interessant opdagelsesrejse med værktøjerne, og selv mens jeg lærte om dem, ændrede og modnede teknologien sig i løbet af en kort periode på to-tre måneder. Det gjorde faktisk det, jeg forestillede mig, muligt. Denne proces var meget kluntet i indgangen: Vi henviste bare folk til Jira og brugte al tiden i bagenden. Nu bliver den i høj grad kørt af en Gumloop-agent, der forbinder Slack og Jira.

Det lyder ret ligetil, ikke? Men der er meget i det, fordi den skal forstå konteksten, for eksempel hvor sagerne skal hen. Vi har en række forskellige fagområder inden for data. Dataforskere og data platform-ingeniører laver meget forskellige ting, og agenten skal forstå graden af hast og oprette sager af høj kvalitet.

Vi vil ikke bare have dårlige sager, som vi efterfølgende skal vende tilbage til folk om for at stille flere spørgsmål. Den skal kunne oprette dem i det rigtige Jira-område og håndtere alle de andre detaljer. Det byggede sig gradvist op, og jeg var meget specifik omkring, hvad jeg ønskede. Jeg prøvede andre værktøjer. Jeg vil ikke sige hvilke, for jeg vil ikke hænge nogen ud, og det er også gode værktøjer, bare til andre ting. De havde bare ikke de funktioner, jeg ønskede.

Så opdagede jeg Gumloop. Jeg deltog i deres forløb og prøvede det af. På det tidspunkt var de meget fokuserede på arbejdsgange, og jeg begyndte at bygge deres arbejdsgang. Det var vanvittigt. Kompleksiteten i arbejdsgangen for at gøre det, jeg forsøgte at gøre, kunne ikke retfærdiggøres. Mens jeg kæmpede med det og prøvede forskellige ting, deltog jeg i endnu et forløb hos dem, og det var på det tidspunkt, de skiftede til agenter.

Som de siger: Alt ændrede sig. Det var dér, jeg tænkte: "Okay, nu kan den gøre det, jeg vil have." Nu havde jeg en agent integreret i en arbejdsgang. Selv da måtte jeg vente på et par nye funktioner eller opdateringer, der gjorde det, jeg ønskede, muligt. For eksempel noget så enkelt som at lade folk stille spørgsmålet i Slack uden at nævne værktøjet, for man kan ikke lære mere end 90 personer – og der er over 1.000 personer i kanalen – at de skal nævne det hver gang.

Så selv sådan en ting. Jeg så mange mennesker få den oplevelse: "Jeg havde de her idéer, men nu kan jeg faktisk føre dem ud i livet." Og jeg tror virkelig, der kom en erkendelse af, at AI ikke vil være det samme om et år, som det er nu, ligesom det heller ikke var det samme, da jeg begyndte at arbejde på værktøjet, som da jeg afsluttede det.

Jeg har glemt, hvilket spørgsmål jeg svarede på, men …

Galen Low: Nej, det er virkelig godt, for jeg synes, du sagde tre meget vigtige ting. For det første ventede du bare på den dag, hvor du kunne automatisere triageringsprocessen. Hvis jeg forstår dig rigtigt, er der 1.000 interessenter og dit team i denne kanal, som lægger forespørgsler, observationer, fejl og alle mulige andre oplysninger ind, som du derefter skal triagere, indtaste i Jira og lave en plan for at løse eller levere. Det tog naturligvis meget tid.

Det er den slags, der får dagen til at forsvinde, uden at det er særlig tilfredsstillende. Du ventede bare på, at teknologien skulle være klar. Den anden ting, jeg godt kan lide, er, at teknologien kom, men det første, du prøvede, var ikke det, der virkede. Du måtte igennem en proces, hvor du stødte ind i forhindringer og tænkte: "Ved du hvad? Måske er det ikke det rigtige værktøj." Teknologien kan mange ting og gør meget godt, men ligesom med ethvert produkt vil der være ét, der passer, og en hel masse, der ikke gør. Og så skal man kunne sige: "Okay, jeg bliver ikke ved med at banke hovedet mod muren. Lad os se, om der findes noget andet."

Og den tredje ting, jeg elsker, er, at teknologien ændrer sig og bevæger sig så hurtigt, at den på en måde reagerer på vores kollektive frustration og vores fælles ønskeliste: "Hvis bare den kunne gøre det her." Vi har alle de her smertepunkter.

Jeg ser mange mennesker afvise det. De siger: "Nej, ChatGPT er bare ikke god til det her. Punktum. Så vi bruger det andet værktøj." Og jeg tænker: "Gæt hvad? Vent en uge." Det ændrer sig så hurtigt, at man er nødt til at holde øje med det. Men jeg synes, det, du sagde, er vigtigt: Uanset hvad det er i dag, kommer det til at se helt anderledes ud om et år.

En del af det handler bare om at sige: "Okay, hvad kan vi løse med den teknologi, vi har i dag?" Og derefter næsten tegne en vej frem, fordi det ikke bliver den stabile tilstand i det næste årti. Det gælder nu og de næste 10 måneder, og vi kan sandsynligvis gøre dette. Endnu før det vil der formentlig være en anden måde.

Alla Tarasenko: Jeg ved, at folk taler om, hvordan vi isolerer vores arbejdsgange fra vores værktøjer, og hvordan vi beskytter os selv. Jeg ved, det er en kliché, men jeg tænker på det som at bygge et fly, mens man falder eller forsøger at flyve. Jeg tænker på det hver dag, fordi det minder meget om det, vi gør.

Man forsøger at skabe noget, og samtidig skal man håndtere alle forandringerne omkring det. Vi ved alle, at jeg ikke bare leger med et lille værktøj. Det er netop blevet rullet ud til mere end 1.000 mennesker, så folk skal vænne sig til det, og det skal fungere godt nok. Der er alle de her ting. Samtidig ændrer den underliggende teknologi sig, og din evne til at lære og optage ny information ændrer sig.

Du bliver måske nødt til at skifte til noget andet, og ja, det er bare noget, man løbende skal holde sig ajour med. Jeg tror, vi alle på et tidspunkt er nødt til at finde ud af, hvordan vi holder hovedet koldt i denne cyklus.

Galen Low: Jeg tror, det er ændringen i tankegang og den nye færdighed.

At bygge et fly, mens man flyver det, er efter min mening færdigheden. Og uden at bruge for mange metaforer i én sætning ser vi ofte vores rolle som det at holde hjulene på bussen. Nu er rollen at bygge en bus. Du nævnte ændringen i tankegang. Var det et stort spring for dig at gå fra at drive ting og sikre, at driften kørte gnidningsfrit, til at bygge ting med lancering og forandringsledelse, eller gik det hånd i hånd?

Føltes det naturligt og organisk?

Alla Tarasenko: Jeg vil være ærlig igen og være sårbar her for enhver, der måske føler det samme og gerne vil have øjeblikket, hvor man tænker: "Det er ikke kun mig." Det var svært. Det var svært, også rent logistisk, fordi jeg havde en forventning om, at jeg bare skulle sætte mig ned og skabe denne arbejdsgang i Gumloop eller forbinde alt til min kode eller hvad det nu var, og at jeg havde brug for uforstyrret tid. Jeg havde svært ved overhovedet at finde den tid i flere uger.

Set i bakspejlet indså jeg, at det handlede mindre om tid og mere om overspringshandlinger på grund af angst – ja, eller hvad man nu kalder det. Men det var svært overhovedet at træde ind i det rum og sige: "Okay, det er det her, jeg laver nu. Jeg er måske dårlig til det, jeg ved ikke engang, hvad jeg kan forvente, og jeg ved ikke, hvad der forbinder sig med hvad, eller hvilket miljø jeg bør være i."

Jeg vidste ikke, hvad jeg målte mig selv imod. Jeg vidste ikke, om jeg – som du nævnte tidligere – var i gang med at arbejde mig selv ud af mit job. Der er alle de her spørgsmål, og jeg tror, de tynger. De kan gøre de første skridt sværere. Når man først tager dem og leverer noget, får man lidt momentum, og så bliver det lettere. Men selv da tror jeg, at skiftet fra: "Jeg løser det her med mennesker, flow eller kommunikation" til: "Jeg løser det her ved at bygge noget" kan være nyt, især hvis man ikke har skrevet kode i lang tid.

Jeg ved, at der er nogle programledere, som allerede har arbejdet meget med automatisering, og for dem er skiftet nok lettere. Men selv en lille ting som den anden dag, hvor jeg bad teamet om hjælp til stikprøvekontrol under UAT af en migrering af en videnbase. Jeg tænkte, at jeg havde brug for fageksperter til at se på materiale, de kendte, så de kunne vurdere, om det føltes rigtigt.

Det første spørgsmål fra engineeringchefen var: "Hvorfor kører vi ikke bare kode mod det?" Og jeg tænkte: …

Galen Low: Den anden opgave, som de ventede på at kunne automatisere, kan automatiseres nu. Ja. "Hej, vi vil ikke lave jeres UAT. Lad os bare …" Men det er en interessant ændring i tankegang, og jeg synes, det er en af fordelene ved at arbejde i en AI-orienteret organisation. Dit team af programmører, ingeniører og dataforskere bliver også understøttet og opmuntret til at bruge AI, lyder det til, og de får stadig mulighed for at skabe værdi i en grad, hvor de faktisk foreslår det.

De siger: "Lad os gøre det her først, og lad os bruge det i processen." At være omgivet af det skaber i det mindste en følelse af tilhørsforhold, selv om vi alle befinder os i den samme båd på vej mod vandfaldet. I det mindste er vi her sammen og tænker over det på samme måde.

Jeg ved, at mange lyttere og mange af de mennesker, jeg taler med, ikke oplever det. De arbejder i en organisation med forskellige lejre, og det er svært at føre en samtale om AI, fordi nogle er meget modvillige. Andre er måske nærmest fanatiske: "Ja, lad os aldrig arbejde igen. Mojitoer på stranden." Og alt derimellem. Kulturelt skaber det en form for splittelse, mens jeg elsker samtalen: "Hey, lad os løse det på denne måde." Føler du, at det at bygge med AI bringer dig tættere på de teams, du arbejder sammen med, som består af programmører og dataforskere?

Alla Tarasenko: Jeg elsker det spørgsmål. Jeg har ikke tænkt over det på den måde, men det tror jeg faktisk. Det er ligesom et fælles mål. Gusto er også meget AI-orienteret. Der er masser af opmuntring og ressourcer til at bruge AI. Man har stor frihed med hensyn til de værktøjer, man bruger, og god adgang til træning og support.

Og det er der en god grund til. Hvis vi ønsker, at al AI's kraft skal være tilgængelig for vores små erhvervskunder, som netop er virksomheder, der kan få stor gavn af enhver hjælp, fordi de forsøger at udrette så meget med så få ressourcer, er vi også nødt til selv at leve efter det. Vi kan ikke gøre det uden at gøre det internt.

Det, jeg elsker ved at bringe teamet tættere på, er, at hvis det er teammedlemmer, som også er ikke-ingeniører, gennemgår man mange af de samme tvivlsspørgsmål, problemer, læringsprocesser og den samme begejstring. Jeg har haft adskillige møder og samtaler med folk, hvor jeg har delt det værktøj, jeg har skabt, og set på det, andre har skabt.

Vi har lavet demonstrationer, og det har været rigtig sjovt. Man lærer folk at kende på en anden måde end gennem det emne, man normalt taler om, og det nyder jeg altid. Men der er også tanken om krydsbestøvning af det, vi laver. Hvis datavidenskabsteamet for eksempel arbejder på værktøjer til at automatisere nogle af spørgsmålene og svarene om data, kan vi så på et tidspunkt bringe det ind i vores modtagelsesproces og få nogle af spørgsmålene besvaret der?

Det er bare det første eksempel, der falder mig ind, men der er sikkert mange flere. Eller hvis vi igen tager modtagelse og triagering som eksempel: Kan vi arbejde sammen med ingeniører, der bruger AI-værktøjer til at automatisere nogle af acceptkriterierne og forberede deres kodningsarbejde, så det bliver en del af hele sagsoprettelsesflowet?

Jeg kan godt lide, at vi kan arbejde sammen om forskellige ting på en måde, som nok ikke var helt mulig før.

Galen Low: Det kan jeg godt lide. Det er mere samarbejdsorienteret. Det er ikke, som om jeg hjælper dig med at løse dit problem, eller du hjælper en anden med at løse deres problem. Det er vores problem. Vi kan arbejde sammen om det og har en fælles forståelse.

Ikke kun en proces eller en tankegang, men også: "Okay, lad os bygge en lille maskine." Det er blevet normalt for alle at høre og forstå, nikke og sige: "Lad os gøre det," og være begejstrede, fordi det faktisk giver os mulighed for at arbejde sammen på en anden måde. Det synes jeg er virkelig interessant.

Alla Tarasenko: Jeg vil gerne skabe noget sammen og finde ud af, hvilken specifik vinkel, hvilket perspektiv og hvilket sæt af kompetencer hver af os bidrager med, så det bliver bedre. Det tænker jeg en del over, også når vi overvejer alle de eksistentielle spørgsmål: Hvad er det, vi bidrager med efter alle de år, vi har tilbragt i vores fag?

Hvad bidrager jeg med til dette værktøj, som en ingeniør ikke kan, eller som en projektleder ikke kan? Hvilken vision har jeg, eller hvilke mangler identificerer jeg, som de måske ikke ser?

Galen Low: Jeg elsker det, fordi jeg ser det skrevet meget på LinkedIn, og jeg ved, hvad folk mener, så jeg prøver ikke at skabe uro. Men jeg ser opslag, der siger: "Som programleder er jeg aldrig eksperten."

Jeg ved, hvad de mener. De mener, at de måske ikke er fageksperter inden for kodning eller design. Men jeg kan godt lide din måde at formulere det på: Jeg bidrager også med noget. Jeg siger altid, at vi faktisk er eksperter i leverancer. Vi er eksperter i at koordinere teamwork og skabe resultater.

Og jeg synes, der er noget vigtigt i det. Også når det gælder dit eksempel: Du kender triageringsarbejdsgangen ud og ind fra alles perspektiv, fordi du har været nødt til det. Du ved, hvad der indgår i den, hvilke kriterier der gælder, og hvilke oplysninger der skal være i sagen, før den sendes videre, så vi ikke spilder nogens tid. Det er det, vi bringer ind i samtalen.

Jeg synes, det er fedt, at vi får mulighed for at fremhæve det. Forhåbentlig ser folk det også sådan.

Alla Tarasenko: Ja. Og det er bestemt noget, man ender med at skulle genbesøge i sin historie: Hvad har man gjort, og hvad har man bidraget med, set på en anden måde end før? Vi har alle været til jobsamtaler, hvor vi taler om, at vi leverede det projekt, gjorde det og det, og at det føltes tilstrækkeligt.

Jeg leverede denne store ting. Den var vellykket og til tiden. Jeg gjorde det, en programleder skulle gøre. Men lige nu ændrer definitionen af, hvad vi leverer, hvad der er tilstrækkeligt, og hvordan vores bidrag måles, sig aktivt. Jeg vil gerne være en del af den samtale, i det mindste.

Galen Low: Netop. Det handler om næsten at forblive relevant og værdifuld ved at blive i samtalen.

Alla Tarasenko: Ja. For i sidste ende lærer vi alle sammen og finder ud af tingene sammen. Vi skal forsøge at undgå store udmeldinger eller at lade, som om vi ved, hvad der kommer til at ske, og det er helt legitimt.

Men i begyndelsen, hvis du er projektleder, der lige er startet, eller en anden ikke-ingeniør, der netop er begyndt at finde ud af det, vil jeg virkelig anbefale at være minimalistisk og fokuseret. Jeg møder folk, som siger: "Jeg vil virkelig gerne prøve at gøre det her, men jeg er ikke begyndt endnu, og jeg skal tage de her 10 kurser. Jeg har hørt om de her 10 værktøjer." De overvælder sig selv, før de overhovedet har gjort noget. Der er intet, der slår simpelthen at sætte sig ned med det værktøj, du har adgang til, og tale med det om, hvad du gerne vil gøre.

Galen Low: Det er fair.

Alla Tarasenko: Så begynd bare med det, du har. Det, du lærer, kan i det mindste delvist bruges andre steder.

Og hvis du er på arbejde og forsøger at bygge noget, så giv dig selv lidt plads og vær gavmild med tiden. Antag ikke, at du bygger noget på én dag. De dele, du tror vil tage lang tid, kan være latterligt hurtige. Selve processen med at skabe agenten og give den den store mængde kontekst, som tog måneder at opbygge, tog måske minutter.

Men så kommer alle problemerne, fejlrettelserne og især infrastrukturarbejdet. Vi kan ikke oprette sager i Jira uden en servicekonto. Derefter skal governance og sikkerhed afklare, om vi må gøre det, og så videre. Det er den del, der tog uger.

Hvis du gør noget nyt, bliver det forhåbentlig lettere, når du gentager det. Det er endnu en pointe. Infrastruktur og forståelse af miljøet tager sandsynligvis længere tid end selve dialogen og byggeriet med AI. Alle taler om, at AI ikke er deterministisk.

Det ved vi. Jeg synes, det viser sig på frustrerende måder, man ikke altid forventer. Lad os sige, at den skal svare på bestemte måder. Jeg har testet den, og den fungerer hver gang. Der er en variation i, hvordan den svarer, men den virker og gør det, den skal.

Så går du ind en uge senere, og den gør noget helt andet. Hvad kommer det fra? Der er helt sikkert en form for zen, jeg gerne vil udvikle omkring det: "Okay, nu sker det her. Hvordan finder vi ud af det?" Og hvad ellers? Ja, giv dig selv lov til at lære, og lad være med at blive overvældet.

Du vil altid have FOMO. Du vil altid føle, at alle omkring dig allerede har skabt hære af agenter og ved alt. Prøv bare at løse de anvendelsesområder, du har foran dig, og som motiverer dig. Du vil meget hurtigt se, om det virker, og du vil lære af det.

Og prøv at være … Jeg synes generelt, det er et godt råd til alle, der arbejder på et produkt: Vær streng med dit omfang. Lad være med at forsøge at gøre for meget med det samme, især hvis det er et nyt værktøj, du arbejder i.

Galen Low: Det er sjovt, for jeg tror, en masse udviklere, der lytter, tænker: "Se? De ting, som I ikke tror tager lang tid, tager lang tid, og de ting, som vi … Det er derfor, vores estimat er forkert. Nu forstår I det." Og jeg tænker: "Ja, faktisk." Det lyder rigtigt, hele den pointe. Det er interessant, for det at komme i gang er næsten designet til at føles tilfredsstillende med det samme.

Jeg vil bygge noget. Chat, chat, chat. Så har jeg noget. Jeg har en fungerende hjemmeside, et dokument eller noget andet. Og man tænker: "Wow, fedt." Men du nævnte det tidligere: Når man kommer ind i infrastruktur, governance og compliance, og man har bygget et meget snævert omfang omkring triagering, samtidig med at det er rullet ud til 1.000 mennesker, så bygger man faktisk software.

Med brugere og en brugerbase. Med fejl, der skal løses, og forbindelser, der skal vedligeholdes. Det var ikke bare prompt, prompt, prompt, færdig. Du har skabt noget organisk og probabilistisk, som kræver vedligeholdelse og vokser over tid.

Man bliver aldrig færdig. Det er ligesom forældrefælden: "Fedt, færdig. Nå nej, jeg er ikke færdig." Det var bare småbørnsårene, og der er stadig mere tilbage.

Alla Tarasenko: Det er en god sammenligning. Ja, præcis. Det er lidt af en rutsjebane.

Galen Low: Jeg spekulerer på, om vi kan dykke lidt ned i din teknologistak.

Specielt fordi folk i mit netværk af digitale projektledere, som er vant til at arbejde med teknologi og tekniske teams, siger: "Jeg er færdig med AI-notetagere." Fint nok. Hvordan forbinder jeg de her ting? Det, der slog mig, var det, du sagde tidligere: Det er ikke bare et apparat, man sætter i stikkontakten.

Det lever ikke alt sammen ét sted. Du har forbundet flere forskellige platforme, herunder Gumloop, Slack og Jira, og sandsynligvis en hel masse derimellem. Hvis du vil dele det, kan du så fortælle om teknologistakken og flowet, og hvad der forbindes med hvad for at få dette modtagelses- og valideringsflow til at fungere?

Alla Tarasenko: Ja. Det er noget, der kører live på mit arbejde, så jeg vil ikke gå for dybt ned i det. Men det er ret sammenligneligt med det, mange virksomheder gør. Vi har adgang til forskellige virksomhedsværktøjer som Claude eller OpenAI og mere specialiserede nicheværktøjer som Gumloop. Vi bruger MCP med RunLayer til at forbinde til andre værktøjer i vores miljø, såsom Google Drev, Jira og Slack.

På den måde er det ret ligetil. Vi havde lidt mere kompleksitet i den tidligere opsætning og skulle gennem Bedrock, AWS og så videre. Men det er blevet mere enkelt for nylig, og jeg tror, at alle ikke-ingeniører er taknemmelige for det. For noget som Gumloop er opsætningen i baggrunden næsten latterligt enkel. Man tilføjer bare Jira og Slack til sine områder, og det fungerer inden for dem.

Jeg bruger primært MCP'er i min kode, som er det, jeg hovedsageligt bruger ud over Gumloop. Til ting, der skal køre efter en tidsplan, bruger jeg ting som webhooks.

Galen Low: Kan du tage mig gennem arbejdsgangen? Noget lytter i Slack efter at kunne sige: "Det her er en forespørgsel."

Alla Tarasenko: Ja.

Galen Low: Og hvis det ikke er tydeligt nok til at kunne triagere den ind i køen, hvad sker der så, og hvad håndterer hvad?

Alla Tarasenko: Hvis vi tager modtagelsesbotten som eksempel, er der grundlæggende to måder at få den til at starte, når der bliver stillet et spørgsmål i Slack. Den ene er at integrere den og nævne den, hvilket er hurtigere. Den anden, som er mindre hurtig, men mere naturlig, er gennem en udløser, der oprettes ved siden af agenten.

Man forbinder den til sin kanal og siger, at når der bliver stillet noget dér, kan den starte. Man kan sætte begrænsninger som for eksempel ikke at reagere på bots. Personen stiller spørgsmålet, og botten svarer. I vores tilfælde er den designet til at føre en dialog med personen, fordi vi først vil hente nogle oplysninger eller nogle gange omdirigere personen, hvis vedkommende tror, at spørgsmålet er til os, men det i virkeligheden handler om IT eller nogen andre.

Hvis personen ikke bliver omdirigeret, stiller botten yderligere spørgsmål. Hver gang personen svarer, er der en udløser i tråden, som går tilbage til agenten. Tråden bliver registreret, så agenten forstår, at det stadig er den samme tråd, og det går gennem arbejdsgangen. Til sidst beder den om bekræftelse.

Den fortæller, hvilket team sagen bliver sendt videre til, og efter bekræftelsen opretter den en sag i Jira ved hjælp af Jira MCP og en servicekonto. Det er altid én generisk konto, der opretter sagerne, men den kan stadig bruge værktøjerne i Jira til at indsætte personens navn i stedet for servicekontoens navn, hvilket er godt af hensyn til sikkerhed og andre forhold.

Det er faktisk både latterligt ligetil og imponerende, hvad den gør. Den kan dog også have frustrerende problemer. Hvis en person for eksempel stiller to spørgsmål lige efter hinanden, kan den nogle gange svare to gange.

Galen Low: Ja.

Alla Tarasenko: Vi har prøvet 10 forskellige måder at løse det på med arbejdsgange, og det sker stadig. Det arbejder vi aktivt på lige nu. Men nogle gange springer flere mennesker ind i en tråd og har en samtale, og så håndterer den det med så stor ynde. Jeg tænker: "Jeg er så stolt."

Galen Low: Som en stolt forælder: "Se lige dig håndtere alt dette komplekse sprog og arbejdspolitik." Det hele foregår i denne Slack-tråd, hvilket jeg elsker, fordi det er dér, arbejdet foregår, og hvor spørgsmålet bliver stillet. Hvornår ser den et menneske næste gang?

Med andre ord har den oprettet Jira-sagen, servicekontoen og indsenderens navn. Den har allerede konteksten. Den husker samtalen og har kunnet indhente flere oplysninger. Laver den triageringen? Beslutter den, hvor hastende sagen er, eller går det videre til et menneske, for eksempel dig, som skal sige: "Er det her niveau et, to eller tre? Jeg tror, det er niveau tre. Hvad tænker du?" Eller kører den bare?

Alla Tarasenko: Det er et godt spørgsmål. Den foreslår en grad af hast på baggrund af samtalen. Det er en af de ting, vi forsøger at udtrække, altså hvilke forretningsmæssige omstændigheder der gør sig gældende. Men denne version er specifikt designet til ikke at lave triagering på individniveau, kun på teamniveau.

Vi har flere forskellige fagområder inden for data. Beslutningen her er derfor, hvilket fagområde sagen skal sendes til. Inden for det fagområde har teamet en proces for gennemgang af backloggen eller noget lignende, hvor de tildeler sagen og fører den videre. Det, jeg ser på nu, er, om det sker effektivt, og hvordan jeg kan hjælpe teams med det næste skridt: Håndterer vi sagerne rettidigt?

Er der noget, der hænger? Lige nu har jeg lanceret et script gennem Claude Code, som én gang om ugen sender en opsummering af, hvilke sager der har kommende deadlines, hvor mange der er oprettet, og hvor mange der har ligget der i mere end en uge. Nu vil jeg eksperimentere med, hvordan jeg kan gøre det mere handlingsorienteret.

I stedet for bare at have en liste med statistikker og målinger om sagerne, hvordan kan den så foreslå, at man sender direkte kommunikation til lederne af de pågældende teams og siger: "Hvad med at gøre dette med den sag og det med den anden?"

Galen Low: Ja. Her er, hvad jeg generelt synes, du bør gøre i dag. Et lille skub.

Alla Tarasenko: Ja. Men der er meget, man kan gøre med dette værktøj. Jeg har en køreplan for fremtidige versioner og for, hvad det kan bruges til, hvis det skal være mere hjælpsomt. Det kan måske håndtere flere spørgsmål direkte uden overhovedet at skulle oprette sager, gøre routingen mere præcis – ikke kun på teamniveau, men på underteam- og under-underteamniveau – og så videre.

Der er meget at lege med. Men igen: Vær streng med dit omfang, så du kan få en fordel, før du forsøger at få endnu flere fordele.

Galen Low: Fortæl mig om fordelene. Jeg ved ikke, om det er det rigtige mål, men hvor meget tid tror du, at du sparer? Eller hvordan måler du faktisk fordelen lige nu?

Og hvor dybt går kaninhullet med hensyn til produktivitet, effektivitet og at få folk til at lave ting, de holder af? Fortæl mig om fordelene.

Alla Tarasenko: Det er et virkelig godt spørgsmål, og helt ærligt er det noget, mange af os kunne blive meget bedre til: Hvordan måler vi det?

For netop dette målte jeg nogenlunde, hvor meget tid vi brugte på triageringsmøder og manuelt arbejde. Det endte på omkring 15-17 timer om måneden. Målet er at bringe det tæt på nul. Vi er ikke helt dér, fordi jeg stadig overvåger flowet og retter fejl, men det er bestemt meget lettere.

En anden måde, jeg måler succesen på, er, at jeg har gennemført forholdsvis regelmæssige tilfredshedsmålinger, et par gange om året, om hvordan det er for vores fælles interessenter at samarbejde med Dataworks – altså dem, der bruger vores system en del – samt interne retrospektive undersøgelser af triageringsgruppen.

Galen Low: Det er sjovt, for vi talte om et snævert omfang, og jeg sagde: "Ja, du har valgt et meget snævert område." Alligevel slår det mig, at du faktisk driver en lille produktforretning, ikke? Du sender NPS-undersøgelser ud til dine kunder. Du har en køreplan. Og selv om det bare var en del af det, du og dit team laver, er det for det første en meget dyb del, og for det andet er den sparede tid ikke ubetydelig.

Og jeg antager … Er det 15-17 timer pr. person, der er involveret, i løbet af en måned?

Alla Tarasenko: Nej, samlet set.

Galen Low: Okay, samlet set. Jeg tænkte: "Det er vildt." Men det er stadig en massiv forbedring.

Alla Tarasenko: Følelsen betyder også noget, for der er forskel på at arbejde med en hjælpsom bot, der guider dig gennem processen, og bare at blive sendt videre til en formular.

Folk havde problemer som: "Vi ved aldrig, hvor formularen endte, eller hvad der skete." Her er det i stedet: "Her er din sag. Lad os følge op på den." Så brugerens oplevelse betyder noget, og det leder os til spørgsmålet om, hvordan man generelt måler det.

Jeg kan virkelig godt lide det, du sagde om, at selv hvis man har skabt en lille agent, der sparer 15 timers arbejde, er det stadig et lille produkt. Hvordan håndterer man lanceringen og kommunikationen omkring det, forandringsledelsen og det næste, der skal ske? Er det vedligeholdelse? Skal man bidrage mere til det? Hvem ejer det? Og måske vigtigst: Hvordan indtager man i højere grad produktrollen i forhold til det?

Det har jeg altid ment stærkt, at hvis man arbejder med programledelse og drift – hvilket i de virksomheder, jeg arbejdede med, ofte var udskifteligt eller noget, man gjorde samtidig – bør man næsten angribe processer, man skaber for mennesker, som en produktleder. Man vil forstå, hvor hullerne er, og hvordan man løser dem, i stedet for bare at skabe løsninger ud fra sin egen idé om, hvordan noget bør være. Med det stigende fokus på AI-drevne løsninger bliver det endnu tydeligere.

Selv hvis du ikke tænkte sådan før, kommer du til det nu. Jeg er begyndt at bygge forskellige dele af den programledelsesstøtte, vi talte om: opstarten, artefakterne, værktøjerne til at sende rapporter og indsamle oplysninger fra arbejdshåndteringsværktøjet og den slags.

Midt i arbejdet indså jeg, at jeg nu vil gå ud til teamet og folkene, især dem, der er nye i at lede et projekt, og undersøge, om det er hjælpsomt. Eller vigtigere: Hvad er deres største problemer? De er måske for første gang blevet bedt om at være DRI eller lede et program på egen hånd, så de er både ingeniør, produktleder og projektleder i én person for dette initiativ.

Hvad dræner dem? Hvad holder dem vågne om natten? Og er det noget, jeg kan hjælpe med? Er det noget, værktøjerne kan hjælpe med? Jeg begynder på denne læringsrejse i næste uge, og den kommer til at informere meget af det, der sker med resten af de her, lad os kalde dem, agenter.

Galen Low: For at være fair er det, du gør, efter min definition af agentbaseret AI sammenlignet med det, jeg ser folk slippe af sted med at kalde en agent, agentisk, proaktiv AI.

Den går ind og træffer beslutninger. Den venter ikke på en prompt. Og jeg tror, det er det, der gør den effektiv og til en oplevelse, et produkt. Det er ikke bare en samtale. Der er mekanik, kriterier og dine egne algoritmer bygget ind i den, hvilket jeg synes er virkelig interessant.

Og hvis vi vender tilbage til det, du sagde oprindeligt om, hvad jeg bidrager med som programleder, driftsansvarlig eller produktperson, så er noget af det netop det. Det er evnen til at sige: "Lad os lave brugerundersøgelser. Lad os forstå kravene. Lad os prioritere kravene. Lad os lave en køreplan." Og: "Lad os sende nogle tilfredshedsmålinger ud en gang imellem." Forståelsen for at lancere noget og lede en forandring er noget, vi bidrager med, og det gør efter min mening de ting, vi bygger, meget mere succesfulde.

Forstå mig ikke forkert. Jeg har talt med folk, der siger: "Jeg vågnede en dag og opdagede, at jeg havde 700 cloud-færdigheder," og jeg tænkte: "Jeg ved ikke engang, hvad de fleste af dem gør." Byg en ting, kom til trin to, og så siger man: "Okay, jeg tror, vi er færdige. Lad os gå videre til noget andet."

Det er noget andet at have dybde, lancere noget, indsamle feedback og forbedre det løbende. Jeg tror, det er en meget vigtig forståelse, når man bygger med AI.

Alla Tarasenko: Jeg elsker, at du nævner forandringsledelse, for jeg tænker mere og mere, at det bliver en af de vigtigste kompetencer og roller for os.

Med AI er der både en forventning om at bevæge sig hurtigt, eksperimentere og bare rulle ting ud, som de er, og det er allerede ved at blive meget overvældende for folk. Den ikke-deterministiske karakter af det, der bliver leveret, skaber endnu et lag af kaos.

Det, man leverer, kommer med en masse fordele, men også med en masse kaos og forvirring. Man er stadig nødt til at anvende forandringsledelse og forstå dens betydning. Men de konkrete ting, man gør, kan være nødt til at ændre sig. Jeg tror næsten, de skal bevæge sig i retning af ikke bare mere kommunikation, men mere empatisk kommunikation, i mangel af et bedre ord.

Jo hurtigere informationen, botterne og samtalerne bevæger sig, desto mere mangler vi et menneskeligt element midt i det hele. En, der siger: "Jeg ved godt, at det her er lidt kaotisk. Det gør alle de her gode ting. Det er noget, vi skal vænne os til og arbejde os igennem, og jeg er her for at støtte dig på disse måder. Fortæl mig, hvad du ellers har brug for."

Det bliver meget vigtigt.

Galen Low: Det er ikke undgået min opmærksomhed, at mange af de AI-vicepræsidenter eller AI-chefer, jeg kender, har en baggrund inden for marketing. Ikke kun at sælge noget, men at forstå behov, levere og pakke noget ind på en empatisk måde, der fokuserer på fordelene for mennesker. Og jeg synes, du har ret.

I høj fart er det dét, der bliver værdifuldt. Vi kan skabe så meget, men det er ikke nødvendigvis de bedste idéer, der kommer igennem. Det er dem, folk faktisk bruger. Forandringsledelsen skal være empatisk og menneskelig, men også hurtig. Ellers bygger man noget på en uge, og så tager det 17 uger for nogen at tage det i brug. Det er nok ikke det, de fleste organisationer eller byggere håber på.

Alla Tarasenko: Jeg har set opslaget, og jeg er sikker på, at du også har set det, om at AI om nogle måneder vil kunne gøre det, alle mennesker gør, og at ingen længere vil være nødvendige i deres jobs.

Uanset om påstanden er korrekt eller ej, synes jeg, at en vigtig del mangler i samtalen: Hvad med implementering? Implementering sker aldrig lige så hurtigt som teknologien. Det gælder på makroniveau, men også i virksomheden, uanset om det er ens lille værktøj eller noget andet.

Hvordan gør man det nemt at tage i brug? Hvordan gør man det på en måde, hvor forandringsledelsen måske kan begrænses? Hvis folk får en masse værktøjer og kommunikation kastet efter sig, bliver det næsten modsat hjælpsomt. Det er noget, vi alle skal finde ud af, men det er fascinerende at tænke over.

Galen Low: Den nemme løsning er at slippe af med menneskerne. Nej, jeg laver bare sjov. Det er måske et godt sted at runde af. For det første tak, fordi du gik så dybt ned i din triageringsarbejdsgang. For det andet ved jeg, at du undersøger, hvordan du kan støtte ikke-projektledere i dit team – de DRI'er, der bliver udpeget til en rolle – og hvad du kan gøre for at hjælpe dem.

Jeg spekulerer på, hvordan visionen for dit team ser ud i fremtiden. Hvordan kommer menneskerne på dit team til at arbejde med AI og måske AI-kolleger? Og hvornår bliver deres AI-kompetence afgørende, hvis det ikke allerede er det?

Alla Tarasenko: Det er et godt spørgsmål, og jeg tænker meget over det.

Jeg tror, vi alle gør det. AI-kompetence er allerede en stor del af vores roller. Da vi begyndte at tale sammen, talte du om de valg, der bliver truffet. Jeg skrev for nylig på LinkedIn, at valget for mig ikke er, om jeg udfører arbejdet med eller uden AI. Det er, om jeg udfører arbejdet, eller om jeg flytter ind i en bus i en skov.

Mit arbejde, i hvert fald inden for det område og den type virksomheder, jeg typisk understøtter, eksisterer ikke længere uden AI.

Og selv hvis jeg på en eller anden måde fandt en virksomhed, hvor AI ikke blev brugt, ville jeg være ret uattraktiv på arbejdsmarkedet, efter at de havde fyret mig.

Galen Low: Ja.

Alla Tarasenko: Det betyder ikke, at vi tvinger AI ned over folk. Det er bare sandheden, at alle bruger AI i en eller anden grad, men det er næsten universelt, og det vil fortsætte sådan.

Det, jeg har svært ved at forestille mig, er fremtiden. Tingene ændrer sig så hurtigt, og vi taler bogstaveligt talt ikke om år, men om måneder og uger, når vi ser på, hvad der ikke var muligt, og hvad der er muligt nu. Jeg har svært ved overhovedet at forestille mig, hvordan det ser ud om et år.

Hvis vi antager, at vi stadig arbejder sammen, tror jeg, der kommer meget mere krydsbestøvning. Det positive billede, jeg forsøger at forestille mig, er, at vi får en masse virkelig nyttige værktøjer, som tager sig af en masse irriterende arbejde, så vi kan læne os tilbage og lave mere meningsfuld strategi, føre samtaler og skabe enighed på tværs af teams, kompetencer og fagområder.

Det er altid interessant, når mennesker med forskellige synspunkter mødes, uanset om det skyldes deres jobs eller noget andet. Det gør det muligt at forbinde punkter, der normalt ikke er forbundet. Som mennesker, der arbejder sammen, har vi ofte ikke plads til at gøre det kreativt. Hvis vi kan skabe plads til kreativitet og gøre det til en vane at diskutere ting sammen som løsninger, uanset vores roller, ville det være fantastisk. Men vi får se. Jeg prøver at være en forsigtig optimist, men lige nu tager jeg det mest én dag ad gangen, lærer og skaber kontakt med folk omkring mig.

Galen Low: Det er ærligt talt et meget forfriskende optimistisk og logisk syn. Når man tænker over det, specialiserer vi os af nødvendighed, fordi man ikke kan vide alt. Men det har også skabt mange siloer i vores arbejde. Når man træder ud af sin silo, tænker man: "Det er ikke mit problem." Det er Als problem at levere noget, eller en andens problem at teste data.

Nu har vi mulighed for, som du siger, at nedbryde siloerne, samarbejde mere og føre samtaler sammen. Vi kan arbejde sammen i stedet for hver for sig, i stedet for bare at kaste sager fra ét sted til et andet og spørge, om de er færdige.

Ideelt set er det dét, der forsvinder, så vi begynder at arbejde mere sammen. Vi får et fælles ordforråd og en fælles forståelse. Det er næsten umuligt at vide alt, men det er stadig muligt at lære mere og få en hjælpende hånd fra AI, der bringer dig lidt længere. Jeg kan godt lide tanken om, at det bringer os tættere sammen og får os til at tale mere.

Vi hører ofte, at vi skal være mere strategiske, men jeg tror, det er det rigtige. Vi kan planlægge og træffe beslutninger sammen, fordi vi ved mere om hinandens arbejde og kan gå videre med de bedste idéer. AI kommer til at være der og kan hjælpe os med at blive bedre til at arbejde sammen.

Jeg ved ikke, om det er dér, jeg vil slutte.

Alla Tarasenko: Det ved jeg heller ikke. Vi troede også, at sociale medier ville hjælpe os med at finde sammen. Vi ved, hvordan det endte.

Galen Low: Vi skal bare vente på, at mennesker ødelægger noget godt.

Alla Tarasenko: Jeg kan godt lide at have en forsigtig, optimistisk vision. Jeg har naturligvis også mange andre visioner i hovedet, ligesom mange af os har, og de dukker op i mange samtaler med branchen, kolleger og andre mennesker. Folk har mange bekymringer og frygt.

Men vi trasker videre og lærer, forsøger at støtte hinanden, som jeg sagde, normalt i perioder med usikkerhed og forandring, som jeg har levet i før. Jeg var barn, da Sovjetunionen brød sammen. Det var en interessant lektion i, hvordan ting kan falde sammen under ens fødder.

Det er ikke helt det samme, men jeg tænker mærkeligt ofte på det i disse dage. Vores mestringsstrategi var altid fællesskab og at komme tættere på andre mennesker, der befandt sig i den samme båd. Det hælder jeg også til nu.

Galen Low: Det kan jeg godt lide. Jeg ved, at du modsatte dig at drage parallellerne direkte, men jeg tror, at mennesker generelt – ikke alle i samme grad – har vist modstandsdygtighed gennem ting, der smuldrer under os. Jeg elsker tanken om, at det er fællesskabet, der holder os sammen og forhindrer os i alle at falde.

Fantastisk. Alla, mange tak for dette. Det har været så sjovt. Du har haft et par perioder, hvor du har slået noget op hver dag på LinkedIn, hvilket jeg både applauderer og er imponeret over. Hvis folk vil vide mere om dig, hvor kan de så finde dig?

Alla Tarasenko: De bør gå til LinkedIn. Det er virkelig dér, jeg er. Jeg har fjernet alle andre sociale medier i et forsøg på at passe på mit mentale helbred, men jeg er stadig på LinkedIn, hvilket er lidt selvmodsigende. Mit navn på LinkedIn er Alla Tara og derefter Senko i parentes. Jeg laver en udfordring med et opslag hver dag i maj, hvilket er lidt udfordrende, fordi jeg faktisk glemte at slå noget op i går. Det behøver vi ikke tale om.

Galen Low: Nu hvor vi ved, at du er én TPM i et team på 130 med tusindvis af interessenter i Slack, er alt tilgivet.

Alla Tarasenko: Jeg elsker at skabe kontakt med andre inden for drift og programledelse. Jeg kan faktisk godt lide at møde nye mennesker, drikke kaffe sammen og se, hvor alle befinder sig i disse vanvittige tider.

Galen Low: Fantastisk. Det kan jeg godt lide. Jeg inkluderer også et link til din profil i shownoterne. Og tak igen. Tak, fordi du delte din viden, fordi du var så ydmyg og menneskelig. Jeg lærte ærligt talt meget, så jeg håber, mine lyttere også gør.

Alla Tarasenko: Mange tak, Galen. Tak, fordi du inviterede mig. Det har været en virkelig, virkelig sjov oplevelse.

Galen Low: Så er det det, folkens. Det var dagens episode af Digital Project Manager Podcast. Hvis du nød denne samtale, så husk at abonnere dér, hvor du lytter. Og hvis du vil have endnu flere taktiske indsigter, cases og værktøjskasser, kan du oprette en gratis konto hos os på thedigitalprojectmanager.com.

Indtil næste gang – tak, fordi du lyttede.