Hvad betyder 10X-engineering for tekniske programledere?

Galen Low: Tekniske programledere forventes typisk ikke at skrive kode, men i dag gør softwareingeniører det heller ikke nødvendigvis – i hvert fald ikke manuelt. Så spørgsmålet er ikke nødvendigvis, om tekniske programledere skal kunne kode. Spørgsmålet er: Hvor dyb en forståelse er nødvendig, for at tekniske programledere kan ændre, hvor de skaber værdi i en verden, hvor teamene omkring dem bruger AI til at arbejde fem, 10 og nogle gange 50 gange hurtigere, end de gjorde for blot få år siden?

For at undersøge, hvordan rollen som teknisk programleder udvikler sig i dagens softwareindustri, har jeg inviteret en VP for leverancer og engineering operations, som har ledet teams af tekniske programledere i organisationer som Dell og Google samt andre hurtigt voksende softwaremiljøer. Sammen skal vi undersøge alt fra de kompetencer, der efterspørges hos tekniske programledere i dag, til hvordan ledere med ansvar for leverancer kan fremhæve deres teams værdi, når der sker ændringer i ledelsen.

Vi skal også tale om, hvordan ansættende ledere kan vurdere kandidater til tekniske programlederstillinger under rekrutteringsprocessen, og hvad konsekvensen ville være, hvis rollen som teknisk programleder gik dinosaurernes vej. Jeg håber, du vil nyde episoden.

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

Og hvis du har kunnet lide det, du har hørt fra os på det seneste, så overvej at følge os, uanset hvor du finder os, og måske endda give os en anmeldelse. Godt. Lad os komme i gang.

Med mig i dag er Satish Menon, en leder inden for teknisk programledelse og engineering operations, som har stået i spidsen for leverancer hos teknologigiganter som Google og Dell samt hos softwarevirksomheder som Tenable, Cohesity og Seismic.

De programmer, Satish har haft ansvar for, har spændt fra hardware- og softwarelanceringer til cloudinfrastruktur og produkter til optimering af datacentre. De har beroet på Satishs evne til at navigere i beslutninger på direktionsniveau, udøve organisatorisk lederskab, udvikle og implementere operationel strategi, transformere processer og rådgive om produktudvikling.

I dag hjælper Satish teams af tekniske programledere med at navigere i en verden med AI-forstærket softwareudvikling og programledelse, samtidig med at han fremhæver værdien af rollen som teknisk programleder i teknologidrevne organisationer.

Satish, mange tak fordi du vil være med i dag.

Satish Menon: Hej Galen. Tak for invitationen. Jeg glæder mig til at være her.

Galen Low: Her er den lille køreplan, jeg har lagt for dagen. Først ville jeg stille dig et lidt kontroversielt spørgsmål, som mine lyttere gerne vil høre dit syn på. Derefter vil jeg bruge det som en linse til at se på tre ting.

For det første ville jeg se på, hvordan rollen som teknisk programleder bliver forstyrret, især inden for software. Jeg tænkte, at vi kunne tale om, hvordan afdelingsledere og teamledere kan forsvare værdien af deres tekniske programledere. Og så tænkte jeg, at vi kunne dykke ned i konsekvenserne af en hybridisering af rollerne mellem ledere af softwareteams og tekniske programledere.

Hvordan lyder det?

Satish Menon: Fremragende. Jeg glæder mig.

Galen Low: Fantastisk. Lad os dykke ned i det. Her er mit lidt provokerende åbningsspørgsmål. Tekniske programledere siger, at de ikke behøver at kunne kode for at skabe værdi. Samtidig synes mange teknologiledere at være uenige. De siger, at AI betyder, at en leder af et softwareudviklingsteam og en teknisk programleder nu er én og samme person.

Så mit spørgsmål er: Hvem har ret? Har AI skabt omstændigheder, der gør det rimeligt for organisationer at forvente, at ledere af softwareteams også er tekniske programledere – og omvendt?

Satish Menon: Du er enig med mig i, at softwareingeniørens rolle har gennemgået en stor transformation på det seneste, ikke?

De er gået fra selv at skrive koden, hvilket tidligere var flaskehalsen, til nu at bruge en masse stemningsbaseret kodning og AI-værktøjer til at generere kode med 10 gange, ja endda 100 gange højere hastighed. Og nu har problemet flyttet sig til gennemgangscyklussen, for eksempel PR-gennemgangen. Størrelsen på pull requests er steget. Derfor er det i den menneskelige overvågning af det, AI genererer i software, at byrden har flyttet sig.

På samme måde som vi ser en ændring i softwareudviklingsarbejdsgangen, hastigheden og det, softwareingeniører laver, må der også ske en tilsvarende tilpasning på den tekniske programleders side. For eksempel var der for tre til fem år siden en stor arbejdsbyrde omkring planen, status, afhængigheder, risici, risikohåndtering, kvalitetssikring, fejl og testdækning.

Det var problemer, som de tekniske programledere håndterede manuelt eller delvist manuelt. Derefter begyndte vi for fire-fem år siden at transformere det med Jira og Atlassian. Når planen først var sat op, begyndte statusoplysningerne at dukke op automatisk, og de tekniske programledere kunne se på kontrolpanelerne og vurdere, hvad der var rødt og gult, og derefter engagere sig i problemløsning.

Rollen ændrede sig altså fra at udarbejde en plan og indsamle status, rapportere og håndtere risici til at overvåge livekontrolpaneler, der viste status, og koordinere løsningsorienteret problemløsning, når der opstod røde og gule signaler.

Nu giver AI endnu flere muligheder for tekniske programledere. Hvis man ser på de værktøjer, der bruges i dag, har man Jira på den ene side, GitHub, hvor koden skrives, og BrowserStack, hvor kvalitet og udrulning håndteres.

Hvis man kan triangulere mellem disse tre værktøjer eller andre relevante værktøjer, får man mere omfattende kontrolpaneler, rigere data og bedre analyser af risici og problemer. Rollen udvikler sig derfor på den måde. Vi behøver ikke længere manuelt at finde ud af, hvad der er rødt og gult. Vi kan bruge AI til at triangulere på tværs af flere værktøjer og finde de rigtige signaler og områder, der skal undersøges, langt bedre end før.

Galen Low: Det elsker jeg. Jeg kan virkelig godt lide indramningen af, at flaskehalsen flytter sig, men at der faktisk er tale om to forskellige flaskehalse.

På engineering-siden bruger programmører mindre tid på manuelt at skrive kode. De arbejder med Cursor, de kan arbejde hurtigere, og det skubber flaskehalsen over i gennemgangen. Når du taler om en leder af et engineeringteam, betyder det faktisk mere gennemgang for vedkommende, ikke?

Flaskehalsen flytter sig. Der er sandsynligvis mere gennemgang og mere kode, der skal overvåges, og de skaber værdi ved at holde denne pipeline i bevægelse og løse problemer hurtigt på kodesiden. Men det betyder også, at der ikke nødvendigvis er ekstra kapacitet til at udføre teknisk programledelse.

På den anden side plejede flaskehalsen at handle om at indsamle information og statusopdateringer. Nu bliver vores rolle også forstyrret. Vi bruger andre værktøjer, som du nævnte, Jira og AI, og noget af denne automatisering bringer os tættere på problemløsningen i stedet for at give os kapacitet til pludselig at overvåge et softwareudviklingsteam.

Jeg kan godt lide den indramning. Forstyrrelsen sker på begge områder, men det bliver ikke til én samlet rolle. Det er to separate ting.

Satish Menon: Der er også et andet aspekt. En engineeringchef eller engineeringdirektør er ansvarlig for at levere kode af høj kvalitet, som er sikker, tilgængelig og har den rette ydeevne, med en god hastighed fra deres teams.

Men hvis man også forventer, at de er ansvarlige for de tværfunktionelle dele af leverancen – afhængigheder fra andre softwareteams, test- og kvalitetssikringsteams, kode- og testdækning, ydeevne, skalerbarhed, systemintegrationstest og at sikre, at kunderne får produktet til tiden – så er det en ekstra byrde.

Der er mange tværfunktionelle aspekter, herunder leverancer fra infrastrukturteamet, forgrenings- og DevOps-teamet samt forventninger fra marken, teknisk dokumentation og kommunikation. Alt dette skal håndteres af nogen, og jeg mener, at tekniske programledere ved hjælp af alle disse værktøjer kan gøre det langt mere effektivt og hurtigere. Men det skal gøres.

Man kan ikke bare forvente, at engineeringdirektører og engineeringchefer også håndterer alt dette. Der er endnu et aspekt. Det er vigtigt at bruge analogien med trafiksikkerhed. Vi har myndigheder, der udsteder kørekort, sikrer, at biler er registrerede, og at trafikreglerne er kendte.

Men vi har også færdselspolitiet, som udsteder bøder og sikrer, at personer, der overtræder systemets regler, bliver straffet gennem stikprøvekontroller eller systematiske kontroller. Man har brug for begge dele for at få et godt system til at fungere. Man kan ikke forvente, at den samme person udsteder kørekort, registrerer alle biler, underviser i sikker kørsel og derefter sikrer et godt resultat.

Man har brug for kontrol og balance.

Galen Low: Det kan jeg virkelig godt lide, for der sker så meget automatisering i mange forskellige roller lige nu, især inden for teknisk programledelse og softwareudvikling. Nogle taler om, at de automatiserer ved hjælp af rammeværk, så alle reglerne er lagt fast, og folk bare skal følge dem.

Men som du siger, er det faktisk ikke det, mennesker er gode til. Der vil altid være mennesker, der støder ind i problemer, bevidst overtræder regler eller ikke forstår, hvor prioriteterne ligger. Grundlæggende er der stadig brug for nogen til at lede processen.

Mindre end før, men der er stadig værdi i det. Og du har en god pointe om, at mange brikker skal falde på plads for at levere et softwareprodukt. Kun en del af det handler om kodekvalitet. Resten handler om tværfunktionel koordinering, så alt sker, når det skal.

Hvis man er distraheret af at lede et team af softwareingeniører, lave en-til-en-samtaler, være karriereleder, gennemgå kodekvalitet og løse tekniske problemer, kan det komme i vejen for leverancen. Det ville være svært at prioritere mellem de to ting.

Satish Menon: Ja. En teknisk programleder skal forstå, at softwareledere godt kan styre projekter, der er afgrænsede inden for deres egen organisation. Men når det handler om en større leverance med afhængigheder på tværs af andre teams, kommer den tekniske programleder ind i billedet.

Det handler ikke kun om tværfunktionelt samarbejde mellem engineering, produktledelse, design, marken, go-to-market og teknisk dokumentation. Det handler også om de afhængigheder, der findes internt i selve softwareleverancen på tværs af teams.

Vi bør derfor aldrig forlade denne samtale med forståelsen af, at en softwarechef eller softwaredirektør ikke udfører projektledelse. Det gør de, men for leverancer, der er fuldt afgrænsede inden for deres organisation. Når der er tale om tværfunktionelle forhold, er det bedre at have en teknisk programleder med et neutralt perspektiv.

Når det gælder det tekniske niveau, foretrækker jeg generelt tekniske programledere, som tidligere har kodet eller har haft stor eksponering for kodning. Det gør dem i stand til at forstå ingeniørernes sprog, vinde deres respekt og samarbejde med dem.

Man skal forstå kodens livscyklus: indtjekninger, commits, PR-gennemgang, gennemgangscyklus, linting og statisk analyse samt forskellen mellem enhedstest, systemtest, integrationstest, ydeevnetest og udrulning.

Man skal også forstå det produkt, man sender ud. Jeg har set tekniske programledere, som blot lægger en proces oven på den tekniske arbejdsgang uden at vide præcis, hvilken software der udvikles, eller hvad den gør. Hvis man forstår produktet, kan man føre bedre samtaler med produktledere, designere, softwareingeniører, customer success-ledere og systemingeniører.

Et tredje teknisk niveau er at kunne skrive egne scripts og generere egne kontrolpaneler og livekontrolpaneler i Jira, Tableau, Sisense eller andre værktøjer. Det er teknisk, men ikke nødvendigvis det samme som at kunne skrive produktionskode.

Galen Low: Jeg kan godt lide, at du fremhæver, at det ikke er binært. Det er ikke sådan, at kun programledere kan udføre programledelse, eller at programledere forsvinder, fordi softwareteamets ledere overtager det hele.

Der er et spektrum, og kompleksitet er en af variablerne. Hvis man leverer software inden for ét team med få bevægelige dele, kan leverancen være mindre kompleks. Men i meget komplekse projektøkosystemer med leverandører, marketing og flere produktinteressenter handler værdien om at samle det hele og navigere i kompleksiteten.

Jeg kan også godt lide din pointe om bedre samtaler. Dybere forståelse og et fælles ordforråd gør det muligt at samarbejde bedre. Der er også en teknisk dimension i næsten alle roller nu, herunder rollen som teknisk programleder. Man skal kunne oprette en rapport, bygge et kontrolpanel eller automatisere en proces uden nødvendigvis at være en person, der skriver kode som en fast del af jobbet.

Satish Menon: Hvis man har bedre samtaler, fører det til større respekt. Større respekt betyder, at man bliver inviteret med til større strategiske drøftelser, hvor man ses som en strategisk partner på eksekveringssiden og som en person, der kan omsætte strategi til gode planer.

Hvis man ikke har det nødvendige ordforråd og den dybde, vinder man ikke deres respekt. Så finder produktledelsen og engineering ud af strategien uden én, og man får ingen plads ved bordet. I stedet afleverer de en plan og siger: "Her er planen. Jeg vil gerne have, at du følger den." Så bliver man en tracker.

Man skal huske, at softwareudvikling ikke begyndte med tekniske programledere. Den begyndte med engineering og produktledere. Når en organisation vokser, opstår der flere engineeringteams og behov for fælles platforme. Så opstår der afhængigheder på tværs af teams, og det er her, man siger: "Lad os få en teknisk programleder på, så vi kan følge alle afhængighederne."

Funktionen kommer altså senere i spillet. Når man kommer ind som organisationens første tekniske programleder, bliver man ofte fortalt, hvad man skal gøre, hvordan man skal gøre det, og hvilket resultat der forventes. Først derefter kan man langsomt begynde at påvirke.

Man er en sen deltager. Derfor skal man opbygge den respekt, der kræves for at blive en ligeværdig partner. Man skal kunne sproget. Det er sådan, man får en plads ved bordet. Afhængighedsstyring er det grundlæggende håndværk, men der er også mange andre områder.

Galen Low: Det kan jeg godt lide. Man skal huske, at man sandsynligvis er kommet sent til festen og derfor skal gøre sig fortjent til respekten. Men samtidig kan organisationen ikke skalere uden en teknisk programleder. Den værdi, man tilfører, er en vækstfaktor, når tingene bliver mere komplekse, flere teams bliver involveret, og indsatsen bliver mere risikofyldt.

Det handler om at tale sproget for alle de teams, man arbejder med på tværs af organisationen, herunder produkt. For ledelsen er den største klage ofte, at folk ikke forstår det. De gør tingene og forsøger at levere til tiden, men sender noget ud, der er forkert, eller overser en mulighed for at skabe mere værdi for en kunde.

Når man taler om at tale sproget, vinde respekt og skabe dybere forståelse på begge sider, handler det om at udvikle mekanikken i at være en strategisk partner, der forstår det, som leveres, og kan være fortaler for visionen og leverancen.

Det handler ikke længere kun om administration, afkrydsning, Jira-billetter og burndown-diagrammer. Værdien ligger i at forstå problemfeltet bedre og iterere på planen for at nå frem til en værdi, der måske er større end den, der oprindeligt blev planlagt.

Satish Menon: I AI-verdenen kan man hurtigt producere en demo af et koncept ved hjælp af stemningsbaseret kodning. Derefter kan man vise den til tre til fem kunder med høj sandsynlighed for at give værdifuld feedback. Tidligere skulle man skrive enorme mængder kode, før man havde en demo, der kunne vises til en kunde.

Hos Seismic kaldte vi det en forskningsforhåndsvisning. Man viser den tidlige kode til kunder, indsamler feedback, forfiner de endelige krav og hærder derefter løsningen frem mod en generel tilgængelighed. Tekniske programledere kan spille en rolle i at håndhæve denne proces og skabe større værdi, før noget går i generel tilgængelighed.

Den strategiske værdi bliver tydelig, når der er overensstemmelse med den øverste ledelse om, hvordan man skaber værdi. Når en ny direktør eller leder kommer ind, kan der opstå usikkerhed, fordi vedkommendes forudfattede opfattelser er anderledes. Nogle gange får man mulighed for at forklare sin værdi og foreslå en periode, hvor man kan demonstrere den. Andre gange træffes ændringerne med det samme.

Galen Low: Dette segment præsenteres af Fingerprint. Alle besøgende på din platform ser i første omgang ens ud. Kan du stole på dem, eller udgør de en trussel? Fingerprint genkender bots, AI-agenter, VPN'er, manipulation og mere end 100 andre unikke signaler for at give dig robust risikoscore og trusselsdetektion i realtid. Selv når menneskelig og agentbaseret aktivitet flyder sammen, kan du identificere mistænkelig trafik hurtigere og bygge mere sikre og beskyttede websteder og apps.

Mere end 6.000 virksomheder bruger Fingerprint hver dag. Slut dig til dem på fingerprint.com. Og nu tilbage til programmet.

Satish Menon: I AI-æraen skal man have en anden samtale med den nye ledelse. Tidligere kunne man forklare, hvordan man organiserede arbejdet, automatiserede kontrolpaneler og indsamlede status. I dag skal man vise, hvordan man har transformeret det til en AI-verden ved at triangulere på tværs af flere systemer og se på tidlige indikatorer for at forhindre dårlige resultater i stedet for blot at reagere bagefter.

Man skal vise sine tidlige indikatorer, aktuelle kontrolpaneler, triangulering på tværs af systemer og den måde, AI bruges til at forstærke engineering. Det er sådan, man viser, at teamet har tilpasset sig AI-verdenen.

En god teknisk programledergruppe kan identificere tidlige risikosignaler i programmer, eksekvering og operationelt effektive teams. Ellers kommer konsekvenserne af dårlige resultater sent og dyrt.

Galen Low: Rollen er anderledes nu, både på grund af AI og fordi professioner generelt udvikler sig. Vi taler om forskningsforhåndsvisninger, stemningsbaseret kodning, produktarbejde og kontrolpaneler med tidlige indikatorer. Hvor anderledes er rollen som teknisk programleder i dag sammenlignet med for tre eller fire år siden?

Satish Menon: Softwareingeniører arbejder måske 10 eller 100 gange hurtigere end før. Vi skal gøre det samme. Vi skal holde op med at lave manuelle rapporter og indsamle status manuelt. Vi skal bruge automatiserede livekontrolpaneler og vurdere røde og gule signaler.

Vi bør validere signaler fra ét værktøj gennem triangulering med andre værktøjer. Hvis Jira siger, at noget nærmer sig afslutning, men GitHub og Claude viser noget andet, er det et advarselssignal. Hvis kodens livscyklus ikke stemmer overens med Jira-rapporten, skal man reagere tidligt.

På testsiden bør man også se på, hvad BrowserStack fortæller om kvalitet, udrulning, cloud, test og staging. Hvis man ikke tilpasser sig disse ændringer og nye måder at tænke på, fortjener man på et tidspunkt at blive udfaset. De, der følger med, overlever.

Galen Low: Jeg kan godt lide tanken om at muliggøre skala og værdi. Vi må ikke blive en flaskehals, fordi vi er forældede i vores måde at arbejde på. Vi skal være aktive deltagere og identificere uoverensstemmelser mellem systemer, før de skaber risiko.

Hvilket niveau af problemer forventer du, at dine tekniske programledere kan løse? Handler det primært om at koordinere teams og skabe fælles forståelse, eller går det dybere?

Satish Menon: Der er et spektrum. Hos Google var de tekniske programledere meget tekniske og kunne løse langt flere tekniske problemer. Det er dog usædvanligt.

Typiske tekniske programledere bør kunne se, at et team er bagud og har brug for hjælp. De bør kunne identificere søsterteams med lignende kompetencer og foreslå, at de hjælper. Hvis et platformteam er forsinket og påvirker en vigtig lancering, skal de sikre, at platformarbejdet prioriteres.

Hvis man bringer originale tanker til bordet og hjælper engineeringlederen med at formulere de næste skridt, skaber man respekt og fjerner noget af det arbejde, lederen selv skulle have udført. Man behøver ikke selv være den ingeniør, der løser problemet, men man skal kunne samle de rigtige personer, formulere problemet og gøre vejen mod en løsning lettere.

Galen Low: Det tilbagevendende tema er, at dybere forståelse faktisk skaber mere værdi. Hvis man ved, at et andet team har de rette kompetencer, er tilgængeligt og kan være en løsning, kan man bringe det ind i stedet for blot at sige: "Det er dit problem. Løs det inden fredag."

Satish Menon: Hvis man bare holder teamet ansvarligt for en dato, falder respekten. Hvis man derimod har tilstrækkelig viden til at foreslå 70 procent af en løsning, for eksempel gennem ressourcefordeling eller kreative løsningsmuligheder, kan man sige: "Her er noget, jeg tænker på. I ejer det, så brug det, hvis det er nyttigt." Så vil teamet sætte pris på, at man kommer med forslag.

Galen Low: Jeg elsker udtrykket 70-procentsløsninger. Kom med noget, der er delvist færdigt. Det er ikke endeligt, men det er et udgangspunkt.

Satish Menon: Forskningsforhåndsvisningen er primært en proces. Det var ikke meningen, at tekniske programledere skulle stemningskode kundedemoer. Det er produktledere og senioringeniører, der gør det, mens programlederne koordinerer, sikrer gode kundedemoer og indsamler flere krav. De tekniske programledere overvåger processen.

Galen Low: Alle bevæger sig hurtigere, især på softwareudviklingssiden, men sammenhold og samarbejde er stadig værdifuldt. Forskningsforhåndsvisningen sker ikke uden engineering. Der er mere samarbejde, fordi udviklere ikke længere skriver al kode manuelt, programledere har bedre værktøjer og kontrolpaneler, og produktledere hurtigt kan skabe prototyper.

Satish Menon: Jeg har set stemningsbaseret kodning og tidlige demoer baseret på ideer fra engineering, produktledelse og produktdesign. Man kan hurtigt kode en idé og demonstrere, hvordan den fungerer. Vi er ikke længere begrænset til kun at vise en Figma-designskitse.

Galen Low: Hvordan griber du ansættelser an? Ville du helst ansætte en tidligere udvikler, der er blevet en god programleder, eller en erfaren programleder, der ikke ved, hvad en merge request er?

Satish Menon: Tekniske programledere, der tidligere har kodet, er ofte bedre. Men der er undtagelser. Jeg vurderer resultatet i stedet for blot at se efter kodning på CV'et.

Jeg ser på, om kandidaten effektivt kan tale ingeniørernes sprog og produktledernes og designernes sprog. Det afgørende er, hvordan kandidaten har opnået det. Det kan være gennem tidligere kodning eller gennem et tæt samarbejde med udviklere og en grundig forståelse af deres arbejdsgang.

Muligheden for at komme ind i teknisk programledelse uden en kodningsbaggrund er dog mindre i dag. Arbejdsmarkedet søger i højere grad færdiguddannede kandidater, og tolerancen for oplæring på jobbet er lav.

Galen Low: Det er et realistisk perspektiv, og det stemmer overens med det, jeg hører på markedet. Hvis man ikke ved, hvad en merge request er, betyder det ikke nødvendigvis, at man ikke kan få jobbet, men man skal være forberedt på at uddanne sig selv og lære at tale sproget.

Satish Menon: I mine interviews bruger jeg en specifik spørgepulje til at teste teknisk forståelse inden for de områder, jeg forventer. Jeg tilpasser spørgsmålene til kandidaten og deres erfaring. Jeg vurderer, hvor de ligger på en skala fra nul til 10 inden for teknisk forståelse, både på det vertikale markedsområde, de har leveret i, og på softwareingeniørens generelle arbejdsgang.

Derefter stiller jeg situationsbestemte spørgsmål om menneskelige forhold og kandidatens emotionelle intelligens. Jeg lærte denne objektive interviewmetode hos Google, og jeg følger stadig denne proces.

Galen Low: Kan du give et eksempel på et situationsbestemt spørgsmål, der tester teknisk viden?

Satish Menon: Hvis en person siger, at vedkommende har arbejdet i et SaaS-miljø og optimeret udgivelsesmiljøet til hurtigere leverancer, spørger jeg, hvad der er anderledes ved SaaS-leverancer sammenlignet med on-premise, hvilke genveje de har taget, og hvorfor.

Jeg spørger også ind til konkrete produkter og funktioner, kandidaten har leveret. De skal kunne forklare, hvad produktet gjorde, hvilken funktion de udgav, og hvilken ændring det skabte for kunderne. Derudover spørger jeg til softwarelivscyklussen, DevOps, forskellen mellem staging og produktion samt sikkerhedsbarrierer.

Galen Low: Hvis den hybride rolle mellem softwareleder og teknisk programleder bliver den dominerende struktur, hvad tror du så, konsekvensen bliver?

Satish Menon: Vi skal fokusere på det, vi kan kontrollere. Vi kan være foran i forhold til de værktøjer, der gør det muligt at skabe værdi for produktleverancer.

Tænk tværfunktionelt, på tværs af teams og på tværs af fagområder. Vores største værdi ligger i krydsfeltet mellem flere funktioner, der samles for at levere et produkt. Først handler det om flere engineeringteams, derefter engineering og kvalitetssikring, så engineering, kvalitetssikring, DevOps og teknisk dokumentation.

Derefter udvides det til produktorganisationen og funktioner som kundesucces, salgsteknik, kundesupport, premiumtjenester, lanceringer og marketing. Her kan man fungere som koordinator på tværs af det hele. Man kan også tænke på flere virksomheder og partnerskaber, hvor en fælles lancering kræver programledelse på tværs af organisationer.

Tænk større og større om de tværfunktionelle problemer, der skal løses.

Galen Low: Jeg elsker det. Vi er i centrum. Hvis man fjerner rollen fra centrum og kun fokuserer på softwareudvikling, mister man al den værdi, der ligger i skalaen, kompleksiteten, partnerne, teamene og fagområderne, der skal samles.

Det er derfor, rollen bør være separat. Men den kræver en dyb forståelse. Vi kan ikke bare afkrydse felter og lægge rammeværk oven på produkter, vi ikke forstår. Vi skal vide, hvad værdi er, hvordan produktet bliver skabt, og hvordan vi kan sikre, at det leveres på en meningsfuld og effektfuld måde.

Satish, mange tak for din tid i dag. Det har været rigtig sjovt. Hvor kan folk lære mere om dig?

Satish Menon: De kan bare finde mig på LinkedIn.

Galen Low: Endnu en gang mange tak.

Satish Menon: Jeg nød samtalen med dig, Galen. Mange tak for muligheden.

Galen Low: Så er det alt for denne episode af Digital Project Manager Podcast. Hvis du nød samtalen, så husk at abonnere, uanset hvor du lytter, og hvis du vil have endnu flere praktiske indsigter, casestudier og playbooks, kan du oprette en gratis konto hos os på thedigitalprojectmanager.com.

Indtil næste gang – tak fordi du lyttede.