Poco più di un anno fa ho passato un'ora al telefono con una persona che ha fatto forward deployment per un decennio nell'azienda che ha inventato il termine. Negli ultimi 12 mesi, ho collaborato in varie forme con persone che stanno costruendo i loro motori di forward deployment. Sento ancora che nessun contenuto rende giustizia a tutto ciò che il forward deployment include.
Quando ho parlato con il mio amico, ho chiesto come funziona il famoso processo di scoperta. La risposta è stata quasi imbarazzantemente concreta, almeno inizialmente, se guardi le cose solo in superficie. Arrivi in aereo. Passi due giorni a incontrare tutti coloro che toccano il problema. Il responsabile ERP ti fa una lezione teorica sugli ordini di acquisto. Poi ti portano in officina così puoi vedere cosa la teoria omette. Poi passi tre settimane a fare loro una domanda al giorno mentre colleghi i dati. Ho chiesto se c'era una formula. Ha detto che la formula è ottenere più tempo possibile con le persone che sanno. Dopo dieci anni, quella parte non è mai cambiata.
Tuttavia, questo può essere fuorviante se non approfondisci. Sì, passano molto tempo con i clienti. Tuttavia, i buoni motori di forward deployment costruiscono il modello in anticipo. I grandi deployment engineer e deployment strategist riconoscono che non capiranno tutto, ma sono molto veloci nel costruire cose e iterare con i clienti. Il primo flusso di lavoro è l'obiettivo immediato. Le ontologie vengono usate come un modo per estendere gradualmente quel strumento a un sistema operativo. Il punto in cui i buoni motori di forward deployment eccellono è che gran parte del contesto proviene dal team, dagli esperti del settore, e loro in qualche modo lo assemblano in gran parte ancor prima di incontrare il cliente per la prima volta. Questa parte è migliorata nel tempo ed è la vera ragione per cui alcuni motori si accumulano e altri no.
Ho subito avuto due pensieri. Probabilmente li avrai anche tu se non hai prestato attenzione a cosa sia un buon forward deployment, quindi ti esorto a continuare a leggere.
Il mio primo pensiero è stato: cosa succede quando non hai la minima idea dei flussi di lavoro del cliente? Dovresti iniziare con un sacco di interviste, giusto? Il mio amico ha detto di no, perché a nessuno piace essere intervistato, ma ha condiviso una storia. Il suo team una volta ha costruito un motore di instradamento per un'azienda di logistica che aveva dispatcher che assegnavano ticket giornalieri agli autisti o alle rotte basandosi sul giudizio manuale e guardando mappe, distanze, posizione delle discariche e altri vincoli operativi. Il mio amico ha costruito uno strumento che dava raccomandazioni ai dispatcher, ma il primo problema era che i dispatcher spesso rifiutavano la raccomandazione basandosi sull'intuito e non riuscivano a spiegare chiaramente il perché. Per gestire questo, il suo team ha dovuto visualizzare tutte le diverse possibili permutazioni di assegnazione e poi hanno usato quella visibilità per confrontare le decisioni umane con i risultati simulati. Questa era la prima volta che qualcuno mappava tutte le permutazioni su uno schermo e quindi era la prima volta che le persone avevano un momento per riflettere se la decisione che stavano prendendo basandosi sull'intuito fosse supportata da dati su larga scala. Ha permesso al team dell'azienda di logistica di verificare il flusso di lavoro stesso, capire se la logica del processo era effettivamente corretta e perfezionare il gemello digitale in modo che corrispondesse meglio a come l'azienda operava nella pratica. Hanno anche apprezzato il processo perché non sembrava mai un'intervista, ma invece permetteva loro per la prima volta di vedere tutti i pezzi del puzzle su un'unica lavagna.
Il mio pensiero successivo è stato: come l'aggiunta degli agenti cambia l'intero processo oggi rispetto a qualche anno fa? La risposta che il mio amico ha dato è che semplicemente implica che possiamo sviluppare molto più velocemente usando gli agenti e avere più contesto a livello di conoscenza tribale, ma quella è solo una parte del puzzle. Ha detto che la salsa segreta nel loro modello FDE quando si tratta di questi piloti non è nulla di geniale. In alcuni casi, anche adesso, mentre fanno i piloti, stanno semplicemente ascoltando i passaggi e i risultati, mappando i verbi e dando al cliente un team di cinque persone che siano i loro ingegneri dedicati. Questi ingegneri codificano tutto e poi possono semplicemente sparire e il cliente può continuare a usare la soluzione. Gli agenti aiutano nel senso che accelerano e approfondiscono il processo di codificazione, rendendo più facile incorporare più contesto e conoscenza tribale provenienti dai sistemi del cliente. Gli agenti sono diventati un modo per andare oltre il semplice feedback diretto degli utenti e invece attingere a contesto storico e operativo, cose come email, cambiamenti nei processi di vendita, cambiamenti di stato in sistemi come Salesforce e altre tracce di come l'organizzazione ha lavorato nel tempo. Questo rende più facile modellare i flussi di lavoro del cliente in modo più ricco, collegare insieme fonti di conoscenza frammentate e costruire sistemi che non solo rappresentano l'azienda attraverso un gemello digitale, ma aiutano anche ad automatizzare o supportare le decisioni che le persone attualmente prendono manualmente.
Ho alcuni paragrafi dalla trascrizione della mia chiamata con lui.
Quindi, il modo in cui iniziamo è che ci concentriamo sempre sulla velocità nel creare valore. Non seguiamo sempre un approccio procedurale come, ok, creiamo l'ontologia. Poi creiamo l'applicazione sopra. Poi andiamo dall'utente. No. Per certi versi lo seguiamo, ma per altri aspetti, chiediamo semplicemente al cliente: qual è il più grande valore aggiunto che possiamo costruire per te o qual è il più grande impatto che possiamo offrirti in questo momento? Spiegaci il problema nel tuo business e ora il problema che pensi possiamo risolvere.
Una volta che il cliente condivide, andiamo alla lavagna e diciamo, ok, tagliamo una versione uno dell'ontologia, costruiamo anche una versione uno dell'applicazione in circa una settimana e testiamola. Quindi è molto simile a, sai, come costruiresti una startup. Spesso scopriamo che potrebbero avere un'idea di un caso d'uso, ma mentre parlano, scopriamo un altro caso d'uso potenzialmente completamente diverso che possiamo semplicemente risolvere. E lo costruiremo, anche se loro pensavano di aver bisogno di qualcos'altro. Alla fine della giornata, cerchiamo di sintonizzarci su qual è il problema più grande che devono risolvere.
Costruiremo qualcosa per quello rapidamente e creeremo cinque oggetti in termini di ontologia. Se stiamo facendo qualcosa legato, diciamo, al sistema ERP, che può essere piuttosto complesso, anche dopo aver fatto le integrazioni, contattiamo quell'esperto ERP un paio di volte per una sessione di jam session di un'ora o una riunione ad hoc di mezz'ora durante la settimana. E poi, una volta che ci siamo dimostrati lì, cerchiamo il secondo, terzo, quarto caso d'uso fino al punto in cui possiamo costruire un sistema operativo aziendale per l'intera azienda.
Di solito lo facciamo sotto forma di una visita in loco. Arriviamo in aereo, diciamo ok, dateci due giorni. Incontriamo gli stakeholder, tutti quelli che possono essere presenti insieme o uno a uno. In molti casi, quando le persone sono impegnate, ci sediamo semplicemente accanto a loro e cerchiamo di capire il loro processo di vendita o il tuo tipo di interazione con il cliente. Cerchiamo di capire dalla loro prospettiva cosa sta succedendo e non cerchiamo di condensare il tempo con il cliente. In realtà continuiamo a insistere di più ed è qualcosa che non è mai cambiato in 10 anni. A volte, passiamo intere settimane con i clienti. Non abbiamo mai cercato di allontanarcene e rendere la nostra piattaforma completamente automatizzata in alcun modo quando si tratta di scoperta.
Un'idea centrale nella discussione era che la codificazione avviene attraverso l'iterazione, non attraverso una documentazione pesante. Il team costruisce un "gemello digitale" dell'azienda direttamente nel codice, usando integrazioni di dati, contesto operativo e input di esperti del settore per rappresentare come l'organizzazione funziona nella pratica. Ma quel modello di dati da solo non basta. Lo strato più difficile e prezioso è la logica di business: la comprensione di dove l'intervento è importante, quali azioni dovrebbero essere raccomandate e come gli operatori esperti prendono effettivamente le decisioni. Tutto questo non significa solo portare alla luce informazioni, ma aiutare gli utenti a valutare i compromessi, convalidare i flussi di lavoro e, infine, codificare il supporto decisionale nel prodotto stesso.
Il resto della mia conversazione è andato più a fondo su come questo lavoro non dipenda dall'avere esperti di dominio profondamente radicati fin dall'inizio. L'aspettativa è che i forward-deployed engineer possano entrare in ambienti sconosciuti, imparare rapidamente e costruire credibilità producendo sistemi utili velocemente. I primi impegni spesso iniziano con un breve bootcamp, supportato da prototipi pre-costruiti e dati di esempio, progettati per dimostrare rapidamente il valore e guadagnarsi il diritto a un'implementazione più profonda. Da lì, la relazione può espandersi da un singolo caso d'uso a un sistema operativo più ampio per il cliente, con l'obiettivo a lungo termine di codificare i flussi di lavoro in modo così efficace che il team possa eventualmente farsi da parte mentre il cliente continua a usare la soluzione.
Questo è un playbook estremamente rilevante per una nuova impresa che viene ora costruita. Questo è il forward deployment. Tutto il resto è forse decorazione.
La legge dell'accumulazione
Il forward deployment è costoso, lento a manifestarsi nel margine lordo e duro per una pianificazione ordinata. I fondatori lo sentono e iniziano a chiedersi se lo sforzo sia pari al risultato. Alla fine qualche leader lo dice ad alta voce: stiamo mettendo il doppio dello sforzo e ottenendo il doppio del risultato.
Quella frase è un campanello d'allarme per certe industrie se implica che il forward deployment non sia il modello giusto. Capisco l'impazienza di un fondatore, essendolo stato anch'io, ma c'è una linea sottile tra ingenuità e impazienza. Per le aziende che funzionano meglio con un motore di forward deployment, chiunque faccia questa moltiplicazione non ha capito il lavoro. Se il doppio dello sforzo compra il doppio del risultato, hai assunto consulenti e li hai vestiti da ingegneri. Aggiungerai persone in perfetta sincronia con i ricavi per sempre, i tuoi margini non scapperanno mai, e il nome onesto per ciò che hai costruito è un'agenzia di personale che spedisce codice o fornisce supporto. Le persone che non hanno chiarezza su cosa stanno costruendo quasi sempre finiscono con risultati mediocri, e questa particolare confusione si accumula contro di te.
Il forward deployment ha senso solo se la matematica si piega. L'implementazione numero uno può essere brutta, artigianale, economicamente indifendibile. Il suo compito è insegnare. L'implementazione numero due deve essere più economica perché la prima ha lasciato un modello, un'integrazione, uno schema documentato, un pezzo di piattaforma. Entro l'implementazione numero dieci, la maggior parte di ciò che il primo team faceva a mano dovrebbe avvenire tramite configurazione, e gli umani dovrebbero essere a un livello superiore, risolvendo problemi che non esistevano un anno fa, nemmeno agli occhi del cliente. La distanza tra quei due numeri al mese 1 e al mese n è l'accumulazione, e quella curva è la cosa reale che stai comprando quando finanzi un team di forward deployment. L'accumulazione è il punto centrale. Chiamarsi forward deployed senza un motore che si accumula è semplicemente stupido.
Un ingegnere del software e un forward deployed engineer differiscono principalmente per la quantità di tempo che uno SWE passa a scrivere codice che mantiene cose, supporta cose o costruisce cose sulla roadmap, rispetto a ciò che l'FDE passa a scoprire cose che spesso non sono sulla roadmap ma sbloccano valore per il cliente, implementandole e passandole al prodotto quando lo schema inizia a ripetersi tra i clienti.
La parola che tutti usano e quasi nessuno intende
L'idea ha un'origine specifica. Due decenni fa, un fondatore chiese perché i grandi ristoranti francesi sono grandi, e la risposta fu il cameriere. In un grande ristorante, il cameriere fa parte della cucina, quindi quando raccomanda qualcosa, è la cucina che parla. Palantir ha costruito la versione ingegneristica di questo e ha dato al ruolo un nome militare, perché i suoi clienti erano militari. Il nome ha dato al lavoro sul campo lo status meritato e giustamente. Pagava così bene che vent'anni dopo tutti vogliono il nome, ma non sono sicuro di quante persone capiscano il lavoro.
In un certo senso, un team di forward deployment deve fare ciò che un fondatore deve fare nella fase 0-1. Spesso stai scoprendo cosa potresti spedire che non solo solleverà una metrica di vanità, ma aiuterà il tuo cliente a far crescere davvero il suo business. Questo è un altro esempio reale dalla conversazione del mio amico. Il suo team è stato assunto da un produttore di caricabatterie per veicoli elettrici che voleva aumentare la produzione di circa 10 volte. Questo era il brief. Riuscite a indovinare il risultato? Perché di sicuro non era un mazzo di strategia. L'obiettivo dell'azienda era semplice in superficie: aumentare la produzione di caricabatterie EV di 10 volte. Quello che il team di forward deployment ha effettivamente fatto è stato andare sul posto e imparare l'operazione da più livelli dell'azienda. Hanno passato del tempo con il proprietario dell'ERP per capire il sistema di registrazione, gli ordini di acquisto, gli ordini di lavoro, l'offerta e la domanda. Poi sono andati in officina per vedere come la produzione avveniva realmente nella pratica. Allo stesso tempo, hanno parlato con i dirigenti per capire la versione strategica del problema, perché ciò che gli operatori in prima linea dicono sia sbagliato o urgente non sempre corrisponde perfettamente a ciò che la leadership vede come il vincolo più importante. Il lavoro, quindi, non era costruire una nuova linea di produzione direttamente, almeno non da ciò che è stato detto nella riunione. Era costruire un gemello digitale dell'operazione e poi identificare dove il software poteva intervenire nel flusso di lavoro, ad esempio, su questioni come la carenza critica di parti, la tempistica degli ordini di acquisto, le scorte di sicurezza e altre decisioni operative. Il risultato descritto era un sistema in grado di segnalare i rischi prima e raccomandare azioni, piuttosto che un cambiamento fisico alla produzione stessa. Spero che questo spieghi cosa intendo quando dico che gli ex fondatori possono essere eccezionali nel forward deployment.
Guarda sotto l'esperienza lavorativa odierna (non le descrizioni) e trovi ingegneri che scrivono codice di produzione all'interno dei sistemi dei clienti e possiedono ciò che accade dopo il go-live, incluso il supporto. Il resto sono sales engineer con un biglietto da visita migliore, giudicati sulla demo, più una coda di ruoli di automazione interna che hanno preso in prestito la parola perché è di moda. Le confusioni contigue su cosa sia il forward deployment sono peggiori. Gestire una rete di esperti attraverso cento interviste di dominio è ricerca, ma non è forward deployment. Quando un private equity raggruppa aziende e invia una squadra di trasformazione, è utile, a volte brillante, ma non necessariamente forward deployment. Lo dico perché nessuno in questi due movimenti possiede ciò che chiamo chiusura del lavoro.
La chiusura del lavoro è l'unità in cui è denominata l'intera disciplina. Non una funzionalità spedita, non un ticket risolto. Un pezzo del lavoro del cliente, portato fino in fondo da una preoccupazione persistente a qualcosa di cui nessuno pensa più. La firma del contratto è il confine tra le professioni che vengono confuse qui. Un sales engineer lavora fino a quel punto. Un team di forward deployment inizia da lì, perché concordare che qualcosa dovrebbe funzionare non è la stessa cosa che farlo funzionare. Se la persona ha una quota, stai guardando alle vendite. Se la persona è ancora nei log del cliente tre mesi dopo il lancio, stai guardando al forward deployment. Un'azienda che vende un prodotto di marketing invierà sales engineer per far firmare l'affare e per implementare e configurare le cose. Un vero FDE potrebbe arrivare alla conclusione che nessuno dei flussi di lavoro supportati dal prodotto aiuterà il cliente in questione e che qualcosa di completamente nuovo avrà un impatto diretto sui ricavi o sui profitti, e poi costruirà quel flusso di lavoro. Questo richiede essere un esperto del Mom's test (leggi il libro), capire che ai clienti non importa della tua funzionalità ma di come fare meglio business, capire di cosa è capace il tuo prodotto e spedire a un ritmo veloce in modo da poter iterare con il cliente sul flusso di lavoro reale.
Quindi, ecco la definizione che metterei sul muro. Il forward deployment è stare nella distanza tra ciò che hai spedito e ciò di cui il cliente aveva bisogno, colmare quella distanza con le tue stesse mani, nel loro mondo, in un modo che insegni al tuo prodotto a colmarla da solo la prossima volta.
La seconda metà di quella frase è dove quasi tutti falliscono.
Perché questo è improvvisamente ovunque
Per settant'anni il software ha aiutato le persone a fare lavoro. Ora sta iniziando a fare il lavoro. Questo capovolge un'ipotesi nascosta. Uno strumento può permettersi di essere adottato lentamente. Un lavoratore no. Nel momento in cui vendi risultati invece di postazioni, qualcuno deve far sì che il risultato si avveri all'interno di un'azienda che si comporta in modo completamente diverso dal tuo ambiente demo.
I modelli hanno smesso di essere il vincolo ad un certo punto negli ultimi due anni. L'implementazione è diventata il vincolo. Lo studio più citato sui piloti di AI aziendale ha scoperto che circa diciannove su venti non producevano alcun impatto misurabile sul P&L, e l'autopsia non è quasi mai la qualità del modello. È un software che non ha mai imparato il flusso di lavoro. Il processo documentato ha quattro fasi. Quello reale ne ha nove, e le cinque mancanti vivono nella memoria di una donna, in un tracker personale che ha costruito anni fa, e in un favore che scambia con un'altra donna in un altro edificio. Nelle industrie più datate, il lavoro passa attraverso sistemi installati prima che i tuoi ingegneri nascessero, tenuti insieme ai margini da fax e telefonate. Niente di tutto ciò ha un'API. Nei giacimenti petroliferi, qualcuno mette l'orecchio contro l'impianto per valutare se il suono indica qualcosa di cui dovrebbero preoccuparsi. Sulla nave che trasporta calamari dall'India agli USA, con una sosta a Londra, tariffe e prezzi vengono decisi in base a intuizioni, dati meteorologici limitati e a ciò che visivamente appare essere la qualità del carico. La conoscenza tribale è lo strato portante di ogni azienda, e nessuno ha mai spedito un SDK per essa. Il cimitero delle piattaforme industriali dell'ultimo decennio ha insegnato questa lezione con miliardi di dollari. Le trasformazioni non muoiono nell'architettura. Muoiono nell'adozione.
Il denaro se n'è accorto. Microsoft ha impegnato due miliardi e mezzo di dollari e seimila persone per incorporare esperti all'interno dei clienti. AWS ha messo un miliardo dietro la stessa idea settimane prima. OpenAI e Anthropic hanno ciascuna creato aziende di implementazione dedicate con alcuni dei più grandi investitori del mondo. Puoi chiamarlo moda. Il capitale a questa scala è raramente un costume. I laboratori hanno valutato le loro stesse pipeline e hanno scoperto che l'acquirente non era mai a corto di intelligenza. L'acquirente era a corto di mani. Il fallimento vive nell'ultimo miglio, e l'ultimo miglio è dove si scava il fossato. Ci sono voluti 10 anni di lavoro intenso sugli LLM per arrivare dove siamo. Potrebbe volerci molto di più se dovessimo far sì che questi modelli comprendano il flusso di lavoro e il quadro decisionale umano.
Perché hai bisogno di una figura commerciale in quel team
L'ingegnere esiste perché il divario viene colmato con il codice, sull'infrastruttura del cliente, contro i casi limite del cliente, di solito entro giorni. Ciò che gli utenti descrivono al mattino dovrebbe essere in esecuzione davanti a loro entro giorni, non trimestri. Quella velocità è il modo in cui si costruisce la fiducia con persone che hanno visto programmi di trasformazione triennali produrre una libreria di slide.
La figura commerciale esiste perché i problemi più difficili nell'implementazione non sono tecnici, e fingere il contrario è il modo in cui i team tecnici falliscono. Qualcuno deve scoprire qual è il lavoro reale prima che qualcuno lo automatizzi. Qualcuno deve decidere quali tre delle venti escalation contano, quale flusso di lavoro è il vero collo di bottiglia, il silenzio di quale dirigente ucciderà l'adozione e quale risultato giustificherebbe l'intero impegno. Qualcuno deve essere bravo a capire quando un cliente esita e quando dice cose solo per essere educato. Qualcuno deve gestire l'interfaccia più delicata nell'AI aziendale, quella tra ciò che il tuo prodotto fa oggi e ciò che hai venduto come inevitabile tra sei mesi. Penso al deployment strategist come al desk dei futures dell'azienda. Vendono ciò che il prodotto diventerà, a un prezzo che la relazione può sopportare, e si assicurano che la posizione non vada mai in default. Le trattative ad alto rischio si vincono su quel desk, e si perdono senza di esso.
Le modalità di fallimento ti dicono quale ruolo ti manca. Affari che si bloccano perché il prodotto non funziona nel mondo del cliente o scenari in cui il prodotto supporta solo flussi di lavoro che esistono all'interno del prodotto significa che ti manca l'ingegnere. Ingegneri che spediscono funzionalità richieste e sono impegnati ma i ricavi non salgono molto, o scenari in cui l'FDE ha fatto 100+ chiamate ma i ricavi contrattati sono ancora un ordine di grandezza superiori ai ricavi realizzati, o silos di flussi di lavoro personalizzati che non migliorano il sistema significa che ti manca lo strategist.
Nei migliori team, i due ruoli si confondono, e la confusione è il punto. L'ingegnere sviluppa l'istinto commerciale, lo strategist impara a leggere uno schema, e ciò che ottieni è la cosa più vicina che un'azienda possa assumere a un fondatore. Il forward deployment è ciò che ogni fondatore fa per anni prima che l'organigramma lo nasconda, seduto nel caos dei clienti, chiudendo il lavoro con ciò che ha a portata di mano, lasciando che ciò che impara ridisegni il prodotto. Il ruolo è la settimana di un fondatore sul cap table di qualcun altro. È anche il motivo per cui questi team sfornano fondatori a un ritmo che mette in imbarazzo le grandi aziende tecnologiche. Se gestisci un pod FDE, dovresti prepararti con una successione pianificata dal primo giorno perché è probabile che i fondatori che costruiranno tra un decennio siano stati tutti FDE nella loro vita passata, che si sta svolgendo oggi.
Come sapere se ne hai davvero uno
Non puoi giudicare un team di forward deployment da un'istantanea, perché in qualsiasi giorno, uno grande e uno falso sembrano identici: persone intelligenti che volano dai clienti e spediscono imprese eroiche. Cinque controlli lo smascherano.
#1 Sforzo per cliente. Un team che ha servito cinque clienti l'anno scorso e ne serve cinque quest'anno non sta accumulando nulla. Un team che ora ne serve quindici sta alimentando un prodotto che assorbe ciò che il campo impara. Con ogni cliente, internamente il tuo team dovrebbe sviluppare un esperto del settore.
#2 La novità del lavoro. Se la quarta implementazione ripete la terza, nessuno possiede il tubo dal campo alla piattaforma. Qualcuno deve essere pagato per cacciare le ripetizioni tra gli account, perché la ripetizione è la roadmap che si scrive da sola.
#3 La forma della seconda implementazione in un segmento. Se il cliente dieci ti costa quanto il cliente uno, non stai scalando un prodotto. Stai concedendo in franchising un progetto.
#4 La linea di riporto. All'interno del prodotto o dell'ingegneria, il ciclo può chiudersi. All'interno di un silo di vendite o servizi, l'apprendimento se ne va in report di viaggio che nessuno legge, e il team diventa silenziosamente margine.
#5 Il tabellone segnapunti del cliente. L'attività è teatro. I numeri di utilizzo possono sembrare spettacolari mentre nulla a valle migliora. L'unica misurazione che sopravvive al contatto con un CFO è una valutazione che il cliente ha aiutato a scrivere, che valuta il lavoro in base ai loro risultati sui loro dati, costruita nella prima settimana e tracciata apertamente. Tieni accanto un test umano. Quando qualcosa si rompe nella loro attività che non ha nulla a che fare con il tuo prodotto, sei la prima chiamata? Ogni dashboard mai costruita è un tentativo di approssimare quella telefonata.
E attenzione allo schema oscuro, perché è ovunque in questo momento. In alcune aziende, il team di forward deployment non è un motore di apprendimento ma un nascondiglio. Il prodotto non funziona del tutto, quindi un essere umano viene piazzato in ogni lacuna. Poiché gli umani sono eroici, le lacune non arrivano mai alla roadmap. Poiché le lacune non arrivano mai alla roadmap, il prodotto non migliora mai, e gli umani non possono mai andarsene. Il prodotto non sente pressione perché il campo continua ad assorbire. Il campo non scrive nulla perché è troppo occupato a salvare account. Le fatture continuano ad arrivare perché il cliente, in effetti, viene servito. La macchina è in equilibrio, e l'equilibrio è il problema. Le aziende ci vivono dentro per anni, facendo crescere il personale sul campo esattamente alla stessa velocità dei clienti e chiamandolo forward deployment. Non lo è. È l'assenza di un prodotto, fatturato mensilmente. È anche il motivo per cui così tante persone di talento in questi ruoli sentono di star fallendo. Sono state assunte per accumulare e sono state assegnate per nascondere.
Come appare in ogni fase
Seed. Il prodotto è una demo. Esistono solo tre clienti, e il fondatore è il team di implementazione. Il feedback è così stretto che non c'è bisogno di un ponte. La domanda non è se l'implementazione sia in corso, ma se il prodotto sia reale.
Serie A. Da 15 a 20 clienti. Il fondatore non può più essere l'unico implementatore. Viene assunta la prima persona dedicata. Il fondatore trasferisce la conoscenza, ma la conoscenza non è ancora abbastanza spessa per essere un manuale. Il rischio è che questa persona diventi un consulente glorificato, risolvendo i problemi del cliente ma non migliorando il prodotto. L'unica protezione è che il fondatore continui a fare da interfaccia, e che la persona assunta riceva una partecipazione sia nel prodotto che nell'implementazione.
Fase iniziale, non assumerla. Sii tu quella persona. I fondatori sono il team schierato in prima linea, e la cosa peggiore che puoi fare con la tua scarsa comprensione è delegarne l'acquisizione. Fai tu stesso i viaggi di due giorni. Siediti con il dispatcher. Quando finalmente assumi, assumi persone che ti rendano più veloce nel chiudere il lavoro, mai persone che si frappongano tra te e il cliente.
La fase di crescita è il momento in cui lo schieramento in prima linea viene frainteso, perché dall'esterno sembra un rallentamento. Il tuo consiglio di amministrazione guarda gli ingegneri passare settimane all'interno di singoli account mentre i concorrenti annunciano funzionalità ogni settimana. La contabilità peggiora le cose. Lo schieramento è registrato nel costo del venduto, anche se il lavoro si comporta come R&S, quindi più impari, peggio appari. Tieni entrambe le verità senza mentire in nessuna direzione. Nel bilancio è un costo. Nella strategia è ricerca. La risoluzione non è una storia, ma dei paletti che costringono la ricerca a ripagare. Vincola ogni intervento a un limite di tempo. Collega ciascuno a un singolo risultato di business nominato. Raccogli i frutti trimestralmente, il che significa che ogni trimestre qualcosa costruito a mano sul campo diventa qualcosa che la piattaforma fa da sola. Lo produttizzeremo dopo è la frase che uccide le aziende in questa fase, perché "dopo" non ha un proprietario.
Su larga scala, la domanda cambia forma. Hai centinaia di clienti che pagano milioni, e hai già consulenti di soluzione, team di implementazione, servizi gestiti, account executive, customer success. I leader in questa fase non sanno davvero dove collocare un team schierato in prima linea, quindi viene aggiunto come un quarto livello di supporto e muore sotto il volume dei ticket. La risposta è che ogni funzione esistente esegue un playbook, e il team schierato in prima linea esiste solo dove non esiste un playbook. I dieci account più ambiziosi. Il nuovo verticale. Il flusso di lavoro che l'intero settore dice non possa essere automatizzato, ma che tu senti di poter automatizzare in modo unico. Riporta al prodotto, ha il mandato di rendere superfluo il proprio lavoro, e passa ogni schema risolto ai team che eseguono i playbook, ed è così che i playbook rimangono vivi. La versione di Uber di questo è istruttiva. Hanno abbinato i loro ingegneri più esperti di AI con esperti di dominio provenienti da finanza, legale e supporto, hanno dato a ogni coppia due settimane e hanno richiesto di costruire accanto alla persona che possiede il flusso di lavoro, invece di presentare a loro. Due giorni di affiancamento, un giorno per scegliere l'obiettivo, live entro il decimo giorno. Sedici pod hanno riconfigurato sedici funzioni in due mesi, e un report che richiedeva due giorni ora richiede dieci minuti. L'unità di automazione non è mai stata il compito. È il flusso di lavoro, e i flussi di lavoro si rivelano solo alle persone che ci siedono dentro.
Lo stesso lavoro indossa abiti diversi in ogni settore
Nella difesa e nel governo, la presenza è il prodotto. Autorizzazioni di sicurezza, reti disconnesse, stanze da cui il tuo laptop non può uscire. Nel settore sanitario, il lavoro è archeologia del flusso di lavoro. Il processo reale passa attraverso sistemi di registrazione vecchi di vent'anni, con fax e alberi telefonici che ancora gestiscono le eccezioni, ogni struttura che esegue la propria variante non scritta. Un team che assume uno standard perde un anno. Nei servizi finanziari, il cliente compra giudizio sotto conformità, il deliverable è spesso una valutazione che un regolatore potrebbe leggere, e l'ansia più profonda non è la fuga di dati, ma la fuga di giudizio: i modelli decisionali delle loro persone migliori che finiscono nel modello di qualcun altro. Nella produzione e logistica, la verità vive sul pavimento e i vincoli sono fisici, motivo per cui la scoperta non può avvenire in video e i sistemi di registrazione sono arcaici, visibilmente complessi e spesso disconnessi dal cloud. Nelle aziende consumer, il ciclo gira in giorni invece che in trimestri, e la competenza rara è il gusto: sapere cosa suona come il brand e quando una macchina dovrebbe smettere di parlare. E il territorio più nuovo è la tua stessa azienda. Gli stessi pod, schierati nelle tue funzioni di finanza, legale e supporto, perché il divario tra ciò che l'AI può fare e ciò che la tua organizzazione effettivamente fa è lo stesso divario, a un edificio di distanza.
Il terreno stabilisce le tattiche, e le tattiche sono negoziabili, ma la sequenza no. Siediti con il lavoro, chiudi il lavoro, alimenta il prodotto.
Chi è davvero bravo in questo
L'inventore, Palantir gestisce ancora la versione più profonda, e il dettaglio che tutti dimenticano è che il modello è nato prima del prodotto. All'inizio non c'era nulla da configurare, solo una scommessa che se ti fossi seduto abbastanza a lungo dentro istituzioni in difficoltà, i prodotti si sarebbero rivelati. Così è stato, e oggi la stessa azienda gestisce interventi più brevi e più standardizzati, perché una volta che il prodotto esiste, la capitalizzazione composta è la religione.
La nuova generazione è più facile da leggere nelle aziende di agenti per il servizio clienti. Sierra gestisce la sua funzione sul campo come ingegneri di agenti, e il ciclo è deliberato. Risolvilo per un cliente, diffondi ciò che ha funzionato all'interno dell'azienda, poi promuovi i vincitori nella piattaforma in modo che ogni cliente li erediti. Quando i loro ingegneri hanno imparato, attraverso dozzine di implementazioni, esattamente quando un agente dovrebbe smettere di riprovare e passare il cliente a una persona, quel giudizio è diventato un componente riutilizzabile. Poi hanno costruito Ghostwriter, un agente che fa la costruzione, alimentato da trascrizioni di chiamate, SOP e foto di lavagne, eseguito su una piattaforma che hanno riarchitettato in modo che un agente potesse operarla direttamente. Scommettere su Sierra è, in gran parte, scommettere che i suoi team schierati continueranno a scoprire flussi di lavoro che nessun altro ha visto. Decagon ha seguito la via dei sistemi, ha analizzato le sue implementazioni per lavori che non avevano motivo di essere su misura, ha ridotto l'ingegneria personalizzata dietro ogni agente dell'ottanta per cento, e poi ha detto la parte non detta in pubblico: che la consegna, non il prodotto, stava diventando il fossato. Ramp assume il suo team sul campo in gran parte da ex fondatori, li indirizza all'intero ciclo di vita del cliente, dalla prima chiamata al supporto a lungo termine, e inculca un'abitudine sopra tutte: metti in discussione il requisito prima di costruirlo, perché la richiesta dichiarata è di solito il sintomo, non la malattia.
Una volta che conosci la forma, la vedi in ogni verticale serio. Harvey inserisce ex avvocati praticanti all'interno degli studi legali, prova che la persona schierata non deve affatto essere un ingegnere, solo responsabile. Nella finanza, Rogo impiega quasi metà dell'azienda con ex banchieri schierati nelle istituzioni da cui provengono, mentre Hebbia invia ingegneri per costruire l'ultimo miglio all'interno dei più grandi gestori patrimoniali del mondo. Abridge sta creando pod di implementazione con sistemi ospedalieri, perché portare uno scriba AI a dodicimila clinici non è un'installazione, è una campagna. HappyRobot si integra con i broker di spedizioni, Gecko Robotics mette i costruttori sulle navi della marina, Applied Intuition siede all'interno della maggior parte dei grandi produttori automobilistici del mondo, e Cursor (SpaceX) gestisce un team schierato in prima linea che collega lo strumento che i tuoi ingegneri amano già a banche e telecomunicazioni.
Forme diverse, una fisica. Il campo alimenta la fabbrica, o non è schieramento in prima linea.
L'argomentazione più forte contro, perché se la merita
C'è un'argomentazione secondo cui questa intera professione è una scusa. Ti è stata venduta una cucina che cucina da sola, ed è arrivata con uno chef che ora vive a casa tua, sul tuo libro paga, con il margine del fornitore, senza data di uscita. La proposta richiede di credere a due cose contemporaneamente: che la macchina sia abbastanza brillante da sostituire la tua cucina e abbastanza impotente da aver bisogno di un badante residente. Se il prodotto ha bisogno di un umano residente, il prodotto non è finito.
Prendi questo seriamente, perché per molti fornitori è semplicemente vero. Il test che separa le specie è lo stesso che questo articolo continua a ripetere. Se l'umano nel divario è permanente, la critica vince, e stai affittando una toppa. Se l'umano nel divario capitalizza in modo composto, chiudendo il lavoro in un modo che rimuove la necessità di se stesso, la critica muore alla seconda implementazione. Ciò che la critica perde è che la maggior parte del lavoro non è mai stato il completamento del prodotto. È l'acquisizione del contesto. I cinque passaggi non documentati, l'intuizione non detta del dispatcher, il favore scambiato tra edifici. Nessun prodotto finito verrà mai fornito con quelli, perché sono diversi all'interno di ogni azienda. Qualcuno deve andare a prenderli. L'unica domanda che conta è se ciò che recuperano si capitalizza in un asset o evapora in fatture.
Dove va a finire
Quattro cambiamenti sono già in corso.
Il contesto diventa l'asset. Ciò che un team schierato costruisce veramente presso ogni cliente è un modello funzionante di come funziona quell'azienda. L'ontologia, il gemello, la mappa di chi decide cosa e perché. Gli investitori hanno iniziato a chiamarlo il cervello aziendale, e il nome sta prendendo piede perché ogni azienda ne avrà bisogno. Più di quanto si pensi può essere avviato prima che qualcuno salga su un aereo, perché i clienti perdono la loro stessa verità costantemente, nei ticket di supporto, nelle trascrizioni delle chiamate, nelle email, nei thread di escalation. Inizia da lì. Ma lo strato più profondo, la conoscenza che le persone non riescono a verbalizzare, richiede ancora presenza e specchi, strumenti che permettano agli insider di verificare la propria intuizione finché non si trasforma in logica. Chiunque possieda quella mappa possiede l'account, il che solleva la domanda che ogni CEO sta per fare a ogni fornitore di AI. Sto affittando l'intelligenza, ma chi possiede l'apprendimento? Se un modello condiviso assorbe il giudizio di credito di ogni finanziatore in un mercato, il sottoscrittore più acuto del pool sta addestrando i suoi concorrenti e pagando per il privilegio. C'è un test che qualsiasi CFO può eseguire. Cambia fornitore di modello domani, sulla carta, e verifica se tutto ciò che hai insegnato al sistema se ne va con lui. Aspettati che contratti, team e, infine, aziende si riorganizzino attorno a una singola riga. Affitta l'intelligenza, possiedi l'apprendimento.
Gli agenti si uniscono al team. L'agente schierato in prima linea esiste già in forme iniziali. Agenti di onboarding che comprimono un pomeriggio di lavoro di integrazione in minuti. Agenti di implementazione che leggono le proprie trascrizioni durante la notte e propongono miglioramenti alle proprie abilità. Guarda cosa fa questo al ruolo umano. Ogni intervento manuale smette di essere il lavoro e diventa un segnale di addestramento, e il lavoro del team si inverte: dal fare implementazioni al gestire la fabbrica che fa le implementazioni. Modelli di personale come i manager assumono personale. Scrivere valutazioni come i manager scrivono recensioni. L'inversione più profonda è in chi è l'utente. I prodotti vengono ricostruiti in modo che gli agenti possano operarli direttamente, e la prima domanda di scoperta presso un cliente sta silenziosamente cambiando da di cosa ha bisogno il tuo team a di cosa ha bisogno il tuo agente. Lo stesso capovolgimento sta colpendo il lato delle entrate, dove una persona con una flotta di agenti ora gestisce la pipeline che un piano di persone gestiva, e il software post-vendita si sta rinominando da strumenti a servizi che possiedono i risultati, fidelizzazione come servizio oggi, espansione come servizio domani. E quando gli agenti del tuo cliente inizieranno a negoziare con i tuoi agenti, gli umani rimasti su entrambi i lati del tavolo faranno le due cose che i loop non possono chiudere da soli: decidere cosa vale la pena volere e certificare che sia effettivamente accaduto.
Il pavimento cade. Le implementazioni che richiedevano cinque milioni di dollari di ingegneria d'élite pochi anni fa ora richiedono poche centinaia di migliaia e un generalista acuto con buoni agenti, e il prezzo sta ancora scendendo. Lo schieramento in prima linea smette di essere un lusso da Fortune 500 e diventa il modo in cui il software mid-market viene venduto. Il vincolo smette di essere la fornitura di ingegneria e diventa la fornitura di giudizio.
Il titolo si dissolve. Ogni ingegnere in un'azienda seria sta diventando parzialmente schierato in prima linea. Gli ingegneri backend partecipano alle chiamate con i clienti. Gli ingegneri di prodotto sviluppano in base alle trascrizioni delle chiamate. Presto, la percentuale di tempo trascorso di fronte al cliente sarà l'unica differenza tra un FDE e un ingegnere del software, e i titoli smetteranno di fingere il contrario. Il che porta con sé un avvertimento che nessuno stampa nelle offerte di lavoro. Questo lavoro converte i costruttori in diplomatici, e molti ingegneri brillanti hanno scelto di costruire proprio perché le stanze piene di estranei li svuotano. Rispetta l'introverso non schierandolo, e rispetta il ruolo non usandolo mai come il posto dove parcheggiare ingegneri che erano mediocri nell'ingegneria. È l'opposto. È dove mandi le persone a cui affideresti la fondazione di qualcosa.
Il lavoro più vecchio nell'azienda
Spoglia della terminologia e lo schieramento in prima linea è la postura originale del fondatore, mantenuta in vita all'interno di un'azienda che è cresciuta abbastanza da dimenticarla. Siediti dove è il lavoro. Chiudi il lavoro. Lascia che ciò che hai imparato cambi ciò che costruisci. Ogni azienda duratura ha fatto questo prima di dargli un nome. La maggior parte delle aziende smette di farlo il giorno in cui può permetterselo.
Quindi la vera domanda non è mai stata se assumere ingegneri schierati in prima linea. È se sei disposto a gestire un'azienda in cui le persone più vicine alla realtà hanno un potere reale, dove lo sforzo è giudicato dalla sua pendenza, e dove nulla di ciò che si impara sul campo è permesso morire lì. Costruisci quello, e il titolo si prenderà cura di sé.
Qual è l'ultimo pezzo di lavoro che il tuo team ha chiuso così completamente che il cliente ha smesso di pensarci? Quando è stata l'ultima volta che un cliente ha rinnovato non perché ha ottenuto il valore dalla tua suite di prodotti, ma perché sa che costruirai cose di cui non sapevano nemmeno di aver bisogno per far crescere la loro attività? Inizia a contare da lì.
