Hace poco más de un año, pasé una hora en una llamada con alguien que ha trabajado en forward deployment durante una década en la empresa que inventó el término. En los últimos 12 meses, he colaborado de diversas formas con personas que están construyendo sus propios motores de forward deployment. Sigo sintiendo que ningún contenido le hace justicia a todo lo que implica el forward deployment.
Cuando hablé con mi amigo, le pregunté cómo funciona realmente el famoso proceso de descubrimiento. La respuesta fue casi embarazosamente física, al menos al principio, cuando solo miras las cosas a nivel superficial. Vuelas. Pasas dos días conociendo a todos los que tocan el problema. El gerente de ERP te da una clase teórica sobre órdenes de compra. Luego te llevan a la planta de producción para que veas lo que la teoría omite. Luego pasas tres semanas haciéndoles una pregunta al día mientras conectas los datos. Le pregunté si había una fórmula. Dijo que la fórmula es conseguir todo el tiempo posible con las personas que saben. Diez años después, esa parte nunca ha cambiado.
Sin embargo, esto puede ser engañoso si no profundizas. Sí, pasan mucho tiempo con los clientes. Pero los buenos motores de forward deployment construyen el modelo de antemano. Los grandes ingenieros de despliegue y estrategas de despliegue reconocen que no entenderán todo, pero son muy rápidos construyendo cosas e iterando con los clientes. El primer flujo de trabajo es el objetivo inmediato. Las ontologías se utilizan como una forma de extender esa herramienta gradualmente hacia un sistema operativo. Donde los buenos motores de forward deployment realmente brillan es en el hecho de que gran parte del contexto proviene del equipo, de los expertos en la materia, y ellos lo unifican en gran medida incluso antes de conocer al cliente por primera vez. Esa pieza ha mejorado con el tiempo y es la verdadera razón por la cual algunos motores se acumulan y otros no.
Inmediatamente tuve dos pensamientos. Probablemente tú también los tengas si no has prestado atención a lo que es un buen forward deployment, así que te insto a que sigas leyendo.
Mi primer pensamiento fue: ¿qué pasa cuando no tienes ni idea de los flujos de trabajo del cliente? Empezarías con muchas entrevistas, ¿verdad? Mi amigo dijo que no, porque a nadie le gusta que lo entrevisten, pero compartió una historia. Su equipo construyó una vez un motor de enrutamiento para una empresa de logística cuyos despachadores asignaban tickets diarios a conductores o rutas basándose en el juicio manual y mirando mapas, distancias, ubicación de vertederos y otras restricciones operativas. Mi amigo construyó una herramienta que daba recomendaciones a los despachadores, pero el primer problema fue que los despachadores a menudo rechazaban la recomendación basándose en la intuición y no podían explicar claramente por qué. Para manejar eso, su equipo tuvo que mostrar todas las diferentes permutaciones de asignación posibles y luego usaron esa visibilidad para comparar las decisiones humanas con los resultados simulados. Esta fue la primera vez que alguien mapeaba todas las permutaciones en una pantalla y, por lo tanto, fue la primera vez que la gente tuvo un momento para reflexionar si la decisión que estaban tomando basada en la intuición estaba respaldada por datos a escala. Permitió al equipo de la empresa de logística auditar el flujo de trabajo en sí, entender si la lógica del proceso era realmente correcta y refinar el gemelo digital para que coincidiera mejor con cómo operaba el negocio en la práctica. También disfrutaron el proceso porque nunca se sintió como una entrevista, sino que por primera vez les permitió ver todas las piezas del rompecabezas en un solo tablero.
Mi siguiente pensamiento fue: ¿cómo cambia la incorporación de agentes todo el proceso hoy en comparación con hace un par de años? La respuesta que dio mi amigo fue que simplemente implica que podemos desarrollar mucho más rápido usando agentes y tener más contexto a nivel de conocimiento tribal, pero eso es solo una parte del rompecabezas. Dijo que la salsa mágica en su modelo de FDE cuando se trata de estos pilotos no es nada digno de Einstein. En algunos casos, incluso ahora, mientras hacen pilotos, simplemente escuchan los pasos y resultados, mapean verbos y le dan al cliente un equipo de cinco personas para que sean sus ingenieros dedicados. Estos ingenieros codifican todo y luego pueden desaparecer y el cliente puede seguir usando la solución. Los agentes ayudan en el sentido de que aceleran y profundizan el proceso de codificación al facilitar la incorporación de más contexto y conocimiento tribal de los sistemas del cliente. Los agentes se han convertido en una forma de ir más allá de la retroalimentación directa del usuario y, en cambio, incorporar contexto histórico y operativo, como correos electrónicos, cambios en los procesos de ventas, cambios de estado en sistemas como Salesforce y otros rastros de cómo la organización ha trabajado a lo largo del tiempo. Eso facilita modelar los flujos de trabajo del cliente de una manera más rica, conectar fuentes de conocimiento fragmentadas y construir sistemas que no solo representen el negocio a través de un gemelo digital, sino que también ayuden a automatizar o respaldar las decisiones que las personas toman manualmente actualmente.
Tengo algunos párrafos de la transcripción de mi llamada con él.
Entonces, la forma en que empezamos es siempre centrándonos en la velocidad para generar valor. No siempre seguimos un enfoque procedural como "bien, primero hagamos la ontología, luego la aplicación encima, luego vayamos al usuario". No. En algunos aspectos lo seguimos, pero en otros, simplemente le preguntamos al cliente: ¿cuál es el mayor valor añadido que podemos construir para ti? o ¿cuál es el mayor impacto que podemos entregarte ahora mismo? Explícanos el problema en tu negocio y el problema que crees que podemos resolver.
Una vez que el cliente comparte, vamos a la pizarra y decimos: bien, armemos una versión uno de la ontología, construyamos una versión uno de la aplicación también en una semana y probémosla. Así que es muy parecido a cómo construirías una startup. A menudo encontramos que pueden tener una idea de un caso de uso, pero mientras hablan, descubrimos otro caso de uso potencial completamente diferente que podemos resolver. Y simplemente construiremos eso, aunque ellos pensaran que necesitaban otra cosa. Al final del día, intentamos sintonizar con cuál es el problema más grande que necesitan resolver.
Construiremos algo para eso rápidamente y crearemos cinco objetos en la ontología. Si estamos haciendo algo relacionado con, digamos, el sistema ERP, que puede ser bastante complejo, incluso después de hacer las integraciones, contactamos a ese experto en ERP un par de veces para una sesión tipo jam session de una hora o una reunión improvisada de media hora durante la semana. Y luego, una vez que nos hemos probado allí, buscamos el segundo, tercer y cuarto caso de uso hasta el punto de poder construir un sistema operativo empresarial para toda su empresa.
Normalmente hacemos esto en forma de visita in situ. Simplemente volamos, decimos: "dennos dos días". Nos reunimos con las partes interesadas, todos los que puedan estar juntos o uno a uno. En muchos casos, cuando la gente está ocupada, nos sentamos a su lado e intentamos entender su proceso de ventas o su tipo de interacción con el cliente. Intentamos entender desde su perspectiva lo que está pasando y no intentamos condensar el tiempo con el cliente. De hecho, seguimos profundizando en ello y es algo que nunca ha cambiado en 10 años. A veces, pasamos semanas enteras con los clientes. Nunca hemos intentado alejarnos de eso y hacer que nuestra plataforma sea completamente automatizada de alguna manera en lo que respecta al descubrimiento.
Una idea central en la discusión fue que la codificación ocurre a través de la iteración, no a través de documentación pesada. El equipo construye un "gemelo digital" de la empresa directamente en código, utilizando integraciones de datos, contexto operativo y la opinión de expertos en la materia para representar cómo funciona la organización en la práctica. Pero ese modelo de datos por sí solo no es suficiente. La capa más difícil y valiosa es la lógica de negocio: la comprensión de dónde importa la intervención, qué acciones deberían recomendarse y cómo los operadores experimentados toman decisiones reales. Todo esto no se trata solo de sacar a la superficie información, sino de ayudar a los usuarios a evaluar compensaciones, validar flujos de trabajo y, finalmente, codificar el soporte de decisiones en el producto mismo.
El resto de mi conversación profundizó en cómo este trabajo no depende de tener expertos en el dominio profundamente integrados desde el principio. La expectativa es que los ingenieros de forward deployment puedan entrar en entornos desconocidos, aprender rápidamente y generar credibilidad produciendo sistemas útiles rápidamente. Los compromisos iniciales a menudo comienzan con un bootcamp corto, respaldado por prototipos preconstruidos y datos de muestra, diseñados para demostrar valor rápidamente y ganarse el derecho a un despliegue más profundo. A partir de ahí, la relación puede expandirse de un solo caso de uso a un sistema operativo más amplio para el cliente, con el objetivo a largo plazo de codificar flujos de trabajo tan efectivamente que el equipo pueda eventualmente retirarse mientras el cliente sigue usando la solución.
Este es un manual altamente relevante para una nueva empresa que se está construyendo ahora. Esto es forward deployment. Todo lo demás es quizás decoración.
La ley de la capitalización
El forward deployment es caro, tarda en aparecer en el margen bruto y es difícil para una planificación ordenada. Los fundadores lo sienten y empiezan a preguntarse si el esfuerzo coincide con el desbloqueo. Eventualmente, algún líder lo dice en voz alta: "estamos poniendo el doble de esfuerzo y obteniendo el doble de resultado".
Esa frase es una bandera roja para ciertas industrias si implica que el forward deployment no es el modelo correcto. Entiendo la impaciencia de un fundador, habiendo sido uno yo mismo, pero hay una línea delgada entre la ingenuidad y la impaciencia. Para los negocios que funcionan mejor con un motor de forward deployment, cualquiera que haga esta cuenta en términos de multiplicación no ha entendido el trabajo. Si el doble de esfuerzo compra el doble de resultado, has contratado consultores y los has vestido de ingenieros. Agregarás cuerpos al mismo ritmo que los ingresos para siempre, tus márgenes nunca escaparán, y el nombre honesto para lo que construiste es una agencia de personal que envía código o brinda soporte. Las personas que no tienen claro lo que están construyendo casi siempre terminan con resultados mediocres, y esta confusión particular se capitaliza en tu contra.
El forward deployment solo tiene sentido si la ecuación se dobla. El primer despliegue puede ser feo, hecho a mano, económicamente indefendible. Su trabajo es enseñar. El segundo despliegue debe ser más barato porque el primero dejó atrás una plantilla, una integración, un patrón documentado, una pieza de plataforma. Para el décimo despliegue, la mayor parte de lo que el primer equipo hizo a mano debería hacerse a través de configuración, y los humanos deberían estar un nivel arriba, resolviendo problemas que no existían hace un año ni siquiera a los ojos del cliente. La distancia entre esos dos números en el mes 1 y el mes n es capitalización, y esa curva es lo que realmente estás comprando cuando financias un equipo de forward deployment. La capitalización es el punto central. Llamarte a ti mismo forward deployed sin un motor que se capitalice es simplemente estúpido.
Un ingeniero de software y un ingeniero de forward deployment se diferencian principalmente por la cantidad de tiempo que un SWE pasa escribiendo código que mantiene cosas, da soporte o construye cosas en la hoja de ruta, en comparación con lo que el FDE pasa descubriendo cosas que a menudo no están en la hoja de ruta pero que desbloquean valor para el cliente, desplegándolo y pasándolo al producto cuando el patrón comienza a repetirse entre clientes.
La palabra que todos usan y casi nadie entiende
La idea tiene un origen específico. Hace dos décadas, un fundador preguntó por qué los grandes restaurantes franceses son excelentes, y llegó a la conclusión: el camarero. En un gran restaurante, el camarero es parte de la cocina, así que cuando recomiendan algo, es la cocina la que habla. Palantir construyó la versión de ingeniería de eso y le dio al rol un nombre militar, porque sus clientes eran militares. El nombre le dio al trabajo de campo el estatus que merecía, con razón. Pagaba tan bien que veinte años después todos quieren el nombre, pero no estoy seguro de cuánta gente entiende el trabajo.
En cierto modo, un equipo de forward deployment tiene que hacer lo que un fundador tiene que hacer en la fase 0-1. A menudo estás descubriendo qué podrías enviar que no solo eleve una métrica de vanidad, sino que realmente ayude a tu cliente a hacer crecer su negocio. Este es otro ejemplo real de la conversación con mi amigo. Su equipo fue contratado por un fabricante de cargadores para vehículos eléctricos que quería aumentar la producción aproximadamente 10 veces. Ese fue el briefing. ¿Puedes adivinar el resultado? Porque definitivamente no fue una presentación de estrategia. El objetivo de la empresa era simple en la superficie: aumentar la producción de cargadores EV en 10x. Lo que el equipo de forward deployment realmente hizo fue ir al sitio y aprender la operación desde múltiples niveles del negocio. Pasaron tiempo con el dueño del ERP para entender el sistema de registro, órdenes de compra, órdenes de trabajo, suministro y demanda. Luego fueron a la planta de producción para ver cómo sucedía realmente la producción en la práctica. Al mismo tiempo, hablaron con los ejecutivos para entender la versión estratégica del problema, porque lo que los operadores de primera línea dicen que está mal o es urgente no siempre coincide perfectamente con lo que el liderazgo ve como la restricción que más importa. El trabajo, entonces, no fue construir una nueva línea de producción directamente, al menos no según lo que se dijo en la reunión. Fue construir un gemelo digital de la operación y luego identificar dónde el software podría intervenir en el flujo de trabajo, por ejemplo, en torno a problemas como la escasez de piezas críticas, el momento de las órdenes de compra, el stock de seguridad y otras decisiones operativas. El resultado descrito fue un sistema que podía detectar riesgos antes y recomendar acciones, en lugar de un cambio físico en la fabricación en sí. Espero que esto explique lo que quiero decir cuando digo que los ex fundadores pueden ser excepcionales en el forward deployment.
Mira debajo de la experiencia laboral actual (no las descripciones) y encontrarás ingenieros que escriben código de producción dentro de los sistemas del cliente y son dueños de lo que sucede después del lanzamiento, incluido el soporte. El resto son ingenieros de ventas con una mejor tarjeta de presentación, juzgados por la demo, más una cola de roles de automatización interna que tomaron prestada la palabra porque está de moda. Las confusiones adyacentes sobre qué es el forward deployment son peores. Ejecutar una red de expertos a través de cien entrevistas de dominio es investigación, pero eso no es forward deployment. Cuando un capital privado consolida empresas y envía un equipo de transformación, es útil, a veces brillante, pero no necesariamente forward deployment. Digo esto porque nadie en esos dos movimientos es dueño de lo que yo llamo cierre de trabajo.
El cierre de trabajo es la unidad en la que se denomina toda esta disciplina. No es una función enviada, ni un ticket resuelto. Es una parte del trabajo del cliente, llevada desde la preocupación persistente hasta algo en lo que nadie piensa más. La firma del contrato es la frontera entre las profesiones que se confunden aquí. Un ingeniero de ventas trabaja hasta ese punto. Un equipo de forward deployment comienza en ese punto, porque aceptar que algo debería funcionar no es lo mismo que funcione. Si la persona tiene una cuota de ventas, estás viendo ventas. Si la persona sigue en los registros del cliente tres meses después del lanzamiento, estás viendo forward deployment. Una empresa que vende un producto de marketing enviará ingenieros de ventas para cerrar el trato, desplegar y configurar cosas. Un verdadero FDE podría llegar a la conclusión de que ninguno de los flujos de trabajo que el producto soporta ayudará al cliente en cuestión y que algo completamente nuevo impactará directamente en los ingresos o en los resultados, y entonces construyen ese flujo de trabajo. Esto requiere ser un experto en la prueba de mamá (lee el libro), entender que a los clientes no les importa tu función, sino cómo pueden hacer mejor negocio, entender de qué es capaz tu producto y enviar a un ritmo rápido para poder iterar con el cliente en el flujo de trabajo en vivo.
Así que aquí está la definición que pondría en la pared. El forward deployment es estar en la distancia entre lo que enviaste y lo que el cliente necesitaba, cerrando esa distancia con tus propias manos, dentro de su mundo, de una manera que enseñe a tu producto a cerrarla solo la próxima vez.
La segunda mitad de esa frase es donde casi todo el mundo falla.
Por qué esto está de repente en todas partes
Durante setenta años, el software ayudó a las personas a hacer su trabajo. Ahora está empezando a hacer el trabajo. Eso cambia una suposición oculta. Una herramienta puede permitirse ser adoptada lentamente. Un trabajador no. En el momento en que vendes resultados en lugar de asientos, alguien tiene que hacer que el resultado se haga realidad dentro de una empresa que no se comporta en absoluto como tu entorno de demostración.
Los modelos dejaron de ser la restricción en algún momento de los últimos dos años. El despliegue se convirtió en la restricción. El estudio más citado sobre pilotos de IA empresarial encontró que aproximadamente diecinueve de cada veinte no producían un impacto medible en P&L, y la autopsia casi nunca es la calidad del modelo. Es software que nunca aprendió el flujo de trabajo. El proceso documentado tiene cuatro pasos. El real tiene nueve, y los cinco que faltan viven en la memoria de una mujer, en un rastreador personal que construyó hace años, y en un favor que intercambia con otra mujer en otro edificio. En industrias más antiguas, el trabajo pasa por sistemas instalados antes de que nacieran tus ingenieros, mantenidos en los bordes por máquinas de fax y llamadas telefónicas. Nada de eso tiene una API. En los campos petroleros, alguien pone su oído contra la plataforma para evaluar si el sonido indica algo que debería preocuparles. En el barco que transfiere calamares de la India a Estados Unidos, con una parada en Londres, las tarifas y los precios se deciden basándose en corazonadas, datos meteorológicos limitados y lo que visualmente parece ser la calidad del stock. El conocimiento tribal es la capa de carga de todas las empresas, y nadie ha enviado nunca un SDK para ello. El cementerio de plataformas industriales de la última década enseñó esta lección con miles de millones de dólares. Las transformaciones no mueren en la arquitectura. Mueren en la adopción.
El dinero se ha dado cuenta. Microsoft comprometió dos mil quinientos millones de dólares y seis mil personas para integrar expertos dentro de los clientes. AWS puso mil millones detrás de la misma idea semanas antes. OpenAI y Anthropic crearon cada una empresas de despliegue dedicadas con algunos de los inversores más grandes del mundo. Puedes llamar a esto moda. El capital a esta escala rara vez es un disfraz. Los laboratorios valoraron sus propios pipelines y descubrieron que el comprador nunca carecía de inteligencia. El comprador carecía de manos. El fracaso vive en la última milla, y la última milla es donde se cava el foso. Se necesitaron 10 años de trabajo agresivo en LLMs para llegar a donde estamos. Podría tomar mucho más si intentáramos que estos modelos tuvieran una comprensión del flujo de trabajo y del marco de toma de decisiones humanas.
Por qué necesitas a una persona de negocios en ese equipo
El ingeniero existe porque la brecha se cierra con código, en la infraestructura del cliente, contra los casos extremos del cliente, generalmente en cuestión de días. Lo que los usuarios describen por la mañana debería estar funcionando frente a ellos en días, no en trimestres. Esa velocidad es cómo se construye la confianza con personas que han visto programas de transformación de tres años producir una biblioteca de diapositivas.
La persona de negocios existe porque los problemas más difíciles en el despliegue no son técnicos, y pretender lo contrario es cómo fallan los equipos técnicos. Alguien tiene que descubrir cuál es el trabajo real antes de que alguien lo automatice. Alguien tiene que decidir cuáles de las veinte escalas importan, qué flujo de trabajo es el verdadero cuello de botella, qué silencio de un ejecutivo matará la adopción, y qué resultado justificaría todo el compromiso. Alguien tiene que ser bueno leyendo cuándo un cliente está dudando y cuándo está diciendo cosas solo por cortesía. Alguien tiene que manejar la interfaz más delicada en la IA empresarial, la que hay entre lo que tu producto hace hoy y lo que vendiste como inevitable dentro de seis meses. Pienso en el estratega de despliegue como la mesa de futuros de la empresa. Venden lo que el producto se convertirá, a un precio que la relación puede soportar, y se aseguran de que la posición nunca entre en default. Los acuerdos de alto riesgo se ganan en esa mesa, y se pierden sin ella.
Los modos de fallo te dicen qué rol te falta. Los acuerdos se estancan porque el producto no funciona en el mundo del cliente o los escenarios donde el producto solo soporta flujos de trabajo que existen dentro del producto significan que te falta el ingeniero. Los ingenieros envían funciones solicitadas y están ocupados, pero los ingresos no suben tanto, o escenarios donde el FDE ha estado en más de 100 llamadas pero los ingresos contratados siguen siendo un orden de magnitud más altos que los ingresos realizados, o silos de flujos de trabajo personalizados que no mejoran el sistema, significan que te falta el estratega.
En los mejores equipos, los dos roles se difuminan, y la difuminación es el punto. El ingeniero desarrolla instinto de negocio, el estratega aprende a leer un esquema, y lo que obtienes es lo más parecido a un fundador que una empresa puede contratar. El forward deployment es lo que todo fundador hace durante años antes de que el organigrama lo oculte: sentarse dentro de los líos de los clientes, cerrar el trabajo con lo que sea que tenga a mano, dejar que lo que aprenden redibuje el producto. El rol es la semana de un fundador en el cap table de otra persona. También es por qué estos equipos producen fundadores a un ritmo que avergüenza a las grandes tecnológicas. Si diriges un pod de FDE, debes prepararte con una sucesión planificada desde el día uno, porque es probable que los fundadores que construyan una década después hayan sido todos FDEs en su vida pasada, que se está desarrollando hoy.
Cómo saber si realmente tienes uno
No puedes juzgar a un equipo de forward deployment por una instantánea, porque en cualquier día dado, uno excelente y uno falso se ven idénticos: personas inteligentes volando a clientes y haciendo heroísmos. Cinco comprobaciones lo revelan.
#1 Esfuerzo por cliente. Un equipo que atendió a cinco clientes el año pasado y atiende a cinco este año no está capitalizando nada. Un equipo que ahora atiende a quince está alimentando un producto que absorbe lo que el campo aprende. Con cada cliente, internamente tu equipo debería desarrollar un experto en la materia.
#2 La novedad del trabajo. Si el cuarto despliegue repite el tercero, nadie es dueño del conducto del campo a la plataforma. Alguien tiene que ser pagado para cazar repeticiones entre cuentas, porque la repetición es la hoja de ruta escribiéndose sola.
#3 La forma del segundo despliegue en un segmento. Si el cliente diez te cuesta lo mismo que el cliente uno, no estás escalando un producto. Estás franquiciando un proyecto.
#4 La línea de reporte. Dentro de producto o ingeniería, el ciclo puede cerrarse. Dentro de un silo de ventas o servicios, el aprendizaje se va en informes de viaje que nadie lee, y el equipo se convierte silenciosamente en margen.
#5 El marcador del propio cliente. La actividad es teatro. Las cifras de uso pueden verse espectaculares mientras nada aguas abajo mejora. La única medición que sobrevive al contacto con un CFO es una evaluación que el cliente ayudó a escribir, que califica el trabajo según sus resultados en sus datos, construida en la semana uno y rastreada abiertamente. Mantén una prueba humana a su lado. Cuando algo se rompe en su negocio que no tiene nada que ver con tu producto, ¿eres la primera llamada? Cada panel de control que se haya construido es un intento de aproximarse a esa llamada telefónica.
Y cuidado con el patrón oscuro, porque está en todas partes ahora mismo. En algunas empresas, el equipo de forward deployment no es un motor de aprendizaje, sino un encubridor. El producto no funciona del todo, así que se estaciona un humano en cada brecha. Como los humanos son heroicos, las brechas nunca llegan a la hoja de ruta. Como las brechas nunca llegan a la hoja de ruta, el producto nunca mejora, y los humanos nunca pueden irse. El producto no siente presión porque el campo sigue absorbiéndolo. El campo no escribe nada porque está demasiado ocupado salvando cuentas. Las facturas siguen llegando porque el cliente, de hecho, está siendo atendido. La máquina está en equilibrio, y el equilibrio es el problema. Las empresas viven dentro de él durante años, aumentando el personal de campo exactamente al mismo ritmo que los clientes y llamándolo forward deployment. No lo es. Es la ausencia de un producto, facturada mensualmente. También es por lo que tantas personas talentosas en estos puestos sienten que están fallando. Fueron contratados para capitalizar y asignados para encubrir.
Cómo se ve en cada etapa
(Nota: El texto original termina con "## What it looks like at each stage" sin contenido adicional. Asumimos que es el final del artículo. Traducimos ese encabezado.)
Cómo se ve en cada etapa
Etapa temprana, no lo contrates. Sélo. Los fundadores son el equipo de despliegue directo, y lo peor que puedes hacer con tu escaso entendimiento es delegar su adquisición. Haz los viajes de dos días tú mismo. Siéntate con el despachador. Cuando finalmente contrates, contrata a personas que te hagan más rápido para cerrar el trabajo, nunca a personas que se interpongan entre tú y el cliente.
La etapa de crecimiento es donde el despliegue directo va a ser malinterpretado, porque desde fuera parece que estás frenando. Tu junta directiva ve a los ingenieros pasar semanas dentro de cuentas individuales mientras los competidores anuncian funciones semanalmente. La contabilidad lo empeora. El despliegue se sitúa en el costo de ingresos aunque el trabajo se comporte como I+D, así que cuanto mejor aprendes, peor te ves. Mantén ambas verdades sin mentir en ninguna dirección. En el libro mayor es costo. En estrategia es investigación. La resolución no es una historia, sino barreras que obligan a la investigación a rendir frutos. Pon un límite de tiempo a cada compromiso. Vincula cada uno a un único resultado de negocio con nombre. Cosecha trimestralmente, es decir, cada trimestre algo que el campo construyó a mano se convierte en algo que la plataforma hace sola. Lo productizaremos después es la frase que mata a las empresas en esta etapa, porque después no tiene dueño.
A escala, la pregunta cambia de forma. Tienes cientos de clientes que pagan millones, y ya empleas consultores de soluciones, equipos de implementación, servicios gestionados, ejecutivos de cuentas, éxito del cliente. Los líderes en esta etapa genuinamente no saben dónde se sienta un equipo de despliegue directo, así que se añade como un cuarto nivel de soporte y muere por el volumen de tickets. La respuesta es que cada función existente ejecuta un manual de juego, y el equipo de despliegue directo existe solo donde no hay ningún manual de juego. Las diez cuentas más ambiciosas. El nuevo vertical. El flujo de trabajo que toda la industria dice que no se puede automatizar pero que sientes que tú, de manera única, puedes automatizar. Reporta a producto, tiene el mandato de hacer que su propio trabajo sea innecesario, y entrega cada patrón resuelto a los equipos que ejecutan manuales de juego, que es cómo los manuales de juego se mantienen vivos. La versión de Uber de esto es instructiva. Emparejaron a sus ingenieros más fluidos en IA con expertos en el dominio de finanzas, legal y soporte, le dieron a cada par dos semanas, y exigieron construir junto a la persona que es dueña del flujo de trabajo en lugar de presentarle a ellos. Dos días de observación, un día para elegir el objetivo, en vivo para el día diez. Dieciséis pods recablearon dieciséis funciones en dos meses, y un informe que solía tomar dos días ahora toma diez minutos. La unidad de automatización nunca fue la tarea. Es el flujo de trabajo, y los flujos de trabajo se revelan solo a las personas que se sientan dentro de ellos.
El mismo trabajo usa ropa diferente en cada industria
En defensa y gobierno, la presencia es el producto. Autorizaciones de seguridad, redes desconectadas, salas de las que tu portátil no puede salir. En salud, el trabajo es arqueología del flujo de trabajo. El proceso real se ejecuta a través de sistemas de registro de veinte años de antigüedad, con máquinas de fax y árboles telefónicos que aún manejan las excepciones, cada instalación ejecutando su propia variante no escrita. Un equipo que asume un estándar de cualquier cosa pierde un año. En servicios financieros, el cliente está comprando juicio bajo cumplimiento, el entregable es a menudo una evaluación que un regulador podría leer, y la ansiedad más profunda no es la fuga de datos sino la fuga de juicio, los patrones de decisión de sus mejores personas entrando en el modelo de otra persona. En manufactura y logística, la verdad vive en el piso y las restricciones son físicas, por lo que el descubrimiento no puede ocurrir por video y los sistemas de registro son arcaicos, visiblemente complejos y a menudo desconectados de la nube. En negocios de consumo, el ciclo se ejecuta en días en lugar de trimestres, y la habilidad escasa es el gusto, saber cómo suena la marca y cuándo una máquina debería dejar de hablar. Y el territorio más nuevo es tu propia empresa. Los mismos pods, desplegados en tus propias funciones de finanzas, legal y soporte, porque la brecha entre lo que la IA puede hacer y lo que tu organización realmente hace es la misma brecha, a un edificio de distancia.
El terreno establece las tácticas, y las tácticas son negociables pero la secuencia no lo es. Siéntate con el trabajo, cierra el trabajo, alimenta el producto.
Quién es realmente bueno en esto
El inventor, Palantir aún ejecuta la versión más profunda, y el detalle que todos olvidan es que el modelo nació antes que el producto. Al principio no había nada que configurar, solo una apuesta de que si te sentabas dentro de instituciones rotas el tiempo suficiente, los productos se revelarían a sí mismos. Lo hicieron, y hoy la misma empresa ejecuta compromisos más cortos y más estandarizados, porque una vez que el producto existe, la capitalización es la religión.
La nueva generación es más fácil de leer en las empresas de agentes de servicio al cliente. Sierra ejecuta su función de campo como ingenieros de agentes, y el ciclo es deliberado. Resuélvelo para un cliente, difunde lo que funcionó dentro de la empresa, luego gradúa a los ganadores en la plataforma para que cada cliente los herede. Cuando sus ingenieros aprendieron, a través de docenas de despliegues, exactamente cuándo un agente debería dejar de reintentar y pasar el cliente a una persona, ese juicio se convirtió en un componente reutilizable. Luego construyeron Ghostwriter, un agente que hace la construcción, alimentado con transcripciones de llamadas, SOPs y fotos de pizarras, ejecutándose en una plataforma que rediseñaron para que un agente pudiera operarla directamente. Una apuesta por Sierra es, en gran parte, una apuesta a que sus equipos desplegados seguirán descubriendo flujos de trabajo que nadie más ha visto. Decagon fue por la ruta de los sistemas, auditó sus despliegues en busca de trabajo que no tenía razón para ser a medida, redujo la ingeniería personalizada detrás de cada agente en un ochenta por ciento, y luego dijo la parte en voz alta, que la entrega, no el producto, se estaba convirtiendo en el foso. Ramp dota a su equipo de campo fuertemente con exfundadores, los apunta a todo el ciclo de vida del cliente desde la primera llamada hasta el soporte a largo plazo, y perfora un hábito por encima de todo, cuestiona el requisito antes de construirlo, porque la solicitud declarada suele ser el síntoma, no la enfermedad.
Una vez que conoces la forma, la ves en cada vertical serio. Harvey incorpora expracticantes de derecho dentro de firmas de abogados, prueba de que la persona desplegada no tiene que ser un ingeniero en absoluto, solo responsable. En finanzas, Rogo dota a casi la mitad de la empresa con exbanqueros desplegados en las instituciones de las que vinieron, mientras que Hebbia envía ingenieros para construir la última milla dentro de los gestores de activos más grandes del mundo. Abridge está estableciendo pods de despliegue con sistemas hospitalarios, porque llevar un escriba de IA a doce mil médicos no es una instalación, es una campaña. HappyRobot se integra con corredores de carga, Gecko Robotics pone constructores en barcos de la armada, Applied Intuition se sienta dentro de la mayoría de los grandes fabricantes de automóviles del mundo, y Cursor (SpaceX) ejecuta un equipo de despliegue directo que conecta la herramienta que tus ingenieros ya aman en bancos y telecomunicaciones.
Diferentes formas, una física. El campo alimenta la fábrica, o no es despliegue directo.
El argumento más fuerte en contra, porque se lo merece
Hay un argumento de que toda esta profesión es una disculpa. Te vendieron una cocina que cocina sola, y llegó con un chef que ahora vive en tu casa, en tu nómina, con el margen del proveedor, sin fecha de salida. El discurso requiere que creas dos cosas a la vez: que la máquina es lo suficientemente brillante como para reemplazar tu cocina y lo suficientemente indefensa como para necesitar un cuidador residente. Si el producto necesita un humano residente, el producto no está terminado.
Tómate esto en serio, porque para muchos proveedores es simplemente cierto. La prueba que separa a las especies es la misma que este artículo sigue repitiendo. Si el humano en la brecha es permanente, la crítica gana, y estás alquilando un parche. Si el humano en la brecha está capitalizando, cerrando el trabajo de una manera que elimina la necesidad de sí mismo, la crítica muere en el segundo despliegue. Lo que pasa por alto es que la mayor parte del trabajo nunca fue terminar el producto. Es adquisición de contexto. Los cinco pasos no documentados, la intuición no dicha del despachador, el favor intercambiado entre edificios. Ningún producto terminado se enviará jamás con esos, porque son diferentes dentro de cada empresa. Alguien tiene que ir a buscarlos. La única pregunta que importa es si lo que recogen se capitaliza en un activo o se evapora en facturas.
A dónde va esto
Cuatro cambios ya están en marcha.
El contexto se convierte en el activo. Lo que un equipo desplegado realmente construye en cada cliente es un modelo funcional de cómo funciona esa empresa. La ontología, el gemelo, el mapa de quién decide qué y por qué. Los inversores han empezado a llamarlo el cerebro de la empresa, y el nombre se está pegando porque todas las empresas van a necesitar uno. Más de lo que la gente piensa se puede iniciar antes de que alguien se suba a un avión, porque los clientes filtran su propia verdad constantemente, en tickets de soporte, transcripciones de llamadas, correos electrónicos, hilos de escalación. Empieza ahí. Pero la capa más profunda, el conocimiento que la gente no puede verbalizar, todavía requiere presencia y espejos, herramientas que permitan a los internos auditar su propia intuición hasta que se convierta en lógica. Quien tenga ese mapa tiene la cuenta, lo que plantea la pregunta que cada CEO está a punto de hacer a cada proveedor de IA. Estoy alquilando la inteligencia, pero ¿quién es dueño del aprendizaje? Si un modelo compartido absorbe el juicio crediticio de cada prestamista en un mercado, el asegurador más agudo del grupo está entrenando a sus competidores y pagando por el privilegio. Hay una prueba que cualquier CFO puede ejecutar. Cambia de proveedor de modelos mañana, sobre el papel, y verifica si todo lo que le enseñaste al sistema se va con él. Espera que los contratos, los equipos y, eventualmente, las empresas se reorganicen en torno a una sola línea. Alquila la inteligencia, posee el aprendizaje.
Los agentes se unen al equipo. El agente de despliegue directo ya existe en formas tempranas. Agentes de incorporación que comprimen una tarde de trabajo de integración en minutos. Agentes de despliegue que leen sus propias transcripciones durante la noche y proponen mejoras a sus propias habilidades. Observa lo que eso hace al rol humano. Cada intervención manual deja de ser el trabajo y se convierte en una señal de entrenamiento, y el trabajo del equipo se invierte, de hacer despliegues a ejecutar la fábrica que hace despliegues. Modelos de dotación de personal de la manera en que los gerentes dotan de personal a las personas. Escribiendo evaluaciones de la manera en que los gerentes escriben reseñas. La inversión más profunda está en quién es el usuario. Los productos se están reconstruyendo para que los agentes puedan operarlos directamente, y la primera pregunta de descubrimiento en un cliente está cambiando silenciosamente de qué necesita tu equipo a qué necesita tu agente. El mismo cambio está afectando al lado de los ingresos, donde una persona con una flota de agentes ahora maneja el pipeline que solía manejar un piso de personas, y el software postventa se está renombrando de herramientas a servicios que poseen resultados, retención como servicio hoy, expansión como servicio mañana. Y cuando los agentes de tu cliente comiencen a negociar con tus agentes, los humanos que queden a ambos lados de la mesa estarán haciendo las dos cosas que los bucles no pueden cerrar solos: decidir qué vale la pena querer y certificar que realmente sucedió.
El piso cae. Los despliegues que hace unos años requerían cinco millones de dólares de ingeniería de élite ahora cuestan unos pocos cientos de miles y un generalista agudo con buenos agentes, y el precio sigue cayendo. El despliegue directo deja de ser un lujo de Fortune 500 y se convierte en cómo se vende el software de mercado medio. La restricción deja de ser la oferta de ingeniería y se convierte en la oferta de juicio.
El título se disuelve. Cada ingeniero en una empresa seria se está convirtiendo parcialmente en desplegado directo. Los ingenieros de backend se sientan en llamadas con clientes. Los ingenieros de producto envían basándose en transcripciones de llamadas. Pronto, el porcentaje de tiempo frente al cliente será la única diferencia entre un FDE y un ingeniero de software, y los títulos dejarán de fingir lo contrario. Lo que conlleva una advertencia que nadie imprime en la oferta de trabajo. Este trabajo convierte a los constructores en diplomáticos, y muchos ingenieros brillantes eligieron construir precisamente porque las habitaciones llenas de extraños los agotan. Respeta al introvertido no desplegándolo, y respeta el rol no usándolo nunca como el lugar donde estacionas a los ingenieros que fueron mediocres en ingeniería. Es lo contrario. Es donde envías a las personas en las que confiarías para fundar algo.
El trabajo más antiguo de la empresa
Quita la terminología y el despliegue directo es la postura original del fundador, mantenida viva dentro de una empresa que creció lo suficiente como para olvidarla. Siéntate donde está el trabajo. Cierra el trabajo. Deja que lo que aprendiste cambie lo que construyes. Toda empresa perdurable hizo esto antes de tener un nombre para ello. La mayoría de las empresas dejan de hacerlo el día que pueden permitírselo.
Así que la pregunta real nunca fue si contratar ingenieros de despliegue directo. Es si estás dispuesto a dirigir una empresa donde las personas más cercanas a la realidad tengan poder real, donde el esfuerzo se juzgue por su pendiente, y donde nada aprendido en el campo pueda morir allí. Construye eso, y el título se encarga solo.
¿Cuál es la última pieza de trabajo que tu equipo cerró tan completamente que el cliente dejó de pensar en ella? ¿Cuándo fue la última vez que un cliente renovó no porque obtuvo el valor de tu suite de productos, sino porque sabe que construirás cosas que ni siquiera sabían que necesitaban para hacer crecer su negocio? Empieza a contar desde ahí.
