Cosa significa l’ingegneria 10X per i responsabili dei programmi tecnici?

Galen Low: I responsabili dei programmi tecnici non sono generalmente tenuti a scrivere codice, ma al giorno d'oggi nemmeno gli ingegneri del software lo fanno, almeno non manualmente. Quindi la domanda non è necessariamente se i TPM debbano saper programmare. La domanda è: quale livello di comprensione è necessario affinché i responsabili dei programmi tecnici possano spostare il punto in cui apportano valore, in un mondo in cui i team che li circondano usano l'intelligenza artificiale per lavorare cinque, 10 e talvolta 50 volte più velocemente rispetto a pochi anni fa?

Per esplorare come si sta evolvendo il ruolo del responsabile dei programmi tecnici nell'industria software odierna, ho invitato un vicepresidente della distribuzione e delle operazioni ingegneristiche che ha guidato team di TPM in organizzazioni come Dell e Google, oltre che in altri ambienti software dinamici e in forte crescita. Insieme, analizzeremo tutto: dalle competenze oggi richieste ai TPM a come i responsabili della distribuzione possono valorizzare il proprio team quando cambia la leadership.

Parleremo anche di come i responsabili delle assunzioni possano valutare i candidati TPM durante il processo di selezione e di quale sarebbe l'impatto se il ruolo del TPM facesse la fine del dodo. Spero che l'episodio vi piaccia.

Benvenuti al podcast del Digital Project Manager, lo spettacolo che aiuta i responsabili della distribuzione a lavorare in modo più intelligente, distribuire in modo più fluido e guidare i propri team con sicurezza nell'era dell'intelligenza artificiale. Sono Galen e ogni settimana analizziamo strategie del mondo reale, tendenze emergenti, framework collaudati e occasionali storie di guerra dal fronte dei progetti. Che stiate guidando enormi progetti di trasformazione, gestendo flussi di lavoro basati sull'intelligenza artificiale o semplicemente cercando di tenere sotto controllo il caos, siete nel posto giusto.

E se vi è piaciuto ciò che avete ascoltato da noi ultimamente, prendete in considerazione l'idea di seguirci ovunque ci troviate e magari di lasciarci anche una recensione. Bene. Iniziamo.

Con me oggi c'è Satish Menon, un responsabile della gestione dei programmi tecnici e delle operazioni ingegneristiche che ha guidato la distribuzione presso giganti tecnologici come Google e Dell, oltre che presso aziende software come Tenable, Cohesity e Seismic.

I programmi sotto la responsabilità di Satish hanno spaziato dal lancio di hardware e software all'infrastruttura cloud e ai prodotti per l'ottimizzazione dei data center, facendo affidamento sulla sua capacità di gestire decisioni a livello dirigenziale, fornire leadership organizzativa, sviluppare e attuare strategie operative, trasformare i processi e fornire consulenza sullo sviluppo dei prodotti.

Oggi Satish aiuta team di responsabili dei programmi tecnici a orientarsi nel mondo dell'ingegneria software e della gestione dei programmi potenziate dall'intelligenza artificiale, sostenendo al contempo il valore che il ruolo del responsabile dei programmi tecnici apporta alle organizzazioni guidate dalla tecnologia.

Satish, grazie mille per essere qui oggi.

Satish Menon: Ciao, Galen. Grazie dell'opportunità. Sono felice di essere qui.

Galen Low: Ecco la piccola tabella di marcia che ho preparato per oggi. Per prima cosa, volevo porti una domanda un po' controversa, perché i miei ascoltatori vorrebbero conoscere il tuo punto di vista. Poi vorrei usarla come lente per analizzare tre aspetti.

Per prima cosa, vorrei esaminare come il ruolo del responsabile dei programmi tecnici stia subendo cambiamenti, soprattutto nell'ambito del software. Potremmo parlare di come i responsabili dei dipartimenti e i team leader possano difendere il valore dei propri responsabili dei programmi tecnici. Inoltre, vorrei approfondire le implicazioni dell'ibridazione dei ruoli tra i responsabili dei team software e i responsabili dei programmi tecnici.

Che ne pensi?

Satish Menon: Ottimo. Non vedo l'ora.

Galen Low: Perfetto. Iniziamo. Ecco la mia domanda pungente. I responsabili dei programmi tecnici dicono di non dover saper programmare per apportare valore. Nel frattempo, molti dirigenti tecnologici sembrano non essere d'accordo. Dicono che l'intelligenza artificiale implica che un responsabile di un team di ingegneria software e un responsabile di programmi tecnici siano ormai la stessa persona.

Quindi la mia domanda è: chi ha ragione? L'intelligenza artificiale ha creato le condizioni per cui sia ragionevole aspettarsi che i responsabili dei team software siano anche responsabili dei programmi tecnici e viceversa?

Satish Menon: Possiamo concordare sul fatto che il ruolo dell'ingegnere software abbia subito una grande trasformazione negli ultimi tempi, giusto?

Sono passati dal dover scrivere personalmente il codice, che prima rappresentava il collo di bottiglia, all'utilizzo di molta programmazione intuitiva e di strumenti di intelligenza artificiale per generare codice a una velocità dieci volte, persino cento volte superiore. Ora il problema si è spostato sul ciclo di revisione, come quello delle richieste di modifica: le dimensioni delle richieste sono aumentate. Quindi il carico si è spostato sulla supervisione umana di ciò che l'intelligenza artificiale genera nel software.

In modo simile al cambiamento che vediamo nel flusso di lavoro e nella velocità dell'ingegneria software e nelle attività degli ingegneri software, anche il lato dei TPM deve adattarsi. Per esempio, da tre a cinque anni fa c'era un grande carico legato al piano e alla domanda: qual è lo stato? A che punto siamo? Come stanno procedendo le dipendenze? Quali sono i rischi e come possiamo mitigarli? Come sta andando il controllo qualità? L'aspetto della garanzia della qualità del nostro progetto è in linea e c'è qualche rischio? Inoltre, c'erano il monitoraggio dei bug, la loro riduzione, il monitoraggio della copertura dei test e così via.

Questi erano i problemi e all'epoca venivano gestiti dai TPM in modo manuale o semimanuale. Poi, quattro o cinque anni fa, abbiamo iniziato a trasformare tutto questo con Jira e Atlassian. Una volta impostato il piano, lo stato iniziava a emergere automaticamente e i TPM potevano semplicemente guardare quei pannelli di controllo e valutare cosa fosse rosso, cosa fosse giallo e cosa richiedesse attenzione. Poi iniziavano a essere coinvolti nella risoluzione dei problemi.

Il ruolo è quindi cambiato: non consisteva più soltanto nel creare un piano, ma anche nel raccogliere informazioni, comunicare lo stato, segnalare i rischi e facilitare le relative mitigazioni. Ora osservo pannelli di controllo aggiornati in tempo reale che mi indicano lo stato, ma quando vediamo elementi rossi e gialli coordino tutte le attività orientate alla soluzione e alla risoluzione dei problemi.

Ora, con l'intelligenza artificiale, ci sono ulteriori opportunità per i TPM. Se consideriamo gli strumenti oggi disponibili, da una parte abbiamo Jira e dall'altra GitHub, dove viene scritto il codice. Poi abbiamo BrowserStack, dove vengono gestiti tutti gli aspetti relativi alla qualità e alla distribuzione.

Se si riesce a triangolare le informazioni tra questi tre strumenti, o tra altri strumenti utilizzati, si ottengono pannelli di controllo più ricchi, dati più completi e analisi più approfondite di rischi e problemi. Il ruolo del TPM si evolve in questo modo. Non dobbiamo più individuare manualmente ciò che è rosso o giallo.

Possiamo usare l'intelligenza artificiale per triangolare più strumenti e individuare i segnali e gli elementi giusti, così da capire dove si trovano le criticità molto meglio di prima.

Galen Low: Mi piace molto. Mi piace l'idea che il collo di bottiglia si sposti, ma il fatto è che ci sono due colli di bottiglia diversi.

Dal lato dell'ingegneria, i programmatori dedicano meno tempo alla scrittura manuale del codice. Lavorano con Cursor, riescono a procedere più velocemente e questo sposta il collo di bottiglia sulla revisione. Quando parli di un responsabile di un team ingegneristico, significa che per lui ci sono più revisioni, giusto?

Il collo di bottiglia si sposta. Probabilmente c'è più revisione e c'è più codice da supervisionare. Il valore viene generato mantenendo fluido il processo e risolvendo rapidamente i problemi sul lato del codice. In altre parole, è lì che possono apportare più valore.

Non c'è questa capacità aggiuntiva che permetta loro di occuparsi anche della gestione dei programmi tecnici. Dall'altra parte, l'altro collo di bottiglia era la raccolta delle informazioni e degli aggiornamenti sullo stato. Ora anche il nostro ruolo sta cambiando: utilizziamo altri strumenti, come Jira, usiamo l'intelligenza artificiale e parte di questa automazione ci avvicina alla risoluzione dei problemi, invece di lasciarci senza nulla da fare per poi avere improvvisamente la capacità di supervisionare un team di ingegneria software.

Mi piace questa prospettiva. Il cambiamento sta avvenendo su entrambi i fronti, ma questo non significa che tutto confluisca in un unico ruolo. Sono due cose separate.

Satish Menon: C'è anche un altro aspetto. Un responsabile o direttore dell'ingegneria software è responsabile della distribuzione, da parte del proprio team, di codice di alta qualità, sicuro, accessibile e con le prestazioni corrette, mantenendo una buona velocità.

La velocità viene migliorata con l'intelligenza artificiale. Ma se ci si aspetta che siano responsabili anche degli aspetti interfunzionali della distribuzione, come le dipendenze da altri team software, la garanzia che i team di test e controllo qualità raggiungano un alto livello di copertura del codice e dei test, la verifica che i test delle prestazioni e dell'integrazione dei sistemi procedano correttamente e la consegna puntuale del prodotto ai clienti, allora il carico aumenta.

Bisogna inoltre considerare i risultati del team infrastrutturale, del team responsabile dei rami di codice, del team DevOps e così via, oltre alle aspettative del personale sul campo, alla documentazione tecnica e alla comunicazione. Ci sono moltissimi aspetti interfunzionali. Qualcuno deve occuparsene e penso che i TPM, con l'aiuto di tutti questi strumenti, possano farlo in modo molto più efficiente e veloce, ma deve essere fatto.

Se ci si aspetta che i direttori e i responsabili dell'ingegneria software svolgano anche questo lavoro, si tratta di un carico aggiuntivo. È importante anche usare l'analogia della sicurezza stradale. Abbiamo enti che rilasciano patenti, verificano che le auto siano registrate e assicurano che le regole del traffico siano note.

Ma abbiamo anche la polizia stradale, che emette multe e assicura che chi non rispetta il sistema venga penalizzato attraverso controlli casuali o sistematici. Servono entrambe le cose perché un sistema funzioni bene. Non ci si può limitare a rilasciare patenti, registrare ogni auto e insegnare alle persone a guidare in sicurezza, aspettandosi poi un buon risultato.

Servono controlli ed equilibri.

Galen Low: Mi piace molto, perché oggi c'è tanta automazione in molti ruoli diversi, soprattutto nella gestione dei programmi tecnici e nell'ingegneria software. A volte sento parlare di persone che automatizzano usando framework in cui tutte le regole sono già definite e gli altri devono semplicemente seguirle.

Ma, come dici tu, non è ciò che gli esseri umani sanno fare bene. Ci saranno sempre persone che incontrano problemi, che magari aggirano deliberatamente le regole o che non comprendono le priorità. In sostanza, serve comunque qualcuno che accompagni il processo.

Meno di prima, ma il valore esiste ancora. Hai anche sottolineato un punto importante: per distribuire un prodotto software devono convergere molti elementi e solo una parte riguarda la qualità del codice. Il resto è orchestrazione interfunzionale, per assicurarsi che tutto converga al momento giusto.

Se sei distratto dalla gestione di un team di ingegneri software, tra riunioni individuali, gestione della carriera, verifica della qualità del codice e risoluzione dei problemi tecnici, è difficile dare priorità anche alla distribuzione. Entrambe le cose sono importanti.

Forse possiamo allontanarci un po' e osservare il quadro generale. Hai guidato team di responsabili dei programmi tecnici presso aziende come Dell e Google, oltre che presso altre grandi aziende software. Abbiamo parlato della risoluzione dei problemi: un responsabile di un team software può risolvere problemi tecnici, mentre il responsabile dei programmi tecnici risolve anch'egli problemi, soprattutto perché i report e i pannelli di controllo disponibili gli permettono di essere più proattivo.

Ma c'è un divario: quali problemi può risolvere un responsabile dei programmi tecnici senza avere un background di programmazione?

Satish Menon: Questo mi porta a un punto importante. Un responsabile o direttore software può gestire i progetti interamente contenuti nella propria organizzazione. Quando però si tratta di un risultato più grande, con dipendenze tra diversi team, entra in gioco il TPM.

Non si tratta solo di coordinamento interfunzionale tra ingegneria, gestione del prodotto, design, personale sul campo, attività commerciali e documentazione tecnica. Riguarda anche le dipendenze interne al risultato software stesso, distribuite tra più team.

Non dovremmo concludere questa conversazione pensando che un responsabile o direttore software non svolga attività di gestione dei progetti. Le svolge, ma per risultati completamente contenuti nella propria organizzazione. Per le attività interfunzionali, è molto meglio avere un TPM con una prospettiva neutrale.

Per quanto riguarda il livello tecnico necessario, preferisco in gran parte utilizzare o assumere TPM che in passato siano stati programmatori o che abbiano avuto una forte esposizione alla programmazione. Questo permette loro di comprendere il linguaggio degli ingegneri, guadagnarne il rispetto e collaborare con loro.

È necessario comprendere il ciclo di vita del codice: cosa sono i controlli del codice, i commit, la revisione delle richieste di modifica, il ciclo di revisione, l'analisi dello stile e l'analisi statica. Bisogna conoscere la differenza tra test unitari, test di sistema, test di integrazione, test delle prestazioni e distribuzione.

È utile anche sapere quale prodotto si sta distribuendo. Ho visto TPM capaci di sovrapporre un processo al flusso di lavoro tecnico, ma senza sapere esattamente quale software stessero sviluppando o cosa facesse.

Se comprendono il prodotto, quando viene richiesta una nuova funzionalità hanno una visione molto più chiara di ciò che si sta sviluppando e distribuendo. Possono quindi dialogare meglio con product manager, designer, ingegneri software, responsabili del successo dei clienti e ingegneri dei sistemi.

Un terzo livello tecnico consiste nella capacità di scrivere i propri script e generare i propri pannelli di controllo aggiornati in tempo reale, tramite Jira o strumenti come Tableau e Sisense. Saper creare script, generare pannelli di controllo, cercare i segnali giusti e capire cos'altro debba essere misurato è utile.

Questi sono aspetti tecnici, ma non al punto da dover scrivere codice come un ingegnere. Questa è la mia opinione, anche se altri possono pensarla diversamente.

Galen Low: Mi piace molto, soprattutto il primo punto: non è una questione binaria. Non è vero che solo i responsabili dei programmi possono gestire i programmi, né che i responsabili dei team software scompariranno perché si occuperanno loro della gestione dei programmi.

C'è uno spettro intermedio e una delle variabili è la complessità. Se si distribuisce software all'interno del proprio team, con pochi elementi in movimento e un sistema ben conosciuto, una parte della distribuzione sarà meno complessa.

I progetti altamente complessi possono invece includere fornitori, marketing e diversi stakeholder del prodotto. Il valore consiste nel collegare tutto e gestire la complessità affinché il risultato venga comunque distribuito.

Mi piace anche il tema delle conversazioni migliori: una comprensione più profonda e un vocabolario condiviso consentono di collaborare meglio. Oggi quasi tutti i ruoli hanno una componente tecnica, compreso quello del responsabile dei programmi tecnici. Bisogna saper creare un report, un pannello di controllo o automatizzare un processo, anche senza essere una persona che scrive abitualmente codice.

Per i responsabili aziendali, qual è il ritorno sull'investimento di una comprensione più profonda e di conversazioni migliori con il team?

Satish Menon: Conversazioni migliori portano a un maggiore rispetto. Un maggiore rispetto significa essere invitati a tavoli strategici più importanti, dove si viene considerati partner strategici sul fronte dell'esecuzione e si contribuisce a trasformare la strategia in buoni piani.

Senza il rispetto, senza il vocabolario e la profondità necessari per ottenerlo, i responsabili di prodotto e gli ingegneri definiscono la strategia senza di te. Ti consegnano il piano e ti chiedono semplicemente di monitorarlo, trasformandoti in una persona che tiene traccia delle attività.

La vita dell'ingegneria software non è iniziata con i TPM. È iniziata con gli ingegneri e i product manager. I product manager hanno idee, gli ingegneri collaborano con loro e le realizzano. A volte un'innovazione tecnologica nasce dagli ingegneri e poi vengono coinvolti i product manager per svilupparla e portarla sul mercato.

Quando l'azienda cresce e ci sono più team ingegneristici, nasce la necessità di una piattaforma comune. A quel punto si creano dipendenze tra i team ed è necessario un TPM per monitorarle.

La funzione del TPM entra quindi in gioco più avanti, non all'inizio. Per definizione, il primo TPM dell'organizzazione viene inizialmente incaricato di svolgere attività definite da altri. Gradualmente può iniziare a influenzare le decisioni.

Per questo è importante conoscere il linguaggio degli ingegneri e dei product manager. Il TPM entra in scena più tardi e deve guadagnarsi un posto al tavolo.

Galen Low: Mi piace perché ci sono due aspetti. Il primo è non dimenticare che probabilmente si arriva dopo gli altri e bisogna guadagnarsi il rispetto con umiltà, comprendendo come lavoravano prima del nostro arrivo. L'altro è molto più incoraggiante: senza di te non possono scalare.

Il valore che porti è quello di una leva di crescita quando le cose diventano più complesse, aumentano i team coinvolti e crescono i rischi. Devi parlare il linguaggio di tutti i team con cui lavori, compreso il prodotto, e diventare un partner strategico capace di comprendere la visione e sostenere la strategia di distribuzione.

Satish Menon: Nell'attuale mondo dell'intelligenza artificiale, se hai un concetto puoi produrre rapidamente una demo realizzata con programmazione intuitiva. Puoi mostrarla a tre o cinque clienti affidabili e disponibili a fornire un feedback.

In passato serviva una grande quantità di codice prima di poter mostrare una demo a un cliente. Ora puoi generare rapidamente una demo, che a Seismic chiamavamo anteprima di ricerca.

Puoi mostrare il codice iniziale ai clienti, ottenere feedback, perfezionare i requisiti e poi consolidare il risultato fino alla disponibilità generale. I TPM possono contribuire a rendere sistematico questo processo, ottenendo più valore prima del rilascio generale.

Per quanto riguarda il valore strategico, è più semplice quando tu e il dirigente aziendale siete allineati sul valore che apporti. Quando cambia un dirigente, può esserci un periodo di incertezza, perché le sue convinzioni iniziali sono diverse. A volte hai l'opportunità di spiegare il valore e chiedere tre mesi per dimostrarlo; altre volte il nuovo dirigente vuole apportare cambiamenti immediati.

Dobbiamo accettare che le convinzioni iniziali dei dirigenti possano influenzare il nostro destino. A volte possiamo modificarle, altre volte ne siamo condizionati.

Galen Low: Questa parte è offerta da Fingerprint. Ogni visitatore della tua piattaforma all'inizio appare uguale. Puoi fidarti o rappresenta una minaccia? Fingerprint riconosce bot, agenti di intelligenza artificiale, VPN, manomissioni e oltre 100 altri segnali unici per fornire una valutazione duratura del rischio e il rilevamento delle minacce in tempo reale. Anche mentre l'attività umana e quella degli agenti si fondono, puoi identificare più rapidamente il traffico sospetto e creare siti e applicazioni più sicuri.

Oltre 6.000 aziende si affidano ogni giorno a Fingerprint. Unisciti a loro su fingerprint.com. E ora torniamo al programma.

Satish Menon: Nell'era dell'intelligenza artificiale dobbiamo dimostrare come abbiamo trasformato il nostro lavoro. Non basta spiegare come automatizziamo i pannelli di controllo: dobbiamo mostrare come triangoliamo più sistemi e analizziamo gli indicatori iniziali per prevenire un esito negativo invece di reagire quando è ormai troppo tardi.

Questi sono i nostri indicatori iniziali, questi i nostri pannelli di controllo attuali e questi i modi in cui utilizziamo l'intelligenza artificiale nella gestione dei programmi tecnici per ampliare ciò che avviene nell'ingegneria. Questa è la conversazione che avrei con un nuovo dirigente.

Galen Low: Alcune battaglie sono impossibili da vincere, soprattutto quando un dirigente è sotto pressione per modificare il personale e migliorare la redditività. Tuttavia, è importante educare sul fatto che il ruolo è cambiato. Il valore non consiste più nel controllare caselle e monitorare attività, ma nell'evitare problemi, gestire i rischi e garantire buoni risultati a velocità elevata.

Satish Menon: Un buon team di TPM, con un modo di operare adeguato all'era dell'intelligenza artificiale, può identificare indicatori iniziali di rischio in qualsiasi programma o attività e avvisare dell'arrivo di un risultato negativo, mitigandolo. Altrimenti le conseguenze arrivano quando è ormai troppo tardi e intervenire è costoso.

Galen Low: Il ruolo è diverso oggi, sia per l'intelligenza artificiale e i cambiamenti nello sviluppo software, sia perché le professioni si stanno evolvendo. Abbiamo parlato di anteprime di ricerca, programmazione intuitiva e pannelli di controllo con indicatori iniziali. Quanto è diverso oggi il ruolo del responsabile dei programmi tecnici rispetto a tre o quattro anni fa?

Satish Menon: Se gli ingegneri software lavorano dieci o cento volte più velocemente, dobbiamo fare lo stesso. Dobbiamo smettere di creare report manuali o raccogliere manualmente lo stato. Dobbiamo usare pannelli di controllo aggiornati in tempo reale e valutare gli elementi rossi e gialli triangolando le informazioni provenienti da più strumenti.

Se Jira indica che qualcosa è quasi completato, ma la valutazione di GitHub e Claude non corrisponde, questo è un segnale d'allarme. Se il ciclo di vita della programmazione è scollegato dal report di Jira, il rischio emerge prima che sia troppo tardi.

Bisogna anche osservare ciò che BrowserStack indica sulla qualità, sulla distribuzione nel cloud, sui test e sull'ambiente di staging. Se non ci adattiamo a questi cambiamenti e ai nuovi modi di pensare allo stato del progetto e alla distribuzione del valore, rischiamo di diventare obsoleti. Chi si adatta è chi sopravvive.

Lo stesso vale per gli ingegneri software. Se usano l'intelligenza artificiale solo occasionalmente, il loro tempo è limitato. Devono adottare un modello in cui gran parte del codice viene generata dall'intelligenza artificiale, mantenendo però una supervisione umana che garantisca il rispetto dei limiti fondamentali.

Dobbiamo fare lo stesso dal lato dei TPM. In questo modo ingegneria software e gestione dei programmi tecnici potranno distribuire le cose molto più rapidamente, mantenendo una partnership in cui entrambe le funzioni accelerano per lavorare meglio e più velocemente.

Galen Low: Mi piace questa idea di abilitare la scalabilità e il valore. Non dobbiamo diventare un collo di bottiglia perché siamo rimasti indietro rispetto al modo in cui oggi funziona l'ingegneria software. Dobbiamo essere partecipanti attivi.

Vorrei tornare alla risoluzione dei problemi. Un responsabile dei programmi tecnici non deve avere un background di programmazione né scrivere codice, ma dovrebbe comprendere il ciclo di sviluppo software. Quale livello di problemi deve saper risolvere?

Satish Menon: C'è uno spettro. Quando lavoravo in Google, i TPM erano molto tecnici e potevano occuparsi di una parte più ampia della risoluzione dei problemi tecnici, ma non è comune nel settore.

Un TPM tipico dovrebbe capire, sulla base di un problema, quale team è in ritardo e ha bisogno di aiuto. Dovrebbe sapere se esistono team con capacità simili che potrebbero fornire supporto. Se un team di piattaforma è in ritardo e questo influirà sul rilascio di un prodotto, bisogna assicurarsi che il lavoro della piattaforma venga prioritizzato.

Comprendere chi può essere coinvolto per aiutare a risolvere il problema e portare idee originali al tavolo aumenta il rispetto. Il TPM dovrebbe ridurre il lavoro che il responsabile ingegneristico deve svolgere per individuare i passi successivi verso una soluzione.

Non mi aspetto che il TPM dica a un gruppo di ingegneri esattamente cosa fare per risolvere un problema tecnico. Mi aspetto che porti il problema alle persone giuste, individui le risorse disponibili e proponga soluzioni parzialmente sviluppate.

Galen Low: Mi piace il tema ricorrente: una comprensione più profonda crea più valore. Se sai già che un altro team possiede le capacità giuste ed è disponibile, puoi proporlo invece di limitarti a dire che il problema appartiene a qualcun altro.

Satish Menon: Se dici semplicemente a un team che il problema è suo e che deve risolverlo entro una certa data, il rispetto diminuisce. Se conosci abbastanza il loro lavoro da proporre almeno il 70% di una soluzione, per esempio nell'assegnazione delle risorse o in modi creativi per affrontare il problema, puoi dire: questa è un'idea, ma il problema resta vostro. Se è utile, usatela; altrimenti trovate un'altra strada.

Questo dimostra che porti almeno alcuni suggerimenti e genera più rispetto.

Galen Low: Mi piace l'espressione soluzioni al 70%. Porti qualcosa di parzialmente sviluppato, non definitivo, ma che rappresenta un punto di partenza. Prima ho formulato la domanda come se stessi dicendo che il TPM avrebbe realizzato con programmazione intuitiva qualcosa per l'anteprima di ricerca.

Satish Menon: No. Si tratta più che altro di un cambiamento di processo. I product manager e gli ingegneri senior sono quelli che realizzano la programmazione intuitiva. I TPM coordinano il lavoro, si assicurano che ci siano buone demo per i clienti e raccolgono ulteriori requisiti. Supervisionano il processo.

Galen Low: Tutti si muovono più velocemente, soprattutto nell'ingegneria software, ma la collaborazione è ancora preziosa. L'anteprima di ricerca non esiste senza l'ingegneria. C'è più collaborazione perché gli sviluppatori non scrivono soltanto codice manualmente, i responsabili dei programmi dispongono di strumenti e pannelli di controllo e i product manager possono creare rapidamente prototipi.

Tutto questo riduce il rischio nella distribuzione.

Satish Menon: Ho visto anteprime di ricerca basate sulla programmazione intuitiva realizzata dagli ingegneri, dai product manager o dai team di design. Un'idea interessante può essere trasformata rapidamente in un prototipo. Non siamo più limitati a mostrare soltanto un progetto realizzato in Figma.

Galen Low: Come affronti le decisioni di assunzione? Preferiresti assumere un ex sviluppatore diventato un ottimo responsabile dei programmi o un responsabile dei programmi esperto che non sappia cosa sia una richiesta di unione?

Satish Menon: Come ho detto, penso che un TPM che abbia programmato in passato sia generalmente migliore. Tuttavia, ci sono eccezioni. Alcuni TPM hanno trascorso molto tempo con i programmatori per comprenderne il lavoro e imparare il flusso di lavoro.

Valuto il risultato, non soltanto il curriculum. Voglio capire se il candidato sa parlare efficacemente il linguaggio degli ingegneri, dei product manager e dei designer. Non importa se ha imparato programmando in passato o collaborando con gli sviluppatori dopo essere diventato TPM.

Oggi, però, l'opportunità per un TPM senza background di programmazione di entrare nel lavoro software e imparare sul posto è molto più ridotta. In passato un responsabile di programmi hardware poteva entrare in un progetto software e imparare a lavorare con gli sviluppatori. Oggi la tolleranza verso chi necessita di formazione sul lavoro è molto bassa e si cercano persone già pronte.

Galen Low: È una prospettiva molto realistica. Non significa che chi non sappia cosa sia una richiesta di unione non troverà lavoro, ma deve essere pronto a formarsi e a cogliere ogni opportunità per parlare quel linguaggio e collaborare con i team interfunzionali.

Satish Menon: Alcune aziende assumono esclusivamente sulla base di domande situazionali non tecniche. Io non lo faccio. In ogni colloquio utilizzo una serie specifica di domande per verificare le competenze tecniche nelle aree che mi aspetto dal candidato.

Valuto la competenza tecnica su una scala da zero a dieci, sia nell'ambito del mercato verticale in cui il candidato ha distribuito prodotti, sia nel flusso di lavoro generale di un ingegnere software. Poi aggiungo domande situazionali sugli aspetti relazionali e sull'intelligenza emotiva.

Ho imparato questo metodo di colloquio strutturato in Google. È un modo molto obiettivo e scientifico di assumere e continuo a seguirlo.

Galen Low: Puoi condividere un esempio di domanda situazionale che verifichi le conoscenze tecniche di un determinato candidato?

Satish Menon: Se qualcuno dichiara di aver lavorato in un ambiente SaaS e di aver ottimizzato l'ambiente di rilascio per distribuire più velocemente, chiedo che cosa differenzi la distribuzione SaaS da quella locale, quali scorciatoie siano state adottate e perché.

Faccio domande di approfondimento per capire quanto il candidato conosca realmente la distribuzione SaaS e il funzionamento del prodotto. Se qualcuno parla di un prodotto distribuito presso un'azienda specifica, studio quel prodotto e chiedo quali funzionalità abbia rilasciato.

In questo modo capisco se il candidato si sia limitato a sovrapporre un processo al ciclo di vita del software senza comprendere il punto di partenza, ciò che è stato distribuito e il cambiamento apportato ai clienti.

Pongo anche domande di base sul ciclo di vita del software dal punto di vista della programmazione, su DevOps, sulla differenza tra staging e produzione e sulle misure di sicurezza che impediscono di introdurre vulnerabilità.

Galen Low: Abbiamo iniziato parlando delle aspettative diverse sul valore generato dai responsabili dei programmi tecnici e da alcuni dirigenti che vorrebbero unire il ruolo del TPM a quello del responsabile del team di ingegneria software. Hai spiegato bene perché non dovrebbe accadere.

Ma se in futuro il ruolo ibrido diventasse la struttura dominante nello sviluppo software, quale sarebbe l'impatto? Cosa significherebbe per leader come te, convinti che i due ruoli debbano restare separati?

Satish Menon: Come comunità dobbiamo concentrarci su ciò che possiamo controllare. Non possiamo controllare tutto.

Possiamo però essere all'avanguardia rispetto a ciò che gli strumenti ci consentono di fare e che continua ad aggiungere valore alla distribuzione dei prodotti. Dobbiamo pensare in termini interfunzionali, multidisciplinari e di più team.

Il nostro valore è massimo all'intersezione di più funzioni che collaborano per distribuire un prodotto. A un livello iniziale si tratta di più team ingegneristici. Poi di ingegneria e controllo qualità, quindi di ingegneria, controllo qualità, DevOps, documentazione tecnica e così via.

A un livello successivo si tratta di collegare ciò che viene distribuito dall'organizzazione di prodotto alle funzioni sul campo, ai responsabili del successo dei clienti, agli ingegneri commerciali, all'assistenza clienti e ai servizi premium. Ci sono eventi di lancio, messaggi di marketing e molte funzioni diverse che contribuiscono al quadro generale.

Il TPM può orchestrare tutto questo. Può anche gestire programmi tra aziende e partnership, quando un prodotto viene lanciato insieme a quello di un'altra organizzazione.

Bisogna pensare in grande, considerando l'evoluzione di ciò che gli strumenti possono fare e ciò che resta nelle nostre mani. Oggi significa pannelli di controllo automatizzati e aggiornati in tempo reale, triangolazione tra più strumenti, uso dell'intelligenza artificiale e coinvolgimento nel prodotto e nella risoluzione dei problemi. Il passo successivo consiste nell'affrontare problemi interfunzionali sempre più grandi.

Galen Low: Mi piace molto. Siamo al centro. Se si elimina questo ruolo dal centro e lo si concentra soltanto sull'ingegneria software, si perde tutto quel valore. Sono la scala, la complessità, i partner, i team e le diverse discipline a creare il valore che giustifica un ruolo separato.

Ma serve profondità di comprensione. Non possiamo limitarci a spuntare caselle e sovrapporre framework a prodotti che non comprendiamo. Dobbiamo sapere che cosa significa valore, come viene realizzato il prodotto e come garantire una distribuzione significativa e d'impatto.

Satish, grazie mille per il tempo che mi hai dedicato oggi. È stato molto piacevole. Per chi apprezza ciò che dici, dove può saperne di più su di te?

Satish Menon: Cercatemi su LinkedIn.

Galen Low: Grazie ancora.

Satish Menon: Mi è piaciuta molto la conversazione, Galen. Grazie dell'opportunità.

Galen Low: Bene, amici. È tutto per questo episodio del podcast del Digital Project Manager. Se avete apprezzato la conversazione, iscrivetevi ovunque ci ascoltiate. Se volete ancora più approfondimenti pratici, casi di studio e guide operative, create un account gratuito su thedigitalprojectmanager.com.

Alla prossima, grazie per aver ascoltato.