Arriviamo quindi all'ultima (credo!) parte della discussione sul ruolo dell'engineering manager.
Diavoletti di Maxwell
Ecco, questa è quella che credo che sia una buona visualizzazione degli engineering manager: sono i diavoletti di Maxwell di un'organizzazione.
Il diavoletto di Maxwell, se non ve ne ricordate, è un esperimento mentale proposto da James Clerk Maxwell nel 1867; questo diavoletto dovrebbe creare ordine a partire dal disordine, diminuendo l'entropia di un sistema e violando così il secondo principio della termodinamica. Il diavoletto non potrebbe esistere nel mondo reale per una ragione molto semplice: richiede energia per poter funzionare.
Che cosa c'entra, qui, questo diavoletto?
Be', la natura del lavoro nelle realtà moderne, in particolare quelle dominate dai knowledge worker, é tutt'altro che lineare; non state lavorando in un contesto industriale dove uno stesso processo, ripetitivo, può essere continuamente raffinato fino ad arrivare vicini alla perfezione. Certo, si parla di Six Sigma anche in campo organizzativo, ma le organizzazioni moderne, grazie ai progressi dell'automazione e dell'informatica, sono spesso degli organismi che devono ideare, creare, modellare, più che gestire compiti standard.
I processi possono aiutare, di certo, ma si parla sempre di persone che lavorano attorno a tali processi. People over process.
Anche il lavoro degli sviluppatori è spesso impredicibile. Bug upstream, peculiarità dei sistemi con cui si lavora, fornitori di terze parti che decidono di cambiare d'improvviso l'implementazione delle loro API; nessuno si dovrebbe attendere che un flusso di sviluppo sia costante e prevedibile; rimane possibile fare delle previsioni e gestire il caos, ma quest'ultimo, va appunto gestito.
Insomma, nel suo insieme ogni azienda è di per sé caotica. Ci sono molte persone con obiettivi diversi; chi vuole vendere quel che si ha, chi vuole sviluppare, chi vuole supportare un cliente, chi ha un'idea e che crede sia la migliore di sempre; l'organizzazione è un organismo che si muove in maniera imprevedibile e talvolta contraddittoria al suo interno.
Gli Engineering Manager in un'azienda tech prendono il caos naturale e cercano di organizzarlo, così che da un parte e dall'altra si possa mantenere una certa comprensibilità della situazione.
Ma non è qualcosa che arriva automaticamente, né è gratis.
La disorganizzazione
Quando discuto con i colleghi sviluppatori italiani, alcuni si lamentano dello stipendio, rispetto all'estero. Ma molti di più, forse quasi tutti, si lamentano di qualcosa d'altro: la disorganizzazione.
Le nostre aziende sono troppo incasinate, e il caos trasuda a tutti i livelli. Non si capisce mai a chi chiedere qualcosa. Non si riesce mai ad avere una risposta definitiva, fosse anche un no. Tutto sembra esistere in un limbo continuo, e spesso ci si muove da uno stato di emergenza ad un altro, senza una visione non di lungo, ma neanche di medio periodo; spesso questa sensazione, tra l'altro, travalica i confini del tech, è quasi una costante italiana, dalla PMI alla grande azienda.
Quante volte avete sentito frasi come possiamo riuscire benissimo a gestire tutto il carico di lavoro, basta organizzarci?
Potrebbe essere vero (anche se tratterò il realismo in un altro articolo), ma rimane il fatto che qualcuno deve dedicarsi a tale organizzazione.
Il caos non è qualcosa che si risolve con attività spot e una tantum, con interventi ad-hoc "quando serve"; gestire il caos richiede energia continua, tant'è che il motivo per cui il diavoletto di Maxwell originale non può esistere è proprio questo.
D'altronde, se il problema è la mancanza di organizzazione, in quale modo l'assumere nuovo personale dedicato ad altre mansioni potrebbe aiutare?
Tutti i sistemi complessi falliscono. Il caos è lo stato naturale delle cose, e la struttura organizzativa è uno degli scudi per evitare il fallimento.
Ma l'overhead?
Il management è overhead; certo. Un manager, spesso (anche se in realtà può svolgere benissimo anche altre attività), non è direttamente produttivo. Tuttavia, nel momento in cui un'organizzazione deve crescere, non ci sono, ad oggi, molte soluzioni migliori; tra l'altro chi crede che i middle manager saranno rimpiazzate dall'AI non ha mai avuto un buon manager, o non ha mai capito il suo lavoro.
Insomma, potremmo dire che una struttura di management è la soluzione peggiore e più costosa al caos e alla gestione del personale; fatta eccezione per tutte le altre.
Che cos'è la cosa più importante, per voi? Poter dire che ogni membro della vostra azienda è produttivo, e notare l'assenza di overhead, o vedere un'incrementata produttività complessiva nella vostra azienda?
Ma io ho un sacco di casini con tutti i miei manager
E' vero, ho visto anch'io queste situazioni. C'è un direttore dello sviluppo, un project manager, un product owner, uno scrum master, un direttore vendite, un direttore marketing, e due sviluppatori.
Il rapporto manager-individual contributor deve avere un senso. Troppi manager aggiungono entropia senza portare valore.
Generalmente il rapporto ideale individual contributor-manager è 6-8:1, e tali IC devono rispondere ad un unico manager, che si interfaccerà con tutti gli altri stakeholder per capire le priorità. Se il rapporto è più alto, il manager farà fatica a lavorare bene con tutti i suoi IC; se è più basso, potrebbe diventare effettivamente una situazione in cui il manager rappresenta un overhead consistente. In queste ultime situazioni non è raro che il manager faccia un po' anche da IC, senza però prendere le redini tecniche della situazione.
E l'agile?
"Ma la presenza di un Engineering Manager non rischia di compromettere la comunicazione lungo gli spazi bianchi (ovvero: senza seguire le linee gerarchiche), come suggerita dall'agile?"
No. L'EM non impedisce la comunicazione. Non è e non dev'essere un gatekeeper. Non obbliga a far passare tutte le comunicazioni attraverso lui/lei. L'EM supporta la comunicazione e si accerta che tutti i messaggi "ufficiali" siano correttamente propagati in tutte le direzioni, sia lungo le linee dell'organigramma che lateralmente.
La comunicazione può avvenire anche in qualsiasi altra direzione o con altri metodi; ma se un'organizzazione, sfruttando l'idea del "facciamo Agile", si basa solo sulla comunicazione spontanea e ad-hoc tra gli spazi bianchi, senza una comunicazione intenzionale, bidirezionale ed efficiente lungo le linee gerarchiche, il rischio è di sottocomunicare e creare disallineamenti di visione nel personale.
That's all folks! (for now)
Probabilmente ritorneremo sui compiti dell'EM (o dei director, o dei VP) nel corso di altri post, ma per il momento dovrei aver detto quel che volevo, e spero di avervi un po' convinto dell'utilità dei ruoli manageriali. Fatemi sapere che cosa ne pensate!
Piccola bibliografia per gli interessati:
An Elegant Puzzle: Systems of Engineering Management https://www.amazon.it/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186/
The Manager's Path https://www.amazon.it/Managers-Path-Leaders-Navigating-Growth/dp/1491973897/
Leading Snowflakes https://leadingsnowflakes.com/
The Essential Drucker https://www.amazon.it/Essential-Drucker-2-Peter-F/dp/0750685069