Projektteams uden projektledere: En undersøgelse af projektlederdilemmaet

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle slåfejl, da robotten ikke er korrekt 100 % af tiden.

Galen Low: Selvledende projektteams. Alene den formulering er nok til at udløse en eksistentiel krise hos enhver projektleder. Men er det en trussel mod vores eksistens? Eller er det nøglen til at løfte projektlederen ind i en markant mere strategisk rolle?

Hvis du har gået og tænkt over projektledelsens fremtid, og om digitale projektledere fortsat vil være relevante, så lyt med. Vi kommer til at undersøge, hvordan én organisation med succes bygger komplekse softwareløsninger ved hjælp af distribuerede, selvledende teams, og hvad det betyder for digital projektledelse generelt.

Tak fordi du lytter med. Mit navn er Galen Low fra The Digital Project Manager. Vi er et fællesskab af digitale fagfolk med en mission om at hjælpe hinanden med at blive dygtigere, mere selvsikre og bedre forbundet, så vi kan levere projekter med formål og effekt. Hvis du vil høre mere om det, så besøg thedigitalprojectmanager.com.

Hej allesammen — tak fordi I hænger ud med os på DPM-podcasten.

Min gæst i dag er en IT-fagperson med base i Kyiv, som i over 15 år har udfordret grænserne inden for forretningsprocesledelse og digital produktledelse. Hun har været forretningsanalytiker, PMO-direktør, produktdirektør og kundesuccesdirektør og har arbejdet med brands som Heinz, Yandex, Adidas og Zyxel for at implementere virksomhedssystemer i stor skala.

I dag er hun produktchef hos Railsware, hvor hun arbejder på Coupler.io-teamet. Her superviserer hun grupper af fjernbaserede, selvledende agile teams, som skaber produkter med høj anvendelse, der nu er blevet kendte navne, såsom Calendly.

Ved siden af arbejdet underviser hun i forretningsprocesser og projektledelse på Lviv Business School og opdrager sin lille baby til at blive en del af den næste generation af kvinder inden for teknologi.

Tag godt imod Julia Ryzhkova. Hej, Julia!

Julia Ryzhkova: Hej! Hej allesammen!

Galen Low: Tak fordi du er med i dag. Tak for vores seneste samtaler. Jeg er virkelig spændt på dagens episode, fordi jeg tror, den går i dybden med noget, som vi alle er en smule selvbevidste omkring som projektledere, nemlig: Vil projektledere fortsat eksistere?

Det kommer vi ind på, men jeg tænkte, at jeg først ville spørge dig — hvordan går livet? Hvad har inspireret dig på det seneste?

Julia Ryzhkova: Det er faktisk to forskellige ting. Hvis vi taler om noget, der vedrører Railsware, så er det BRIDGeS-rammeværket. Det er en slags beslutningsramme, hvor man på et højt niveau kan beskrive sit problem og derefter omsætte det til en løsning.

Vi åbnede det for nylig, og lige nu er jeg involveret i at sprede kendskabet til det gennem mund-til-mund. Det er virkelig godt, og jeg er meget begejstret for det. Vi har udviklet det i mere end 15 år. Det her er begyndelsen på at åbne det for offentligheden, og det er virkelig inspirerende.

Fra et personligt perspektiv er jeg også involveret i det, du nævnte. Jeg arbejder med Lviv Business School, og lige nu afholder vi et offentligt onlinekursus om forretningsprocesser. Jeg håber, at det vil forbedre den generelle modenhed i Ukraines kultur omkring forretningsprocesser.

Det er også inspirerende.

Galen Low: Det elsker jeg. Begge dele er meget spændende og flotte resultater. Tillykke!

Hvis folk gerne vil lære mere om BRIDGeS-rammeværket, hvor kan de så finde det?

Julia Ryzhkova: På Railswares hjemmeside har vi et dedikeret underdomæne til det.

Galen Low: Fantastisk. Meget spændende. Og når vi optager dette, er det december. Vi er på vej ud af 2021 og ind i 2022, så jeg spekulerer på — hvad glæder du dig mest til i 2022?

Julia Ryzhkova: Alle taler i øjeblikket om kunstig intelligens og maskinlæring. For nylig havde vi et møde om vores produkters produktvisioner, og vi fik idéen at bruge kunstig intelligens i mit produkt, Coupler.io. Det glæder jeg mig virkelig til at prøve af og se, hvordan det går.

Galen Low: Så spændende.

Okay, lad os gå i gang. I dag taler vi om, hvordan små grupper af fjernbaserede agile teams kan lede sig selv og organisere sig i sværme for at skabe komplekse softwareløsninger uden på noget tidspunkt at have brug for en projektleder. Er det en trussel mod os projektledere? Er det en mulighed for, at projektledere kan blive mere strategiske? Vækker det alle vores lytteres eksistentielle angst?

Det undersøger vi i detaljer, og vi løfter virkelig låget og går i dybden.

Men først tænkte jeg, om du kunne fortælle os lidt om din egen karrierevej. Hvad er din rolle i dag, og hvordan nåede du dertil?

Julia Ryzhkova: I dag er jeg produktchef, hvilket betyder, at jeg leder produktudvikling, markedsføring, prisstrategi og salgsstyrke.

Jeg har en teknisk uddannelse, som har hjulpet mig meget inden for datalogi, men jeg kunne faktisk ikke lide at programmere. Da jeg ledte efter karrieremuligheder, søgte jeg noget, hvor man kunne skabe en algoritme og lade en anden kode den. Det var sådan, jeg blev forretningsanalytiker. Derefter udviklede jeg mine lederevner og blev teamleder for forretningsanalytikere, projektleder og chef for en afdeling for forretningsanalyse.

Men jeg bemærkede, at resultaterne af mit arbejde i høj grad afhang af det produkt, jeg arbejdede med. Derfor besluttede jeg at skifte til forskning og udvikling som produktejer og blive en del af produktet. Det var faktisk første gang, jeg følte, at jeg var det rigtige sted. Derefter voksede vores produkt, teamet voksede, vi fik flere produktejere, og jeg blev viceproduktdirektør med ansvar for halvdelen af Scrum-teamene.

Da vi allerede havde en produktdirektør, besluttede jeg — og jeg ville stadig gerne videre til ledelsen — at blive kundedirektør. Jeg fik ansvar for support og alt, der vedrørte tjenester, supportakademi og så videre. Det lykkedes mig at opbygge gode processer og skabe gode resultater.

Derfor besluttede vi at bruge disse kompetencer til at opbygge processer i andre afdelinger, og jeg blev PMO-direktør. Så kom barselsorloven. Efter at have afsluttet den vigtige periode i mit liv ville jeg tilbage til produktledelse.

Det var en vigtig beslutning, og måske undrer du dig over, hvorfor produktledelse frem for projektledelse. Det skyldes, at jeg ville fokusere på fordelene for kunderne og lade procesledelsen ligge et andet sted. For mig er det forskellen mellem produkt- og projektledelse, selv om der er mange ligheder.

Produktledere kan fokusere på produktet og kunden, mens projektledere fokuserer på en proces og dens resultater. Det er her, selvorganiserede teams bliver afgørende. Da jeg fandt Railsware og hørte og læste om virksomheden, vidste jeg, at det var et perfekt match.

Galen Low: Jeg elsker den udvikling. Jeg elsker den tekniske baggrund. Jeg elsker, at du har erfaring med kundeoplevelser og ledelse af PM-teams. Det er helt sikkert inspirerende for folk i vores branche.

Kan du fortælle lidt om Railsware, om den teamstruktur du fører tilsyn med, og måske om de typer projekter, Railsware arbejder med?

Julia Ryzhkova: Lad os begynde med projekterne, for teamstrukturen afhænger af de projekttyper, vi arbejder med. Vi er et produktstudio, hvilket betyder, at vi skaber produkter til os selv og til andre virksomheder. Hos Railsware kan vi lide at automatisere alt, og nogle gange kan vi ikke finde et værktøj på markedet, der faktisk kan udføre den del, vi har brug for.

Så beslutter vi, at vi kan udvikle noget til vores egne formål. Derefter bruger vi det, lancerer det offentligt og deler det med markedet, fordi vi ved, at vi ikke er de eneste, der har brug for det. Derfor starter vi som regel med et lille team, mens vi undersøger markedet.

Nogle gange er det endda en deltidsudvikler. Et af vores produkter, Smart Checklist for Jira, blev for eksempel udviklet på deltid af én udvikler. Først efter 50.000 i månedlig tilbagevendende omsætning besluttede vi at tildele produktet fuldtidsudviklere.

På små produkter som Coupler.io har vi ét udviklingsteam med fire eller fem udviklere og ét marketingteam med fire eller fem forskellige specialister.

Alle andre arbejder deltid, såsom dataanalytikere og supportchefer. Selv som produktchef arbejder jeg med både dette produkt og kundernes produkter. Men når et produkt vokser — som det for eksempel skete med Calendly — udvider vi udviklingsteamet og deler det derefter op i flere grupper, fordi vi mener, at det er mere effektivt at arbejde i små grupper.

Calendly har for eksempel i øjeblikket tre teams på vores side og mange udviklere på deres side. Sådan fungerer det.

Galen Low: Det er virkelig spændende. Jeg vil meget gerne gå i dybden med begreberne grupper og sværme. Jeg kan godt lide, at marketing er en gruppe. Jeg ved, at jeg tidligere fremstillede det som agile teams, men agilt betyder ikke nødvendigvis teknik eller udvikling.

Det kan betyde mange forskellige ting, hvilket vi kommer ind på. Jeg tænkte, at jeg ville spørge dig: Hvad er den største udfordring, du står over for i din rolle i dag set fra et produktudviklingsperspektiv?

Julia Ryzhkova: Jeg tror ikke, det kommer som nogen overraskelse. Den sædvanlige udfordring, som enhver produktchef har i et startup-produkt, er at finde sin guldmine på markedet.

Vi løser normalt et problem for kunden, og derfor vokser vores kundebase og vores KPI'er. Men vi vil gerne fastholde tempoet og fordoble det. Derfor skal vi finde et andet problem, som kunderne er villige til at betale dobbelt for at slippe af med.

Galen Low: I løser problemer. Det, jeg kan lide ved det, er, at det lyder som om, I løser problemer for jer selv og derefter lader løsningen sprede sig til andre, der har det samme problem. Det er lidt som et internt produkt, der bevæger sig udad. Samtidig er I også en serviceorganisation, der hjælper andre organisationer med at skabe deres drømmeprodukter og slippe af med den smerte, de ikke længere kan holde ud.

Det er meget spændende.

Lad os give vores lyttere lidt orientering. I mine kredse er begrebet selvledende teams lidt af et tveægget sværd. På den ene side ønsker de fleste projektledere, at deres teams er selvstændige, så arbejdet kan udføres uden at en projektleder bliver en flaskehals. På den anden side vil de fleste projektledere også gerne forblive relevante og fortsat have et arbejde.

Men idéen om projektteams uden projektledere er vel ikke rigtig ny. I et agilt Scrum-team er der for eksempel ikke en egentlig projektlederrolle. Der er kun en produktejer, en Scrum-master og udviklingsteamet. På en måde har tegnene derfor været tydelige i et stykke tid, men vi forsøger stadig at forstå, hvad de betyder, og hvem de gælder for.

På nogle måder er det en trussel. Hvem har brug for projektledere, hvis projektteams kan lede sig selv? Men på andre måder er det faktisk projektledelsesnirvana. Mange projektledere taler om at ville være mere strategiske og tættere på produktet og kunden og mindre optagede af den daglige styring af arbejdet.

Så spørgsmålet er vel, om der findes en balance. Jeg tænkte, at vi kunne begynde med et udgangspunkt. Kan du forklare, hvordan denne idé om selvledende grupper fungerer hos Railsware og på Coupler.io-teamet?

Julia Ryzhkova: Svaret hænger sammen med vores koncept om udviklerens produktmindset.

Vi afholdt for nylig et særskilt webinar om idéen. Vi leder efter erfarne udviklere, der er T-formede. Som du nævnte, har jeg mange forskellige erfaringer, og det er den type person, vi søger. De kan faktisk begynde at arbejde med kunden som udvikler, produktudvikler eller produktchef i MVP-perioden.

Vi har gennem mange år udviklet vores rekrutteringsproces, så vi kan finde den slags mennesker, for det er naturligvis ikke let. Vi introducerer talenterne til vores interne produkter, så en udvikler bruger noget tid på et internt produkt, før vedkommende kan arbejde på et kundeprodukt. På den måde lærer de vores håndværk og tilgange og kan udvikle dette produktmindset.

Derefter kan de arbejde med kunden som et helt orkester bestående af én person. Det samme gælder andre roller. Ikke kun udviklere — alle hos Railsware kan arbejde selvstændigt. De fleste har ledelseserfaring eller har endda drevet deres egne virksomheder. Det gælder HR-medarbejdere, designere, produktchefer og naturligvis mange andre.

Ingen af os er dog direkte leder for teamet. Den måde, man bliver en autoritet på, er gennem princippet om at lede ved eksempel. Man leder produktet og viser på den måde teamet, at man er værd at følge. Man kan ikke bare fortælle andre, hvad der skal gøres. Man gør sit bedste for at skabe en effekt på produktet og det samlede resultat. På den måde får teamet tillid til en og begynder at gøre det samme.

Galen Low: Det elsker jeg. Jeg elsker idéen om, at teamet prioriterer at være T-formet og bringer mange forskellige erfaringer ind. Jeg hører dig, og jeg vil meget gerne gå i dybden med rekrutterings- og onboardingprocessen senere.

Rekrutteringsprocessen handler altså ikke kun om tekniske færdigheder, men også om ledelseserfaring og folk, der har haft og drevet deres egne virksomheder og ledet deres egne teams. Den erfaring er værdifuld og vigtig, selv om de træder ind i en rolle, hvor teamet faktisk er meget fladt. Det synes jeg er interessant.

Vi talte tidligere om, at du har en baggrund inden for projektledelse, og at du tidligere ledede et PMO. Som en person med den baggrund: Fandt du nogensinde idéen om selvledende teams lidt afskrækkende eller måske ligefrem truende?

Julia Ryzhkova: Det er sjovt, at du spørger. Det gjorde jeg faktisk i prøveperioden hos Railsware. Det er let at vurdere sin nødvendighed for virksomheden, når man er den ene helt, og alt kommer ud af kontrol uden en. Så føler man sig sikker hver dag, man arbejder. Men når tingene fungerer godt, selv uden en, kan man ikke mærke sin indflydelse på samme måde, som man plejede.

Man foretager nogle ændringer, implementerer en ny proces og forbedrer noget, og tingene ændrer sig en lille smule. Det er en forbedring, og ens tilstedeværelse gør tingene bedre, men man kan mærke, at man faktisk kunne tage to ugers ferie, uden at noget ville falde fra hinanden. Så hvorfor har de brug for mig?

På et tidspunkt holder man dog op med at forsøge at kontrollere alt. Med al den fritid, man får, finder man andre måder at skabe indflydelse på.

Man fokuserer på produktet, kunden og strategien, og man kan faktisk skabe en endnu større effekt med den tid, man har. Når man giver teamet mere plads, kan de skabe noget utroligt i faggruppen. Vi har en gruppe med fire ingeniører og én kvalitetssikringsmedarbejder. Derudover har vi en ingeniørfaggruppe, en kvalitetssikringsfaggruppe og en produktledelsesfaggruppe.

Produktledelsesfaggruppen udviklede for eksempel BRIDGeS-rammeværket, som jeg nævnte i begyndelsen. Det er umuligt at skabe noget sådant, hvis man ikke har plads til at gøre det, man mener, der skal gøres, uden hele tiden at skulle forbedre alting.

Galen Low: Det kan jeg virkelig godt lide. Jeg tror, det er helt afgørende. Alle, jeg har talt med, som har haft en god oplevelse med et team, fortæller, at deres bedste projekter altid har været teams, der på en eller anden måde var selvstændige eller selvledende. Det betyder ikke nødvendigvis, at projektlederen fjernes, men at teamet er bemyndiget nok til at få en retning og løbe med den.

Som projektledere beskriver vi ofte de mikrostyrende dele af arbejdet. Vi hyrder katte og sørger for, at tingene bliver leveret. Men i virkeligheden handler det om at give vejledning og retning, inspirere et team og give dem mulighed for at udføre deres bedste arbejde.

Det lyder, som om det er den kultur, I har. Det handler ikke om, at vi ikke længere har brug for Julia, eller at vi kan skille os af med hende. Det handler om, at vi kan løfte Julia — eller løfte den rolle, som tidligere ville have været en projektleder — så den bliver mere strategisk. Jeg kan virkelig godt lide idéen om at få teamet til at føle sig selvstændigt og bemyndiget og samtidig kunne holde ferie.

Jeg spekulerer på, hvordan du ser din rolle nu. Du er ikke projektleder, men produktchef. På nogle måder er du lidt dirigent for orkestret, sådan som jeg forestiller mig det.

Julia Ryzhkova: Det kan man godt sige.

Galen Low: Bruger du stadig nogle af dine projektledelseskompetencer? Har du haft gavn af din baggrund inden for projektledelse som produktchef?

Julia Ryzhkova: Ja, helt sikkert. Jeg kan ikke forestille mig, at nogen kan være produktchef uden nogen form for baggrund inden for projektledelse. Det er en afgørende del. Min tekniske baggrund har givet mig fordele, men projektledelseskompetencer er afgørende for en produktchef, så vidt jeg kan se.

Som en del af vores kompetencematrix har alle seniorroller hos Railsware projektledelseskompetencer. Kommunikation er for eksempel afgørende for os. Vi har fundet ud af, at disse kompetencer er nyttige for det samlede resultat.

Hvis vi taler om specifikke færdigheder fra PMBOK-områderne, så arbejder jeg næsten ikke med integrations- og kommunikationsledelse. Det er en del af selvledelsen, ellers ville det ikke være selvledelse. Men omfang, omkostninger, tidsplan og især interessenthåndtering er stadig til stede.

Hvad ellers? Kvalitet. Kvalitet er en del af kvalitetssikringens og ingeniørernes område, så det gør jeg næsten ikke. Risikostyring er fordelt blandt alle teammedlemmer, ligesom indkøb. Hvis man har brug for noget til arbejdet, opretter man blot en indkøbsanmodning og forklarer hvorfor.

Jeg kan ikke forestille mig, hvordan — og vigtigst af alt hvorfor — jeg skulle forstå, hvorfor vi har brug for dette opsøgende marketingværktøj eller det specifikke udviklingsbibliotek. Det er dejligt, at jeg ikke skal gøre det.

Galen Low: Det kan jeg godt lide. Især at du siger, at alle seniorroller har projektledelseskompetencer. Vi tager nogle gange omfang, omkostninger, tidsplan og interessenthåndtering for givet, fordi det naturligt er en del af en rolle. Men det er faktisk en naturlig del af forretningen og af at få ting gjort på en bæredygtig og ansvarlig måde.

Er det en del af rekrutteringsprocessen, eller får en person, der træder ind i en seniorrolle, projektlederuddannelse?

Julia Ryzhkova: Når jeg taler om seniorroller, taler jeg også om ingeniører og kvalitetssikringsmedarbejdere, ikke kontorchefer. Alle roller, der bidrager til produkter og projekter, skal som minimum kunne lede sig selv — deres omfang, tidsplan, omkostninger og indkøb. Det forventer vi af en person. Derfor leder vi efter erfarne udviklere og andre erfarne teammedlemmer.

Vi forventer ikke nødvendigvis, at de har gennemført en grundlæggende, dedikeret projektlederuddannelse eller har en særlig baggrund inden for projektledelse. Det er færdigheder, alle allerede bruger uden nødvendigvis at være klar over det. Vi kan udvide disse færdigheder, men vi lærer dem ikke fra bunden.

Galen Low: Det kan jeg godt lide. Som digitale produkt- og projektledere skal vi lære meget om fagområderne hos de teams, vi arbejder sammen med. Jeg mener, at vi også kan gøre mere for at dele vores faglighed med dem, når det handler om at få ting gjort, lede os selv, håndtere samarbejde og forstå forretningssiden.

Vi bygger ikke bare ting for sjov. Vi bygger dem til brugere og kunder, og vi har begrænsninger. Hvordan arbejder vi ansvarligt inden for disse begrænsninger? Det kan jeg virkelig godt lide.

Lad os gå i dybden med, hvordan alt dette fungerer, og især hjælpe de lyttere, der er en del af eller leder en organisation eller et team, som undersøger en model som denne. Hvad skal de overveje?

Det, der slår mig, er, at grupper af små selvledende teams, der arbejder sammen, sandsynligvis kræver mange klart definerede processer og en virkelig solid onboarding. Hvordan kommunikerer disse grupper og holder sig afstemt med hinanden?

Julia Ryzhkova: Det er nok en del af kulturen. Da Railsware kun havde to grundlæggere, definerede de processer og håndterede dem som simple opgavelister. Men de gjorde det. De havde en struktureret tilgang og dokumenterede alt. De ledte naturligvis efter folk, der ville slutte sig til den lille virksomhed, og som delte den samme kultur.

Det er ikke almindeligt for små virksomheder. Normalt begynder man først at tænke på processer, når tingene falder fra hinanden. Hos os begyndte man fra fundamentet, og derfor blev det en del af kulturen.

Vi har en god onboardingproces og princippet om at dokumentere, mens man arbejder. Ethvert møde kan have en delt dokumentfil eller et Figma-board, hvor alle deltagere skriver noter før eller under mødet, ikke bagefter. Vi laver ikke referater, der kræver meget tid efter mødet. Vi forbereder noterne på forhånd, og hvis nogen begynder at dele noget uden for den dokumenterede ramme, skriver alle andre noterne ned for at sikre, at alt er med.

Efter to ugers ferie kan jeg åbne nogle få dokumenter, læse dem og forstå, hvad der foregik, og hvor vi er nu, uden yderligere koordinering. Intet bliver efterladt uden for systemet.

Det handler også om en gennemsigtig kultur. Kommunikation foregår i offentlige kanaler og Slack-kanaler. Vi har mere end 300 af dem og næsten ingen private arbejdssamtaler. Alt bliver taget op offentligt, og alle kan læse det og måske svare hurtigere end den person, spørgsmålet oprindeligt var rettet til.

Man kan blot læse kanalen og forstå, hvad der foregik under ens fravær.

Galen Low: Det er meget spændende. Det er noget, mange af de grupper, jeg taler med, forsøger at mestre: asynkron kommunikation, hvor man kan gå tilbage og indhente alle samtalerne, fordi de ligger foran en.

Det lyder, som om Railsware var meget progressiv fra første dag. Det behøver ikke være omfattende — det handler bare om at skrive tingene ned et sted, så andre kan forstå dem.

Julia Ryzhkova: Jeg beundrer det. Jeg plejede at undervise i, at man på et tidspunkt får brug for forretningsprocesser, men ikke nødvendigvis fra begyndelsen. Hvis man er én person i sin virksomhed og ved, hvordan tingene skal gøres, har man ikke brug for dem.

Efter at have lært Railswares historie at kende har jeg ændret mening. Nu siger jeg, at man skal gøre det fra begyndelsen, og det kan være meget enkelt. Det kan bare være en tjekliste, men man skal gøre det.

Selv når man gør personlige ting, for eksempel søger et nyt job, laver man en liste over virksomheder og følger en proces for hver virksomhed. Man skal skrive ned, hvor man er, og hvad næste skridt er. Det er også en opgaveliste, og man har brug for den, ellers kan det slet ikke styres.

Jeg begyndte at tænke, at man ikke kan undvære processer, hvis man vil drive en virksomhed.

Galen Low: Det kan jeg godt lide. Jeg spekulerer på, om vi kan berøre teamets målepunkter. Hvilke præstationsmålinger er vigtigst, og hvordan ved man, at tingene er på rette spor? Teamet arbejder på egen hånd, og ansvarligheden er næsten delt.

Hvordan ved du, at tingene udvikler sig som planlagt? Hvad følger du?

Julia Ryzhkova: Jeg følger slet ikke præstationsmålinger. Måske lyder det urealistisk, men jeg følger i stedet produktmålinger.

Vi følger, hvordan vi vokser, om vores SaaS-målinger udvikler sig godt, om vi har god konvertering, god omsætning og så videre. Jeg følger teamets hastighed, men ikke som en præstationsmåling. Jeg bruger den til at forudsige, hvad vi kan nå i en udgivelse og i de næste tre måneder. Tidsplanlægning er stadig en del af arbejdet.

Jeg anvender hastigheden på fremtidige epics og estimater for at beregne de tidligste forventede datoer. Når man leverer til produktion hver dag eller som minimum hver anden uge, er det acceptabelt, at noget bliver to uger forsinket. Ingen dør af to ekstra uger.

Grupperne styrer deres egen præstation. De laver parprogrammering med nye medarbejdere, krydstest og kodegennemgang. De følger deres egen præstation og formulerer tydeligt over for hinanden, hvad der skal forbedres.

Jeg kan se det under daglige møder og retrospektiver. Vi har ikke den opfattelse, at interessenter og produktejere nødvendigvis skal deltage i udviklingsteamets retrospektiv. Jeg var involveret i retrospektivet fra begyndelsen, og vi involverer kunden i det. Teamet deler åbent og gennemsigtigt input om hinandens præstationer.

Denne feedbackkultur er på et højt niveau. Alle nye medarbejdere får feedback fra alle teammedlemmer, og enhver kan påpege et præstations- eller kvalitetsproblem. Den nye medarbejder kan også give feedback om processerne, virksomheden eller mig som produktchef og fortælle, hvordan jeg kan forbedre mig.

Derfor er der kun to muligheder: Man består ikke prøveperioden, eller også præsterer man godt, og så behøver vi ikke kontrollere præstationen længere.

Galen Low: Meget interessant. Kan det blive intenst nogle gange?

Julia Ryzhkova: Det kan det. Men normalt er alle afstemt. Hvis nogen ser et problem, ser alle det, og vi deler feedbacken. Jeg har ikke oplevet egentlige problemer med det.

Galen Low: Det er indlejret i kulturen og i den måde, I rekrutterer til jeres teams på. I ansætter folk, som allerede tænker sådan og er klar til at have disse samtaler, udvikle sig som team, give feedback, dele feedback og modtage feedback, så teamet præsterer godt i den flade struktur.

Julia Ryzhkova: Det er faktisk noget, vi undersøger under rekrutteringsprocessen. Vi bruger meget tid og investerer meget i det.

For produktchefer afsætter vi for eksempel en hel dag, hvor vi samarbejder om et problem. Det er otte timers pararbejde med produktchefer, hvor produktchefen udfører noget, mens man deler feedback og ser, hvordan personen reagerer på den. Det er en stor investering fra virksomhedens side, fordi en direktør på C-niveau og en produktchef bruger en hel dag på beslutningen.

Det kræver også en stor indsats fra kandidaterne. Man får ikke et tilbud, før man har afsat en hel dag til processen. Resultatet er dog fremragende. Kandidaterne mærker os og forstår, om vi passer kulturelt sammen, og vi vurderer dem ikke kun teknisk, men også på, hvordan vi giver feedback, hvordan de hører feedback, hvordan de reagerer på den, og om vi har samme humor.

Som følge heraf får vi mennesker, der kan være en del af denne feedbackkultur.

Galen Low: Det kan jeg godt lide. I mange moderne rekrutteringsprocesser er der en masse vilkårlige tests. Det, der virkelig viser, at man investerer i at finde det rette match eller den rette kulturelle tilføjelse, er, at en produktchef og en direktør på C-niveau bruger en hel dag eller to på faktisk at arbejde sammen med kandidaterne og sikre, at samarbejdsdynamikken fungerer.

Det er enormt. Ikke alle kan gøre det på grund af deres struktur, men når man skal være sikker på menneskerne, er det en god metode.

Julia Ryzhkova: For kandidaten er det også en investering. De investerer ikke tre måneder i en prøveperiode for derefter at opdage, at det ikke er en virksomhed, de kan arbejde i. Det giver mening. Vi gør det ikke på samme måde for alle roller. Vi samarbejder med kandidater til alle roller, men ikke nødvendigvis en hel dag.

Det kan være to eller fire timer afhængigt af rollen. Men vi har stadig brug for det for at lære hinanden at kende.

Galen Low: Det giver mening. Du nævnte tidligere, at hvis man forsøger at levere noget på to uger, og det bliver forsinket med to uger, dør ingen nødvendigvis. Men som produktchef styrer du produktplanen og lover kunderne funktioner. Hvad sker der, når tingene ændrer sig?

Hvad sker der, når du opdaterer produktplanen, prioriterer opgaverne i backloggen igen eller ændrer leveringsdatoen? Hvilken adfærd ønsker du, at teamet udviser, når det møder forandringer?

Julia Ryzhkova: Du bliver måske overrasket, men der sker faktisk ikke noget særligt. Jeg kan tage noget ud af et sprint, sætte en anden opgave ind og forklare hvorfor. Vi diskuterer det, og så er det det. Jeg kan ændre backloggen midt i et sprint, og vi stopper ikke sprintet på grund af én eller to opgaver.

Vi planlægger et møde for at diskutere, hvad der skal gøres, afholder en estimeringssession, og derefter er alle afstemt. Jeg ændrer ikke produktplanen særlig ofte. Jeg reviderer den normalt én gang om måneden med nye indsigter, nye målinger og det, jeg har set i vores kontrolpaneler.

Teamet kender produktvisionen og deltager i strategimøder med ledelsen for at dele deres tekniske perspektiv på, om vi skal gentænke noget eller ændre prioriteter.

Da vi ændrede prismodellen, delte en af vores ingeniører for eksempel oplysninger om et system, som integreres med mange kunder. De havde også ændret deres prismodel, og nu var vores priser ikke længere konsistente. Vi skulle måske indarbejde det og genoverveje vores grænser. Det var fantastisk at diskutere prismodellen og få input fra en ingeniør.

Det er det team, jeg arbejder med. Teamet er indstillet på forandringer. I løbet af mine første seks måneder ændrede jeg for eksempel projektstyringsværktøj tre gange: fra Trello til Coda, derefter til Pivotal Tracker og så til JIRA, indtil jeg fandt de to, der faktisk dækkede alle vores behov.

De sagde bare: Har du brug for vores hjælp, eller skal du give os 15 minutters introduktion til det nye værktøj? Det lyder fantastisk, og det er derfor, jeg er så inspireret af dem.

Galen Low: Det lyder virkelig fantastisk. Især fordi det kan være som at trække tænder ud at ændre projektstyringssoftware. Folk klamrer sig ofte til stabiliteten i det værktøj, de i det mindste kender.

Det fremhæver for mig, hvad du tidligere sagde om at finde mennesker med et produktmindset — også på ingeniør-, design- og marketingniveau. Når man forklarer, hvorfor noget ændrer sig, hvorfor prismodellen skal ændres, eller hvorfor en funktion er vigtigere end en anden, er teamet indstillet på at forstå, at det måske er bedst for kunden, slutbrugeren eller produktet som helhed.

Det handler ikke om, at de allerede var halvvejs med noget. Det handler om, hvad der er bedst for helheden. Produktet er forandring. Det er det, der går igen i denne samtale.

Nogle gange forsøger projektledelse at opnå stabil perfektion. Mange tror, at det er deres opgave. Men både på projekt- og produktsiden handler arbejdet om at reagere på forandringer og se fremad. Man skal bruge hastighed til at planlægge og træffe beslutninger om fremtiden, organisere sig, kommunikere effektivt og have et omfang, men tingene ændrer sig.

Vi kan ikke stole på, at en plan, vi lavede for seks måneder siden, stadig er perfekt og helt nøjagtig. Det handler om, hvordan vi reagerer på forandringer, og hvordan vores teams reagerer på dem.

Julia Ryzhkova: Mens du talte, kom jeg i tanke om en nylig samtale med en udvikler. Han sagde, at han følte stabilitet, fordi vi havde en backlog for de næste flere sprints. Men han var ligeglad med, om den ændrede sig fuldstændigt. Han vidste bare, at der var noget, og han kunne se det.

Jeg har fire JIRA-sprints for fremtiden, og de er fyldt med opgaver. De er ligeglade med, hvad der står som nummer nul. De ser på produktplanen, kender visionen og har brug for at vide, at vi også kender visionen og deler med dem, hvad vi på et overordnet niveau vil gøre næste år og de kommende år.

Det betyder ikke så meget, præcis hvordan vi kommer derhen. Vi diskuterer opgaverne under forfinelsen lige før sprintets begyndelse. De ved, at jeg har noget planlagt, og det opfylder behovet for stabilitet og tryghed.

Galen Low: Det er tillid gennem gennemsigtighed. I deler visionen og planen med dem og lader dem være en del af processen. De er ikke bare hænder, der udfører arbejdet. De er en del af produktteamet, som navigerer i det hele.

Det skaber tillid. Så længe der er ting i backloggen, og de har set produktplanen, ved de, hvor vi skal hen. Det giver teamet tilstrækkelig retning til at være selvstændigt, selvhjulpent og have en følelse af stabilitet.

Jeg vil vende tilbage til backloggen og det at skifte retning midt i et sprint. Nogle lyttere vil måske sige, at vi taler om agil softwareudvikling, hvor nogle af disse ting naturligvis fungerer. Efter din mening fungerer det så kun med agil softwareudvikling, eller kan modellen bruges af tværfunktionelle teams, der skaber alle mulige former for produkter?

Julia Ryzhkova: Man skal helt sikkert være agil, men jeg mener agilitet i betydningen fra Det Agile Manifest, som ikke siger, at man skal skabe software.

Alle vores grupper bruger lignende tilgange. Marketing-, økonomi- og driftsteams har lært at estimere. Vi laver forfinelse, styrer produktplaner, estimerer HR-projekter, bruger story points og planlægger og følger hastighed. Alle kan bruge det til at styre deres processer.

Galen Low: Det kunne være en hel podcast-episode, for mange lyttere tænker sikkert: Jeg ville ønske, mit marketingteam arbejdede agilt fra en backlog og i sprints. Mange teams og organisationer bevæger sig i den retning, men ikke-udviklings- og ikke-designteams møder stadig modstand.

Nogle tror, at agilitet ikke er for dem, fordi de arbejder på en anden måde. Men det er værd at udfordre i enhver organisation, fordi det, du taler om, er at være smidig og kunne reagere på forandringer. Det kan alle afdelinger og teams drage fordel af.

Julia Ryzhkova: Ingeniørteamet arbejder for eksempel med Scrum, ligesom designteamet. Marketing arbejder med Kanban og har et Kanban-board med en produktplan. Det fungerer bedre for dem. Alt dette er agile tilgange.

Galen Low: Det giver mening, fordi det på nogle måder er operationelt og løbende.

Lad os gå videre til det interessante, for der er nogle konsekvenser, vi har kredset om, og som jeg ved, at vores lyttere vil have spørgsmål til. Mange, der diskuterer projektlederledede projekter over for selvledende teams, sætter den ene eller den anden model på en piedestal. Men ingen model er perfekt.

For dem, der overvejer at gå over til denne model og måske tror, at det bliver let og perfekt, en utopi: Hvad går galt, når tingene går galt i denne model?

Julia Ryzhkova: Det er et svært spørgsmål. Vi har nogle problemer på højt niveau.

En gruppe er ikke altid klar over, hvad der foregår inde i en anden gruppe. Vi har for eksempel to produkter, Mailtrap og Coupler.io, som er mit produkt. Coupler.ios udviklingsteam udviklede mange nye funktioner, som vores lille marketingteam ikke kunne nå at dække med indhold og landingssider.

I Mailtrap var det omvendt. Derfor besluttede ledelsen at flytte teams og tildele en del af marketingteamet fra Mailtrap til Coupler.io og en del af udviklingsteamet fra Coupler.io til Mailtrap for at styrke begge produkter.

Den slags beslutninger kan ikke træffes inde i gruppen, fordi gruppen ikke ser det samlede billede. Virksomhedsdækkende beslutninger skal stadig træffes af ledelsen.

Galen Low: Det er rimeligt. Er det typisk en del af din rolle, eller er det nogen i en driftsrolle, der træffer beslutningen?

Julia Ryzhkova: Det er en rolle på C-niveau. Jeg kender mit produkt og deler under strategiske møder, at vi er langt foran med udviklingen og har brug for flere marketingressourcer. Det samme gør produktchefen for Mailtrap, hvis de er foran med marketing og har brug for flere udviklingsressourcer.

Ledelsen er ikke involveret i mikrostyring. Én gang om måneden kan de frit træffe den slags beslutninger, fordi de ikke er overvældet af detaljer. De kan se det klart og sige: I skal bytte teams.

Galen Low: Var det en permanent ændring, eller introducerede det en model, hvor folk deles mellem grupper? Eller var det midlertidigt for at håndtere kapaciteten?

Julia Ryzhkova: Det er midlertidigt. Der er to måder at afslutte det på. Man kan rekruttere nye udviklere til Coupler.io og nye marketingmedarbejdere til Mailtrap, eller man kan flytte teamene tilbage.

Vi gør en blanding af begge dele, men vi er ikke færdige endnu. Vi arbejder stadig med ændringen. Vi er agile, og hvis vi kan ændre tre værktøjer på et halvt år, kan et team også flyttes til et andet produkt i et halvt eller helt år. Det er ikke et problem.

Galen Low: Det handler også om den grundlæggende årsag. Grupperne skal være afstemt. Så længe de er afstemt, vil marketingteamet ikke forsøge at promovere en masse funktioner, der ikke er klar, og udviklingsteamet vil ikke skabe funktioner, som marketing ikke kan følge med til at lancere.

Det grundlæggende problem og stedet at løse det er afstemningen mellem grupperne. Hvor ofte taler marketinggruppen og udviklingsgruppen på Coupler.io med hinanden?

Julia Ryzhkova: Det afhænger af situationen. Vi har naturligvis en demo, hvor udviklingsteamet viser, hvad der er blevet gjort i den seneste iteration, og hvad vi skal udgive. Vi har en ugentlig koordinering, hvor jeg deler, hvad vi arbejder på, og hvad der skal udgives i den nærmeste iteration.

Hvis der er behov for at opdatere landingssider eller udgive versionsnoter, tilføjer marketingteamet det til deres liste. De har en global produktplan med store marketingprojekter, og en del af deres kapacitet bruges på at støtte udviklingsteamet.

Vi har en proces for inputstyring. Alle i teamet kan oprette input, der skal med i en andens backlog, og vi gennemgår det én gang om ugen.

Hvis inputtet ikke stemmer overens med visionen, lægger vi det i isboksen. Hvis det ikke er prioriteret, tager vi det med i produktplanen, måske i det nærmeste eller det næste sprint for at forbedre noget.

Sådan holder teams sig afstemt. Marketingteamet kan for eksempel foreslå at ændre hjemmesidens design eller forbedre skabeloner til landingssider, og vi tilføjer det til udviklingen. Omvendt kan en udvikler foreslå, at en e-mail-skabelon skal med i udviklingen af applikationen. Vi skal sende en e-mail og har brug for en god tekst og skabelon, så marketing kan levere det.

Galen Low: Det er virkelig spændende. Noget, vi ikke har talt så meget om, men som er implicit i begyndelsen af samtalen, er geografier og tidszoner. I har teammedlemmer fordelt på tværs af geografier og tidszoner, faktisk over hele verden.

Er der ineffektivitet, som skal kompenseres for, eller er det ikke et problem fra dit perspektiv?

Julia Ryzhkova: Jeg vil sige det modsatte. Fjernarbejde gør det muligt at bruge mere tid effektivt. Det kan naturligvis være svært at holde et møde, når man har en udvikler fra Argentina og en produktchef fra Thailand. Man skal tilpasse sit arbejde og sin tidsplan, så man kan koordinere på en praktisk måde.

Det er nok det eneste problem, jeg kan komme i tanke om. Størstedelen af vores team arbejder fjernbaseret, mere end 80 %, vil jeg sige, og de kommer fra over 15 lande. Delte dokumenter og offentlige kanaler gør det muligt at organisere arbejdet godt.

Når vi arbejder og kommunikerer asynkront, behøver vi ikke bruge meget tid på at planlægge onlinemøder efter internationale tidsplaner.

Galen Low: Det elsker jeg. Det skelner mellem to ting. Asynkront arbejde betyder ikke, at man aldrig mødes. Man kan stadig holde møder, når det er nødvendigt, og nogle gange skal man være fleksibel med sin tidsplan og mødes uden for normal arbejdstid.

Asynkron kommunikation betyder ikke, at der aldrig må være synkron kommunikation. Og fjernarbejde er ikke det samme som hjemmearbejde. Man kan arbejde fjernbaseret, have et fjernteam og stadig være på et kontor.

Dokumentation og en kultur med gennemsigtighed betyder, at man ikke behøver masser af møder med kompliceret planlægning. Det handler om at have et spor af kommunikationen, som alle kan tilgå.

Er projektledelse lidt af et tabu i selvledende teams? Er de modvillige over for at have en projektleder, fordi de ikke har brug for at blive ledet? Er projektledelse et fyord?

Julia Ryzhkova: Jeg synes ikke, der er noget, jeg vil kalde et tabu. Vi elsker at eksperimentere, og der er ingen pligt til at gøre noget bestemt. Jeg mener ikke, at alle skal gennemføre en fuld projektlederuddannelse.

Vi deler vigtig viden under faggruppemøder som en del af faglig udvikling. Jeg underviste for eksempel driftsteamet i estimering, story points og grundlæggende Kanban og Scrum.

Hvis man føler, at man har brug for grundlæggende projektlederuddannelse, kan man bruge uddannelsesbudgettet på det. Men vi mener, at det er mere effektivt at dele viden, lige når der er brug for den.

Galen Low: Det kan jeg godt lide. Man deler dele af fagligheden uden nødvendigvis at forsøge at gøre alle til projektledere. Projektledere forsøger heller ikke nødvendigvis at blive ingeniører. Det handler om de færdigheder, der hjælper os med at arbejde sammen og levere godt arbejde.

Jeg vil slutte med det store spørgsmål. Som en person, der var projektleder og ledede et PMO, men nu har en mere strategisk rolle som produktchef: Ser du selvledende grupper som projektledelsens fremtid generelt?

Julia Ryzhkova: Jeg tror, det er fremtiden for succesfulde produktvirksomheder.

Selvledende teams gør det muligt for projektledere at fokusere på strategi, produkt og kunde. Det er her, man endelig kan nå nirvana og arbejde med den vigtige, men ikke hastende del af opgaverne.

Man har normalt ikke tid til det, fordi teamet forsøger at rydde op i det hastende, men ikke vigtige, som ofte optager projektledernes tid. Man kan dog ikke forvente, at alle omkring en kan lede sig selv, især ikke lige efter uddannelsen eller i begyndelsen af karrieren.

Juniorer har brug for mentoring og coaching, men også direkte, klassisk ledelse i begyndelsen. Der findes også mennesker, som ikke kan sætte deadlines for sig selv og ikke arbejder effektivt uden dem. Det kan endda gælde erfarne tekniske eksperter.

Der vil derfor altid være plads til klassisk projektledelse.

Jeg tror dog, at enhver virksomhed eller ethvert team, der vil opnå fremragende produktresultater, bør nå det punkt, hvor selvledelse erstatter direkte projektledelse. Det frigiver projektlederens tid til strategi og generel procesforbedring i stedet for at løse hvert enkelt problem.

Galen Low: Det kan jeg godt lide. Man løfter rollen og arbejder proaktivt. Jeg tror, at det, der resonerede mest med mig, er idéen om et produktmindset.

Et produktmindset handler ikke kun om produktets løbende livscyklus, udgivelser og så videre. Det handler om tilpasningsevne og åbenhed over for forandring. Et moderne produkt skabes ikke én gang og forbliver derefter uændret. Det drives af slutbrugere, kunder og markedet, og alt dette ændrer sig hele tiden.

Produktmindsettet handler derfor ikke kun om evnen til at tænke på et produkt, men også om evnen til at reagere på forandringer, være agil og smidig og forstå hvorfor tingene ændrer sig.

Det betyder, at jobbet ændrer sig, backloggen ændrer sig, udgivelsesplanen ændrer sig, og projektstyringsværktøjerne måske ændrer sig tre gange på et år. Det er det, vi mener med et produktmindset. Et selvledende team skal have disse egenskaber for at kunne tilpasse sig forandringer og udvikle produkter dynamisk, agilt og smidigt.

Et sidste spørgsmål: Hvilket råd vil du give en organisation, der forsøger at bevæge sig hen imod små selvledende teams?

Julia Ryzhkova: Lad være med kun at forsøge — gør det. Begynd med ét lille team. Forsøg ikke at implementere tilgangen i hele organisationen, hvis den er stor.

Saml jeres bedste mennesker, giv dem den nødvendige myndighed, og sørg for resultaterne. Når I ser fordelene, gør I alt, hvad der skal til for at overføre tilgangen til hele virksomheden. I har brug for succes, og for at opnå den skal I begynde med de mennesker, der passer bedst til det billede, jeg har beskrevet.

Galen Low: Det er fantastisk. Julia, mange tak fordi du var med i dag. Jeg nød virkelig vores samtale. Det er fascinerende at lære, hvordan jeres organisation har håndteret dette, hvordan jeres selvledende grupper arbejder, og hvordan hele den agile proces fungerer i udviklingen af produkter i jeres produktstudio.

Jeg håber, vores lyttere har lært meget, og måske har samtalen inspireret dem til at få deres teams tættere på en selvledende kultur uden den underliggende trussel om, at projektledere ikke længere vil eksistere i fremtiden.

Vi vil meget gerne have dig tilbage for at tale mere om, hvordan tingene udvikler sig, og høre mere om, hvordan kunstig intelligens kommer til at indgå i Coupler.io-produktet.

Julia Ryzhkova: Jeg håber, at jeg kan dele alle disse indsigter med jer.

Galen Low: Det er virkelig spændende. Tak igen.

Julia Ryzhkova: Tak. Det var virkelig rart at tale sammen og dele det, for alt dette inspirerer mig meget. Jeg håber, at det inspirerer andre til at gøre det samme og nyde resultaterne.

Galen Low: Fantastisk. Tak igen.

Julia Ryzhkova: Tak.

Galen Low: Hvad synes du? Er selvledende teams fremtiden, eller har de begrænsninger, der gør dem uegnede til bestemte typer organisationer og brancher?

Fortæl os en historie. Hvad er det mest selvledende projektteam, du har arbejdet med, og hvordan gik det? Hvad har på den anden side været din mest frustrerende oplevelse med at skulle hyrde katte i stedet for at arbejde strategisk? Fortæl os, hvad du synes, i kommentarerne nedenfor.

Og hvis du vil skærpe dine færdigheder som strategisk projektleder, så kom med i vores fællesskab!

Besøg thedigitalprojectmanager.com/membership for at få adgang til et støttende fællesskab, der deler viden, løser komplekse udfordringer og sammen former fremtiden for vores fag.

Fra robuste skabeloner og månedlige træningssessioner, der sparer dig tid og energi, til den kollegiale støtte i vores debatforum, fællesskabsarrangementer og mastermind-grupper: Som medlem af vores fællesskab har du over tusind mennesker i ryggen, mens du navigerer i din karriere inden for digital projektlevering.

Og hvis du kunne lide det, du hørte i dag, så abonnér og hold kontakten på thedigitalprojectmanager.com

Indtil næste gang — tak fordi du lyttede.