> ## Content Index
> Fetch the complete content index at: https://www.marcosantonocito.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Builders Organization
- URL: https://www.marcosantonocito.com/the-builders-organization/
- Published: 2026-09-03T06:00:30.000Z
- Updated: 2026-09-03T06:00:29.000Z
- Description: Come dovremmo organizzare un team di prodotto quando costruire non è più il principale collo di bottiglia?
- Author: Marco Santonocito
- Tags: AI Native Teams, Management, High Agency

#### In sintesi

Abbiamo da sempre organizzato i team di prodotto attorno a una premessa: costruire software è lento e costoso. Per questo abbiamo creato pipeline di specialisti: PM decide, Designer disegna, Engineer costruisce. L'AI sta abbattendo il costo di costruire, e se produrre è alla portata di tutti, la capacità di scegliere la direzione giusta diventa sempre più importante. Il collo di bottiglia non è più "can we build it?" ma "should we build it?".

Quindi, visto che i confini tra Product, Design ed Engineering diventeranno sempre più permeabili, vedo emergere tre archetipi:

- ****Builder:** persona ad alta agency che possiede un outcome intero, dalla scoperta del problema alla misura del risultato. Non riceve task, riceve problemi.
- ****Guardian:** lo specialista che codifica la sua expertise in regole eseguibili e condivise (design system, skill, MCP condivisi, permessi a livelli) usate da persone e agenti AI.
- ****Orchestrator:** il manager che smette di distribuire task e distribuisce contesto: vision, priorità, constraint, metriche.

****In sintesi:** Builders own outcomes. Guardians own standards. Orchestrators own context. Leaders own direction.

Per quindici anni ho lavorato dentro product organization assumendo ogni possibile forma: developer, designer, product manager, CTO, CPTO. E per quindici anni tutte queste organizzazioni, per quanto diverse, poggiavano sulla stessa premessa: **costruire software è difficile, lento e costoso**.

Da quella premessa discende quasi tutto il resto. Il Product Manager decide cosa costruire, il Designer definisce come dovrebbe funzionare, l'Engineer lo trasforma in software,... Il modello ha funzionato per decenni perché ogni passaggio richiedeva competenze specialistiche e, soprattutto, perché la produzione era il collo di bottiglia del sistema.

L'AI sta erodendo quella premessa. Non perché PM, Designer e Developer stiano diventando inutili, ma perché **sta crollando il costo di trasformare un'intenzione in qualcosa che funziona**: un prototipo che richiedeva settimane oggi si costruisce in ore; un designer può produrre codice; un PM può interrogare i dati, montare una demo e testare un'ipotesi senza aprire una roadmap. 

Lo vivo ogni giorno costruendo prodotti digitali seguendo in prima persona design, prodotto, crescita e distribuzione, con l'AI al fianco su quasi tutto. Lo vivo ogni giorno formando PM ed engineers all'interno di multinazionali. 

E questo apre una domanda organizzativa molto più interessante della solita domanda su quali professioni spariranno:

> **Come dovremmo organizzare un team quando costruire non è più il principale collo di bottiglia?**

La mia ipotesi è che i confini tra Product, Design ed Engineering diventeranno progressivamente più permeabili, e che al loro posto emergeranno tre archetipi:

1. **Builders**: individual contributor ad alta agency responsabilizzati su un outcome.
2. **Guardians**: specialisti che trasformano la propria expertise in sistemi, standard e guardrail utilizzabili da tutta l'organizzazione (umani e agenti AI inclusi).
3. **Orchestrators**: manager e leader che distribuiscono contesto, direzione e capacità decisionale invece di distribuire task.

Non è più solo un'ipotesi mia. Un working paper di Harvard Business School e INSEAD ([Kim & Koning, *AI-Native Firms*, 2026](https://www.hbs.edu/ris/Publication%20Files/26-090%5F96f92aa0-37d9-4789-beaa-5c0cb87a4032.pdf?ref=marcosantonocito.com)) ha misurato le startup AI-native confrontandole con quelle tradizionali: risultano circa il **25% più piccole a parità di condizioni**, ma **con il 13% di engineer in più**, **gerarchie più piatte e circa il 15% di manager in meno**. Sono primi dati, non conclusioni definitive; ma la firma statistica è esattamente questa: meno persone, più capability per testa, meno livelli.

Il risultato non è un'organizzazione senza specialisti. È un'organizzazione nella quale **la specializzazione cambia posizione**.

![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/ChatGPT-Image-27-ago-2026--18_06_32.png)

**I tre archetipi: chi possiede l'outcome, chi possiede gli standard, chi possiede il contesto.*

[Prima di continuare, iscriviti](#/portal/signup/free)

## Il collo di bottiglia si sta spostando

Ogni organizzazione è progettata attorno ai propri vincoli. Quando scrivere software costa molto, è razionale proteggere il tempo degli engineer con una lunga pipeline decisionale: qualcuno raccoglie i requisiti, qualcuno studia gli utenti, qualcuno definisce le priorità, qualcuno disegna l'interfaccia, qualcuno scrive una specifica abbastanza dettagliata da non sprecare sviluppo.

Ma cosa succede quando la produzione costa sempre meno? Il collo di bottiglia si sposta. La domanda non è più *"can we build it?"*; diventa *"should we build it?"* e, subito dopo, *"did we build the right thing?"*.

La capacità scarsa smette di essere quella di produrre software. Diventano scarse la comprensione del problema, il giudizio, il gusto, la capacità di distinguere un segnale dal rumore, la responsabilità sull'outcome. In una frase:

> **Quando execution è commodity, judgment è il vero vantaggio competitivo.**

Il report DORA di Google Cloud sullo sviluppo assistito da AI ([State of AI-assisted Software Development, 2025](https://dora.dev/dora-report-2025/?ref=marcosantonocito.com), quasi 5.000 professionisti) arriva alla stessa conclusione da un'altra strada: l'adozione AI tra gli sviluppatori è al 90%, ma l'AI si comporta da **amplificatore**. 

> **L'AI aumenta i punti di forza delle organizzazioni sane e le disfunzioni di quelle malate: il ritorno, di conseguenza, non viene dai tool ma dalla qualità delle piattaforme interne, dalla chiarezza dei workflow e dall'allineamento dei team.** 

Questo è il punto di partenza di tutto il framework.

## Da specialisti in pipeline a persone che possiedono outcome

Il team tradizionale divide il lavoro per disciplina; ownership e conoscenza vengono continuamente trasferite: il PM parla con l'utente e racconta il problema al Designer; il Designer crea una soluzione e la racconta all'Engineer; l'Engineer implementa; il PM torna alla fine a controllare. Ogni handoff introduce perdita di contesto, interpretazione, attesa, coordinamento, riunioni.

Quando produrre è costoso, questo overhead è accettabile. Quando produrre diventa velocissimo, il coordinamento rischia di costare più della produzione stessa.

L'alternativa è spostare l'ownership verso l'individuo: la stessa persona attraversa discover, define, prototype, build, ship, measure, learn. Non significa che lavori da sola; significa che **non delega continuamente la responsabilità del problema**.

Marty Cagan descrive questa distinzione da anni: i [feature team ricevono soluzioni e sono misurati sull'output, i product team ricevono problemi e sono misurati sull'outcome](https://www.svpg.com/product-vs-feature-teams/?ref=marcosantonocito.com). Il modello della **Builder Organization** porta quella logica fino in fondo, dall'unità team all'unità persona.

## Il Builder

![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/ChatGPT-Image-27-ago-2026--18_10_19.png)

Un Builder non è semplicemente un developer che usa Claude, e non è un PM che sa programmare. È prima di tutto una persona che possiede un outcome: riceve una direzione, un problema, un contesto, alcuni constraint e una definizione di successo, e ha sufficiente capacità orizzontale per decidere autonomamente come procedere.

Per me è una figura molto concreta, perché è quello che faccio ogni giorno: nella stessa settimana analizzo un funnel, parlo con gli utenti, interrogo il database, creo un prototipo, ne modifico l'interazione, pubblico l'esperimento e decido se continuare. L'AI mi aiuta a eseguire quasi tutto; le competenze servono a un'altra cosa, cioè a capire cosa sta facendo e dove non deve mettere le mani. Un Builder con buon gusto estetico e basi tecniche sa, per esempio, che l'AI non può toccare il database in un certo modo. È orizzontale sul prodotto, ma capace di andare deep dove serve.

Il profilo che ne esce non è la vecchia T-shape con una punta profonda e il resto a zero. È un profilo con uno spike specialistico forte e un **baseline orizzontale molto più alto**: un Engineering-heavy Builder resta molto più profondo tecnicamente, ma non può avere Product a zero; deve conoscere discovery, prioritizzazione, metriche, experimentation. Il punto non è rendere tutti uguali; è alzare drasticamente la baseline delle competenze adiacenti.

Che questa baseline si stia già alzando lo suggeriscono i dati firmati dal Politecnico di Milano: secondo l'[Osservatorio Artificial Intelligence](https://www.osservatori.net/comunicato/artificial-intelligence/intelligenza-artificiale-italia/?ref=marcosantonocito.com), il 41% dei lavoratori che usano l'AI svolge attività che non saprebbe fare altrimenti. È la misura più vicina che esista al concetto di baseline orizzontale. E l'[Anthropic Economic Index](https://www.anthropic.com/research/economic-index-june-2026-report?ref=marcosantonocito.com) osserva che sui pattern d'uso di Claude l'augmentation (52%) ha superato l'automation (45%): un indizio, non una prova, che l'AI stia amplificando le persone più che sostituirle.

La capacità fondamentale, però, non è tecnica: è l'**agency**. Passare da *"cosa devo fare?"* a *"qual è l'outcome che dobbiamo ottenere e cosa posso fare per avvicinarci?"*. Prima, una persona ad alta agency era comunque limitata dalle proprie competenze tecniche; oggi può delegare parte della produzione a un sistema AI. Una persona passiva con l'AI produce task più velocemente. Una persona ad alta agency con l'AI attraversa intere discipline.

> **AI amplifica l'agency più di quanto amplifichi la competenza tecnica.**

## I Guardian: un'autorità per ogni verticale

![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/ChatGPT-Image-27-ago-2026--18_11_48.png)

Il secondo archetipo è quello che rischia di più di essere frainteso, quindi chiarisco subito due cose. I Guardian sono **più di uno** ed esiste (o dovrebbe esistere) per ogni verticale critico dell'organizzazione: design, engineering, dati, AI, privacy, brand,... Ovunque ci sia un'expertise profonda le cui regole devono valere per tutti, lì serve un Guardian.

La definizione è questa: **il Guardian è l'autorità di un verticale che codifica la propria expertise in regole eseguibili**, utilizzabili tanto dalle persone quanto dagli agenti AI. Non partecipa a ogni progetto e non approva ogni singola decisione; costruisce il sistema che rende difficile fare male nel suo verticale.

Il bisogno di questa figura non l'ho dedotto dalla teoria: l'ho visto emergere da un problema pratico, e il design è semplicemente il verticale dove l'ho notato per primo. L'AI sul design è potentissima: genera template, layout, interi design system in tempi che due anni fa sembravano fantascienza. Ma dopo un po' te ne accorgi: **gli output cominciano ad assomigliarsi tutti**. Se dieci Builder generano interfacce in autonomia, senza nessuno che presidi l'identità, il brand si diluisce in una media statistica. Da qui il Design Guardian: possiede il design system, lo porta nel workspace condiviso dove lavorano persone e agenti, e rivede gli output dei Builder perché brand, gusto e user experience restino coerenti.

Lo stesso identico schema, però, si ripete su ogni altro verticale. In pratica, oggi, codificare l'expertise significa **skill condivise e MCP condivisi**, e ogni Guardian scrive quelli del proprio territorio:

- il **Design Guardian** definisce il design system, la skill che governa il micro-copy, la skill che struttura i flussi di onboarding;
- l'**Engineering Guardian** definisce stack, regole e limiti di sviluppo, quali MCP connettere e come usarli, e cosa l'AI non deve toccare (il database in un certo modo, per esempio);
- il **Privacy Guardian** definisce la skill che insegna all'AI a strutturare i dati in modo GDPR-compliant;
- il **Data Guardian** presidia definizioni delle metriche, qualità e semantica dei dati, perché due team non chiamino "activation" due cose diverse;
- l'**AI Guardian** presidia scelta dei modelli, eval, safety e observability degli agenti stessi;
- il **Brand Guardian** presidia voice, positioning e coerenza del messaggio.

E con le regole arrivano i permessi a livelli: dentro ogni verticale, un livello di autorità arriva a fare richieste su staging, un livello più alto arriva in production. L'expertise smette di vivere solo nella testa dello specialista o nelle code review; diventa infrastruttura.

Chi conosce [*Team Topologies*](https://teamtopologies.com/?ref=marcosantonocito.com) di Skelton e Pais riconoscerà qui l'idea di *platform as a product*: team di piattaforma che costruiscono strade asfaltate self-service per ridurre il carico cognitivo degli altri team. È lo stesso approccio che applica Bending Spoons.

La differenza, ed è la parte che ritengo davvero nuova, è che nella Builders Organization la piattaforma è indirizzata **anche agli agenti AI, non solo agli umani**. Il design system smette di essere una libreria per designer e diventa l'interfaccia attraverso cui l'organizzazione codifica il proprio gusto: documentazione machine-readable, componenti con semantica chiara, token, esempi, anti-pattern, skill, MCP.

Quanti Guardian servono, e dove stanno? Dipende dalla scala e dalla forma dell'organizzazione. Un Guardian può essere **orizzontale**, un'unica autorità che scrive le regole del suo verticale per tutti i Builder di tutti i team; oppure **per verticale di business**, quando un'area è strutturalmente diversa e le sue regole devono restare separate. E non è nemmeno detto che sia una persona dedicata: un Guardian può essere un Builder che, sul suo territorio di expertise, indossa anche quel cappello.

> **Il Guardian trasforma expertise individuale in organizational leverage: from specialists as gates to specialists as leverage.**

## L'Orchestrator: il contesto è il nuovo coordinamento

![](https://storage.ghost.io/c/e0/d5/e0d59659-cf02-46e9-9ca9-5c5ae0a043c8/content/images/2026/08/ChatGPT-Image-27-ago-2026--18_15_26.png)

Nella realtà che sto costruendo, l'Orchestrator sono io. Decido cosa costruire, come prioritizzare e con quali vincoli, sulla base di tutte le informazioni che ho a disposizione: mercato, clienti, numeri, relazioni. Mi faccio aiutare dall'AI in ogni fase, ma non le lascio la guida della strategia. È il punto che distingue questo ruolo: l'Orchestrator non distribuisce task, distribuisce **contesto**.

Le aziende tradizionali investono enormemente nel coordinamento: meeting, roadmap, planning, sync, ticket, status update. Ma gran parte di quel coordinamento esiste perché le persone possiedono frammenti diversi del contesto. Se vision, strategia, bet correnti, constraint, priorità, evidenze e metriche di successo diventano chiari, condivisi e interrogabili (dalle persone e dagli agenti), una parte del coordinamento si può semplicemente eliminare.

> **Le organizzazioni AI-native sostituiscono il coordinamento con il contesto, ovunque sia possibile.**

Il manager, in questo modello, perde una parte del ruolo tradizionale: smette di raccogliere aggiornamenti, coordinare handoff e tradurre tra funzioni, e inizia a progettare il sistema nel quale persone autonome prendono decisioni coerenti. Non dovrebbe essere promosso perché coordina più persone, ma perché costruisce ambienti in cui più persone lavorano bene senza di lui. La domanda con cui valuterei un manager AI-native è una sola: **quanto bene funziona il tuo team quando tu non sei nella stanza?**

Anche qui i primi dati vanno nella stessa direzione: nelle aziende AI-native misurate da [Kim & Koning](https://aiinstitute.hbs.edu/less-headcount-more-valuation-how-ai-native-firms-change-the-game/?ref=marcosantonocito.com) le gerarchie sono più piatte, con circa il 15% di manager in meno a parità di dimensione. Non perché il management sparisca, ma perché cambia natura: da smistamento di task a design del contesto.

## Cappelli, non persone

Qui devo essere onesto, perché è il punto in cui la mia esperienza diretta rifinisce il framework.

Nella realtà che sto costruendo, oggi, i tre archetipi li indosso quasi tutti io: orchestro la strategia, costruisco da Builder, e mi faccio da Guardian definendo le regole che i miei agenti devono rispettare. Se il framework prevedesse tre persone distinte per forza, la mia stessa esperienza lo contraddirebbe.

Ma il punto è un altro: **Builder, Guardian e Orchestrator sono cappelli, non persone**. A piccola scala una persona li indossa tutti e tre; crescendo, si separano. "Faccio tutto io" non è una tesi: è una fase, legata alla scala. E sto già sperimentando come delegare senza creare persone che si limitino a duplicare le mie competenze: il valore non sta nel clonare il generalista, sta nel far crescere ownership vera su outcome veri.

L'evoluzione che mi aspetto, e che sto iniziando a costruire, è un'organizzazione con vari Orchestrator di verticale; dentro ogni verticale, nuclei di persone che portano avanti il progetto, guidati dall'Orchestrator e supportati dai Guardian. Alcuni Guardian saranno Builder loro stessi; altri copriranno orizzontalmente l'intera azienda. Un team AI-native attorno a un outcome come "aumentare l'activation" potrebbe essere composto da tre Builder (uno engineering-heavy, uno design-heavy, uno growth-heavy) con accesso condiviso ai Guardian di design, engineering, AI e data. Il team non viene assemblato sulla base delle discipline necessarie: viene assemblato sulla base del problema.

## Il rischio della velocità

Il modello ha un problema evidente, ed è bene guardarlo in faccia: l'AI riduce il costo di costruire, ma non riduce il costo di costruire la cosa sbagliata. Semmai lo accelera. Prima, una pessima idea poteva morire durante requirements, design, planning ed estimation; il sistema era lento, ma la lentezza creava per caso un filtro. Domani il percorso è: bad idea, AI, production.

L**'abbondanza di output non è abbondanza di risultato**. Ed è esattamente il motivo per cui Orchestrator e Guardian non sono un vezzo, e per cui l'obiettivo non è aumentare la velocity ma aumentare il **validated learning per unit of time**.

Per lo stesso motivo, **misurare story point e feature consegnate in un'organizzazione dove l'output è decuplicato incentiva solo a produrre più software**: le metriche devono spostarsi su esperimenti completati, apprendimenti validati, outcome per i clienti, e su una domanda nuova per la career ladder: **quanto grande e ambiguo è il problema che puoi possedere autonomamente?**

Accanto a questa dimensione ne serve una seconda, quella del leverage: quanto riesci ad aumentare le capacità degli altri. È lì che un Principal Engineer può scegliere di diventare Guardian invece che manager, con un impatto misurato sulla qualità dell'intera organizzazione.

## Il principio fondamentale

Il paradigma precedente chiedeva: *come coordiniamo specialisti differenti per costruire software?* Il paradigma AI-native chiede: *come creiamo persone sufficientemente capaci e informate da possedere autonomamente un outcome, e quali sistemi dobbiamo costruire perché possano farlo senza sacrificare qualità, sicurezza e coerenza?*

Da queste due domande emergono naturalmente i tre archetipi, e la sintesi che vorrei restasse in testa è questa:

> **Builders own outcomes. Guardians own standards. Orchestrators own context. Leaders own direction.**

Il risultato non è un'organizzazione in cui tutti fanno tutto, né un'organizzazione senza specialisti. È un'organizzazione in cui molte più persone possono fare molto di più autonomamente, e in cui la specializzazione si sposta dal flusso di produzione all'infrastruttura che lo rende possibile.

Ed è probabilmente questa la vera conseguenza organizzativa dell'AI: non solo software prodotto più velocemente, ma una radicale espansione della superficie di responsabilità che una singola persona può possedere. Io la sto attraversando in prima persona, un cappello alla volta.