Call alle 10:30. Messaggio Slack alle 11:15. "Scusa, una domanda veloce" alle 11:45. Call di allineamento alle 14:00. Messaggio del cliente alle 15:20. Un'altra domanda alle 16:00. Il costo delle interruzioni per gli sviluppatori è enorme, ma quasi mai misurato.
Il tuo sviluppatore ha avuto 8 ore di giornata lavorativa. Di quelle 8 ore, quante sono state davvero di lavoro concentrato e continuo?
Questo non è un articolo sulla produttività personale. È un articolo sul costo economico delle interruzioni — un costo che non appare in nessun budget ma che spesso incide più di un’assunzione.
La ricerca: 23 minuti non sono un’opinione
Gloria Mark, ricercatrice all’Università della California Irvine, ha studiato per anni l’impatto delle interruzioni sul lavoro cognitivo complesso. Il risultato medio osservato: dopo un’interruzione servono circa 23 minuti per tornare al livello di concentrazione precedente.
Non perché serva tempo a “ripartire”, ma perché lo sviluppo software richiede di mantenere un modello mentale complesso: struttura del sistema, flusso del codice, dipendenze, stato del problema. Una notifica può interrompere questo equilibrio. Ricostruirlo richiede tempo.
Il conto economico che raramente si fa
Una “domanda veloce” di 3 minuti non costa 3 minuti. Costa circa 26 minuti: 3 di interruzione + 23 di recupero.
Una call di 30 minuti non costa 30 minuti. Ne costa più di 50.
Con 5 interruzioni al giorno — un numero realistico in molti team — il costo supera facilmente le 2 ore.
In una settimana sono circa 10 ore. In un mese, circa 40 ore: l’equivalente di una settimana di lavoro. In un team di 4 persone, è come perdere uno sviluppatore a tempo pieno, ogni mese, senza accorgersene. E aggiungere persone non risolve il problema se il modo di lavorare resta lo stesso.
Perché le interruzioni a metà mattina sono le peggiori
Molti sviluppatori iniziano a essere davvero produttivi solo dopo i primi 30–45 minuti della giornata, quando hanno ricostruito il contesto del lavoro lasciato il giorno prima.
Interrompere questo momento con una call o una richiesta urgente spezza proprio la fase di massima produttività. Non si perde solo il tempo della riunione, ma l’intera finestra di lavoro che la precedeva e quella che serve per rientrare nel flusso.
Tre regole operative che cambiano tutto
1. Finestre di comunicazione
Raggruppa call e riunioni in slot precisi: inizio giornata, fine mattina, inizio pomeriggio o fine giornata. Evita il centro dei blocchi di lavoro.
Se devi interrompere il flusso, fallo quando il flusso non è ancora iniziato o sta per finire.
2. Blocchi di lavoro protetti
Almeno 2–3 ore consecutive senza interruzioni reali. Niente call, niente “domande veloci”, niente richieste sincrone.
La differenza tra 3 ore continue e 3 ore spezzettate non è marginale: spesso è la differenza tra completare una feature o appena iniziarla.
3. Comunicazione asincrona di default
La maggior parte delle richieste può aspettare qualche ora. Tratta come urgenti solo i veri blocchi operativi o gli incidenti reali.
Se puoi aspettare senza fermare il tuo lavoro, scrivi un messaggio e lascia che lo sviluppatore risponda quando esce dal flusso.
Segnali che il tuo team è troppo interrotto
- Il lavoro vero si fa la sera o nel weekend.
- Le stime sembrano sempre sforare.
- Tutti sono occupati tutto il giorno, ma le feature avanzano poco.
- Sviluppatori bravi mostrano segni di frustrazione o burnout — e trovarli è già abbastanza difficile.
Spesso il problema non è la capacità del team, ma il tempo effettivo di concentrazione che ha a disposizione.
Per il CEO: proteggi il deep work come proteggi il budget
Il tempo di concentrazione del team tecnico è una risorsa limitata e preziosa. Ogni riunione evitabile, ogni richiesta non urgente, ogni notifica superflua erode quella risorsa.
Le aziende che consegnano più velocemente non hanno necessariamente team più grandi o più talentuosi. Hanno team che riescono a lavorare in modo concentrato per più ore al giorno.
La differenza tra 2 ore di lavoro profondo e 5 ore di lavoro profondo al giorno cambia radicalmente la velocità di avanzamento di un progetto.
Simone Giusti
Consulente software strategico
