Nelle aziende che ho visto da vicino, la velocità di esecuzione è una delle parole più amate. Si parla di team agili, di sprint, di delivery. Si premia chi consegna in fretta. Si valutano i manager su quanto riescono a far succedere in un trimestre. La velocità è diventata, in molti contesti, il segnale principale di competenza.

C’è qualcosa di vero in questo. Esecuzione lenta è quasi sempre un sintomo di problemi. Ma c’è anche una trappola che si fa fatica a riconoscere quando ci si è dentro. La velocità di esecuzione, da sola, non garantisce che si stia andando nella direzione giusta. Garantisce solo che ci si arriva prima, qualunque essa sia.

Quando le decisioni a monte sono chiare, la velocità diventa un moltiplicatore. Un team che sa esattamente cosa sta costruendo e perché può consegnare in fretta e accumulare risultati. Quando le decisioni a monte non sono chiare, la velocità fa il lavoro contrario. Moltiplica gli errori, gli attriti, i lavori da rifare. Si va lontano, ma in mezzo a un terreno che non è quello che si voleva attraversare.

Lo si vede bene in un’azienda che ho seguito per qualche mese. Avevano un team prodotto considerato di prim’ordine. Velocità di rilascio settimanale. Nuove funzionalità ogni quindici giorni. I numeri di delivery erano sopra la media del settore. Le riunioni operative giravano bene. Visto da fuori, era un caso di scuola.

Visto da dentro, il problema era un altro. Le funzionalità che venivano rilasciate cambiavano direzione ogni due o tre mesi. Una funzionalità A nasceva per servire un certo segmento di clienti. Tre mesi dopo veniva ripensata per un segmento diverso. Sei mesi dopo veniva quasi smantellata perché si era scoperto che il segmento iniziale era quello giusto, ma l’avevano riscritta nel frattempo. La velocità di rilascio era reale. La velocità di apprendimento, in pratica, era nulla. Si correva avanti e indietro sullo stesso terreno.

Quando abbiamo guardato il problema da vicino, la diagnosi è venuta da sola. Le decisioni di prodotto strategiche, quelle che dovevano dichiarare per chi facciamo questa cosa, e perché, non venivano prese. Si rimandavano al prossimo trimestre, alla prossima ricerca utenti, al prossimo round di feedback. Nel frattempo il team continuava a eseguire, perché nessuno voleva fermare la macchina. La velocità era diventata una scusa per non decidere.

Questo è il punto sottile. Quando le persone si abituano a misurarsi sulla velocità di esecuzione, decidere diventa un’attività che rallenta. Si evita. Si rimanda. Si delega a iterazioni successive, sperando che la decisione emerga dai dati. Ma i dati non decidono al posto nostro. Mostrano cosa è successo, non cosa dovrebbe succedere. Per quello serve una scelta, e una scelta richiede un momento in cui ci si ferma.

Fermarsi, in un’azienda fissata sulla velocità, sembra perdere terreno. Sembra ammettere di essere bloccati. È esattamente il contrario. È l’unico modo per evitare di accumulare velocità nella direzione sbagliata.

Ho un test mentale che propongo ai team che si trovano in questa condizione. Guardare cosa hanno consegnato negli ultimi sei mesi e chiedersi: di tutto questo, quanto è ancora vivo, usato, parte stabile del sistema? Quanto invece è stato modificato, sostituito, smantellato, accantonato? Se il rapporto tra le due cose è sbilanciato verso la seconda, la velocità non sta producendo valore. Sta producendo lavoro.

C’è un effetto secondario di questo accumulo. Le persone che lavorano in team a velocità senza direzione si stancano in un modo specifico. Non è la stanchezza fisica del troppo lavoro. È la stanchezza cognitiva di vedere il proprio lavoro venire modificato di continuo senza che nessuno spieghi davvero perché. Dopo un anno di questo regime, i talenti migliori cominciano a guardarsi intorno. Se ne vanno non perché lavorino troppo, ma perché vedono che il loro lavoro non si accumula in nulla di solido.

La velocità è un’amplificatrice. Non è una direzione. Quando le decisioni sono prese, l’amplificatrice serve. Quando le decisioni non sono prese, l’amplificatrice fa solo più danni in meno tempo.

La domanda da farsi non è come acceleriamo l’esecuzione. È abbiamo deciso cosa stiamo eseguendo, prima di accelerare?