Quella che segue è la mia lettura del mestiere, con riferimento ai saggi che ho scritto. Non è un manuale: è il punto di vista di chi da quindici anni fa software in ruoli ibridi — architetto, advisor, manager — e prova a capire cosa cambia davvero e cosa resta.
Ultima revisione: 7 maggio 2026.
Tesi in una frase
Il software è un mestiere nel senso preindustriale del termine: apprendistato, gusto, e limiti. La maggior parte delle “best practice” sono scelte di default fatte per le ragioni sbagliate, conservate perché nessuno ha mai misurato il costo di averle adottate.
Come la vedo
- Un’architettura è un insieme di decisioni ereditabili. Se dopo due anni nessuno sa perché una scelta è stata fatta, quella scelta non è un’architettura: è un incidente fossilizzato.
- La leadership tecnica è un problema di autorità, non di gerarchia. Ti seguono perché hanno visto che hai ragione abbastanza volte. Il resto è un costume.
- L’Europa non deve copiare la Silicon Valley. Non ne ha i presupposti — né il capitale, né l’ecosistema, né il fallimento socialmente accettato. Il nostro vantaggio è il tempo lungo: progetti che durano, squadre stabili, clienti fedeli. Invece di imitare il modello veloce, vale la pena capitalizzarlo.
Saggi su questo tema
Lavoriamo insieme
Il mio ingaggio su architetture e leadership tecnica è quasi sempre uno di questi tre: una decisione da prendere bene adesso, un’architettura in difficoltà da raddrizzare, una persona tecnica da far crescere.
Per chi è utile
CTO e Head of Engineering che devono presentare a un board una scelta architetturale significativa e vogliono una seconda testa prima
Fondatori tecnici che si accorgono che l’architettura che li ha portati qui non li porterà al prossimo ordine di grandezza
Team di piattaforma che ereditano un sistema complesso e devono decidere cosa tenere, cosa riscrivere, cosa buttare
Leader tecnici in crescita che vogliono un mentor esterno con cui parlare delle decisioni più scomode
Come lavoro
- Architecture review (2–4 settimane)
Prendo un’architettura esistente o in progetto, parlo con chi la mantiene, leggo i design doc e gli ADR, e restituisco un giudizio documentato: cosa tenere, cosa cambiare, cosa misurare prima di cambiarlo.
- Disegno di una nuova piattaforma (4–8 settimane)
Da zero o da una situazione che non regge più. Lavoro con il team interno per produrre un insieme di ADR, uno stack argomentato e una roadmap con milestone misurabili.
- Mentoring per leadership tecnica (ingaggio continuativo)
Un paio di call al mese con un CTO, un tech lead o un architect in crescita. Spazio protetto per parlare di decisioni difficili senza politica interna.
Domande operative
- Ti occupi di coding o code review?
No. Non è il mio valore aggiunto. L’advisory è sulle decisioni di perimetro, non sull’implementazione.
- Lavori con qualunque stack?
Lavoro con le decisioni di stack, non dentro un singolo stack. Il mio valore è indipendente dal linguaggio — è capire quali trade-off contano davvero a due anni.
- Quanto dura un ingaggio tipico?
Due–quattro settimane per una review, uno–due mesi per un disegno, continuativo per il mentoring.
- Come si fattura?
A output documentabile, non a giornate. Il prezzo è fisso e legato a consegnabili concordati all’inizio.
Scrivimi a hello@margiovanni.it con due righe di contesto. Rispondo entro qualche giorno lavorativo con una proposta concreta o un cortese no se non è il mio perimetro.
Domande e risposte
Perché 'mestiere' invece di 'ingegneria'?
Perché l’ingegneria presuppone un sapere codificato e ripetibile. Nel software reale — quello che entra in produzione, sopravvive a tre CTO e finisce in dieci capitolati diversi — il sapere è largamente tacito, si trasmette per apprendistato, e cambia con il contesto. Mestiere descrive meglio la realtà.
Che differenza fa?
Cambia tutto su chi assumi, come lo fai crescere, come documenti, come decidi. Chi ragiona da ingegnere cerca processi. Chi ragiona da artigiano cerca maestri, pazienza e un patrimonio di scelte passate da cui partire.