Hace poco más de un año, pasé una hora en una llamada con alguien que ha estado haciendo despliegue avanzado (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 despliegue avanzado. Aún siento que ningún contenido le hace justicia a todo lo que implica el despliegue avanzado.
Cuando hablé con mi amigo, le pregunté cómo funciona realmente el famoso proceso de descubrimiento. La respuesta fue casi vergonzosamente física, al menos al principio, cuando solo miras las cosas en la superficie. Vuelas. Pasas dos días reuniéndote con todos los que tocan el problema. El gerente de ERP te da una clase teórica sobre órdenes de compra. Luego te llevan al piso 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 la mayor cantidad de 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. Sin embargo, los buenos motores de despliegue avanzado 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 para construir cosas e iterar con los clientes. El primer flujo de trabajo es el objetivo inmediato. Las ontologías se utilizan como una forma de extender esa herramienta a un sistema operativo gradualmente. Donde realmente brillan los buenos motores de despliegue avanzado es en el hecho de que gran parte del contexto proviene del equipo, de los expertos en la materia, y de alguna manera lo unen todo 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 que algunos motores se acumulan y otros no.
Inmediatamente tuve dos pensamientos. Probablemente los tengas si no has prestado atención a lo que es un buen despliegue avanzado, así que te insto a seguir leyendo.
Mi primer pensamiento fue: ¿qué sucede 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 una vez construyó un motor de enrutamiento para una empresa de logística que tenía despachadores asignando 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 posibles permutaciones de asignación y luego usaron esa visibilidad para comparar las decisiones humanas con los resultados simulados. Esta fue la primera vez que alguien mapeó 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 hoy la adición de agentes todo el proceso 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 en la capa de conocimiento tribal, pero eso es solo parte del rompecabezas. Dijo que la salsa secreta en su modelo de despliegue avanzado (FDE) cuando se trata de estos pilotos no es nada digno de Einstein. En algunos casos, incluso ahora, mientras hacen pilotos, simplemente están escuchando los pasos y resultados, mapeando verbos y dándole al cliente un equipo de cinco personas para que sean sus ingenieros dedicados. Estos ingenieros codifican todo y luego pueden simplemente 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 simple retroalimentación directa del usuario y, en cambio, extraer contexto histórico y operativo, cosas como correos electrónicos, cambios en los procesos de ventas, cambios de estado en sistemas como Salesforce y otros rastros de cómo ha funcionado la organización 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 actualmente de forma manual.
Tengo algunos párrafos de la transcripción de mi llamada con él.
Entonces, la forma en que empezamos es que siempre nos enfocamos en la velocidad para generar valor. No siempre seguimos un enfoque procesal como, de acuerdo, primero hagamos la ontología. Luego, construyamos 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 brindarte ahora mismo? Explícanos el problema en tu negocio y ahora el problema que crees que podemos resolver.
Una vez que el cliente comparte, vamos al tablero de dibujo y decimos, okay, vamos a hacer una versión uno de la ontología, construir una versión uno de la aplicación también en aproximadamente una semana y probémosla. Entonces es muy similar a, ya sabes, cómo construirías una startup. A menudo descubrimos 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, tratamos de sintonizar con cuál es el problema más grande que necesitan resolver.
Construiremos algo para eso rápidamente y crearemos cinco objetos en términos de la ontología. Si estamos haciendo algo relacionado, digamos, con 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 ad hoc de media hora durante la semana. Y luego, una vez que nos hemos probado allí, buscamos ese segundo, tercer, cuarto caso de uso hasta el punto de que podamos construir un sistema operativo empresarial para toda su empresa.
Generalmente hacemos esto en forma de una visita in situ. Simplemente volamos, decimos okay, danos dos días. Nos reunimos con las partes interesadas, todos los que puedan estar juntos o de lo contrario 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á sucediendo y no tratamos de condensar el tiempo con el cliente. De hecho, seguimos profundizando más 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 cuando se trata del 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 aportes 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 realmente toman decisiones. 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, eventualmente, codificar el soporte para la toma de decisiones dentro del propio producto.
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 despliegue avanzado puedan entrar en entornos desconocidos, aprender rápidamente y construir credibilidad produciendo sistemas útiles rápidamente. Los compromisos tempranos a menudo comienzan con un breve campo de entrenamiento, apoyado 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 de manera tan efectiva que el equipo pueda eventualmente dar un paso atrás mientras el cliente continúa usando la solución.
Este es un manual altamente relevante para una nueva empresa que se está construyendo ahora. Esto es despliegue avanzado. Todo lo demás es quizás decoración.
La ley de la acumulación
El despliegue avanzado es caro, lento para aparecer en el margen bruto y difícil para una planificación ordenada. Los fundadores sienten esto y comienzan 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 señal de alerta para ciertas industrias si implica que el despliegue avanzado 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 despliegue avanzado, 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 como ingenieros. Añadirá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 proporciona soporte. Las personas que no tienen claro lo que están construyendo casi siempre terminan con resultados mediocres, y esta confusión particular se acumula en tu contra.
El despliegue avanzado solo tiene sentido si la matemática se dobla. Al despliegue uno se le permite ser feo, hecho a mano, económicamente indefendible. Su trabajo es enseñar. El despliegue dos debe ser más barato porque el despliegue uno dejó atrás una plantilla, una integración, un patrón documentado, una pieza de plataforma. Para el despliegue diez, la mayor parte de lo que el primer equipo hizo a mano debería suceder a través de la configuración, y los humanos deberían estar un nivel arriba, resolviendo problemas que no existían hace un año, incluso a los ojos del cliente. La distancia entre esos dos números en el mes 1 y el mes n es la acumulación, y esa curva es la cosa real que estás comprando cuando financias un equipo de despliegue avanzado. La acumulación es todo el punto. Llamarte a ti mismo de despliegue avanzado sin un motor que se acumule es simplemente estúpido.
Un ingeniero de software y un ingeniero de despliegue avanzado difieren principalmente en la cantidad de tiempo que un ingeniero de software pasa escribiendo código que mantiene cosas, soporta cosas o construye cosas en la hoja de ruta, en comparación con lo que el ingeniero de despliegue avanzado (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 los clientes.
La palabra que todos usan y casi nadie significa
La idea tiene un origen específico. Hace dos décadas, un fundador preguntó por qué los grandes restaurantes franceses son excelentes, y llegó al 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 y con razón. Pagaba tan bien que veinte años después todos quieren el nombre, pero no estoy seguro de cuántos entienden el trabajo.
En cierto modo, un equipo de despliegue avanzado 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 ayude a tu cliente a hacer crecer realmente su negocio. Este es otro ejemplo real de la conversación de 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 era el resumen. ¿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 para vehículos eléctricos 10 veces. Lo que el equipo de despliegue avanzado realmente hizo fue ir al sitio y aprender la operación desde múltiples niveles del negocio. Pasaron tiempo con el propietario del ERP para entender el sistema de registro, las órdenes de compra, las órdenes de trabajo, la oferta y la demanda. Luego fueron al piso de producción para ver cómo se producía realmente en la práctica. Al mismo tiempo, hablaron con 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 era construir una nueva línea de producción directamente, al menos no según lo dicho en la reunión. Era construir un gemelo digital de la operación y luego identificar dónde el software podí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 misma. Espero que esto explique lo que quiero decir cuando digo que los ex fundadores pueden ser excepcionales como personal de despliegue avanzado.
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 de un 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 lo que es el despliegue avanzado son peores. Ejecutar una red de expertos a través de cien entrevistas de dominio es investigación, pero eso no es despliegue avanzado. Cuando un capital privado consolida empresas y envía un equipo de transformación, es útil, a veces brillante, pero no necesariamente despliegue avanzado. Digo esto porque nadie en esos dos movimientos es dueño de lo que 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, no es un ticket resuelto. Es una pieza del trabajo del cliente, llevada todo el camino desde una preocupación constante 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 ella. Un equipo de despliegue avanzado comienza en ella, porque estar de acuerdo en que algo debería funcionar no es lo mismo que hacerlo funcionar. Si la persona tiene una cuota, estás viendo ventas. Si la persona todavía está en los registros del cliente tres meses después del lanzamiento, estás viendo despliegue avanzado. Una empresa que vende un producto de marketing enviará ingenieros de ventas para cerrar el trato e implementar y configurar cosas. Un verdadero equipo de despliegue avanzado (FDE) podría llegar a la conclusión de que ninguno de los flujos de trabajo que admite el producto ayudará al cliente en cuestión y que algo completamente nuevo impactará directamente en los ingresos o en los resultados, y luego construyen ese flujo de trabajo. Esto requiere ser un experto en la prueba de la mamá (lee el libro), entender que a los clientes no les importa tu función, sino cómo hacer mejores negocios, entender de lo que tu producto es capaz y enviar a un ritmo rápido para que puedas 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 despliegue avanzado es pararse 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 le enseñe a tu producto a cerrarla solo la próxima vez.
La segunda mitad de esa oración es donde casi todos fallan.
Por qué esto está de repente en todas partes
Durante setenta años, el software ayudó a las personas a hacer 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 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 el 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 se ejecuta a través de sistemas instalados antes de que nacieran tus ingenieros, mantenidos en los bordes por faxes y llamadas telefónicas. Nada de eso tiene una API. En los campos petroleros, alguien pone su oreja contra la plataforma para evaluar si el sonido indica algo que debería preocuparles. En el barco que transfiere calamares de la India a los Estados Unidos, con una parada en Londres, las tarifas y los precios se deciden basándose en corazonadas, datos climáticos limitados y lo que visualmente parece ser la calidad del stock. El conocimiento tribal es la capa de carga de toda empresa, 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 incrustar expertos dentro de los clientes. AWS puso mil millones detrás de la misma idea semanas antes. OpenAI y Anthropic cada una establecieron empresas de despliegue dedicadas con algunos de los inversores más grandes del mundo detrás de ellas. 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. Tomó 10 años de trabajo agresivo en los LLM para llegar a donde estamos. Podría tomar mucho más si tuviéramos que hacer que estos modelos tuvieran una comprensión del flujo de trabajo y el 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 cuestión de días, no de 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 realmente antes de que alguien lo automatice. Alguien tiene que decidir cuáles tres de las veinte escaladas importan, qué flujo de trabajo de quién es el verdadero cuello de botella, qué silencio de qué ejecutivo matará la adopción, y qué resultado justificaría todo el compromiso. Alguien tiene que ser bueno para leer cuándo un cliente está dudando y cuándo están diciendo cosas solo para ser educados. Alguien tiene que manejar la interfaz más delicada en la IA empresarial, la que existe 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 llegará a ser, a un precio que la relación pueda soportar, y se aseguran de que la posición nunca incumpla. 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. Acuerdos estancados porque el producto no se ejecutará en el mundo del cliente o escenarios donde el producto solo admite flujos de trabajo que existen dentro del producto significa que te falta el ingeniero. Ingenieros enviando funciones solicitadas y estando ocupados, pero los ingresos no aumentan tanto, o escenarios donde el equipo de despliegue avanzado (FDE) ha tenido 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 significa 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 despliegue avanzado es lo que todo fundador hace durante años antes de que el organigrama lo oculte, sentado dentro de los líos de los clientes, cerrando el trabajo con lo que tenga a mano, dejando que lo que aprenden redibuje el producto. El rol es la semana de un fundador en la tabla de capitalización 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 equipo de despliegue avanzado (FDE), debes prepararte con una sucesión planificada desde el primer día, porque es probable que los fundadores que construyan una década después hayan sido todos ingenieros de despliegue avanzado (FDE) en su vida pasada, que se está desarrollando hoy.
Cómo saber si realmente tienes uno
No puedes juzgar a un equipo de despliegue avanzado 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 enviando heroísmos. Cinco comprobaciones lo exponen.
#1 Esfuerzo por cliente. Un equipo que atendió a cinco clientes el año pasado y atiende a cinco este año no está acumulando 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 de la tubería del campo a la plataforma. Alguien tiene que ser pagado para buscar la repetición 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 silenciosamente se convierte en margen.
#5 El propio marcador del cliente. La actividad es teatro. Las cifras de uso pueden verse espectaculares mientras nada mejora aguas abajo. La única medición que sobrevive al contacto con un director financiero (CFO) es una evaluación que el cliente ayudó a escribir, calificando el trabajo contra sus resultados en sus datos, construida en la semana uno y rastreada abiertamente. Mantén una prueba humana al 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 (dashboard) jamás 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 despliegue avanzado no es un motor de aprendizaje, sino un encubridor. El producto no funciona del todo bien, por lo que se coloca un humano en cada brecha. Debido a que los humanos son heroicos, las brechas nunca llegan a la hoja de ruta. Debido a que las brechas nunca llegan a la hoja de ruta, el producto nunca mejora, y los humanos nunca pueden irse. Producto no siente presión porque el campo sigue absorbiendo. 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 la plantilla de campo exactamente tan rápido como los clientes y llamándolo despliegue avanzado. No lo es. Es la ausencia de un producto, facturado mensualmente. También es por lo que tantas personas talentosas en estos puestos sienten que están fallando. Fueron contratados para acumular y dotados de personal para encubrir.
Cómo se ve en cada etapa
Etapa temprana: no lo contrates. Sé tú quien lo hace. Los fundadores son el equipo de despliegue adelantado, 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 personas que te hagan más rápido para cerrar el trabajo, nunca personas que se interpongan entre tú y el cliente.
En la etapa de crecimiento, el despliegue adelantado es malinterpretado, porque desde afuera parece una desaceleración. 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 clasifica como costo de ingresos, aunque el trabajo se comporte como I+D, así que entre más 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, son barreras de protección que obligan a la investigación a dar frutos. Ponle tiempo límite a cada compromiso. Vincula cada uno a un solo resultado de negocio con nombre. Cosecha trimestralmente, es decir, cada trimestre algo que el equipo de 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 cuenta, éxito del cliente. Los líderes en esta etapa genuinamente no saben dónde ubicar un equipo de despliegue adelantado, 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 operaciones, y el equipo de despliegue adelantado existe solo donde no hay un manual. 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 tú sientes que puedes automatizar de manera única. 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 los manuales, que es como los manuales se mantienen vivos. La versión de Uber es ilustrativa. Emparejaron a sus ingenieros más fluidos en IA con expertos en dominio de finanzas, legal y soporte, le dieron a cada par dos semanas y exigieron que construyeran junto a la persona que es dueña del flujo de trabajo en lugar de presentarle. Dos días de seguimiento, un día de elegir el objetivo, en funcionamiento para el día diez. Dieciséis pods reconfiguraron dieciséis funciones en dos meses, y un informe que tomaba 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 solo se revelan a quienes están sentados dentro de ellos.
El mismo trabajo viste ropas diferentes en cada industria
En defensa y gobierno, la presencia es el producto. Autorizaciones de seguridad, redes desconectadas, salas que tu laptop no puede abandonar. En salud, el trabajo es arqueología de flujos de trabajo. El proceso real corre a través de sistemas de registro de veinte años de antigüedad, con faxes 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 normativo, 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 yéndose al modelo de otro. En manufactura y logística, la verdad vive en el piso de producción y las restricciones son físicas, por lo que el descubrimiento no puede ocurrir por videollamada 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 debe 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 dicta 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, todavía 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. 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 todos los clientes los hereden. Cuando sus ingenieros aprendieron, a través de docenas de despliegues, exactamente cuándo un agente debería dejar de reintentar y pasar al 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 tomó la ruta de los sistemas, auditó sus despliegues en busca de trabajo que no tenía razón para ser hecho a medida, redujo la ingeniería personalizada detrás de cada agente en un ochenta por ciento, y luego dijo lo que nadie dice en público: que la entrega, no el producto, se estaba convirtiendo en el foso. Ramp dota a su equipo de campo en gran medida con exfundadores, los apunta a todo el ciclo de vida del cliente, desde la primera llamada hasta el soporte a largo plazo, e inculca un hábito por encima de todos: 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 a expracticantes de derecho dentro de los bufetes de abogados, prueba de que la persona desplegada no tiene que ser ingeniera en absoluto, solo responsable. En finanzas, Rogo emplea a casi la mitad de la empresa con exbanqueros desplegados en las instituciones de las que provinieron, 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 asistente 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 coloca a constructores en barcos de la marina, Applied Intuition está dentro de la mayoría de los grandes fabricantes de automóviles del mundo, y Cursor (SpaceX) ejecuta un equipo de despliegue adelantado que conecta la herramienta que tus ingenieros ya aman con bancos y telecomunicaciones.
Diferentes formas, una misma física. El campo alimenta la fábrica, o no es despliegue adelantado.
El argumento más fuerte en contra, porque se lo merece
Existe 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 interno. 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 las especies es la misma que este artículo repite. 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 eso, porque son diferentes dentro de cada empresa. Alguien tiene que ir a buscarlos. La única pregunta que importa es si lo que traen se capitaliza en un activo o se evapora en facturas.
Hacia dónde va esto
Cuatro cambios ya están en marcha.
El contexto se convierte en el activo. Lo que un equipo de despliegue realmente construye en cada cliente es un modelo funcional de cómo opera esa empresa. La ontología, el gemelo digital, 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á quedando porque toda empresa va a necesitar uno. Más de lo que la gente cree puede ser iniciado antes de que alguien 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 escalamiento. 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 todo 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 modelo mañana, en 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, sé dueño del aprendizaje.
Los agentes se unen al equipo. El agente de despliegue adelantado 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 dirigir la fábrica que hace despliegues. Modelos de dotación de personal de la misma manera que los gerentes asignan personas. Escribiendo evaluaciones de la misma manera 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 son dueños de los resultados: retención como servicio hoy, expansión como servicio mañana. Y cuando los agentes de tus clientes empiecen a negociar con tus agentes, los humanos que queden en 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 suelo cae. Los despliegues que hace unos años requerían cinco millones de dólares de ingeniería de élite ahora toman unos pocos cientos de miles y un generalista astuto con buenos agentes, y el precio sigue cayendo. El despliegue adelantado deja de ser un lujo de Fortune 500 y se convierte en cómo se vende el software para el 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 despliegue adelantado. Los ingenieros de backend se sientan en llamadas con clientes. Los ingenieros de producto envían código basado 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 las ofertas 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 nunca usándolo como el lugar donde estacionas a los ingenieros que fueron mediocres en ingeniería. Es lo contrario. Es a donde envías a las personas en quienes confiarías para fundar algo.
El trabajo más antiguo de la empresa
Quita la terminología y el despliegue adelantado 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 verdadera pregunta nunca fue si contratar ingenieros de despliegue adelantado. 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 tenga permiso de 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í.
