Nessun PM nel team: cosa dovrebbe fare un Senior?

Ho recentemente superato il periodo di prova, e durante un 1-on-1 il mio manager mi ha detto: "Mi piacerebbe che fossi più proattivo nell'esplorare i problemi del prodotto."

Mi ha colto di sorpresa. Scrivevo codice ogni giorno, sistemavo issue e portavo avanti i progetti. Come poteva non essere abbastanza proattivo? Mi ci è voluto un po' per capire cosa intendesse realmente.

Tutto in esecuzione contemporaneamente

Superare il periodo di prova non significava meno pressione. Semmai, significava destreggiarsi con ancora più cose contemporaneamente:

Elemento	Natura	Cosa posso controllare
Correzione issue	Lavoro quotidiano, con output misurato in parte per volume	Mantenere un ritmo costante
Progetto A	Un progetto formale, ma il lato utente è lento nel confermare i requisiti	Limitato — principalmente in attesa di risposte
Ricerca prodotto	Cercare proattivamente modi per migliorare il prodotto	Quando consegnare, come presentarlo, come riportarlo

Quando passi da una cosa all'altra tre o più volte in un solo giorno, la parte estenuante non sono le ore. È il costante context switching.

Poi ho realizzato: non abbiamo un PM

Lo sapevo dal primo giorno, ma non avevo mai veramente riflettuto su cosa significasse.

Abbiamo un BA (Business Analyst) che gestisce l'analisi dei requisiti, ma nessuno si occupa davvero di domande come: A che punto siamo? Chi è bloccato? Dovremmo rivedere le priorità?

Nella mia azienda precedente, il PM o il Tech Lead gestiva tutto questo. Dovevo solo controllare il backlog, confermare le priorità, chiarire i requisiti del prodotto e concentrarmi sulla scrittura del codice. Arrivava la spec, io costruivo. Se ero bloccato, lo dicevo al PM e loro gestivano il resto.

Ora quel ruolo non esiste. Quindi chi se ne occupa?

Il Senior.

Senior non è PM, ma serve Ownership

All'inizio non capivo. Sono un ingegnere — perché dovrei rincorrere gli utenti per le risposte, segnalare proattivamente i blocker o allineare le priorità con il mio manager? Non è lavoro da PM?

Ma questo non significa che un Senior debba sostituire un PM assumendosi il roadmap del team, gestendo il coordinamento interfunzionale o tracciando i progressi di tutti gli altri. Il punto vero è più semplice: non puoi trattare i blocker nel tuo stesso lavoro come se fossero il problema di qualcun altro.

Quando ho confrontato i due ruoli, la differenza è diventata più chiara:

	PM	Senior
Di chi gestire i progressi	L'intero team	Le tue linee di lavoro
Decidere cosa costruire	Roadmap, priorità	Non decidi, ma ti allinei
Rincorrere stakeholder	Tutti i coinvolti	I tuoi blocker
Responsabile verso	Obiettivi di business	Le funzionalità che gestisci

Un Senior non ha bisogno di gestire altre persone. Devi solo mantenere le tue tre o quattro linee senza farle cadere. Segnala i blocker proattivamente invece di aspettare in silenzio. Abbi opinioni sulle funzionalità che gestisci invece di aspettare solo istruzioni.

Questo si chiama ownership, non PM.

Non è che il mio lavoro precedente fosse troppo facile

Per un momento mi sono chiesto se la mia vecchia azienda avesse semplicemente aspettative più basse per i Senior. Ma più ci pensavo, più mi rendevo conto che non era quello il problema. Gli ambienti erano semplicemente diversi.

La mia azienda precedente aveva un PM che mi schermava dal lavoro di coordinamento, e la linea di prodotto era più semplice. Lì, "Senior" era definito più in termini tecnici: se sapevi risolvere problemi difficili, bastava. Nel mio ambiente attuale, parte del lavoro è anche spingere avanti il progresso del prodotto, perché nessun altro lo farà al posto tuo.

In un team snello, è normale. Non è irragionevole. Semplicemente non ci sono ancora abituato.

Cosa ho effettivamente fatto

Una volta capito questo, ho fatto alcuni cambiamenti:

Dare priorità e allinearsi con il manager. Ho elencato tutto per priorità e ho chiesto: "Questo ordine ti sembra OK?" È solo un messaggio, ma cambia l'atteggiamento da aspettare passivamente istruzioni a gestire attivamente il proprio lavoro.

Quando sei bloccato, cambia linea, ma lascia un registro. Se l'utente del Progetto A non risponde, faccio un ping una volta a settimana e lascio una traccia scritta. Il mio manager sa che il blocker non è dalla mia parte, e posso usare il tempo liberato per portare avanti la ricerca prodotto.

Non fare context switching troppo spesso. Usa le priorità per decidere su cosa lavorare oggi invece di toccare tutto un po'. Registra le linee bloccate, mettile da parte e torna quando si sbloccano.

Pensiero finale

Tutto questo sembra basilare, ma per un ingegnere abituato ad avere un PM che gestisce il coordinamento, ci vuole tempo per adattarsi. Sotto pressione, può sembrare di fare un lavoro che non è il tuo. Ma almeno in un team senza PM, questo fa parte di ciò che significa essere Senior.

Come nota a margine, ho prima ordinato i pensieri dietro questo post attraverso conversazioni con l'AI, poi li ho tracciati attraverso un sistema personale che ho costruito per il logging quotidiano e il feedback — lo chiamo Pasiv. Il Vibe coding non è solo usare l'AI per costruire progetti. Include anche usarlo per sbrogliare dove ti trovi attualmente.