Febbraio 2025. Decido un esperimento concreto: per quattro settimane di calendario, non apro l’IDE. Niente PR, niente commit, niente pair su un bug. Tutto quello che è codice, lo delegano i dev del team. Io passo il mese su quello che fatico di più a tenere fermo: product strategy, sales pipeline, hiring, conti. È il primo esperimento di questo tipo che mi impongo da founder-tecnico, e non lo faccio per ascesi, lo faccio perché il context switching tra codice e gestione mi sta costando in qualità su entrambi i lati. Vedi anche gli altri post di questa rubrica: Workshop.
Le regole, piccole e ferree
Le regole sono semplici, e le ho scritte sulla prima pagina del taccuino:
- Niente IDE. Code review sì, ma da web (GitHub UI), non da editor locale.
- Niente PR a mio nome. Niente piccoli fix da dieci minuti, neanche un typo nel README.
- Niente debugging in shell di produzione, nemmeno per “guardare un log”.
- Sì alle decisioni tecniche scritte. ADR, design doc, schemi di architettura. Quello non è “scrivere codice”.
- Sì alle call di product e sales, anche con il cliente. Quello è il punto.
La regola sottile e importante: niente “ah ma è un attimo, lo faccio io”. Quel reflex di founder-tecnico è esattamente il bias che volevo capire.
Settimana uno: l’astinenza
I primi giorni sono i peggiori. Non per noia, per fastidio. Vedo PR aperte di un dev che potrei chiudere in mezz’ora se entrassi a sistemare due cose, e mi tocca scrivere un commento di review e aspettare che il dev abbia tempo di rilavorarci. Costo immediato: quattro ore di latenza in più sulla PR.
Il fastidio si trasforma in osservazione utile dopo tre giorni. Mi accorgo che la velocità di chiusura delle PR non era merito di un sistema efficiente, era merito mio che entravo a fare i fix. Senza la mia disponibilità a entrare, il sistema reale si è rivelato: review più lente, onboarding tecnico non documentato bene, aspettative sui tempi di review non esplicite.
Lo scrivo sul taccuino: non era un sistema efficiente, era un founder che compensava un sistema inefficiente. Bug del processo, non feature.
Settimana due: il context switching che non vedevo
La cosa che meno mi aspettavo è quanto migliorino le decisioni di product senza il fardello del codice corrente in testa.
Quando sei dentro a un refactor, la mappa mentale del prodotto è distorta dalla mappa mentale del codice di quel refactor. Pensi in termini di “cosa è facile da implementare nei prossimi tre giorni” anziché in termini di “cosa serve al cliente nei prossimi tre mesi”. Cal Newport l’ha descritto come la differenza tra deep work e shallow work: le decisioni di product profonde non sopravvivono al rumore del codice corrente.
In settimana due ho preso una decisione architetturale importante su un nuovo modulo: tenant-aware sì o no, single-database o database-per-tenant, esposizione via REST o via job asincrono. Da dentro al codice l’avrei probabilmente decisa in funzione del minor effort per il dev che lavorava in quell’area. Da fuori, con la testa al cliente e ai prossimi sei mesi, l’ho decisa in funzione di dove il prodotto deve andare. È uscita peggio per il piano corrente (più lavoro adesso) e meglio per i sei mesi successivi (zero refactor strutturale dopo).
Lo scrivo sul taccuino: alcune decisioni tecniche le prendi meglio quando non sei in mezzo. Non tutte, alcune.
Settimana tre: l’altra metà della medaglia
Tre settimane in, comincio a sentire un effetto opposto: alcune decisioni tecniche le prendo peggio da fuori. Specificamente, le decisioni di basso livello che richiedono di sentire come reagisce un database, come si profila una query. Quelle non le delego bene neanche al dev più senior, perché la sensibilità è mia, costruita su anni di codice in produzione.
Esempio concreto: performance issue su una query di rollup mensile. Il dev mi descrive il piano di esecuzione, il numero di righe, l’indice usato. Io leggo, suggerisco un’ipotesi di refactoring. Il dev prova, l’ipotesi è sbagliata. Se fossi entrato in shell, in dieci minuti avrei capito che il problema vero era a monte (un join che esplodeva su una tabella secondaria). In modalità “no codice” ci sono volute due iterazioni asincrone in due giornate.
Conclusione sfumata: il founder-tecnico è bravo in cose specifiche (debugging profondo, performance issues su sistemi suoi) ed è meno bravo in altre (delegare a freddo, vedere il prodotto da fuori, gestire il sales pipeline). Il digiuno totale come pratica continua sarebbe un errore tanto quanto il “tutto codice”.
Settimana quattro: cosa torno a fare e cosa no
Nell’ultima settimana è uscita da sola la regola operativa che da allora applico:
Quello che torno a fare in prima persona. Architecture review serie sui sistemi che conosco a fondo. Performance issues critiche dove la mia sensibilità è un asset reale. Onboarding tecnico di un nuovo dev. Code review con commenti tecnici approfonditi.
Quello che lascio ai dev del team. Feature implementation completa (mai più “ah faccio io questa parte”). Bug non critici. Setup di nuovi progetti dopo il primo.
La vera scoperta. Schedule di “no-code days” come pratica continua, non come digiuno totale. Due giorni alla settimana (martedì e venerdì) per default no-code, dedicati a product, sales, hiring, conti. Gli altri tre sono giorni in cui posso entrare nel codice, ma solo nelle aree dove la mia presenza aggiunge valore reale.
Per un team di cinque persone, in Romiltec oggi, è la calibrazione che funziona.
Cosa mi sono portato a casa dal mese senza codice
Tre cose, in ordine di durata.
Prima. Il context switching tra codice e gestione non è gratis, anche se ti senti veloce su entrambi. Per quattro settimane senza switch ho preso decisioni di product migliori, e questo non è merito del talento, è merito del non avere la mappa mentale del codice corrente in testa nello stesso momento. La decisione architetturale di settimana due da sola valeva il mese.
Seconda. Quando un founder-tecnico è “sempre disponibile” per chiudere fix veloci, sta nascondendo bug del processo. Non è un sistema efficiente, è un founder che compensa un sistema inefficiente. Toglierti dalla disponibilità è il modo più rapido per vedere dove il sistema reale è lento.
Terza. Il digiuno totale è un test diagnostico, non una pratica continua. Tornare al codice, dopo un mese, è ossigeno mentale: lo sentivo nelle dita, non solo nella testa. Ma tornare selettivo (solo dove aggiungo valore tecnico reale, non solo dove sono il default più veloce) è la pratica che ha senso da marzo in avanti.
Febbraio 2025, mese senza codice, conclusione operativa: due giornate la settimana di no-code per default, e mai più “ah ma è un attimo, lo faccio io” su task che il sistema dovrebbe sapere chiudere senza il founder. Da fuori, il prodotto si vede meglio. Da dentro, alcune cose si fanno meglio. La distinzione non è “sempre dentro” o “sempre fuori”: è capire, per ogni decisione, da quale dei due punti di vista la stai prendendo.