Giugno 2023, prima vera call di onboarding con un cliente nuovo. Lui apre lo screen share, condivide un Trello con quaranta task in colonna To do, e mi chiede chi è il project manager con cui parlerà nei prossimi mesi. Risposta: sono io, e sono anche il dev che ti scrive il backend, e sono anche il sysadmin che il giorno del go-live alle 7:14 risponde all’alert di Prometheus. Cinque persone, zero commerciali: era già la regola di Romiltec, scritta sulla whiteboard di Calcinaia il primo giorno. Tutti i post di Workshop tornano su questa scelta, perché tutto il resto della società ne discende.
Cosa intendo per zero commerciali
Per chiarezza tecnica, la regola in versione precisa è questa: in Romiltec non c’è nessuna persona che vive di percentuale sui contratti firmati, nessuna che ha come job description “vendere”, nessuna che fa da intermediario fra il cliente e chi scrive il codice. Il “commerciale” come ruolo dedicato non esiste. Il “project manager” come ruolo dedicato neanche. La call di scoping la faccio io con il dev che lavorerà sul progetto. La proposta tecnica e il preventivo a prezzo fisso li scrive lo stesso dev che, due settimane dopo, sarà sul terminale a fare il primo git push su quel repo.
Questa non è una scelta di immagine (“siamo un team flat, fluido”), è una scelta tecnica con conseguenze precise sui costi, sul throughput e sulla qualità del codice.
Perché regge sotto i 10 dipendenti (con i numeri tecnici)
In una società di cinque persone, ogni meeting di allineamento interno costa cinque ore-persona. Se introduci un account manager fra cliente e dev, ne paghi il costo tre volte: sul costo fisso del suo stipendio, sul tempo che spende a parlare col dev per capire la richiesta, sul tempo che il dev spende a riformulare la stessa cosa per il cliente alla call successiva (perché l’account, per quanto bravo, non capirà mai una sottigliezza di schema DB come la capisce chi lo ha disegnato).
Concretamente, in due mesi di operatività ho misurato questi numeri sul mio calendario:
- Call settimanali coi clienti: ~6 ore
- Tempo di risposta medio a una richiesta cliente via email: 2-4 ore lavorative (perché la risposta la dà chi conosce già il codice)
- Tempo di onboarding di un nuovo cliente sul progetto: 2-3 giornate, di cui mezza spesa col dev di backend, mezza con un sysadmin per accessi e VPN, il resto distribuita
- Numero di “passaggi di consegne” interni per un’esigenza cliente: 0 (il cliente parla direttamente con il dev di riferimento)
Confronta con un’organizzazione classica a livelli (cliente → account → PM → tech lead → dev): la stessa richiesta passa da quattro persone, ognuna con il suo MTBF di reinterpretazione. È il telephone game applicato al delivery software. Sotto i dieci dipendenti, eliminarlo è il guadagno tecnico più grosso che riesco a vedere.
Le obiezioni che ho ricevuto in faccia (e le mie risposte)
In due mesi di chiacchiere con altri founder pisani, le obiezioni che mi hanno fatto sono sempre le stesse tre. Le metto in fila, con la mia risposta tecnica.
“I dev senior non vogliono parlare coi clienti, vogliono scrivere codice”. Vero per una percentuale del campione. Falso per i dev senior che sto cercando io. Il profilo dev senior + capacità di stare in call con un caporedattore senza tradire l’ansia è raro ma esiste, e secondo me è il profilo che produce più valore in una software house piccola. Io stesso negli ultimi otto anni come CTO ho passato metà del mio tempo in chiamata col cliente: la skill è scalabile, non solo ai founder.
“Sotto stress, qualcuno deve mediare fra le richieste cliente e il backlog tecnico, sennò il dev viene tritato”. Concordo che lo stress esiste. La mia risposta è che il dev non si fa tritare se il prezzo è fisso al mese e gli sprint sono brevi: il cliente sa che non può chiedere arbitrariamente, e il dev sa che cosa è in scope nello sprint. Il “filtro commerciale” è inutile se il contratto stesso è progettato bene. (Su questo scriverò un post a parte: prezzo fisso al mese, come l’ho calcolato la prima volta e quanto ho sbagliato.)
“Senza un commerciale, come fai pipeline?”. È la domanda più onesta. Risposta brutalmente onesta: i miei primi clienti arrivano da quindici anni di lavoro nel territorio pisano, dal blog tecnico su Laravel/MaxScale/MeiliSearch che mantengo da prima di Romiltec, da una rete di ex-colleghi e di clienti storici della società dove ero CTO. Per i primi due anni di Romiltec questo è sufficiente. Quando finirà, vedremo se serve un ruolo dedicato o se la pipeline può vivere su contenuto + reputazione. Non lo so ancora, e non è onesto fingere che la risposta ce l’abbia adesso.
Cosa cambia per il dev senior che entra in Romiltec
Per un dev senior abituato a una software house tradizionale, i primi tre mesi in Romiltec sono spiazzanti.
In una software house classica, il dev riceve un ticket Jira già formattato, con criteri di accettazione scritti dal PM, e il suo lavoro è “fare quello che dice il ticket”. In Romiltec il dev riceve invece una call cliente di trenta minuti con il caporedattore di una redazione, in cui il problema viene descritto in linguaggio editoriale (“dobbiamo poter chiudere l’edizione delle 17 senza che le foto blocchino la pubblicazione”), e il suo lavoro è tradurre quel problema in un’astrazione di codice corretta.
È un lavoro più completo, più rischioso, più lento all’inizio. In compenso il dev impara a vedere il problema dal punto di vista del processo cliente, non solo del bordo del suo modulo: e questa è la skill che, secondo me, separa un senior da un mid. Ogni dev di Romiltec, a un anno, dovrà saper fare entrambe le cose: scrivere codice di qualità e capire il workflow editoriale o gestionale del cliente. Non è opzionale.
Quando questa regola si romperà
Sono onesto: la regola zero commerciali si romperà a un certo numero di dipendenti. Non so esattamente a quale numero. Probabilmente intorno a quindici, forse venti. Quando il numero di clienti attivi e di pipeline in entrata supererà la capacità di un founder + un senior dev di gestirla, dovrò introdurre un ruolo intermedio. Quando arriverà quel momento, ho due idee preliminari:
- Il “commerciale” futuro sarà un ex-dev. Non un profilo commerciale puro venuto da una software house tradizionale. Un dev che è cresciuto in Romiltec e a cui piace stare in call coi clienti. La curva di adozione interna è più dolce.
- Il “PM” futuro sarà a tempo parziale. Un PM full-time è un costo fisso che pesa molto su una società piccola. Un PM al 30%, condiviso con un altro ruolo, regge fino a una taglia molto superiore di quanto mi aspetto.
Per ora la regola tiene. Cinque persone, zero commerciali, prezzo fisso al mese: è il triangolo di vincoli che definisce il setup di Romiltec, e nei prossimi due anni voglio vedere se questi vincoli reggono o si spezzano sotto carico.
Il filo che voglio lasciare
In una società di cinque persone il rischio non è la mancanza di ruoli, è la loro proliferazione anticipata. Ogni ruolo che assumi prima di averne bisogno congelato è un costo fisso che ti costringe a fatturare di più per pareggiarlo, e a fatturare di più senza i ruoli giusti significa accettare progetti su cui sai già che perderai qualità. Ogni founder tecnico che ho letto, da Jason Fried a Tyler Tringas, torna sullo stesso punto: il setup di vincoli iniziale è la prima decisione strategica vera. Tutto il resto è esecuzione.
Quel cliente di giugno 2023 che mi chiedeva chi era il PM ha capito al secondo meeting come funzionava: a un certo punto mi ha detto quindi se ti scrivo via email mi rispondi tu, vero?. Sì. È quello il modello.