Proseguo la mia analisi introducendo una figura centrale in molte aziende tech: l' Engineering Manager, che il titolo più comune; talvolta può anche essere chiamato Software Development Manager.

People manager

L'engineering manager è, prima e soprattutto, quello che viene definito un people manager. Ho assunto questo ruolo da qualche tempo. Quando l'ho detto ad alcuni amici e colleghi italiani, la prima cosa che mi hanno chiesto è stata:

ah, ma sei passato a Human Resources?

Si dice che è un people manager perché sì, deve capire la tecnologia con cui sta lavorando il suo gruppo, ma non è il suo primo compito; il suo primo compito è invece lavorare sulla squadra.

Quale squadra?

Il team è ormai considerato l'unità centrale e inscindibile nel nel campo dello sviluppo software. Di solito è un gruppo piuttosto costante (nel senso che non dovrebbe cambiare formazione ogni settimana) - meno cambia nel corso del tempo, meglio lavorerà, più rilevanti saranno le stime, le previsioni, e più consistente la qualità dell'output. L'engineering manager è a capo di un team a livello gestionale, non tecnico. Questa distinzione è assolutamente rilevante: mi capita non di rado di vedere, sui profili LinkedIn di alcune aziende italiane con dipartimenti tech anche medio-grandi (es. banche, assicurazioni, telco) dei CTO con una descrizione come:

Responsible for architecture, design, technical development, human resources management.

Il che, nella mia opinione, è un anti-pattern: o guidi una squadra a livello tecnico, o lo fai a livello manageriale. Ciascuno è una lavoro di tutto rispetto, ma che richiede un sacco di tempo ed energie, e soprattutto richiede stili di lavoro diversi. Anche le persone in gamba sia dal lato tecnico che da quello gestionale fanno fatica a coprire entrambe le mansioni ruoli contemporaneamente.

Da questa confusione nascono molti dei problemi di crescita che affliggono tante aziende nostrane.

Ma quindi? Che cosa fa un EM?

L'EM è il primo contatto dei candidati durante la procedura di assunzione (dopo il team di talent acquisition), discute con i membri del team cercando di capire i loro problemi, le loro ambizioni, i loro punti di forza; osserva le loro performance, dando loro consigli per migliorare quando non sono eccezionali.

Ma soprattutto: è il vero centro nevralgico del team per quanto riguarda la gestione delle priorità dei lavori - eventualmente coordinato con un product manager.

Se qualsiasi persona esterna al team ha bisogno di aiuto da parte di qualche membro del team va a interfacciarsi con l'EM, che valuta la richiesta e la priorità della stessa, bilanciandola con quelle che sono le attività del team in un certo momento. L'EM quindi:

  • è sempre al corrente di quello che i membri del team stanno facendo
  • è sempre al corrente di quali sono le priorità del team
  • gestisce le richieste in entrata, e le passa al team solo quando c'è davvero una ragione. Molto importante: può, e spesso deve, dire no, senza neanche rompere le scatole ai membri del team.
  • fa lo screening in fase di ricerca del personale, evitando che gli sviluppatori debbano perdere troppo tempo nelle fasi iniziali della ricerca.

In generale, l'engineering manager fa sì che la squadra sia motivata, allineata, e possa mantenere il focus sui compiti davvero importanti da svolgere, senza venire distratta senza un buon motivo.

Ma perché ne avrei bisogno?

Cito qui un vecchio - ma sempre valido - articolo di Paul Graham, Maker's schedule, Manager's Schedule.

Il succo è: perché gli sviluppatori - o altri maker - hanno bisogno di tempo e focus per poter lavorare bene. Due riunioni al giorno, mezz'ora al mattino e mezz'ora al pomeriggio, e avrete azzoppato la produttività del vostro miglior sviluppatore.

Puoi decidere di non avere un manager nel tuo team. Ma questo non toglierà la necessità di gestione che esistono nel momento in cui un'azienda cresce.. Ci sarà comunque bisogno di parlare con un cliente, un fornitore, o un altro dipartimento all'interno dell'azienda; questo compito sarà preso in mano da uno sviluppatore (o da più sviluppatori in diversi momenti), distraendolo, e rendendo le priorità meno chiare.

Ma... e il project manager? Lo scrum master? Il product manager?

Belle domande; ne discuterò nella parte 2, che arriverà questa volta a strettissimo giro!