Wat betekent 10x-engineering voor technische programmamanagers?

Galen Low: Van technische programmamanagers wordt doorgaans niet verwacht dat ze code schrijven, maar tegenwoordig geldt dat ook niet meer voor software-engineers, althans niet met de hand. De vraag is dus niet per se of TPM's moeten kunnen coderen. De vraag is: hoeveel diepgang is er nodig om technische programmamanagers hun toegevoegde waarde te laten verschuiven in een wereld waarin de teams om hen heen AI gebruiken om vijf, tien en soms vijftig keer sneller te werken dan enkele jaren geleden?

Om te onderzoeken hoe de rol van een technische programmamanager zich ontwikkelt in de huidige software-industrie, heb ik een VP Delivery en Engineering Operations uitgenodigd die teams van TPM's heeft geleid bij organisaties als Dell en Google, maar ook in andere snelgroeiende softwareomgevingen. Samen onderzoeken we alles, van de vaardigheden waar tegenwoordig vraag naar is bij TPM's tot de manier waarop deliverymanagers de waarde van hun team kunnen verdedigen wanneer er veranderingen in de leiding plaatsvinden.

We bespreken ook hoe personeelsmanagers TPM-kandidaten tijdens het wervingsproces kunnen beoordelen en wat de gevolgen zouden zijn als de rol van de TPM de weg van de dodo zou volgen. Ik wens je veel luisterplezier.

Welkom bij de Digital Project Manager Podcast — de show die deliveryleiders helpt slimmer te werken, soepeler te leveren en hun teams vol vertrouwen te leiden in het tijdperk van AI. Ik ben Galen en elke week duiken we in strategieën uit de praktijk, opkomende trends, bewezen raamwerken en zo nu en dan een waargebeurd verhaal uit de frontlinies van projecten. Of je nu enorme transformatieprojecten aanstuurt, AI-workflows in goede banen leidt of gewoon probeert de chaos onder controle te houden: je bent hier op de juiste plek.

En als je de afgelopen tijd graag naar ons hebt geluisterd, overweeg dan om ons te volgen op het platform waar je ons vindt en misschien zelfs een beoordeling achter te laten. Goed, laten we beginnen.

Vandaag is Satish Menon bij me, een leider op het gebied van technisch programmamanagement en engineering operations die delivery heeft aangestuurd bij technologiereuzen als Google en Dell, maar ook bij softwarebedrijven als Tenable, Cohesity en Seismic.

De programma's waarvoor Satish verantwoordelijk was, varieerden van hardware- en softwarelanceringen tot cloudinfrastructuur en producten voor datacenteroptimalisatie. Daarbij vertrouwde men op Satish' vermogen om beslissingen op directieniveau te navigeren, organisatorisch leiderschap te bieden, operationele strategieën te ontwikkelen en implementeren, processen te transformeren en advies te geven over productontwikkeling.

Tegenwoordig helpt Satish teams van technische programmamanagers om hun weg te vinden in de wereld van AI-ondersteunde software-engineering en programmamanagement. Tegelijkertijd verdedigt hij de waarde van de rol van de technische programmamanager in technologiegedreven organisaties.

Satish, hartelijk dank dat je vandaag bij me bent.

Satish Menon: Hé Galen. Bedankt voor de uitnodiging. Ik kijk ernaar uit.

Galen Low: Dit is de kleine routekaart die ik voor vandaag heb opgesteld. Eerst wil ik je een enigszins controversiële vraag voorleggen waarvan mijn luisteraars graag jouw visie horen. Daarna wil ik die vraag gebruiken als lens om naar drie dingen te kijken.

Ten eerste wil ik onderzoeken hoe de rol van de technische programmamanager wordt verstoord, vooral in de softwarewereld. We kunnen bespreken hoe afdelingshoofden en teamleiders de waarde van hun technische programmamanagers kunnen verdedigen. En daarnaast wil ik ingaan op de gevolgen van de vervaging van rollen tussen managers van softwareteams en technische programmamanagers.

Hoe klinkt dat?

Satish Menon: Geweldig. Ik kijk ernaar uit.

Galen Low: Mooi. Laten we erin duiken. Dit is mijn prikkelende openingsvraag. Technische programmamanagers zeggen dat ze niet hoeven te kunnen coderen om waarde te leveren. Ondertussen lijken veel technologieleiders het daar niet mee eens te zijn. Zij zeggen dat software-engineeringmanagers en technische programmamanagers door AI nu één en dezelfde rol zijn.

Dus mijn vraag is: wie heeft er gelijk? Heeft AI omstandigheden gecreëerd waarin het redelijk is dat organisaties van softwareteammanagers verwachten dat ze ook technische programmamanagers zijn, en omgekeerd?

Satish Menon: Je zult het met me eens zijn dat de rol van de software-engineer de afgelopen tijd enorm is veranderd, toch?

Ze zijn van het zelf schrijven van code — wat vroeger de flessenhals was — overgestapt op veelvuldig gebruik van vibe coding en AI-tools om code tien keer, of zelfs honderd keer, sneller te genereren. Het probleem is daardoor verschoven naar de beoordelingscyclus, zoals de beoordeling van pull requests. De omvang van pull requests is toegenomen. De last ligt nu dus bij het menselijke toezicht op wat AI in software genereert.

Op dezelfde manier waarop we veranderingen zien in de workflow, snelheid en werkzaamheden van software-engineers, moet er ook aan de kant van TPM's een vergelijkbare aanpassing plaatsvinden. Drie tot vijf jaar geleden bestond een groot deel van het werk uit vragen als: dit is het plan, maar wat is de status? Waar staan we? Hoe sluiten de afhankelijkheden op elkaar aan? Wat zijn de risico's en hoe beperken we die? Hoe doet QA het? Ligt de kwaliteitsborging van ons project op schema en is daar een risico? Ook het monitoren van bugs, bugreductie en testdekking hoorde daarbij.

Dat waren de problemen en die werden destijds grotendeels handmatig of semi-handmatig door TPM's afgehandeld. Daarna begonnen we dat vier of vijf jaar geleden te transformeren met Jira en Atlassian. Zodra je het plan had ingesteld, kwam de status automatisch naar boven. TPM's konden naar die dashboards kijken, beoordelen wat rood of geel was en zich vervolgens gaan bezighouden met het oplossen van problemen.

De rol veranderde dus van: ik maak een plan, verzamel statusinformatie, rapporteer risico's en faciliteer risicobeperking, naar: ik observeer live dashboards die me de status tonen en coördineer vervolgens de oplossingsgerichte probleemoplossing voor de rode en gele signalen.

Nu biedt AI nog meer mogelijkheden voor TPM's. Kijk bijvoorbeeld naar de tools die vandaag worden gebruikt. Aan de ene kant heb je Jira en aan de andere kant GitHub, waar de code wordt geschreven. Daarnaast heb je BrowserStack, waar kwaliteit en implementatie worden beheerd.

Als je deze drie verschillende tools, of andere tools die in gebruik zijn, met elkaar kunt vergelijken, krijg je rijkere dashboards, rijkere gegevens en een rijkere analyse van risico's en problemen. De rol van de TPM ontwikkelt zich op die manier. We hoeven niet langer handmatig uit te zoeken wat rood en geel is. We kunnen AI gebruiken om meerdere tools en de juiste signalen met elkaar te vergelijken en veel beter dan voorheen te bepalen waar de rode en gele signalen zitten.

Galen Low: Dat vind ik geweldig. Ik vind het een sterke manier om het verschuiven van de flessenhals te beschrijven, maar het gaat in feite om twee verschillende flessenhalzen.

Aan de engineeringkant schrijven programmeurs minder tijd handmatig code. Ze werken met Cursor, kunnen sneller werken en daardoor verschuift de flessenhals naar de beoordeling. Als je het hebt over een manager van een engineeringteam, betekent dat juist meer beoordelingswerk, toch?

De flessenhals verschuift. Er is waarschijnlijk meer code om te beoordelen en toezicht op te houden. Zij leveren waarde door die pijplijn in beweging te houden en problemen aan de codekant snel op te lossen. Daar kunnen ze dus meer waarde leveren.

Dat betekent niet dat er vervolgens extra capaciteit ontstaat om ook technisch programmamanagement te doen. Aan de andere kant lag de flessenhals vroeger bij het verzamelen van informatie en statusupdates. Ook onze rol wordt nu verstoord. We gebruiken andere tools, zoals Jira en AI, en een deel van die automatisering brengt ons dichter bij het oplossen van problemen. We zitten niet meer de hele dag duimen te draaien totdat we plotseling capaciteit hebben om toezicht te houden op een software-engineeringteam.

Ik vind die invalshoek goed. De verstoring vindt aan beide kanten plaats, maar dat betekent niet dat dit optelt tot één taart. Het zijn twee afzonderlijke zaken.

Satish Menon: Er is nog een ander aspect. Een software-engineeringmanager of -directeur is verantwoordelijk voor het leveren van hoogwaardige code die veilig en toegankelijk is en de juiste prestaties levert, met een behoorlijke snelheid.

Met AI verbeteren ze die snelheid. Maar als je verwacht dat ze ook verantwoordelijk zijn voor de cross-functionele onderdelen van die levering — afhankelijkheden van andere softwareteams, het waarborgen van voldoende code- en testdekking, performance- en schaalbaarheidstests, systeemintegratietests en het op tijd leveren van het product aan klanten — dan leg je hun een extra last op.

Daar komen ook de opleveringen van infrastructuur-, branching- en DevOps-teams bij, evenals de verwachtingen vanuit het veld, technische documentatie en communicatie naar het veld. Er zijn zoveel cross-functionele aspecten. Iemand moet daarvoor zorgen. TPM's kunnen dat met behulp van al deze tools veel efficiënter en sneller doen, maar het moet wel gebeuren.

Als je verwacht dat software-engineeringdirecteuren en -managers dat er ook bij doen, is dat een extra belasting. Er is nog een aspect. Het is nuttig om de analogie van verkeersveiligheid te gebruiken. We hebben instanties die rijbewijzen uitgeven, auto's registreren en ervoor zorgen dat de verkeersregels bekend zijn.

Maar er is ook verkeerspolitie die boetes uitdeelt en ervoor zorgt dat mensen die de regels overtreden door willekeurige of systematische controles worden bestraft. Voor een goed systeem heb je beide nodig. Je kunt niet alleen rijbewijzen uitgeven, elke auto registreren en mensen leren veilig te rijden en vervolgens een goed resultaat verwachten.

Je hebt controlemechanismen en tegenwicht nodig.

Galen Low: Dat vind ik sterk, want er vindt momenteel veel automatisering plaats in allerlei verschillende functies, vooral in technisch programmamanagement en software-engineering. Soms hoor ik mensen praten over het automatiseren van processen met raamwerken, zodat alle regels zijn vastgelegd en mensen ze alleen maar hoeven te volgen.

Maar zoals jij zegt: dat is niet waar mensen goed in zijn. Er zullen altijd mensen zijn die problemen tegenkomen, die de regels misschien bewust overtreden of die niet begrijpen waar de prioriteiten liggen. Uiteindelijk heeft iemand nog steeds de taak om het proces te begeleiden.

Minder dan vroeger, maar er is nog steeds waarde. En je maakt een goed punt: er moeten veel puzzelstukjes samenkomen om een softwareproduct te leveren. Slechts een deel daarvan is codekwaliteit. De rest is cross-functionele orkestratie om ervoor te zorgen dat alles op het juiste moment samenkomt.

Als je wordt afgeleid door het managen van een team software-engineers — één-op-één-gesprekken voert, hun loopbaanmanager bent, codekwaliteit controleert en technische problemen helpt oplossen — dan is dat belangrijk werk. Als het echter ten koste gaat van de levering, wordt het moeilijk om tussen die twee prioriteiten te kiezen.

Je hebt teams van technische programmamanagers geleid bij bedrijven als Dell en Google en bij andere grote softwarebedrijven. We hebben het over probleemoplossing gehad. Een softwareteamleider lost misschien technische problemen op en de technische programmamanager lost ook problemen op, vooral omdat rapportages en dashboards hen proactiever maken.

Maar er is een kloof. Welke problemen kan een technische programmamanager oplossen zonder een achtergrond in programmeren? Welk niveau van technische vaardigheid verwacht je van je technische programmamanagers? Welke concepten moet iedere TPM die met software-engineers werkt begrijpen, en waarom?

Satish Menon: Dat brengt me bij een belangrijk punt. Een softwaremanager of -directeur kan projecten managen die volledig binnen de eigen organisatie vallen. Zodra een grotere oplevering afhankelijkheden tussen meerdere teams heeft, komt de TPM in beeld.

Dat gaat niet alleen om de cross-functionele samenwerking tussen engineering, productmanagement, design, het veld, go-to-market, technische documentatie enzovoort, maar ook om afhankelijkheden binnen de softwareoplevering zelf, dus afhankelijkheden tussen teams.

We moeten dit gesprek niet verlaten met het idee dat een softwaremanager of -directeur geen projectmanagement doet. Dat doen ze wel, maar voor opleveringen die volledig binnen hun organisatie vallen. Voor cross-functionele zaken werkt het veel beter om een TPM vanuit een neutrale positie te betrekken.

Wat het technische niveau betreft, ben ik er grotendeels voorstander van om TPM's te gebruiken of aan te nemen die in het verleden programmeur zijn geweest of veel ervaring hebben met programmeren. Daardoor kunnen ze de taal van engineers begrijpen, hun respect verdienen en goed met hen samenwerken. Als je hun taal niet begrijpt, verlies je respect.

Je moet een gelijkwaardige partner kunnen zijn. Je hoeft niet dagelijks code te schrijven, maar je moet de levenscyclus van code begrijpen: wat check-ins en commits zijn, wat een pull-requestbeoordeling en beoordelingscyclus zijn, wat linting en statische analyse betekenen, wat het verschil is tussen unit-, systeem-, integratie- en performancetests, en hoe implementatie werkt.

Als je eerder hebt gecodeerd, ken je dat. Na vijf tot tien jaar als goede TPM en naarmate je complexere zaken gaat behandelen, kan coderen wat roestig zijn geworden. Toch heb je de levenscyclus van code niet achter je gelaten.

Je moet ook de levenscyclus buiten de code begrijpen: vereisten, coderen, testen, piloteren, algemene beschikbaarheid, de checklist voor algemene beschikbaarheid en het verzenden van het product. Je moet dus zowel de bredere levenscyclus als de interne levenscyclus van de code en de engineers kennen.

Een tweede technisch niveau is kennis van het product dat je verzendt. Ik heb TPM's gezien die alleen een proces over een technische workflow konden leggen, maar niet wisten welke software precies werd ontwikkeld of wat die deed.

Veel systeemsoftware en SaaS-software is tegenwoordig complex in het gebruik door eindklanten. Als je dat begrijpt, heb je bij een nieuwe feature een veel beter beeld van wat er wordt ontwikkeld en wat je verzendt. Je kunt dan betere gesprekken voeren met productmanagers, designers, software-engineers, customer-successmanagers en systeemengineers.

Een derde technisch niveau is het kunnen schrijven van eigen scripts en het genereren van eigen dashboards, inclusief live dashboards in Jira of tools als Tableau en Sisense. Als je kunt scripten, de juiste signalen kunt vinden en kunt bepalen wat nog meer gemeten moet worden, helpt dat.

Dat zijn technische vaardigheden, maar niet noodzakelijk het niveau waarop je daadwerkelijk softwarecode schrijft. Dat is mijn visie, maar mensen kunnen daar anders over denken.

Galen Low: Ik vind vooral belangrijk wat je eerst zei: het is niet binair. Het is niet zo dat alleen programmamanagers programmamanagement kunnen doen, en ook niet dat programmamanagers verdwijnen omdat softwareteammanagers het werk overnemen.

Er is een spectrum. Een van de variabelen is complexiteit. Als je software binnen één team levert, er weinig bewegende delen zijn en je je team goed kent, kan een deel van de levering minder complex zijn. Bij zeer complexe projectecosystemen heb je leveranciers, marketing en verschillende productbelanghebbenden. Dan wordt het belangrijker om alles aan elkaar te knopen en die complexiteit te navigeren.

Ik waardeer ook je thema van betere gesprekken. Een dieper begrip en een gedeelde woordenschat maken betere samenwerking mogelijk. Daarnaast is er tegenwoordig een technische component aan bijna elke functie, ook aan die van technische programmamanager. Je moet een rapport of dashboard kunnen bouwen en een proces kunnen automatiseren.

Voor bedrijfsleiders die zeggen: dat klinkt goed, maar wat is de ROI van een dieper begrip en betere gesprekken? Wat levert dat op?

Satish Menon: Betere gesprekken leiden tot meer respect. Meer respect betekent dat je wordt uitgenodigd aan grotere tafels voor strategische discussies. Daar zien ze je als strategische partner aan de uitvoeringskant en als iemand die ervoor zorgt dat de strategie wordt omgezet in goede plannen.

Als je hun respect niet verdient en niet de woordenschat en diepgang hebt om dat respect te krijgen, zullen productmanagement en engineering de strategie bepalen zonder jou. Je krijgt vervolgens een plan overhandigd met de vraag om het te volgen. Je wordt dan een voortgangsbewaker.

Een belangrijk concept is dat het leven in software-engineering niet met TPM's is begonnen. Het begon met engineers en productmanagers. Productmanagers hadden ideeën en engineering werkte met hen samen om die uit te voeren.

In het begin zijn er misschien nog geen TPM's. Wanneer een startup groeit, ontstaan er meerdere engineeringteams en is er behoefte aan een gemeenschappelijk platform. Dan ontstaan er afhankelijkheden tussen teams en wordt een TPM toegevoegd om die afhankelijkheden te volgen.

De TPM-functie komt dus later in het spel. Als eerste TPM van een organisatie krijg je aanvankelijk te horen wat je moet doen, hoe je het moet doen en wat de uitkomst moet zijn. Je begint met een achterstand: productmanagement en engineering praten en plannen al lange tijd met elkaar, terwijl jij nieuw bent.

Daarom moet je de taal beheersen om een gelijkwaardige partner te worden en een plaats aan tafel te krijgen. Je komt laat in de levenscyclus binnen, meestal wanneer afhankelijkheden complex worden. Afhankelijkheidsmanagement is je basiswerk, naast alle andere zaken die we hebben besproken.

Galen Low: Dat vind ik goed, want er zitten twee dingen in. Vergeet niet dat je waarschijnlijk later bij het feest komt en respect moet verdienen. Maar het is ook krachtig dat teams zonder jou niet kunnen opschalen. Jij bent een groeiversneller wanneer zaken complexer worden, meer teams betrokken zijn en er meer op het spel staat.

Je moet de taal spreken van alle teams waarmee je cross-functioneel werkt, inclusief product. Een strategische partner begrijpt wat er wordt geleverd en waarom. Niet alleen de productvisie, maar ook de manier waarop de levering wordt georganiseerd om zo veel mogelijk waarde te creëren.

Soms worden programmamanagers nog gezien als administratief: vakjes aankruisen, Jira-tickets bekijken en de burndown-grafiek volgen. Maar dat levert minder waarde dan iemand die het probleem beter begrijpt en het plan blijft aanpassen om mogelijk meer waarde te realiseren dan oorspronkelijk was gepland.

Satish Menon: In de huidige AI-wereld kun je een idee snel omzetten in een met vibe coding gemaakte demo. Daarna kun je die laten zien aan drie tot vijf klanten met een hoge kans op waarde of aan vriendelijke klanten die feedback willen geven.

Vroeger moest je veel code schrijven voordat je een demo aan een klant kon tonen. Nu kun je snel een demo maken. Bij Seismic noemden we dit een onderzoeksvoorbeeld. Je toont vroege code aan klanten, verzamelt feedback, verfijnt de vereisten en maakt het product vervolgens klaar voor algemene beschikbaarheid.

TPM's kunnen het proces van zo'n onderzoeksvoorbeeld bewaken, zodat er meer waarde wordt gevalideerd voordat iets algemeen beschikbaar wordt.

Een ander punt is de strategische waarde. Het is makkelijker wanneer jij en je directielid het eens zijn over hoe je waarde toevoegt. Wanneer een nieuwe directeur binnenkomt, kunnen er echter onzekerheid en andere verwachtingen ontstaan. Sommige leiders geven je de gelegenheid om in drie maanden je waarde aan te tonen; anderen willen onmiddellijk veranderingen doorvoeren.

Dat moeten we accepteren. Soms kun je de vooronderstellingen beïnvloeden en soms ben je afhankelijk van hoe iemand over de functie denkt.

Galen Low: Dit segment wordt mogelijk gemaakt door Fingerprint. Iedere bezoeker op je platform ziet er in eerste instantie hetzelfde uit. Kun je die bezoeker vertrouwen of vormt die een bedreiging? Fingerprint herkent bots, AI-agents, VPN's, manipulatie en meer dan honderd andere unieke signalen om realtime duurzame risicoscores en dreigingsdetectie te bieden. Ook wanneer menselijke en agentische activiteit door elkaar lopen, kun je verdacht verkeer sneller identificeren en veiligere websites en apps bouwen.

Meer dan zesduizend bedrijven vertrouwen dagelijks op Fingerprint. Sluit je nu aan via fingerprint.com. En nu terug naar de show.

Satish Menon: In het AI-tijdperk moeten we een andere standaard gebruiken om onze waarde uit te leggen. Vroeger vertelden we hoe we dashboards automatiseerden, statusupdates verzamelden, problemen oplosten en risico's beperkten.

Tegenwoordig moeten we uitleggen hoe we dat hebben aangepast aan de AI-wereld: hoe we meerdere systemen met elkaar vergelijken, naar voorlopende indicatoren zoeken en slechte resultaten proberen te voorkomen in plaats van achteraf te reageren.

Je kunt laten zien wat je voorlopende indicatoren zijn, welke dashboards je gebruikt, hoe je systemen met elkaar vergelijkt en hoe je AI in de TPM-wereld gebruikt om AI in engineering aan te vullen. Zo laat je zien hoe je team zich aan het AI-tijdperk heeft aangepast.

Galen Low: De rol is anders geworden. Dat komt door AI en veranderingen in softwareontwikkeling, maar ook doordat beroepen zich voortdurend ontwikkelen. Hoe anders is de rol van de technische programmamanager vandaag in vergelijking met drie of vier jaar geleden?

Satish Menon: Software-engineers werken tien of honderd keer sneller dan vroeger. Wij moeten hetzelfde doen. We moeten stoppen met handmatige rapportages en handmatige statusverzameling. We moeten live dashboards gebruiken en rode en gele signalen beoordelen.

We moeten signalen uit de ene tool valideren door ze te vergelijken met andere tools. Als Jira aangeeft dat iets bijna klaar is, maar GitHub of Claude dat niet bevestigt, is dat een waarschuwingssignaal. Wanneer de levenscyclus van code niet overeenkomt met de Jira-status, komt het risico vroeg aan het licht.

Ook aan de testkant moet je kijken wat BrowserStack zegt over kwaliteit, implementatie, cloudtests en staging. Door die bronnen te combineren krijg je een rijkere beoordeling.

Als je je niet aanpast aan deze veranderingen, verdien je het op een gegeven moment om overbodig te worden. Wie wel bijblijft, overleeft. Software-engineers moeten AI niet alleen gebruiken wanneer ze vastlopen; het grootste deel van de code zal door AI worden gegenereerd, met menselijk toezicht om te controleren of de juiste dingen gebeuren en grenzen niet worden overschreden.

Aan de TPM-kant moeten we hetzelfde doen. Engineering en TPM's blijven partners, maar beide functies versnellen om sneller en beter te werken.

Galen Low: Het gaat dus om schaal- en waardevergroting. We mogen geen flessenhals worden omdat we verouderde werkwijzen gebruiken. Tegelijk moeten we actief deelnemen aan het proces.

Een technische programmamanager hoeft geen codeerachtergrond te hebben, maar moet wel iets begrijpen van de levenscyclus van softwareontwikkeling en de taal kunnen spreken. Welk niveau van problemen verwacht je dat TPM's kunnen oplossen?

Satish Menon: Er is een spectrum. Bij Google waren TPM's zeer technisch en konden ze meer technische problemen oplossen, maar dat is niet gebruikelijk in de sector.

Een doorsnee TPM moet op basis van een probleem kunnen bepalen welk team achterloopt en hulp nodig heeft. Je moet kunnen herkennen dat een vergelijkbaar team misschien capaciteit en vaardigheden heeft om te helpen. Als een platformteam vertraging heeft en daardoor een verticale release wordt beïnvloed, moet je ervoor zorgen dat het platformwerk de juiste prioriteit krijgt.

Je hoeft niet zelf tegen een groep engineers te zeggen welke code ze moeten schrijven. Je moet wel kunnen bepalen wie kan helpen, de juiste mensen samenbrengen, het probleem goed formuleren en mogelijke vervolgstappen aandragen. Als je ze een deel van de oplossing biedt, haal je werk van hun bord en vergroot je je waarde.

Galen Low: Een dieper begrip creëert dus meer waarde. Als je weet dat een ander team de juiste vaardigheden en beschikbaarheid heeft, kun je intelligente capaciteitsinzet voorstellen in plaats van alleen te zeggen: dit is jullie probleem, los het voor vrijdag op.

Satish Menon: Als je mensen alleen verantwoordelijk houdt voor een datum, daalt je aanzien. Als je genoeg kennis hebt om bijvoorbeeld zeventig procent van een oplossing voor te stellen — een mogelijke capaciteitsverdeling of creatieve aanpak — kunnen zij daarop voortbouwen. Ze waarderen dat je met suggesties komt, terwijl zij eigenaar blijven van de oplossing.

Galen Low: Ik vind de uitdrukking zeventigprocentsoplossingen mooi. Geef mensen iets dat gedeeltelijk is uitgewerkt, niet definitief maar wel een startpunt.

Ik suggereerde eerder dat TPM's misschien zelf met vibe coding een onderzoeksvoorbeeld zouden maken.

Satish Menon: Nee, dat bedoelde ik niet. Het gaat om een procesverandering. Productmanagers en senior engineers gebruiken vibe coding. TPM's coördineren het proces, zorgen voor goede klantdemo's en verzamelen aanvullende vereisten. Ze houden toezicht op de processtroom.

Galen Low: Iedereen werkt sneller, vooral aan de engineeringkant. Maar samenwerking blijft waardevol. Het onderzoeksvoorbeeld bestaat niet zonder engineering. Er is juist meer samenwerking doordat developers niet alles meer handmatig typen, programmamanagers betere tools en dashboards hebben en productmanagers snel prototypes kunnen maken.

Dat vermindert risico's in de levering.

Satish Menon: Ik heb vroege demo's en onderzoeksvoorbeelden gezien die engineers met vibe coding maakten op basis van ideeën van productmanagers of productdesigners. Je kunt een goed idee snel uitwerken en bent niet langer beperkt tot alleen een Figma-ontwerp.

Galen Low: Hoe benader je werving vanuit dat perspectief? Neem je liever een voormalige developer aan die een goede programmamanager is geworden, of een ervaren programmamanager die niet weet wat een merge request is?

Satish Menon: TPM's die eerder hebben gecodeerd zijn vaak betere TPM's, maar er zijn uitzonderingen. Ik test het resultaat in plaats van alleen naar het cv te kijken.

Kunnen ze de taal van engineers spreken? Kunnen ze de taal van productmanagers en designers spreken? Het maakt mij minder uit hoe ze die kennis hebben opgedaan. Als ze die vaardigheden hebben, zou ik ze aannemen.

De kans om zonder codeerachtergrond in software-TPM-werk te komen en dat tijdens het werk te leren, is tegenwoordig echter kleiner. Vijftien jaar geleden kon een hardwareprogrammamanager gemakkelijker overstappen naar een softwareproject en daar leren hoe software werkt. Tegenwoordig is de tolerantie voor mensen die nog op het werk moeten worden opgeleid zeer laag. Werkgevers zoeken mensen die direct inzetbaar zijn.

Galen Low: Dat is realistisch en sluit aan bij wat ik in de markt hoor. Het betekent niet dat je geen baan krijgt als je niet weet wat een merge request is, maar je moet bereid zijn jezelf bij te scholen en elke kans te benutten om die taal te leren.

Satish Menon: Sommige bedrijven en personeelsmanagers gebruiken uitsluitend niet-technische situatievragen. Dat doe ik niet. Ik gebruik een specifieke vragenbank om technische vaardigheid te testen op de gebieden die ik verwacht. Ik pas die aan de kandidaat aan op basis van diens ervaring en de beweringen in het cv.

Ik wil objectief bepalen op welk niveau iemand zit, van nul tot tien, zowel wat betreft technische vaardigheid in het domein waarin de kandidaat producten heeft geleverd als wat betreft de algemene workflow van een software-engineer. Daarnaast stel ik situatievragen over mensen en emotionele intelligentie.

Ik heb deze objectieve interviewmethode bij Google geleerd. Daar zag ik hoe wetenschappelijk en objectief werving kan worden aangepakt. Ik volg die aanpak nog steeds.

Galen Low: Kun je een voorbeeld geven van een situatievraag waarmee je technische kennis van een bepaald type kandidaat test?

Satish Menon: Als iemand zegt dat hij in een SaaS-omgeving heeft gewerkt en de releaseomgeving voor snellere levering heeft geoptimaliseerd, vraag ik wat anders is aan SaaS-levering in vergelijking met on-premises levering. Ik vraag ook welke snelkoppelingen ze hebben genomen en waarom.

Ik stel vervolgvragen om steeds dieper te gaan en te bepalen hoeveel ze werkelijk begrijpen van SaaS-levering en de werking van het product. Als iemand een product noemt dat bij Disney of Salesforce is uitgebracht, doe ik onderzoek naar dat product en vraag ik naar specifieke features die de kandidaat heeft uitgebracht.

Zo ontdek ik of iemand alleen een proces over een bestaande softwarelevenscyclus heeft gelegd, of werkelijk begrijpt wat het startpunt, de oplevering en de verandering voor klanten waren.

Ik stel ook basisvragen over de softwarelevenscyclus aan de codekant, DevOps, het verschil tussen staging en productie en de beveiligingsmaatregelen die nodig zijn om kwetsbaarheden te voorkomen. Zo bepaal ik of iemand begrijpt hoe software en de cloud werken.

Galen Low: We begonnen met de vraag of technische programmamanagers en software-engineeringmanagers één rol zouden moeten worden. Je hebt goede redenen gegeven waarom dat niet zo zou moeten zijn. Maar stel dat die hybride rol toch de dominante structuur wordt. Wat zou dat betekenen voor leiders die vinden dat de rollen gescheiden moeten blijven?

Satish Menon: We moeten ons richten op wat we kunnen beïnvloeden. We kunnen vooroplopen in wat de tools van vandaag mogelijk maken en waarde toevoegen aan productlevering.

Denk cross-functioneel, over meerdere teams en interdisciplinair. Onze grootste waarde ligt op het snijpunt van meerdere functies die samen een product leveren. Dat kan beginnen bij meerdere engineeringteams, daarna engineering en QA, vervolgens engineering, QA, DevOps en technische documentatie, en daarna de samenwerking tussen product, het veld, customer success, sales engineers, klantenservice en premiumdiensten.

Daar komen lanceringsevenementen, marketingboodschappen en verschillende partnerorganisaties bij. Je hebt de kans om al die onderdelen te orkestreren. Denk ook aan samenwerking tussen meerdere bedrijven, bijvoorbeeld wanneer een gezamenlijke lancering afhankelijk is van een partnerproduct.

Denk groter naarmate het landschap zich ontwikkelt. Gebruik geautomatiseerde live dashboards, vergelijk meerdere tools met elkaar, gebruik AI en raak betrokken bij product- en probleemoplossing. Daarna kun je steeds grotere cross-functionele problemen aanpakken.

Galen Low: Ik vind dat geweldig. We bevinden ons in het middelpunt. Als je die rol uit het middelpunt haalt en alleen op software-engineering richt, verlies je veel waarde. Het is de schaal en complexiteit van verschillende partners, teams en disciplines die onze waarde bepaalt.

Daarom moet het een afzonderlijke rol blijven die die waarde begeleidt en orkestreert. Maar daarvoor is wel een diep begrip nodig. We kunnen niet alleen vakjes aankruisen en raamwerken leggen over producten die we niet begrijpen. We moeten weten wat waarde is, hoe het product wordt gemaakt en hoe we de levering ervan betekenisvol en effectief kunnen maken.

Satish, hartelijk dank dat je vandaag tijd voor me hebt gemaakt. Het was erg leuk. Waar kunnen mensen meer over je te weten komen?

Satish Menon: Zoek me gewoon op LinkedIn op.

Galen Low: Nogmaals hartelijk dank.

Satish Menon: Ik heb genoten van ons gesprek, Galen. Bedankt voor de gelegenheid.

Galen Low: Goed, mensen. Dat was deze aflevering van de Digital Project Manager Podcast. Als je dit gesprek interessant vond, abonneer je dan via het platform waarop je luistert. Wil je nog meer praktische inzichten, casestudy's en draaiboeken, maak dan een gratis account aan op thedigitalprojectmanager.com.

Tot de volgende keer en bedankt voor het luisteren.