Che cos'è un Project Manager tecnico?

Che cos'è un Technical Project Manager (TPM)? La risposta dipende da chi chiedi, afferma Andi Blackwell, un veterano consulente IT ed esperto di operazioni aziendali. In qualità di Lead Director di Project and Product Management di Toptal, Blackwell dirige il team responsabile dell'incontro di project manager altamente qualificati nella rete di freelance di Toptal con organizzazioni che cercano i migliori talenti per iniziative specifiche. Negli ultimi anni ha assistito a un aumento della domanda di TPM.

"C'è sicuramente un dibattito nel settore tecnologico su cosa significhi effettivamente quel termine", afferma Blackwell. "Ci sono molte persone che si definiscono Technical Project Manager perché hanno lavorato a stretto contatto con un team di ingegneri o hanno guidato un team tecnico dal punto di vista della gestione del progetto, ma non è quello che stiamo cercando".

La definizione di Toptal è più specifica. Tutti i project manager nella rete di Toptal sono esperti nelle tradizionali capacità di gestione dei progetti come l'ambito, il budgeting e la gestione delle tempistiche, nonché nelle pratiche di sviluppo software Agile relative alla consegna iterativa e al miglioramento continuo. Hanno invariabilmente lavorato a stretto contatto con gli ingegneri e, se chiamati, potrebbero allenare e guidare un team Scrum.

Per qualificarsi come TPM, tuttavia, devono avere un ulteriore livello di esperienza oltre alla gestione dei processi Agile e alla collaborazione con gli sviluppatori: devono essere essi stessi sviluppatori.

Una combinazione pregiata

Le organizzazioni grandi e piccole sono sempre più interessate a questa particolare combinazione di competenze. "La maggior parte delle startup non può assumere una persona che può fare solo una cosa", afferma Blackwell, e le aziende più grandi vogliono vedere "sviluppatore" o "architetto" nel profilo di un candidato se stanno assumendo per un progetto di ingegneria.

Anche nei casi in cui un cliente non richieda specificamente un project manager con un background tecnico, avere la casella "sviluppatore" selezionata è un importante punto di forza. Qualcuno in grado di pianificare ed eseguire un progetto software, implementare e ottimizzare processi e codice Agile? Questo è un enorme vantaggio.

In realtà, tuttavia, non ci si aspetta che i TPM codifichino, molti non codificano da anni. Perché, allora, la necessità di esperienza di programmazione?

I TPM sono necessari per prendere decisioni tecniche, afferma Blackwell: "Se non hai almeno un'esperienza pratica relativamente recente con uno stack tecnologico moderno, un SDK (kit di sviluppo software), un'architettura o una piattaforma di automazione dei test, allora" potenzialmente non prendere le decisioni giuste. Non avrai credibilità con il cliente perché non hai mai usato quelle cose prima.

Lavorare con i team

Dimostrare credibilità a un potenziale cliente è un fattore significativo per garantire impegni, ma è solo il primo ostacolo. Una volta assegnato a un progetto, un TPM deve guadagnarsi rapidamente la fiducia e il rispetto di un team tecnico.

Michael Poythress ha iniziato a programmare da adolescente. A 16 anni ha costruito un sito web commerciale per un'attività di pubblicità immobiliare iniziata con suo padre. Da allora è CEO e fondatore di diverse startup. Nel 2018 è entrato a far parte della rete Toptal come TPM e ora lavora a stretto contatto con i team di ingegneri. "Se non avessi esperienza con la programmazione, i programmatori se ne accorgerebbero", dice. “Non avrebbero sparato direttamente con me. Ma se li sfido e parlo con loro da pari, c'è rispetto e un rapporto".

Ed è l'esperienza tecnologica che conta più del titolo, afferma Allen Takatsuka, un TPM di Toptal con sede a Orange County, California: “Da quello che ho visto, la 'T' in TPM non ha davvero alcun peso per gli ingegneri. Pensano che sia solo un altro project manager che organizzerà le loro riunioni e chiederà loro di compilare fogli di calcolo".

Una volta stabilito un terreno comune, tuttavia, “il sapore dell'interazione è molto diverso. È più una partnership con l'ingegneria,” dice.

Takatsuka ha trascorso decenni alla guida di team di ingegneri all'inizio della sua vita professionale. Attribuisce a quell'esperienza il merito di aver migliorato le sue competenze trasversali. "È un po' un'abilità di empatia diversa", dice. “Devi dimostrare di saper parlare la lingua. Puoi dire: 'Capisco perché hai queste sfide in base alle cose tecniche che stanno succedendo.'"

Dan Allen, un consulente tecnologico di Vienna, Virginia, descrive la sua carriera come "programmatore ragazzo nell'armadio per dirigere tecnico ad architetto, direttore, VP, CTO, CIO". Da quando è entrato a far parte della rete Toptal come TPM nel 2019 è stato impegnato, avendo lavorato su 14 incarichi con i clienti.

“Raramente leggo il codice. Non scrivo quasi mai codice", dice. “Ma ci sono state situazioni in cui uno sviluppatore si è bloccato. Possono guidarmi attraverso l'architettura e posso vedere esattamente cosa stanno cercando di fare e la logica".

Trova la dinamica utile non solo nei casi limite, ma più in generale. "Il tuo team sa che possono venire da te e parlare, e tu capisci davvero cosa stanno dicendo", dice. “Puoi aiutarli a considerare tutte le complessità nel caso si siano persi qualcosa. Puoi essere una cassa di risonanza e fornire feedback”.

L'effetto moltiplicatore

Questo tipo di feedback e intuizione è importante per qualcosa di più della costruzione di relazioni. I TPM offrono una proposta di valore diversa a un'organizzazione. Servono meno come canali di informazione e più come fonti di conoscenza. Sì, pianificano, coordinano e comunicano, ma aiutano anche clienti e team a lavorare attraverso decisioni tecnologiche complesse.

"Hai la capacità di essere tecnicamente supponente", dice Takatsuka. "E questo aggiunge valore all'organizzazione perché ora hai più un effetto moltiplicatore, invece di organizzare e collaborare semplicemente".

Takatsuka osserva che i TPM devono saltare attraverso un minor numero di cerchi per risolvere i problemi. Soprattutto nelle organizzazioni più grandi, un programma non tecnico o un project manager potrebbe affrontare una sfida tecnica identificando gli attori e le parti interessate rilevanti, offrendo contesto, aggregando informazioni e quindi vagliando i risultati per prendere una decisione. I TPM possono mettere a frutto le proprie conoscenze.

"Puoi affrontare i rischi in modo molto più efficiente", afferma Oana Ciherean, TPM con sede a Tokyo. “E quei rischi possono provenire da così tanti posti. Possono provenire da stime sbagliate da parte della squadra. Quindi puoi dire: "Va bene, sono sicuro che questo pezzo di codice non richiederà una settimana per essere scritto" perché in realtà sono due giorni. Quindi puoi effettivamente sbloccare le persone. Perché hai capito che sono bloccati ed è per questo che ci vogliono cinque giorni. Lo sai perché ci sei stato e sei rimasto bloccato anche tu".

Trovare l'equilibrio

Ciherean ha iniziato la sua carriera come sviluppatore, ma presto è passata alla gestione dei progetti per il desiderio di essere coinvolta in un quadro più ampio. In quei ruoli, tuttavia, ha scoperto che le mancava la programmazione. Dice che il Technical Project Management offre il meglio di entrambi i mondi: "Mi permette di essere davvero pratico nella tecnologia ma anche di alto livello nella comprensione del business, dei clienti e di ciò che vogliono nelle funzionalità".

Anche Poythress sente di aver trovato il suo punto debole. "Sono un traduttore o un collegamento tra i visionari che hanno un'idea e il talento tecnico che sa come costruirla e realizzarla", dice. “Parlo correntemente entrambe le lingue. Parlo 'persona normale' e parlo 'tecnico-ese.'"

Il Mini CTO

I TPM che lavorano per startup e piccole imprese occupano un posto particolarmente privilegiato all'incrocio tra business e tecnologia. In questi impegni, un TPM è spesso il primo assunto a salire a bordo all'inizio di un progetto. Lui o lei è quindi responsabile della valutazione della fattibilità del prodotto, della definizione dell'ambito tecnico e dei requisiti e dell'assistenza al cliente (a volte un singolo fondatore con una piantina di un'idea) a selezionare uno stack tecnologico, valutare i fornitori per la fornitura del servizio, implementare le migliori pratiche DevOps, e formare la squadra giusta.

Takatsuka considera questi impegni come ruoli di "mini CTO", in cui il TPM unisce il mondo degli affari e quello tecnico per far decollare le cose. Alcuni clienti non sanno quasi nulla dello sviluppo di software, dice: “Come faccio ad aprire un negozio? Ho letto di Agile. Come lo faccio?"

Poythress vede i due ruoli sovrapposti, in alcuni casi addirittura indistinguibili l'uno dall'altro. "C'è un sacco di impollinazione incrociata", dice. "Un CTO per un'organizzazione più piccola potrebbe facilmente passare a un ruolo di PM tecnico senior in un'organizzazione più grande e sentirsi come a casa."

Abilitazione dell'agilità

Mentre i meccanismi di Agile sono alla guida di praticamente qualsiasi project manager con esperienza di sviluppo software, qualcuno con attitudine tecnica può portare una prospettiva più sfumata alla gestione dei processi.

Ciherean rileva che le metodologie Agile non sono mai implementate rigorosamente dal libro; devono essere personalizzati, combinati e adattati alle esigenze specifiche di un team e di un progetto.

"Devi assicurarti che ciò che stai progettando come processo non interferisca con il lavoro degli sviluppatori e lo renda effettivamente più efficiente o produttivo", afferma. “A volte ciò significa approfondire il flusso di lavoro di GitHub, ad esempio, per vedere come eseguono i loro commit, vedere come creano rami per il loro codice e vedere se il tuo processo si adatta al loro flusso di lavoro. E poi correggi il tuo processo o correggi il loro flusso di lavoro".

L'esperienza di un TPM può anche fornire informazioni su artefatti e pratiche Agile specifici, come il product backlog e le stime relative alle dimensioni.

"Se capisci la tecnica, conosci la grossolana complessità delle cose in un arretrato", afferma Takatsuka. “Altrimenti, tutto ciò che hai è questa lista e sarebbe difficile per te sapere se il numero uno è una maglietta di taglia Large rispetto al numero due. Potresti avere un'idea che uno sia più difficile, ma non sai davvero cosa c'è dietro le quinte. Un TPM "estremo", dice, "potrebbe valutare le cose da solo, con l'avvertenza che quando la squadra salirà a bordo, avranno la propria velocità".

Poythress usa la sua comprensione della stima delle dimensioni come indicatore per valutare i tecnici e gli ingegneri che considera per un progetto. Se si aspetta che qualcosa sia un piccolo compito ma qualcun altro lo considera gigantesco, è una bandiera rossa: "Li ascolterò per vedere se ci sono complessità che non conosco, ma se questo non regge, Sono tipo, 'Ok, beh, non è una buona scelta.' Abbiamo bisogno di qualcuno che lo capisca molto bene e che non sia intimidito da quella che dovrebbe essere una semplice funzionalità".

I TPM aiutano anche a istruire i clienti sui requisiti non funzionali. Come gestisci l'alta disponibilità? Come gestisci il ripristino di emergenza? "Senza la comprensione tecnica, non so come tu abbia quella discussione", dice Takatsuka. “Probabilmente ti fermerai al livello dei requisiti Scrum e chiamerai un giorno fino all'arrivo dei tecnici. Bene, allora hai questo enorme baratro.

Mantenersi aggiornati

Sebbene il tempo trascorso alla tastiera svolga un ruolo fondamentale in ciò che fanno oggi, i TPM non possono fare affidamento sull'esperienza passata per rimanere pertinenti. Data la velocità con cui la tecnologia cambia e si sviluppa, è facile rimanere indietro.

Poythress l'ha imparato a proprie spese, durante una finestra di cinque anni prima di entrare in Toptal, quando era concentrato esclusivamente sulla gestione della propria azienda. "Sono decisamente stagnante", dice. "Sono arrivate molte lingue diverse e hanno risolto problemi in quel periodo di tempo di cui non sapevo nulla perché avevamo il nostro stack tecnologico ed era tutto ciò di cui avevamo bisogno".

Oggi trascorre fino al 10 percento del suo tempo a leggere documentazione, guardare YouTube e fare sandbox "per conoscere le cose più recenti e straordinarie".

"Mi dilettavo quasi sempre con una nuova lingua o tecnologia, solo così rimango sveglio", dice. “Perché se non lo faccio, l'industria andrà avanti. Mi è successo prima. Ed è molto più difficile stipare che tenersi aggiornati”.

Takatsuka è anche proattivo nel colmare le sue lacune di conoscenza: "Google è fantastico in questi giorni. YouTube è fantastico. Dovete fare i compiti. Ma quel lavoro si basa su se stesso”.

Si affida anche a un'ampia rete di colleghi consulenti per il supporto e la condivisione delle conoscenze. "Mi sono trovato in situazioni in cui il cliente desidera utilizzare Google, ma mi capita di conoscere meglio la piattaforma AWS", afferma. “Posso chiamare gli amici e dire: 'Ehi, useremo Firebase. Hai avuto clienti che lo fanno? E la scalabilità?'”

Anche dopo oltre 30 anni nel mondo degli affari e diversi ruoli a livello dirigenziale, Dan Allen non ha paura di sporcarsi le mani. Negli ultimi tre anni ha imparato da solo a distribuire da solo su Amazon e Google Cloud. "L'ho fatto in modo da poterlo capire e aiutare un cliente Toptal", dice. “Non avevano un team tecnologico. Tutto quello che avevano ero io. Così sono andato alla YouTube University e l'ho fatto".

Tanto è cambiato da quando Allen ha iniziato come sviluppatore nel 1985. Ma apprezza le sfide che si presentano con ogni nuova opportunità. "Questo fa parte di ciò che amo del lavoro", dice. “C'è sempre qualcosa che non hai fatto, qualcosa di nuovo. E te ne vai sempre con un tocco in più nel tuo berretto che puoi sfruttare al prossimo impegno. "