3 Bugie Che il Tuo Team Tecnologico Ti Racconta (e Si Racconta da Solo)

Ognuna di queste è una bugia che il tuo team tecnico racconta a te—e a se stesso. Questi malintesi molto comuni derivano da un errore fondamentale endemico tra gli ingegneri: la convinzione nel “meglio”.

Meglio Non È Meglio (per Tutti)

All’interno di un computer, è la terra degli uno e zero. Non ci sono dubbi o incertezze sull'aritmetica e sulle porte logiche, e a parte qualche raro raggio cosmico, la macchina è completamente deterministica, seguendo sempre lo stesso percorso ogni volta che fornisci gli stessi input. 

Anche l’apparente casualità nei giochi o nelle simulazioni è in realtà un’illusione. Se fornisci uno specifico “seme pseudocasuale” a, per esempio, Minecraft, otterrai esattamente lo stesso comportamento ad ogni partita. È utile ricordare che ogni membro del tuo team IT ha scelto una professione che coinvolge questo livello di certezza e prevedibilità; è letteralmente impossibile svolgere il loro lavoro senza ragionare rigorosamente dai primi principi.

Ma fuori dal regno computazionale, incontriamo esseri umani imprevedibili, e tutte le certezze svaniscono. Nessun team vendite prenderebbe mai in considerazione l’idea di applicare la stessa presentazione o proposta a ogni potenziale cliente, e ogni chiamata di assistenza è diversa e sorprendente. Script e formazione aiutano il personale a raggiungere coerenza, certo, ma è fondamentale variare l’approccio per adattarsi a ogni situazione, come hanno scoperto molte organizzazioni quando hanno provato ad adottare olocrazia o metodi lean per imitare il successo di Zappos e Toyota e sono miseramente fallite.

Questo vale tanto nel creare software quanto nell’operatività, nella finanza o nella strategia: non esiste un unico modo giusto per progettare una schermata di login, creare un report o scoprire quali funzionalità i clienti sono disposti a pagare. Ecco perché gli ingegneri hanno escogitato una gamma vertiginosa di metodologie software, come Scrum, Kanban, ShapeUp, il modello Spotify, SAfE e centinaia di altri, tutti di successo in alcuni casi e disastrosi in altri.

Ora puoi capire perché noi tecnici siamo vittime della trappola del "migliorismo". Ognuno di noi troverebbe attraente credere che da qualche parte esista una tavola di pietra con la risposta ai nostri problemi scolpita sopra, ma la certezza è pericolosamente seducente quando ogni giorno lavori con strumenti e macchine il cui stesso funzionamento dipende dalla coerenza assoluta. Ma come si spezza l’abitudine del pensiero binario?

Prima di Tutto, Domanda Senza Sosta

Per molti di noi, la tecnologia è pura magia nera. Gli ingegneri borbottano strane formule su Kubernetes e zettabyte e dal nulla appaiono siti web, email e pagamenti con carta di credito. Così, quando gli “stregoni” ci assicurano di seguire le "best practice", chi siamo noi per metterli in dubbio?

La risposta sei TU! Proprio come qualunque altro membro del team, anche gli sviluppatori hanno bisogno di feedback su quanto i loro piani e risultati siano in linea con la strategia aziendale. Non serve parlare geek per dare le tue impressioni e indicazioni; tocca a loro imparare abbastanza del tuo mercato e dei tuoi obiettivi per essere realmente responsabili nei tuoi confronti usando un linguaggio comprensibile. Non aver paura di fare tutte le domande su ciò che stanno dando priorità, i motivi delle loro scelte tecniche, e soprattutto su come si aspettano che il resto dell’azienda tragga benefici. 

Credo così tanto nell’importanza delle domande, che ho fatto stampare certificati in foglia d’oro molto eleganti che conferiscono il permesso ufficiale di interrogare gli ingegneri su qualsiasi argomento, e li distribuisco ogni volta che posso. Sotto trovi un esempio. Se vuoi averne uno da appendere in ufficio, scrivimi e te ne manderò uno gratis! 

Poi, Gioca al Gioco del Perché

Una volta superata la paura di fare domande e compreso meglio l’approccio del tuo team tecnico, è ora di giocare al gioco del “perché”. Le regole sono semplici e familiari a ogni bambino di cinque anni: prima chiedi cosa fa lo sviluppatore, poi chiedi "perché" ripetutamente. 

“Sto sostituendo la nostra pagina di pagamento.”

“Perché?”

"Perché è inefficiente.”

“Perché è inefficiente?”

“Facciamo controlli superflui che rallentano i tempi di risposta.”

“Perché la velocità è importante?”

"Perché gli utenti rinunciano se devono aspettare troppo per pagare.”

Il segnale per fermarsi arriva quando si parla di denaro. Una volta che senti dire: “perché aumenterà le conversioni”, “perché più clienti faranno l’upgrade” o “perché ridurremo i costi di ricerca”, hai vinto. Se non ci arrivi mai, finendo con “non lo so” oppure “perché Jane l’ha detto,” hai perso tu (non l’ingegnere) il gioco del 'perché'. Cerca di trovare il modo di collegare molto più da vicino il tuo team tecnico ai risultati di business così che la prossima volta siano tutti vincitori.

Dopo qualche giro di "Perché", inizierai a vedere schemi ricorrenti e lacune. Per esempio, ho lavorato con un team che era focalizzato come un laser sull’aumento del tasso di conversione ma ignorava completamente i costi. Non sorprende quindi che siano andati ben oltre il budget utilizzando strategie pubblicitarie social iper-ottimizzate che erano troppo complesse per una semplice campagna di Natale.

Sì, i loro algoritmi intricati erano “migliori” nell’ottenere un piccolo vantaggio di prezzo su certe parole chiave, ma la fattura di Facebook è stata una brusca sveglia quando è arrivata (inclusi addebiti per aver effettivamente mandato in crash alcuni server pubblicitari di facebook.com con troppe richieste!). Quando noti punti ciechi di questo tipo, correggi le priorità, cancella ciò che è inutile e ribadisci che la tecnologia deve essere strettamente allineata agli obiettivi di business.

Infine, Assicurati della Responsabilità

Ora che hai individuato e rimosso le soluzioni tecniche “migliori” che in realtà non funzionano per te, fornisci modi semplici agli ingegneri per dimostrarti che restano allineati e sulla strada giusta. Nota che non ho menzionato il "responsabilizzare il team tecnico", un approccio accusatorio che mi fa sempre venir voglia di nascondermi sotto la scrivania più vicina. Invece, consenti ai tuoi sviluppatori di essere responsabili nei tuoi confronti. Per esempio,

• Pianifica una dimostrazione settimanale dei miglioramenti IT, con i team leader che descrivono i benefici per il business e raccolgono feedback da te e dagli altri.
• Prepara una dashboard che mostri metriche importanti come uptime di sistema o chiamate risposte, e chiedi agli sviluppatori di spiegare spesso come le loro azioni migliorano questi risultati.
• Crea un percorso guidato per monitorare l’avanzamento dei progetti chiave e per recuperare velocemente quando elementi fondamentali subiscono ritardi.

Una strategia chiara per feedback frequenti e attenzione ai veri benefici concreti garantirà che le tue spese IT non vengano buttate in progetti “migliori” ma inutili. E se tu, come la maggior parte delle aziende con cui lavoro, stai spendendo milioni per la tecnologia ottenendo al massimo risultati incerti, non vale forse la pena misurare il ritorno su questo enorme investimento?

Iscriviti alla newsletter di The CTO Club per altri consigli dalla nostra community.