Projectteams zonder projectmanagers: het dilemma van de PM onderzocht

Lees het transcript:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Galen Low: Zelfsturende projectteams. Die uitdrukking alleen al is genoeg om bij elke projectmanager een existentiële crisis te veroorzaken. Maar vormt dit een bedreiging voor ons bestaan? Of is het juist de sleutel om de projectmanager naar een uitgesproken strategischere rol te tillen?

Als je hebt nagedacht over de toekomst van projectmanagement en over de vraag of digitale projectmanagers relevant zullen blijven, blijf dan luisteren. We gaan bekijken hoe één organisatie succesvol complexe softwareoplossingen bouwt met behulp van gedistribueerde, zelfsturende squads, en wat dat in bredere zin betekent voor digitaal projectmanagement.

Bedankt dat je luistert. Mijn naam is Galen Low van The Digital Project Manager. Wij zijn een community van digitale professionals met als missie elkaar te helpen vaardigheden en zelfvertrouwen op te bouwen en met elkaar verbonden te blijven, zodat we projecten met doel en impact kunnen opleveren. Als je daar meer over wilt horen, ga dan naar thedigitalprojectmanager.com.

Hallo allemaal — bedankt dat jullie met ons rondhangen bij de DPM-podcast.

Mijn gast vandaag is een IT-professional uit Kiev die al meer dan vijftien jaar vernieuwend bezig is op het gebied van bedrijfsprocesmanagement en digitaal productmanagement. Ze is businessanalist geweest, PMO-directeur, productdirecteur en customer-successdirecteur. Ze heeft gewerkt met merken als Heinz, Yandex, Adidas en Zyxel om op schaal bedrijfssystemen te implementeren.

Vandaag is ze productmanager bij Railsware. Ze werkt aan het Coupler.io-team, waar ze toezicht houdt op squads van externe, zelfsturende Agile teams die veelgebruikte producten creëren die inmiddels bekende namen zijn geworden, zoals Calendly.

Naast haar werk geeft ze les in bedrijfsproces- en projectmanagement aan de Lviv Business School en voedt ze haar baby op tot de volgende generatie vrouwen in de technologiesector.

Mensen, verwelkom Julia Ryzhkova. Hallo, Julia!

Julia Ryzhkova: Hoi! Hallo iedereen!

Galen Low: Bedankt dat je vandaag bij ons bent. Dankzij onze recente gesprekken ben ik erg enthousiast over deze aflevering, omdat we ingaan op iets waar we ons als projectmanagers allemaal een beetje onzeker over voelen: zullen projectmanagers blijven bestaan?

Daar gaan we op in, maar ik wilde je eerst vragen: hoe is het leven? Wat inspireert je de laatste tijd?

Julia Ryzhkova: Dat zijn eigenlijk twee verschillende dingen. Als we het hebben over iets dat met Railsware te maken heeft, dan is dat het BRIDGeS-framework. We hebben het onlangs geopend. Het is een soort beslissingsframework waarmee je op hoofdlijnen je probleem kunt beschrijven en het vervolgens kunt omzetten in een oplossing.

We hebben het onlangs publiek beschikbaar gemaakt en ik ben momenteel betrokken bij het verspreiden van de boodschap erover. Het is echt geweldig en ik ben er erg enthousiast over. We hebben er meer dan vijftien jaar aan gewerkt. Dit is dus het begin van de openstelling voor het publiek, en dat inspireert me enorm.

Persoonlijk ben ik, zoals je al zei, ook betrokken bij de businessschool van Lviv. Momenteel organiseren we een openbare onlineopleiding over bedrijfsprocessen. Ik hoop dat dit de algemene volwassenheid van de bedrijfscultuur rond processen in Oekraïne zal verbeteren.

Ook dat inspireert me.

Galen Low: Dat vind ik geweldig. Beide dingen zijn erg bijzonder en het zijn geweldige prestaties. Gefeliciteerd!

Als mensen meer willen leren over het BRIDGeS-framework, waar kunnen ze dan terecht?

Julia Ryzhkova: Op de website van Railsware. We hebben er een speciaal subdomein voor.

Galen Low: Geweldig. Heel gaaf. En wanneer we dit opnemen is het december. We staan op het punt 2021 af te sluiten en 2022 binnen te gaan. Waar kijk je het meest naar uit in 2022?

Julia Ryzhkova: Iedereen praat momenteel over AI en machine learning. Onlangs hadden we een vergadering over de productvisies van onze producten en toen kwam het idee naar voren om AI te gebruiken in mijn product, Coupler.io. Ik wil dat heel graag proberen en zien hoe het uitpakt.

Galen Low: Heel gaaf.

Goed, laten we erin duiken. Vandaag bespreken we hoe kleine squads van externe Agile teams zichzelf kunnen managen en zich zelf kunnen organiseren in zwermen om complexe softwareoplossingen te creëren zonder op enig moment een projectmanager nodig te hebben. Is dat een bedreiging voor ons als projectmanagers? Is het een kans voor projectmanagers om strategischer te worden? Wakkert het de existentiële angst van al onze luisteraars aan?

We gaan dit allemaal uitgebreid onderzoeken en de deksel eraf halen om er echt in te duiken.

Maar eerst vroeg ik me af of je iets kunt vertellen over je eigen loopbaan. Wat is je rol vandaag en hoe ben je daar gekomen?

Julia Ryzhkova: Vandaag ben ik productmanager. Dat betekent dat ik verantwoordelijk ben voor productontwikkeling, marketing, de prijsstrategie en het verkoopteam.

Ik heb een technische opleiding in de informatica, die me enorm heeft geholpen, maar ik hield eigenlijk niet van programmeren. Toen ik naar carrièremogelijkheden zocht, wilde ik iets doen waarbij ik algoritmen kon creëren en iemand anders ze kon laten programmeren. Zo ben ik businessanalist geworden. Daarna ontwikkelde ik leiderschapsvaardigheden en werd ik teamleider van businessanalisten, projectmanager en hoofd van de afdeling businessanalyse.

Maar ik merkte dat de resultaten van mijn werk sterk afhankelijk waren van het product waaraan ik werkte. Daarom besloot ik over te stappen naar R&D als product owner en onderdeel te worden van het productteam. Dat was eigenlijk de eerste keer dat ik voelde dat ik op de juiste plek zat. Vervolgens groeide ons product en groeide het team. We kregen meer product owners en ik werd plaatsvervangend productdirecteur, waarbij ik de leiding had over de helft van de Scrumteams. Daarna wilde ik verder.

Omdat we al een productdirecteur hadden en ik nog steeds naar het bestuur wilde, werd ik customer-experiencedirecteur. Ik gaf leiding aan support, alles wat met diensten te maken had, de academie enzovoort. Ik heb daar geweldige processen opgebouwd en goede resultaten laten zien.

Daarom besloten we die vaardigheden te gebruiken om in andere afdelingen processen op te bouwen, en werd ik PMO-directeur. Toen kwam mijn zwangerschapsverlof. Nadat ik dat belangrijke deel van mijn leven had afgerond, wilde ik terugkeren naar productmanagement.

Dat was een belangrijke beslissing. Misschien vraag je je af waarom productmanagement en niet projectmanagement. Dat komt doordat ik me wilde richten op de voordelen voor klanten en procesmanagement ergens buiten beschouwing wilde laten. Voor mij is dat het verschil tussen product- en projectmanagement, al zijn er veel overeenkomsten.

Productmanagers kunnen zich richten op het product en de klant, terwijl projectmanagers zich richten op een proces en de resultaten daarvan. Daar komen zelfsturende teams goed van pas. Toen ik Railsware ontdekte en erover hoorde en las, wist ik dat het perfect bij me paste.

Galen Low: Ik vind die ontwikkeling geweldig. Je technische achtergrond, je ervaring met klantervaring en je leiderschap van PM-teams — dat is absoluut inspirerend voor mensen in onze sector.

Kun je iets vertellen over Railsware en over de teamstructuur waar je toezicht op houdt? Misschien ook over de soorten projecten die Railsware uitvoert?

Julia Ryzhkova: Laten we beginnen met de projecten, want de teamstructuur hangt af van het soort projecten waaraan we werken. Wij zijn een productstudio. Dat betekent dat we producten creëren voor onszelf en voor andere bedrijven. Bij Railsware automatiseren we graag alles. Soms kunnen we op de markt geen hulpmiddel vinden dat precies het deel uitvoert dat we nodig hebben.

Dan besluiten we iets voor onze eigen doeleinden te ontwikkelen. Vervolgens gebruiken we het zelf en brengen we het publiekelijk uit, omdat we weten dat wij niet de enigen zijn die het nodig hebben. Daarom beginnen we meestal met een klein team, terwijl we de markt onderzoeken.

Soms is dat bijvoorbeeld zelfs maar een deeltijdontwikkelaar. Een van onze producten, Smart Checklist for Jira, is deeltijds door één ontwikkelaar ontwikkeld. Pas nadat het een maandelijkse terugkerende omzet van 50.000 had bereikt, besloten we daar fulltimeontwikkelaars aan toe te wijzen.

Bij kleine producten zoals Coupler.io hebben we één ontwikkelingssquad, bestaande uit vier of vijf ontwikkelaars, en één marketingsquad, die ook uit vier of vijf verschillende specialisten bestaat.

Alle anderen werken parttime, zoals data-analisten en supportmanagers. Ook ik werk als productmanager aan dit product en aan producten van klanten. Maar wanneer een product groeit — zoals bij Calendly — breiden we het ontwikkelteam uit en verdelen we het in verschillende squads, omdat we geloven dat het efficiënter is om in een kleine squad te werken.

Calendly heeft momenteel bijvoorbeeld drie teams aan onze kant en veel ontwikkelaars aan hun kant. Zo werkt het.

Galen Low: Dat is echt interessant. Ik wil graag dieper ingaan op het idee van squads en zwermen. Ik vind het interessant dat marketing een squad is. Ik kaderde het eerder als Agile teams, maar Agile betekent niet noodzakelijk engineering of ontwikkeling.

Het kan veel verschillende dingen betekenen, waar we nog op terugkomen. Wat is vanuit het perspectief van productontwikkeling de grootste uitdaging waarmee je vandaag in je rol te maken hebt?

Julia Ryzhkova: Ik denk dat dit niet als een verrassing komt. De gebruikelijke uitdaging voor elke productmanager van een startup is het vinden van je goudmijn op de markt.

We lossen meestal een pijnpunt van de klant op. Daardoor groeit ons klantenbestand en groeien onze KPI's, maar we willen het tempo vasthouden en verdubbelen. Daarom moeten we een ander pijnpunt vinden waarvoor klanten bereid zijn het dubbele te betalen om ervan af te komen.

Galen Low: Jullie zijn probleemoplossers. Wat ik mooi vind, is dat het klinkt alsof jullie problemen voor jezelf oplossen en die oplossing vervolgens naar buiten brengen voor andere mensen die hetzelfde probleem hebben. Het is als een intern product dat naar buiten wordt gebracht. Tegelijkertijd zijn jullie ook een dienstverlenende organisatie die andere organisaties helpt de producten van hun dromen te bouwen om van hun pijnpunten af te komen.

Dat is heel bijzonder.

Laten we onze luisteraars wat houvast geven. In mijn kringen is het concept van zelfsturende teams een tweesnijdend zwaard. Enerzijds willen de meeste projectmanagers dat hun teams onafhankelijk zijn, zodat het werk kan doorgaan zonder dat een PM een knelpunt wordt. Anderzijds willen de meeste projectmanagers relevant blijven en hun baan behouden.

Het idee van projectteams zonder projectmanagers is eigenlijk niet nieuw. In een Scrum- of Agile-team wordt de rol van projectmanager bijvoorbeeld niet echt genoemd. Er is alleen een product owner, een Scrum Master en het ontwikkelteam. De voortekenen waren dus al een tijdje zichtbaar, maar we proberen nog steeds te begrijpen wat ze betekenen en op wie ze van toepassing zijn.

Aan de ene kant is het een bedreiging: wie heeft projectmanagers nodig als projectteams zichzelf kunnen managen? Aan de andere kant is het eigenlijk de projectmanagementhemel. Veel projectmanagers willen strategischer worden, dichter bij het product en de klant staan en minder tijd besteden aan het dagelijkse beheer van het werk.

Is er een balans te vinden? Kun je uitleggen hoe het idee van zelfsturende squads bij Railsware en binnen het Coupler.io-team werkt?

Julia Ryzhkova: Het antwoord hangt samen met ons concept van een productmindset voor ontwikkelaars.

We hebben onlangs een apart webinar over dat onderwerp georganiseerd. We zoeken volwassen ontwikkelaars met een T-vormig profiel. Jij noemde dat ik veel verschillende ervaringen heb; dat is precies het soort persoon waarnaar wij zoeken. Zij kunnen in de MVP-periode als ontwikkelaar, productontwikkelaar of productmanager rechtstreeks met de klant werken.

We hebben ons wervingsproces jarenlang gevormd om zulke mensen te kunnen vinden, want dat is uiteraard niet eenvoudig. We leiden talenten eerst op binnen onze interne producten. Voordat een ontwikkelaar aan een klantproduct mag werken, brengt diegene enige tijd door aan een intern product om het vak te leren, onze werkwijzen te delen en die productmindset te ontwikkelen.

Daarna kan die persoon als een soort eenmansorkest met de klant werken. Hetzelfde geldt echter voor andere rollen. Niet alleen ontwikkelaars — iedere Railswarian, zoals we elkaar hier noemen, kan zelfstandig werken. De meesten hebben managementervaring of hebben zelfs een eigen bedrijf geleid. Dat geldt voor HR-medewerkers, ontwerpers, productmanagers en eigenlijk bijna iedereen.

Niemand van ons is echter de directe manager van het team. Je wordt een autoriteit door het principe van leidinggeven door het goede voorbeeld te geven. Je leidt het product en laat daarmee aan het team zien dat je het waard bent om het team te leiden. Je kunt niet alleen vertellen wat er moet gebeuren. Je doet zelf je best om impact te maken op het product en het algemene resultaat. Zo gaat het team je vertrouwen en hetzelfde doen.

Galen Low: Dat vind ik geweldig. Jullie geven prioriteit aan een T-vormig team met veel verschillende ervaringen. Ik zou later graag dieper ingaan op het wervings- en onboardingproces.

Die ervaring gaat dus niet alleen over technische vaardigheden, maar ook over managementervaring en het hebben geleid van een eigen bedrijf en eigen teams. Dat is waardevol en belangrijk, ook al gaan mensen een rol vervullen in een team dat in feite vrij plat is georganiseerd.

Je hebt eerder verteld dat je een achtergrond in projectmanagement hebt en ooit een PMO leidde. Vond je het idee van zelfsturende teams ooit onaangenaam of zelfs bedreigend?

Julia Ryzhkova: Ja, grappig dat je dat vraagt. Dat was inderdaad zo tijdens mijn proeftijd bij Railsware. Wanneer je de enige held bent en alles zonder jou uit de hand loopt, is het gemakkelijk om je eigen noodzaak voor het bedrijf te beoordelen. Je bent elke dag bezig en voelt je veilig.

Maar wanneer alles ook zonder jou goed gaat, voel je de impact niet meer op de manier die je gewend was. Je voert veranderingen door, implementeert een nieuw proces en verbetert iets. Er verandert inderdaad iets, maar slechts een beetje. Je aanwezigheid maakt de zaken beter, maar je voelt dat je twee weken vakantie kunt nemen zonder dat alles instort. Dan vraag je je af: waarom hebben ze mij nodig?

Op een gegeven moment stop je echter met alles te willen controleren. Met de vrije tijd die je krijgt, vind je andere manieren om impact te maken.

Je richt je op het product, de klant en de strategie. Met de tijd die je hebt, kun je zelfs een grotere impact maken. Als je het team meer ruimte geeft, kunnen ze binnen de gilde iets geweldigs creëren. We hebben squads met vier engineers en één QA-specialist. Daarnaast hebben we een engineeringgilde, een QAgilde en een productmanagementgilde.

Het productmanagementgilde heeft bijvoorbeeld het BRIDGeS-framework gebouwd dat ik aan het begin noemde. Iets dergelijks kun je niet bouwen als je daar geen ruimte voor hebt.

Galen Low: Dat vind ik een belangrijk punt. De beste projecten zijn vaak teams die op de een of andere manier onafhankelijk of zelfsturend zijn. Dat betekent niet noodzakelijk dat de projectmanager wordt buitengesloten, maar wel dat het team voldoende bevoegdheden heeft om richting te krijgen en ermee aan de slag te gaan.

Als projectmanagers beschrijven we de micromanagementkant vaak als het bijeenhouden van alles en ervoor zorgen dat zaken worden opgeleverd. Maar uiteindelijk gaat het om begeleiding, richting geven, een team inspireren en mensen in staat stellen hun beste werk te doen.

Het klinkt dus alsof dat de cultuur is. Niet dat Julia niet meer nodig is, maar dat Julia of de projectmanagementrol naar een hoger, strategischer niveau kan worden gebracht. Ik vind het ook mooi dat je gewoon vakantie kunt nemen.

Zie je jezelf nu als een soort dirigent van het orkest?

Julia Ryzhkova: Dat kun je inderdaad zo zeggen.

Galen Low: Gebruik je nog steeds vaardigheden uit projectmanagement? Heb je als productmanager voordeel gehad van je achtergrond in projectmanagement?

Julia Ryzhkova: Zeker. Ik kan me moeilijk voorstellen dat iemand productmanager kan zijn zonder enige achtergrond in projectmanagement. Dat is een cruciaal onderdeel. Mijn technische achtergrond heeft me voordelen opgeleverd, maar projectmanagementvaardigheden zijn cruciaal voor een productmanager.

Als onderdeel van onze vaardighedenmatrix hebben alle seniorfuncties bij Railsware projectmanagementvaardigheden nodig. Communicatie is bijvoorbeeld voor ons essentieel. We hebben gemerkt dat die vaardigheden nuttig zijn voor het totale resultaat.

Als we naar specifieke vaardigheden kijken, zijn scope-, kosten-, plannings- en stakeholdermanagement nog steeds aanwezig. Integratie- en communicatiemanagement doe ik nauwelijks; dat hoort bij zelfmanagement. Kwaliteitsmanagement ligt bij QA en engineering. Risicomanagement wordt verdeeld over alle teamleden, net als inkoop.

Als je iets nodig hebt voor je werk, maak je gewoon een inkoopverzoek en leg je uit waarom je het nodig hebt. Ik hoef niet te begrijpen waarom marketing een bepaalde outreachtool nodig heeft of waarom een ontwikkelaar een specifieke bibliotheek nodig heeft. Het is prettig dat ik dat niet hoef te doen.

Galen Low: Wat ik vooral interessant vind, is dat alle seniorfuncties projectmanagementvaardigheden hebben. Scope, kosten, planning en stakeholdermanagement zijn natuurlijk onderdeel van het werk, maar ook van zakendoen en op een duurzame en verantwoordelijke manier dingen gedaan krijgen.

Is dat onderdeel van het wervingsproces? Of krijgt iemand die een seniorfunctie gaat vervullen projectmanagementtraining?

Julia Ryzhkova: Met seniorfuncties bedoel ik ook engineers en QA-specialisten, niet alleen kantoormanagers. Voor alle functies die bijdragen aan producten en projecten geldt dat mensen op zijn minst zichzelf moeten kunnen managen: hun scope, planning, kosten en inkoop. Dat verwachten we van iedereen. Daarom zoeken we volwassen ontwikkelaars en volwassen andere teamleden.

We verwachten niet dat iemand een specifieke projectmanagementopleiding of een formele achtergrond heeft. Iedereen doet al iets van projectmanagement zonder het te beseffen. Wij kunnen die vaardigheden uitbreiden, maar we leren ze niet vanaf nul aan.

Galen Low: Dat vind ik goed. Als digitale product- en projectmanagers moeten we veel leren over de vakgebieden van de teams om ons heen. Tegelijkertijd kunnen we meer van ons vak met hen delen: dingen gedaan krijgen, onszelf managen, samenwerken en inzicht hebben in de zakelijke kant.

We bouwen niet zomaar dingen voor ons plezier. We bouwen ze voor gebruikers en klanten, binnen bepaalde beperkingen. De vraag is hoe we binnen die beperkingen verantwoord kunnen opereren.

Laten we dieper ingaan op hoe dit allemaal werkt. Vooral voor mensen die deel uitmaken van een organisatie of een organisatie of team leiden dat een model als dit onderzoekt. Waar moeten zij rekening mee houden?

Het valt me op dat clusters van kleine, zelfsturende teams die samenwerken waarschijnlijk veel duidelijk gedefinieerde processen en een zeer goede onboarding vereisen. Hoe communiceren deze squads met elkaar en blijven ze op één lijn?

Julia Ryzhkova: Dat is waarschijnlijk onderdeel van de cultuur. Toen Railsware nog maar twee oprichters had, definieerden zij processen en beheerden die als eenvoudige takenlijsten. Ze deden het wel. Ze hadden een gestructureerde aanpak en documenteerden alles.

Ze zochten mensen die dezelfde cultuur deelden. Dat is niet gebruikelijk bij kleine bedrijven. Meestal beginnen mensen pas over processen na te denken wanneer alles uit elkaar valt. Bij Railsware gebeurde dat vanaf het fundament. Daarom werd het onderdeel van de cultuur.

We hebben onboarding als proces en het principe: documenteer terwijl je bezig bent. Elke vergadering kan aan een gedeeld document of Figma-bord worden gekoppeld. Iedereen die aan de vergadering deelneemt, maakt vóór of tijdens de vergadering notities, niet erna.

We maken dus geen uitgebreide notulen nadat de vergadering is afgelopen. We bereiden de notities vooraf voor. Als iemand iets deelt dat buiten de bestaande documentatie valt, schrijven de anderen het op zodat alles wordt vastgelegd.

Na twee weken vakantie kan ik enkele documenten openen en lezen. Dan weet ik wat er is gebeurd en waar we nu staan, zonder extra synchronisatie. Niets blijft ongedocumenteerd.

Dit maakt deel uit van een transparante cultuur. Communicatie vindt plaats in openbare kanalen en Slack-kanalen. We hebben er meer dan driehonderd en bijna geen privégesprekken over het werk. Alles wordt publiekelijk gedeeld. Iedereen kan het lezen en soms sneller antwoorden dan de persoon aan wie de vraag oorspronkelijk was gericht.

Je kunt een kanaal lezen en begrijpen wat er tijdens je afwezigheid is gebeurd.

Galen Low: Dat is heel interessant. Veel groepen die ik spreek proberen asynchrone communicatie onder de knie te krijgen. Je kunt dan alle gesprekken terugvinden omdat ze voor je staan.

Railsware was vanaf de eerste dag vooruitstrevend met die twee oprichters en eenvoudige takenlijsten. Het hoeft niet uitgebreid te zijn; het moet alleen ergens worden vastgelegd op een manier die anderen begrijpen.

Julia Ryzhkova: Ik bewonder dat. In mijn trainingen over bedrijfsprocessen leerde ik vroeger dat je pas op een bepaald moment bedrijfsprocessen nodig hebt, niet noodzakelijk vanaf het begin. Als je alleen bent in je bedrijf en weet hoe je dingen moet doen, heb je ze niet nodig.

Nadat ik de geschiedenis van Railsware had leren kennen, besloot ik dat te veranderen. Nu zeg ik dat je er vanaf het begin mee moet beginnen. Het kan heel eenvoudig zijn, bijvoorbeeld een checklist, maar je moet het doen.

Zelfs bij persoonlijke zaken maak je een lijst. Als je bijvoorbeeld een nieuwe baan zoekt, maak je een lijst met bedrijven en doorloop je voor elk bedrijf een proces. Je moet ergens vastleggen waar je bent en wat de volgende stap is. Dat is ook een takenlijst en je hebt die nodig, anders is het helemaal niet beheersbaar.

Ik ben gaan denken dat je geen processen kunt missen als je zaken wilt doen.

Galen Low: Ik vraag me af of we het kunnen hebben over teammetrics. In dit model vragen veel luisteraars zich waarschijnlijk af welke prestatie-indicatoren het belangrijkst zijn om te volgen en om te weten of alles op schema ligt. Het team werkt zelfstandig en de verantwoordingsstructuur is vrijwel gedeeld. Hoe weet je dat alles verloopt zoals gepland? Wat volg je?

Julia Ryzhkova: Ik volg helemaal geen prestatiemetrics. Misschien klinkt dat onrealistisch, maar het is echt zo. In plaats daarvan volg ik productmetrics.

We volgen hoe we groeien en of onze SaaS-metrics goed presteren. We kijken naar conversie, omzet en dergelijke. Ik volg wel de teamsnelheid, maar niet als prestatiemetric. Ik heb die nodig om te voorspellen wat we binnen een release en in de komende drie maanden kunnen doen. Planningsmanagement is nog steeds aanwezig.

Ik pas de snelheid toe op toekomstige epics en schattingen om de vroegst mogelijke opleverdata te voorspellen. Wanneer je elke dag of minimaal eens per twee weken naar productie oplevert, is het niet erg als iets twee weken later komt. Niemand gaat dood als het nog twee weken duurt.

De squads beheren hun eigen prestaties. Ze doen dat met pair programming met nieuwe medewerkers, kruistesten en code reviews. Ze volgen hun eigen prestaties en maken duidelijk aan elkaar wat moet worden verbeterd.

Dat zie ik tijdens stand-ups en retrospectives. Stakeholders en zelfs product owners hoeven niet aan de retrospectieve van het ontwikkelteam deel te nemen. Ik was vanaf het begin betrokken bij de retrospectives en we betrekken de klant erbij. Het team deelt feedback over elkaars prestaties duidelijk en transparant.

Die feedbackcultuur staat op een hoog niveau. Een nieuwe medewerker krijgt feedback van alle teamleden. Iedereen kan een prestatie- of kwaliteitsprobleem benoemen. Een nieuwe medewerker kan op zijn beurt feedback geven over onze processen, het bedrijf of mij als productmanager.

Er zijn dus eigenlijk maar twee mogelijkheden: iemand slaagt niet voor de proeftijd of presteert goed, waarna we de prestaties niet voortdurend hoeven te controleren.

Galen Low: Interessant. Kan dat soms intens worden?

Julia Ryzhkova: Dat kan. Meestal zit iedereen echter op één lijn. Als iemand een probleem ziet, ziet iedereen het en delen we die feedback. Ik heb daar geen grote problemen gezien.

Galen Low: Het zit dus ingebakken in de cultuur en in de manier waarop jullie teams aannemen. Jullie brengen mensen binnen die al op deze manier denken en bereid zijn deze gesprekken te voeren, samen te groeien en feedback te geven, te delen en te ontvangen.

Julia Ryzhkova: Dat controleren we inderdaad tijdens het wervingsproces. We besteden daar veel tijd en energie aan.

Voor productmanagers reserveren we bijvoorbeeld een volledige dag waarin we samen aan een probleem werken. Een productmanager werkt dan acht uur samen met andere productmanagers. Die persoon doet iets, wij geven feedback en we zien hoe diegene daarop reageert.

Dat is vanuit het bedrijf gezien een grote investering: een C-levelmanager en een productmanager besteden er een volledige dag aan. Ook voor kandidaten is het een grote inspanning. Je krijgt geen aanbod voordat je een volledige dag hebt vrijgemaakt om dit proces te doorlopen.

Het resultaat is echter geweldig. We leren elkaar kennen en begrijpen of er een culturele match is. We beoordelen iemand niet alleen technisch, maar ook op de manier waarop diegene feedback geeft, ontvangt en erop reageert, en zelfs of we hetzelfde gevoel voor humor hebben.

Zo krijgen we mensen die deel kunnen uitmaken van die feedbackcultuur.

Galen Low: Dat vind ik goed. In hedendaagse wervingsprocessen zijn er veel willekeurige tests. Wat laat zien dat je echt investeert in de juiste match of aanvulling op je team, is dat een productmanager en een C-levelmanager een dag of twee met kandidaten samenwerken om te zien of de samenwerking werkt.

Niet iedere organisatie kan dat doen, maar als je zeker wilt zijn van je mensen, is het een uitstekende aanpak.

Julia Ryzhkova: Voor kandidaten leggen we uit dat het ook een investering van hun kant is. Zo voorkomen zij dat ze drie maanden in een proeftijd zitten om daarna te ontdekken dat dit geen bedrijf is waar ze kunnen werken. Vanuit ons perspectief doen we dit niet voor elke rol een hele dag. Afhankelijk van de functie kan het twee of vier uur duren. We hebben die tijd nodig om elkaar te leren kennen.

Galen Low: Dat is logisch. Je zei eerder dat wanneer iets twee weken wordt uitgesteld, niemand noodzakelijkerwijs doodgaat. Maar als productmanager beheer je de productroadmap en doe je beloften aan klanten over functies. Wat gebeurt er wanneer dingen veranderen?

Wat gebeurt er wanneer je de roadmap bijwerkt, de backlog opnieuw prioriteert of de opleverdatum wijzigt? Welk gedrag verwacht je van je teams wanneer ze met verandering worden geconfronteerd?

Julia Ryzhkova: Je zult misschien opnieuw verrast zijn, maar eigenlijk gebeurt er niets bijzonders. Ik kan iets uit een sprint halen en een andere taak toevoegen. Ik leg uit waarom en geef de context. We bespreken het en dat is het.

Ik kan de backlog zelfs midden in een sprint wijzigen. Als het om één of twee taken gaat, stoppen we de sprint niet. We plannen een vergadering om te bespreken wat er moet gebeuren, maken een inschatting en synchroniseren. Dat is alles.

Ik wijzig de roadmap niet vaak. Meestal herzie ik die één keer per maand op basis van nieuwe inzichten, nieuwe metrics en wat ik in onze dashboards heb gezien.

Het team kent de productvisie en neemt deel aan strategische synchronisaties met C-levelmanagers. Ze kunnen vanuit technisch perspectief aangeven of iets opnieuw moet worden bekeken of dat prioriteiten moeten veranderen.

Toen we bijvoorbeeld het prijsmodel wijzigden, deelde een van onze engineers informatie over een systeem waarmee we bij veel klanten integreren. Dat systeem had zijn prijsmodel ook veranderd, waardoor onze prijzen niet meer op elkaar aansloten. De engineer stelde voor onze limieten opnieuw te bekijken en die informatie mee te nemen.

Dat was geweldig. We bespraken het prijsmodel en kregen input van een engineer. Dat had ik niet verwacht. Dat is het team waarmee ik werk.

Tijdens mijn eerste zes maanden heb ik de projectmanagementtool drie keer gewijzigd. We gingen van Trello naar Coda, vervolgens naar Pivotal Tracker en daarna naar Jira, totdat ik de twee tools vond die werkelijk aan al onze behoeften voldeden. Het team vroeg alleen: hebben jullie onze hulp nodig, of geef je ons vijftien minuten training over de nieuwe tool?

Dat klinkt geweldig en daarom inspireert het team me zo.

Galen Low: Zeker bij het wijzigen van projectmanagementsoftware kan dat voor veel mensen moeilijk zijn. Mensen hechten zich aan de stabiliteit van een tool die ze kennen. Wat hieruit voor mij naar voren komt, is het belang van mensen met een productmindset, zelfs op engineering-, ontwerp- en marketingniveau.

Als je uitlegt waarom iets verandert — waarom het prijsmodel moet veranderen of waarom een functie belangrijker is dan een andere — begrijpt het team dat het in het belang is van de klant, eindgebruiker of het product als geheel. Het gaat niet om: ik was al halverwege. Het gaat om het grotere belang.

Een product is verandering. Bij projecten en projectmanagement bestaat soms de neiging om stabiele perfectie na te streven. Maar de taak is juist reageren op verandering en vooruitkijken. Je hebt snelheid nodig om te plannen en voorspellingen te doen. Je hebt organisatie, communicatie en scope nodig, maar dingen zullen veranderen.

We kunnen niet vertrouwen op een plan dat zes maanden geleden is gemaakt en zes maanden later nog steeds perfect accuraat is. Succes hangt af van hoe we op veranderingen reageren en hoe onze teams daarop reageren.

Julia Ryzhkova: Terwijl je sprak, dacht ik aan een recent gesprek met een ontwikkelaar. Hij zei dat hij stabiliteit voelde omdat we een backlog voor de komende sprints hebben. Het maakt hem echter niet uit als die backlog volledig verandert. Hij weet gewoon dat er werk is.

In Jira heb ik vier sprints voor de toekomst die gevuld zijn met taken. Het maakt hen niet uit wat precies op nul staat. Ze kijken naar de roadmap en kennen de visie. Ze moeten begrijpen dat wij die visie ook kennen en dat we op hoofdlijnen delen wat we volgend jaar en de jaren daarna willen doen.

Het maakt niet uit hoe we daar precies komen. We bespreken de gevulde backlog met taken tijdens de refinement vlak vóór het begin van de sprint. Ze weten dat er werk is en dat geeft een gevoel van stabiliteit en veiligheid.

Galen Low: Dat is vertrouwen door transparantie. Jullie delen de visie en het plan en laten mensen deelnemen. Ze zijn niet alleen uitvoerende handen, maar maken deel uit van het productteam dat de koers bepaalt.

Dat vertrouwen geeft het team voldoende richting om onafhankelijk en zelfvoorzienend te zijn, met een gevoel van stabiliteit.

We hebben het gehad over de backlog en wijzigingen midden in sprints. In jouw visie werkt dit alleen met Agile softwareontwikkeling, of kan dit model ook worden gebruikt door crossfunctionele teams die andere soorten producten maken?

Julia Ryzhkova: Je moet zeker Agile zijn, maar Agile uit het Agile-manifest gaat niet over het maken van software.

Al onze squads gebruiken vergelijkbare benaderingen. De marketingsquad, financiële squad en operationele squad werken ook met schattingen. We doen refinement en roadmapping, schatten HR-projecten met storypoints en plannen en volgen de snelheid. Iedereen kan dat gebruiken.

Galen Low: Dat zou een hele andere podcastaflevering kunnen zijn. Veel luisteraars denken waarschijnlijk: ik wou dat mijn marketingteam Agile werkte vanuit een backlog en in sprints. We komen daar in veel organisaties langzaam naartoe, maar niet-ontwikkelings- en niet-ontwerpteams bieden vaak nog weerstand.

Sommige mensen denken dat Agile niets voor hen is. Toch gaat het hier om wendbaarheid en kunnen reageren op verandering, en daarvan kan elke afdeling en elk team profiteren.

Julia Ryzhkova: Engineering werkt bijvoorbeeld met Scrum, net als het ontwerpteam. Marketing werkt met Kanban. Zij hebben een roadmap en een Kanbanbord. Dat werkt beter voor hen. Het zijn allemaal Agile benaderingen.

Galen Low: Dat is logisch, omdat marketing deels operationeel en doorlopend is.

Laten we naar de interessante implicaties gaan. Mensen plaatsen projecten onder leiding van een projectmanager en zelfsturende teams vaak tegenover elkaar, alsof één van beide modellen perfect is. Geen enkel model is perfect.

Voor mensen die overwegen naar dit model over te stappen: wat gaat er mis wanneer het niet goed gaat?

Julia Ryzhkova: We hebben enkele problemen op hoog niveau. Een squad weet niet altijd wat er binnen een andere squad gebeurt.

We hebben bijvoorbeeld twee eigen producten: Mailtrap en Coupler.io. Het ontwikkelteam van Coupler.io ontwikkelde veel nieuwe functies die ons kleine marketingteam niet met content en landingspagina's onder de aandacht kon brengen.

Bij Mailtrap gebeurde het omgekeerde. Daarom besloot het management teams te wisselen: een deel van het marketingteam van Mailtrap ging naar Coupler.io en een deel van het engineeringteam van Coupler.io ging naar Mailtrap om beide producten te versterken.

Dat soort beslissingen kan niet binnen één squad worden genomen, omdat die de grote geheel niet ziet. Bedrijfsbrede beslissingen moeten door het management worden genomen.

Galen Low: Dat is eerlijk. Wie neemt zulke beslissingen? Is dat jouw rol of iemand in operations?

Julia Ryzhkova: Dat is een soort C-levelrol. Ik weet hoe het met mijn product gaat en deel tijdens strategische synchronisaties dat we vooroplopen in ontwikkeling en meer marketingmiddelen nodig hebben. Bij Mailtrap gebeurt hetzelfde: de productmanager daar ziet dat marketing voorloopt en dat er meer ontwikkelmiddelen nodig zijn.

De C-levelmanagers zijn niet betrokken bij micromanagement. Eén keer per maand kunnen zij dit soort beslissingen nemen. Ze worden niet overspoeld door details en kunnen het helder zien: teams wisselen, ga je gang.

Galen Low: Was dat een permanente verandering of was het tijdelijk om capaciteitsproblemen op te lossen?

Julia Ryzhkova: Ik zou zeggen dat het tijdelijk is, maar er zijn twee mogelijkheden. Je kunt nieuwe ontwikkelaars en marketeers aannemen, of je kunt de teams terugwisselen.

Momenteel doen we een combinatie daarvan. We zijn nog niet klaar met de verandering, maar dat is geen probleem. We zijn Agile. Als we binnen een halfjaar drie tools kunnen veranderen, kan een team ook een halfjaar of zelfs een jaar naar een ander product worden verplaatst.

Galen Low: De oorzaak ligt uiteindelijk bij afstemming. Squads moeten op één lijn zitten. De marketingafdeling moet niet promoten wat nog niet klaar is en het ontwikkelteam mag niet zoveel functies opleveren dat marketing het niet kan bijhouden.

Hoe vaak praten de marketing- en engineering-squads van Coupler.io met elkaar?

Julia Ryzhkova: Dat hangt ervan af. We hebben demo's waarin het engineeringteam laat zien wat in de vorige iteratie is gedaan en wat we gaan uitbrengen. Daarnaast hebben we wekelijks overleg waarin ik deel waar we aan werken en wat in de volgende iteratie wordt uitgebracht.

We bespreken of landingspagina's moeten worden bijgewerkt en of we releasenotities moeten publiceren. Marketing zet dit op een shortlist. Zij hebben een algemene roadmap met grote marketingprojecten en reserveren een deel van hun capaciteit voor ondersteuning van het ontwikkelingsteam. Hetzelfde geldt voor het ontwikkelteam.

We hebben een proces voor ideeën en verzoeken. Iedereen in het team kan een verzoek maken dat in de backlog van iemand anders moet worden opgenomen. We beoordelen die verzoeken wekelijks.

Als iets niet bij de visie past, zetten we het in de ijsbak. Als het prioriteit krijgt, nemen we het op in de roadmap en in een komende sprint om iets te verbeteren. Zo blijven de teams op één lijn.

Marketing kan bijvoorbeeld vragen om het ontwerp van de website of landingspaginasjablonen te verbeteren. Dat nemen we op in de ontwikkeling. Andersom kan een ontwikkelaar vragen om een e-mailtemplate met goede tekst en vormgeving voor de applicatie.

Galen Low: Dat is interessant. We hebben nog niet veel gesproken over geografie en tijdzones. Jullie squads zijn over verschillende landen en tijdzones verspreid. Zijn er inefficiënties die je moet compenseren om met een gedistribueerd team efficiënt te kunnen werken?

Julia Ryzhkova: Ik zou het tegenovergestelde zeggen. Op afstand werken geeft je de mogelijkheid meer tijd te besteden en efficiënter te zijn. Soms is het moeilijk om een gesprek te plannen tussen een ontwikkelaar in Argentinië en een productmanager in Thailand. Je moet je werk en planning aanpassen om op een geschikt moment te kunnen synchroniseren.

Dat is eigenlijk het enige probleem dat ik kan bedenken.

Het grootste deel van ons team werkt op afstand, meer dan 80 procent, uit meer dan vijftien landen. De gedeelde documenten en openbare kanalen maken het mogelijk alles goed te organiseren.

Omdat we asynchroon werken en communiceren, hoef je niet veel tijd te besteden aan het plannen van onlinevergaderingen volgens internationale agenda's.

Galen Low: Asynchroon werken betekent dus niet dat je nooit vergadert. Je kunt nog steeds vergaderen wanneer dat nodig is. Soms moet je flexibel zijn met je planning en buiten je normale werktijden afspreken, wat ook helpt om te bepalen of een vergadering echt belangrijk is.

Asynchroon betekent niet dat er nooit synchrone communicatie is. Ook zijn op afstand werken en thuiswerken niet hetzelfde. Je kunt op afstand werken en toch een kantoor hebben.

Documentatie en een transparante cultuur zijn essentieel. Daardoor heb je niet talloze vergaderingen nodig die veel planning vereisen en mensen inefficiënt maken. Het gaat om een toegankelijk spoor van communicatie.

Is projectmanagement binnen zulke zelfsturende teams een soort stigma? Zijn teams afkerig van een projectmanager omdat ze nooit gemanaged willen worden?

Julia Ryzhkova: Ik denk niet dat er hier sprake is van een stigma.

We experimenteren graag en niemand is verplicht iets op een bepaalde manier te doen. Mensen hoeven geen volledige PM-opleiding te volgen. We delen belangrijke kennis tijdens gildebijeenkomsten als onderdeel van vakontwikkeling.

Ik heb het operationele team bijvoorbeeld geleerd hoe je schattingen maakt en wat storypoints zijn. Ik kan ook basiskennis over Kanban of Scrum delen.

Als je het gevoel hebt dat je een basistraining projectmanagement nodig hebt, kun je je opleidingsbudget gebruiken. Toch is het efficiënter om kennis te delen op het moment dat die nodig is.

Galen Low: Het gaat dus om het delen van onderdelen van het vak, niet om van iedereen projectmanager te maken. Net zoals projectmanagers niet noodzakelijk engineers proberen te worden. Het gaat om de vaardigheden die ons helpen samen te werken en goed werk op te leveren.

Mijn grote vraag: zie je zelfsturende squads als de toekomst van projectmanagement, nu je ooit projectmanager en PMO-leider was en nu een veel strategischere rol als productmanager vervult?

Julia Ryzhkova: Ik denk dat het zeker de toekomst is van succesvolle productbedrijven.

Zelfsturende teams stellen projectmanagers in staat zich te richten op strategie, product en klant. Dan kun je eindelijk werken aan het belangrijke maar niet urgente werk.

De teams ruimen het urgente maar niet belangrijke werk op dat projectmanagers normaal gesproken veel tijd en energie kost. Je kunt echter niet verwachten dat iedereen zelfsturend is, vooral niet direct na het afstuderen en aan het begin van een loopbaan.

Junior medewerkers hebben mentoring en coaching nodig, maar ook directe, klassieke aansturing. Er zijn ook mensen die zelf geen deadlines kunnen stellen en zonder deadlines niet effectief werken. Dat kan zelfs bij senior technische experts voorkomen.

Er blijft dus altijd ruimte voor klassiek projectmanagement.

Toch geloof ik dat elk bedrijf of team dat uitzonderlijke productresultaten wil behalen, uiteindelijk het punt moet bereiken waarop zelfmanagement direct projectmanagement deels vervangt. Daardoor komt tijd vrij voor strategie en algemene procesverbetering in plaats van het oplossen van elk afzonderlijk probleem.

Galen Low: Ik vind het onderscheid tussen urgent en belangrijk sterk. Projectmanagers in een klassieke rol voelen zich vaak overweldigd en willen strategischer werken. Het antwoord ligt in de mensen in je team, de cultuur die je creëert en de processen die het team in staat stellen zelfstandig te werken.

Dat betekent niet dat je baan verdwijnt. Je kunt juist strategischer werk doen en je richten op wat belangrijk is in plaats van alleen op wat urgent is.

Julia Ryzhkova: Projectmanagement is ook belangrijk werk. Ik ben misschien minder projectmanager dan vroeger omdat ik met een zelfsturend team werk. Maar bij andere soorten teams blijft de hoofdrol van de projectmanager: dingen gedaan krijgen.

De projectmanager is verantwoordelijk voor het afronden van het project binnen de planning en het budget. Dat is het hoofddoel. Zonder zelfsturend team kun je dat niet bereiken zonder directe betrokkenheid. Met een zelfsturend team kun je dingen gedaan krijgen zonder zo diep betrokken te zijn. Dan kun je nadenken over wat er moet gebeuren in plaats van precies uit te zoeken hoe het moet gebeuren.

Galen Low: Til de rol dus naar een hoger niveau en wees proactief.

Julia, deze inzichten zijn erg waardevol. Wat mij vooral bijblijft, is het idee van een productmindset. Het gaat niet alleen om nadenken over een product en zijn levenscyclus, releases enzovoort.

Het gaat om aanpassingsvermogen en openstaan voor verandering. Onze moderne opvatting van een product is niet dat je iets maakt en het daarna hetzelfde blijft. Een product wordt gestuurd door eindgebruikers, klanten en de markt, en al die zaken veranderen voortdurend.

Een productmindset gaat dus niet alleen over het vermogen om over een product na te denken, maar ook over het vermogen om op verandering te reageren, Agile en wendbaar te zijn en dat te accepteren. Je begrijpt waarom iets verandert, in plaats van het gevoel te hebben dat verandering je wordt aangedaan.

Dat betekent dat je baan verandert, de backlog verandert, je releaseschema verandert en je projectmanagementtools misschien drie keer per jaar veranderen. Dat bedoelen we met een productmindset. Een zelfsturend team moet die eigenschappen hebben om zich aan te passen en producten op een dynamische, Agile en wendbare manier te ontwikkelen.

Wat is je laatste advies voor een organisatie die wil overstappen naar kleine zelfsturende teams?

Julia Ryzhkova: Probeer het waarschijnlijk niet alleen — doe het gewoon. Begin met één klein team. Probeer deze aanpak niet meteen in de hele organisatie te implementeren als je een grote organisatie hebt.

Verzamel je beste mensen, geef hun de bevoegdheden die ze nodig hebben en zorg voor resultaten. Wanneer je de voordelen ziet, doe je alles wat nodig is om de aanpak naar het hele bedrijf over te brengen. Je hebt succes nodig en om dat te bereiken moet je beginnen met de mensen die het beste bij dit beeld passen.

Galen Low: Geweldig. Julia, heel erg bedankt dat je vandaag bij ons was. Ik vond ons gesprek erg interessant. Het was fascinerend om te leren hoe jullie organisatie dit probleem heeft aangepakt, hoe jullie zelfsturende squads werken en hoe het Agile proces binnen jullie productstudio werkt.

Ik hoop dat onze luisteraars veel hebben geleerd en geïnspireerd zijn geraakt om hun teams zelfsturender te maken zonder de onderliggende angst dat projectmanagers in de toekomst niet meer zullen bestaan.

We zouden je graag terugvragen om te praten over hoe dit zich ontwikkelt. Ook horen we graag meer over hoe AI zijn weg zal vinden naar het Coupler.io-product.

Julia Ryzhkova: Ik hoop dat ik deze inzichten met jullie kan delen.

Galen Low: Heel interessant. Nogmaals bedankt.

Julia Ryzhkova: Bedankt. Het was erg leuk om hierover te praten en dit te delen, omdat al deze onderwerpen mij erg inspireren. Ik hoop dat het iemand anders inspireert om hetzelfde te doen en van de resultaten te genieten.

Galen Low: Geweldig. Nogmaals bedankt.

Julia Ryzhkova: Bedankt.

Galen Low: Wat denk jij? Zijn zelfsturende teams de weg van de toekomst, of hebben ze beperkingen waardoor ze ongeschikt zijn voor bepaalde soorten organisaties en sectoren?

Vertel ons een verhaal. Wat is het meest zelfsturende projectteam waarmee je hebt gewerkt en hoe ging dat? Wat was daarentegen je meest frustrerende ervaring met het bijeenhouden van alles, terwijl je liever strategisch bezig was? Deel je gedachten in de reacties hieronder.

En als je je vaardigheden als strategische projectleider wilt aanscherpen, kom dan bij onze community!

Ga naar thedigitalprojectmanager.com/membership voor toegang tot een ondersteunende community die kennis deelt, complexe uitdagingen oplost en samen de toekomst van ons vak vormgeeft.

Van robuuste sjablonen en maandelijkse trainingssessies die je tijd en energie besparen tot ondersteuning door vakgenoten via ons discussieforum, community-evenementen en mastermindgroepen: lid zijn van onze community betekent dat meer dan duizend mensen je steunen terwijl je je loopbaan in digitale projectoplevering vormgeeft.

Als je vandaag iets hebt gehoord dat je beviel, abonneer je dan en blijf in contact via thedigitalprojectmanager.com

Tot de volgende keer, bedankt voor het luisteren.