Calcinaia, provincia di Pisa, novembre 2024. La sede di Romiltec è una scrivania, un router, un NAS. Le persone del team sono distribuite tra Toscana e Sicilia, due fusi orari uguali ma cinque routine diverse. Quando un cliente editoriale ci scrive un lunedì alle 7:30 perché un cron è morto, la prima risposta arriva da un sysadmin che non è in ufficio, perché ufficio nel senso classico non ce l’abbiamo. Eppure 45M di visite al mese girano sopra il nostro stack, e per mesi non abbiamo mai avuto due persone nella stessa stanza. Vedi anche gli altri post di questa rubrica: Workshop.
Cosa funziona, in ordine di importanza
Async-first communication. La regola implicita: scrivi prima, parla solo se non basta. Un thread ben scritto su Mattermost vale più di una call da venti minuti, perché lo rileggi a freddo, lo cita un collega due settimane dopo, lo cerchi quando ti serve il contesto di una decisione. È la stessa filosofia che 37signals codifica nel loro handbook sul lavoro distribuito. Le call esistono, ma come eccezione: ogni call sostituibile da un messaggio scritto bene è una call non programmata.
Document writing serio. Le decisioni tecniche significative finiscono come ADR (Architectural Decision Record) o note di design, non come sintesi orale di una call. Costo iniziale alto (scrivere costa più che parlare), beneficio che si capitalizza nel tempo: dopo sei mesi nessuno si ricorda perché avevamo scelto MariaDB invece di PostgreSQL su un certo prodotto, ma la pagina con la decisione è ancora lì. Stesso vale per le indagini post-incidente: la timeline scritta vale più dello sfogo a voce.
Una sync video alla settimana, breve. Mezz’ora, con agenda condivisa scritta prima. Non è check-in di micro-management, è il punto in cui si vedono i blocker che non sono emersi sui canali async, si calibrano le priorità della settimana e ci si guarda in faccia.
Ownership chiara per area. Frontend a chi prende le UX decisions, backend e DB a chi mantiene gli schemi, infrastruttura a chi accede alle macchine. Niente “tutti su tutto”. L’ownership chiara è la condizione che rende l’async sostenibile: se per ogni decisione servono tre teste in call, l’async muore.
Niente micro-management, niente timesheet. I task vivono in board condivise, lo stato lo aggiorna chi ci lavora, le retrospettive guardano cosa è stato consegnato, non quante ore ha staccato chi. Il numero di ore di uno sviluppatore senior non è un proxy onesto del valore prodotto.
Cosa non funziona, e perché
Pair programming complesso, in async. Due dev che devono ragionare insieme su un’astrazione delicata o su un bug subdolo non lo fanno bene su Mattermost. Lo stato condiviso (ipotesi, esperimenti falliti, half-formed thoughts) ha bisogno di una call con screen share. Async va bene per scrivere insieme una API, non per debuggare una race condition.
Onboarding di nuove persone. Le prime due settimane di un developer nuovo sono difficili da fare interamente da remoto. Non per la parte tecnica (quella si recupera con setup script e documentazione), ma per il contesto culturale: cosa è un “buon PR” da noi, come si scrivono i commit, come si parla con un cliente quando un cron muore. Quel contesto si trasferisce meglio di persona, almeno una settimana sul posto al primo mese.
Incidenti critici. Quando un servizio è down e un cliente Enterprise ha 2h di SLA, l’async perde. Ci vuole una call aperta, un incident commander, screen share, log che scorrono in un canale dedicato. Lo abbiamo formalizzato dopo un incident in cui la prima ora si era persa in messaggi paralleli sulla stessa root cause. Oggi la regola è semplice: se è P1, si parte in call e si scrive solo dopo.
Brainstorming generativo. L’idea nuova nasce meglio in una stanza con una lavagna che in un thread Slack. Per i pezzi di product che richiedono divergere prima di convergere, una giornata di persona vale più di tre call distribuite.
La sede di Calcinaia, una software house digitale
Calcinaia ha un significato preciso per il team: non è “l’ufficio dove si va”, è “il punto fisico che esiste se ti serve”. È la sede legale, è il backup di scrivania quando uno dei dev vuole staccare dal contesto domestico, è il riferimento culturale che ci radica nel territorio pisano. Non siamo una software house “remota da nessuna parte”: siamo una software house italiana che usa lo smart working come modo di lavorare. La presenza fisica ha un costo (pendolarismo, ore di vita) e va spesa solo dove serve davvero.
Cinque persone è il limite naturale
A cinque persone lo smart working tiene da solo. Le decisioni le prende chi ha l’ownership, le call sono brevi e mirate, le chat funzionano. Sopra le cinque, la complessità di coordinamento cresce in modo non lineare (ogni nuova persona aggiunge N nuovi canali bilaterali), e quello che a cinque era implicito inizia a chiedere di essere esplicito. A sette o otto servono altri pezzi: un weekly engineering all-hands con minute, un tech lead che assorba la coordinazione, una documentazione di processo. Per ora siamo a cinque, e a cinque funziona.
Cosa mi sono portato a casa
Tre cose, in ordine pratico.
Prima. Lo smart working serio non è “lavorare da casa”. È un modo di organizzare la comunicazione, le decisioni e l’ownership in modo che la stanza fisica non sia una dipendenza. Se quando il team è remoto le cose si rompono, non è colpa dello smart working: è che il processo era sostenuto dall’aula riunioni e dalle conversazioni informali, e nessuno se n’era accorto.
Seconda. L’async non vale per tutto. Pair programming difficile, onboarding nuovi, incidenti critici, brainstorming divergente: questi vivono meglio in sincronia. Riconoscere quando rompere la regola è parte della regola.
Terza. Cinque persone è una soglia tecnica, non una preferenza. Sotto, il coordinamento è cheap. Sopra, devi spendere energia in processo. Per noi, oggi, restare a cinque significa restare nella zona in cui ogni euro di fatturato torna in tecnologia, non in coordinamento. È una scelta consapevole, non un accidente.
Calcinaia, novembre 2024. Sul desk c’è un router e una scrivania. Sul cluster ci sono 45M visite al mese. Tra le due cose, un team di cinque persone che non si è mai sentito un “team distribuito”, perché distribuito non è uno stato d’animo, è solo la geografia delle scrivanie. Per il resto, si lavora come si è sempre lavorato, una pull request alla volta.