Ultimamente, ho continuato a riflettere su due argomenti che condividono un tema simile. Il primo argomento ha a che fare con lo stato delle infrastrutture pubbliche della California e quanto sia diventato inefficiente nel corso degli anni. Il secondo è l'incapacità delle grandi aziende tecnologiche di innovare ed eseguire più rapidamente rispetto alle startup storiche. Permettetemi di fornire alcune prospettive sul motivo per cui questi argomenti sono correlati fornendovi prima due esempi su cui riflettere:

• Infrastrutture : la costruzione del Golden Gate Bridge ha richiesto circa quattro anni (1933-1937) e ci è costata circa 500 milioni di dollari di oggi. Al contrario, l'SDS ( Suicide Deterrent System ), che sostanzialmente aggiunge una rete attorno al ponte, ci vorranno cinque anni per essere completato (2017-2023) e si prevede che ci costerà ~ $ 217 milioni. Se si esaminano i principali progetti infrastrutturali in California, si scopre che per i progetti completati prima degli anni '50 il lavoro è stato svolto più velocemente, più economico e con una qualità superiore rispetto a quanto viene fatto oggi di almeno una grandezza 5 volte superiore, anche se oggi abbiamo più capitale, migliore tecnologia, migliori materie prime e un numero assoluto più elevato di ingegneri civili e architetti.
• Aziende tecnologiche : Adobe, nonostante tutte le sue risorse finanziarie e umane, si trova a dover acquisire un concorrente per 20 miliardi di dollari. Resta da vedere se Adobe abbia pagato in eccesso per Figma, ma la domanda più interessante è perché un'azienda con 100 volte il personale, 100 volte la profondità di esperienza negli strumenti di progettazione e 100 volte il capitale finanziario non è riuscita a vincere?

Allo stesso modo, se dai un'occhiata all'interno delle aziende, potresti scoprire che man mano che crescono, elaborano e gonfiano si insinua in qualsiasi cosa e soffoca il vero lavoro e l'innovazione. In quell'ambiente, i dipendenti che sono i più desiderosi di creare cose, i produttori, scoprono che è semplicemente più attraente saltare la nave in un luogo più piccolo dove il loro lavoro ha uno sbocco per materializzarsi. Sia i fallimenti dell'infrastruttura che i fallimenti dell'innovazione aziendale sono almeno in parte dovuti a gonfiori e scorrimento dei processi.

Perché si verifica lo scorrimento del processo?

Ogni processo inizia con buone intenzioni.

• "Vogliamo assicurarci che tutte le parti interessate abbiano un contributo al lavoro finale, quindi tutte le proposte di progetto presentate devono essere riviste dai team legali, di progettazione, di prodotto e di ingegneria".
• "Vogliamo assicurarci che i grandi progetti infrastrutturali non causino danni, quindi dobbiamo eseguire studi ambientali approfonditi prima di iniziare qualsiasi lavoro".
• "Vogliamo ridurre al minimo le violazioni dei dati, quindi qualsiasi richiesta di dati deve essere effettuata tramite i team IT e di sicurezza".

La strada per il perfezionismo

Ricordo di aver sentito un manager ben intenzionato dire ai suoi dipendenti diretti di scrivere software come se dovesse durare 100 anni. Sebbene l'osservazione fosse iperbolica, il consiglio riecheggia qualcosa che ho sentito spesso nel settore tecnologico attraverso adagi come "misura due volte e scrivi una volta" o "se non hai tempo per farlo bene, hai tempo per farlo due volte?.” Questo non è un cattivo consiglio. In alcune situazioni, devi scrivere codice come se durerà 100 anni, e andare a capofitto nell'esecuzione senza una pianificazione è uno spreco. Tuttavia, l'estrema enfasi sulla pianificazione può portare alla paralisi e all'incapacità di riconoscere i benefici dell'apprendimento attraverso l'iterazione. Preferirei vivere in un mondo in cui il software viene riscritto ogni anno perché c'è un forte riconoscimento che la perfezione non esiste e che il prerequisito per l'evoluzione è il cambiamento, invece di un mondo in cui le cose funzionano su " basi di codice vecchie di 50 anni ".

Troppa colla

Molti anni fa ho letto il post sul blog di Tanya Reilly sull'essere Glue (lettura altamente raccomandata, tra l'altro). A quel punto della mia carriera, il contenuto ha risuonato davvero perché avevo a che fare con alcuni colleghi che, sebbene tecnicamente competenti, semplicemente non stavano lavorando alle cose giuste. Le persone colla si impegnano in un processo di leadership tecnica e tutoraggio che porta a rendere più produttive le altre persone del team. Una certa quantità di colla è necessaria, tuttavia, ho scoperto che troppa colla crea una serie di altri problemi:

• Le persone che lavorano con la colla impediscono ad altre persone di migliorare le loro abilità non tecniche. Ad esempio, un responsabile tecnico che non consente al proprio team di parlare del proprio lavoro o che spesso funge da "cuscinetto" sta essenzialmente togliendo opportunità ai circuiti integrati per lottare e alla fine migliorare le proprie capacità di comunicazione.
• Versioni estreme e tossiche del comportamento della colla a volte si manifestano nel prendersi il merito del lavoro di altre persone o nel generare attribuzioni grossolanamente esagerate (“ad esempio, senza che io faccia da intermediario, il progetto non avrebbe successo”). Mentre Tanya parla delle situazioni in cui le persone di Glue spesso non vengono riconosciute, la mia esperienza è completamente l'opposto. Perché le persone di Glue sono dei bravi comunicatori, sanno come pubblicizzare il loro lavoro e fanno bene la politica. In cambio, ottengono maggiore visibilità e maggiori opportunità di promozione, mentre l'ingegnere che lavora sui dettagli dell'implementazione spesso ottiene un riconoscimento simbolico o nessun credito.
• Infine, l'aggiunta di troppe persone di colla riduce la proprietà e la responsabilità per i singoli ingegneri. Invece di aggiungere persone collanti per gestire un team tecnicamente competente, lascerei semplicemente andare gli ingegneri che sembrano non avere intuito aziendale, mancano di capacità comunicative o non riescono a mettere insieme un paragrafo che descriva perché il lavoro che svolgono ha un impatto. Suggerire che hai bisogno di più colla per gestire gli ingegneri finisce per respingere lo schema generale secondo cui le persone tecnicamente brillanti hanno anche un alto livello di intelligenza generale, leggono molto, imparano per tutta la vita e sono molto brave negli affari e non solo nel codice.

Quando ero alla Novell, avevo appreso che c'erano persone che io chiamo "persone colla". Le persone colla sono persone incredibilmente simpatiche che siedono ai confini interstiziali tra i gruppi e aiutano nell'attività. E sono molto, molto leali, e la gente li ama, e tu non ne hai affatto bisogno.

A Novell, ho continuato a cercare di sbarazzarmi di queste persone colla, perché si stavano mettendo in mezzo, perché hanno rallentato tutto. E ogni volta che mi sbarazzavo di loro in un gruppo, si presentavano in un altro gruppo, e si trasferivano, e venivano riassunti e tutto il resto.

Entropia

Man mano che le organizzazioni crescono, la conoscenza istituzionale, il numero di parti interessate, le basi di codice e l'entropia aumentano. L'aumento dell'entropia porta a sprechi elevati, carico cognitivo elevato, disorganizzazione e caos.

Come ingegneri del software, penso che abbiamo fatto un pessimo lavoro nella gestione della complessità. Ad esempio, per anni abbiamo sentito dire che i monoliti sono dannosi perché generano basi di codice gonfie, rendono difficili le distribuzioni o creano problemi con la scalabilità. Tuttavia, all'altro estremo, dove dobbiamo operare in un mondo di microservizi, trovo che per spedire cose di base ho bisogno di operare su più basi di codice scritte in linguaggi diversi, ognuno con le proprie stranezze di implementazione e modelli di architettura, con l'intero paradigma che si trasforma in spaghetti lambda . Fermarsi e concentrarsi nuovamente su ciò che è importante ha un grande impatto sulla riduzione dell'entropia. A un livello basso, orientato all'azione, può manifestarsi come segue:

• Eliminazione di codice morto che non viene eseguito in produzione. Ho interagito con così tante basi di codice in cui> il 50% del codice era codice morto e ha creato un carico cognitivo per i colleghi. Vorrei che ci fosse qualcosa nello spazio di produttività degli sviluppatori che generasse una copertura del codice basata su linee eseguite in produzione. Ogni trimestre ti fermi e rivedi quei report ed elimini semplicemente i file che non hanno avuto esecuzione.
• Come product manager, non riflettiamo abbastanza su quali funzionalità dovremmo eliminare o ripristinare. Tuttavia, fermarsi e riflettere su ciò che dovrebbe essere eliminato può essere molto significativo per semplificare e migliorare l'esperienza dell'utente. Mi considero un esperto di tecnologia, tuttavia trovo che molti dei prodotti creati oggi siano stati iper-ottimizzati su un insieme di utenti esistenti, portando a un'esperienza UX disordinata e confusa per i nuovi utenti. Chiedere alla fine del trimestre "Quale caratteristica possiamo annullare?" può essere utile per ridurre il disordine.

L'ego è il nemico

Ryan Holiday suggerisce nel suo libro Ego is the Enemy, c'è una forte "tentazione che esiste per tutti - per parlare e clamore per sostituire l'azione". L'ego è una grande ragione per cui il progresso e l'innovazione possono essere poco brillanti in molte istituzioni. Ecco come si manifesta l'ego:

• Vedere le stesse persone che non vedono l'ora di inserire i loro pensieri in una conversazione di gruppo, anche se le loro idee aggiungono un valore marginale nullo o minimo.
• Avere persone che non si impegnano mai a sponsorizzare attivamente i propri colleghi o che cercano di accumulare visibilità. Se sei un manager o un manager di manager, puoi notarlo osservando la frequenza con cui il tuo subordinato parla dei successi o dei contributi di altre persone nei tuoi rapporti 1:1. La mancanza di riconoscimento o la sponsorizzazione disinteressata di altre persone può essere un segno di un ego malsano.
• Ottimizzazione per il team anziché per l'intera azienda o organizzazione. Ho preso in prestito il diagramma da Staff Engineer's Path di Tanya Reilly ed esemplifica perfettamente questo problema in cui i team ottimizzano per il massimo locale. Ad esempio, saresti d'accordo con lo scioglimento del tuo team e la ridistribuzione dei dipendenti ad altri team se all'interno del tuo dominio stai entrando in modalità manutenzione? La maggior parte dei manager non lo farebbe mai perché significherebbe perdere qualsiasi capitale sociale e politico all'interno dell'azienda.

• A seconda del tuo ruolo, c'è una forte dicotomia in termini di come consideri il valore delle riunioni. “ Le persone più potenti sono nel programma del manager ”. Sfortunatamente, la loro percezione del valore degli incontri crea un override culturale che colpisce le persone che preferiscono avere tempo ininterrotto per pensare a un problema e alla soluzione. Anche ai fini del brainstorming, le prove suggeriscono che il brainstorming di gruppo è una perdita di tempo . Ma perché così tante organizzazioni gonfie finiscono per dedicare metà del tempo degli IC alle riunioni?

Conclusione

Il motore dell'innovazione si basa sul cambiamento evolutivo. Alla fine, se un'istituzione si irrigidisce e non si adatta al cambiamento, morirà di morte lenta. Nella mia esperienza, l'introduzione di un processo ha spesso costi imprevisti che portano a una velocità ridotta. Invece, mi concentrerei su quanto segue:

• Favorire l'iterazione e imparare dagli errori invece di cercare di raggiungere il perfezionismo.
• Le persone colla sono necessarie, ma ci deve essere un limite al loro numero, in modo che possano agire con una leva elevata. La semplice assunzione di persone tecnicamente competenti e con una buona intuizione aziendale può risolvere la necessità di assumere in eccesso per ruoli di collante.
• Infine mi concentrerei sulla riduzione dell'entropia chiedendo costantemente cosa può essere scartato e premiando le persone per comportamenti che aumentano la semplicità.