Si costruisce fino a quando la cosa sta accesa. Si stacca quando avete qualcuno che può tenerla, non quando la call è stanca. In Snowinch l'handoff è un esito possibile, non una slide di "autonomia" il primo giorno.
Il founder arriva senza un team di prodotto. Serve un referente, infra, un live che tenga. Poi, a un certo punto, assume. O promuove. O trova un CTO che non vuole ereditare un mistero. Quello è il momento in cui o si fa un passaggio, o si diventa un fornitore eterno che finge di essere interno.
Quando ha senso restare
Restare ha senso finché il live non ha un padrone da voi. Repo, on-call, chi ruota una chiave: se quelle risposte siamo noi, e voi non avete ancora chi le prenda, sparire è un abbandono. Lo si dice. Si resta sul perimetro, o si allarga solo se il segnale lo chiede.
Restare ha senso anche quando il team c'è ma è nuovo sul sistema. Un mese di affiancamento vero (non un PDF) è lavoro. Non è "supporto a consumo" mascherato da ownership.
Non restiamo per abitudine. Se il prodotto è acceso, il team lo governa, e la call settimanale è diventata un riassunto, stiamo occupando una sedia. Si stacca.
Quando staccare (e cosa deve esserci)
Staccare ha senso quando esiste una persona da voi che può rompere e riparare senza scriverci come primo riflesso. Non "ha letto il README". Ha fatto un deploy, ha visto un job morto, sa dove stanno i segreti.
Cosa deve essere documentato, in concreto. Come si alza l'ambiente. Come si riconosce che è rotto (non "guarda le dashboard": quale segnale, quale soglia, chi viene svegliato). Dove stanno le chiavi e come si ruotano. Quali integrazioni mentono, e in che campo. Cosa è fuori scope, così il team nuovo non ricostruisce il marketplace "perché c'era nel vecchio deck".
Senza quello, l'handoff è una cartella. La cartella non risponde alle due di notte.
Preferisco ritardare lo stacco di qualche settimana e fare fare al team le mani sul pezzo brutto, piuttosto che consegnare un sistema "pulito" che nessuno ha toccato. Il costo è che sembriamo lenti a "chiudere il contratto". Lo prendo. L'alternativa è un addio educato e un incidente al primo vendor che rinomina un campo.
C'è un pattern che abbiamo visto (senza appendere numeri): ore che diventano collaborazione su una piattaforma intera, poi uno stacco quando il team interno c'è davvero. Funziona se lo stacco è un progetto, non un "adesso ve la cavate". Se lo trattate come un extra, tornerete in chat al primo errore, arrabbiati come se fossimo ancora i padroni.
Un aside: mi è rimasto un handoff in cui il "documento" era una registrazione di un'ora, senza lista di segreti. Il team nuovo ha girato la registrazione a 1.5x. Le chiavi erano ancora in una chat. Abbiamo rifatto il passaggio. La registrazione, da sola, era un alibi.
Cosa non documentiamo per finta
Non inventiamo un time-to-autonomy. Non c'è un "in N settimane siete indipendenti" che tenga su prodotti diversi. C'è: sapete deployare, sapete revocare, sapete dove sono le copie, sapete cosa non è in scope. Quando quelle quattro sono vere, si può firmare lo stacco. Prima, no.
Non è un kit. Non è un playbook da vendere. Su servizi il build include il fatto che, se internalizzate, il prodotto deve potervi restare. Stesso motivo per cui pochi progetti e un referente non sono una poetica: qualcuno deve poter passare la palla, non disperdere.
Il ponte con validare e poi dover tenere il live è lo stesso oggetto. Se stacchi su un prototipo, non hai fatto handoff. Hai interrotto una prova.
Se vuoi un fornitore eterno e zero team, dillo: si resta, con un perimetro. Se vuoi lo stacco il giorno uno, senza nessuno in casa, questa è la call sbagliata. Il mezzo (segnale, live, poi team) si parla in contatti.
