Cómo convertirte en Forward Deployed Engineer: qué hace, qué sabe y un plan de 30 días

En resumen: Un Forward Deployed Engineer (FDE) trabaja dentro de la operación de un cliente y, con lo que aprende de su negocio, construye sistemas que operan en producción. Su trabajo tiene tres movimientos: entender cómo ocurre hoy el trabajo, decidir dónde entra la inteligencia y construir el sistema que une las dos cosas. En Puente OS este rol se llama Growth Ops. Para llegar a él, lleva un proceso real desde el levantamiento hasta producción: en 30 días terminas con un caso de estudio completo.

Hoy cualquier retailer de Santiago, Lima o Ciudad de México puede contratar la misma inteligencia artificial que su competencia, el mismo día. La diferencia entre dos empresas aparece después: en qué procesos entra esa inteligencia, con qué reglas y quién se hace cargo de ponerla a trabajar.

Esa persona es el Forward Deployed Engineer. En Puente OS, la plataforma que construye los sistemas que operan tu negocio, la llamamos Growth Ops, y es el centro de cómo trabajamos con empresas de retail, eCommerce y logística en Chile, Perú y México.

Soy Cris Ugarte, CEO y cofundador de Puente OS. Con Octavio Flores, mi socio, hicimos este trabajo en Walmart Chile antes de conocer su nombre: pasábamos el día copiando datos entre sistemas que no se hablaban, y construimos la primera versión de Puente OS como una herramienta interna para que ese trabajo corriera solo. Esta guía resume lo que aprendimos en el camino y cómo formamos hoy a las personas que hacen este trabajo.

¿Qué es un Forward Deployed Engineer?

Un Forward Deployed Engineer es un ingeniero que trabaja embebido en la operación de un cliente, con acceso a sus sistemas y a las personas que ejecutan el trabajo, y que responde por que la tecnología resuelva un problema real en producción. Mide su éxito en el negocio del cliente: horas recuperadas, errores evitados y volumen que el equipo absorbe.

El término viene de Palantir. En su blog de ingeniería, la empresa distingue dos roles: el ingeniero de producto, que construye una capacidad para muchos clientes, y el ingeniero desplegado en terreno, que toma un cliente y combina muchas capacidades para resolver su problema.

Con la llegada de los modelos de lenguaje, el título pasó a toda la industria de la IA. Los laboratorios que venden modelos y las startups que construyen sobre ellos contratan personas con este perfil para llevar la tecnología desde la demo hasta la operación diaria de sus clientes.

¿Por qué el Forward Deployed Engineer es uno de los roles más buscados?

El Forward Deployed Engineer es uno de los roles más buscados porque la inteligencia se abarató y la implementación pasó a ser el cuello de botella. El costo de usar un modelo con el nivel de GPT-3.5 cayó más de 280 veces entre noviembre de 2022 y octubre de 2024, y la mayoría de los proyectos de IA de las empresas se queda antes de llegar a producción.

Tres datos lo muestran:

• La inteligencia se abarató. El AI Index 2025 de Stanford midió que consultar un modelo con el rendimiento de GPT-3.5 pasó de US$20 a US$0,07 por millón de tokens en ese período.
• Los proyectos se quedan en el camino. Según S&P Global Market Intelligence, en 2025 el 42% de las empresas abandonó la mayoría de sus iniciativas de IA, contra 17% el año anterior, y en promedio descartaron el 46% de sus pruebas de concepto antes de producción. Las causas que citaron fueron costo, privacidad de datos y riesgos de seguridad.
• El mercado le puso precio al rol. En junio de 2025, Joe Schmidt, de a16z, llamó al FDE el trabajo más buscado de las startups. En abril de 2026, los avisos de trabajo para el rol crecieron más de 729% contra el año anterior, con un sueldo base promedio de US$171.911 al año en Estados Unidos, según datos de Indeed que publicó LeadDev.

La conclusión cabe en una línea: la inteligencia se compra y la ventaja se implementa. Lo que separa a una empresa de otra es dónde, cómo y para qué pone a trabajar esa inteligencia, y quien toma esas decisiones es el Forward Deployed Engineer.

¿Qué hace un Forward Deployed Engineer en el día a día?

Un Forward Deployed Engineer hace tres cosas, en orden. Primero, entiende cómo ocurre hoy el trabajo, con sus herramientas, personas y excepciones. Después, decide qué parte del proceso corre con reglas, cuál necesita un modelo de IA y cuál queda en manos de una persona. Por último, construye el sistema, lo pone en producción y responde por su funcionamiento.

1. Entiende cómo se hace el trabajo de verdad

El procedimiento escrito describe la versión oficial del proceso. La operación real vive en las pantallas, las planillas y los chats de quienes lo ejecutan, y ahí está la complejidad que hay que resolver.

Un ejemplo ilustrativo, armado con patrones que vemos seguido en eCommerce: la conciliación de pagos de marketplaces. El procedimiento dice "se descarga la liquidación y se cruza con las ventas". Cuando te sientas al lado de quien lo hace, aparece el proceso real:

• Cada marketplace liquida con su propio formato y su propio calendario, y uno de ellos cambió las columnas del reporte hace dos meses.
• La comisión depende de la categoría del producto, y las devoluciones parciales aparecen en liquidaciones de semanas después.
• Las ventas revisadas se marcan en colores en el Excel madre, y ese archivo es el registro que consulta todo el equipo.
• Cuando un monto no cuadra, se resuelve por WhatsApp con alguien de finanzas, y la regla aplicada queda en la cabeza de esa persona.

En Puente OS, el levantamiento parte con dos preguntas: "Muéstrame cómo haces esto, paso a paso" y "¿Qué pasa con los casos excepcionales?". La primera revela el proceso real. La segunda, la complejidad que el procedimiento esconde. Ese levantamiento es la mitad del trabajo, y lo hace una persona sentada junto a quien ejecuta el proceso.

2. Decide dónde entra la inteligencia

Cada paso del proceso recibe la pieza que le corresponde:

• Una regla, cuando las entradas y el criterio son predecibles: cruzar un pago con una venta por monto y fecha, asignar un courier por zona y costo.
• Un agente de IA, cuando el objetivo está claro y la entrada varía: leer el correo de un cliente, interpretar un PDF, clasificar un reclamo.
• Una persona, cuando la decisión carga ambigüedad, responsabilidad o consecuencias difíciles de revertir: aprobar un descuento fuera de política, resolver una diferencia grande con un proveedor.

En la conciliación del ejemplo, la descarga y el cruce por monto y fecha corren como un workflow con reglas. Un agente lee los correos del marketplace que explican un ajuste y propone a qué venta corresponde. La persona de finanzas decide las diferencias que superan la tolerancia, desde una pantalla que le muestra las ventas candidatas.

Casi todo lo que opera una empresa es predecible y lo resuelven un flujo y una regla de negocio. El modelo de IA entra donde hay que interpretar. En Puente OS esto se construye con cuatro piezas: workflows para lo repetible, agentes para interpretar, apps para que el equipo decida y bases de datos para el contexto. Es la disciplina que llamamos Diseño Autónomo.

3. Construye el sistema que une los dos mundos

El Forward Deployed Engineer construye sobre los sistemas que el cliente ya tiene: su ERP, su eCommerce, sus marketplaces y sus couriers siguen en su lugar. El sistema lee de ellos, cruza la información, ejecuta lo claro y escribe de vuelta cada acción donde corresponde, con registro y vuelta atrás. Es lo que llamamos un system of action.

Desde la salida a vivo, la operación depende de ese sistema para despachar, cobrar o responder. Por eso el FDE se queda después de salir a producción: mide, corrige y responde por el resultado.

¿Qué habilidades necesita un Forward Deployed Engineer?

Un Forward Deployed Engineer combina criterio de negocio, para saber qué problema vale la pena resolver y cómo se mide su valor, con criterio técnico, para construir un sistema que funcione con los datos y los sistemas reales del cliente. Su valor aparece cuando las dos mitades trabajan sobre el mismo proceso.

Criterio de negocio

• Cómo gana y pierde plata la operación: margen por producto, costo por orden, promesa de entrega.
• Quién decide, quién ejecuta y qué incentivos tiene cada uno.
• Qué riesgo carga cada decisión y cuál se puede deshacer.
• Cómo adopta un equipo una herramienta nueva, y qué lo hace volver al Excel.
• Cómo se cuenta el valor: horas, errores, costo y volumen.

Criterio técnico

• Cómo guardan la información un ERP, un eCommerce, un marketplace y un courier.
• Las vías por las que se conectan los sistemas: APIs, webhooks, archivos por FTP y reportes exportados.
• Los datos de una operación: qué es una orden, una línea, un despacho, un pago.
• Cuándo sirve un modelo de lenguaje y cuándo basta una regla.
• Cómo se prueba un sistema, cómo falla y cómo se recupera.

Las personas que mejor hacen este trabajo vienen de operaciones, consultoría, producto o ingeniería, y aprenden en terreno la mitad que les falta.

En Puente OS, la mitad técnica tiene otro peso. El Growth Ops construye con Puente Studio: describe en lenguaje natural lo que el proceso necesita y obtiene apps, workflows, bases de datos y agentes corriendo. Por eso el rol se abre a quien viene de operaciones y entiende el negocio desde adentro. Y por eso una sola persona sostiene la operación de software de un cliente completo: en un vendedor multicanal mexicano de electrónica, una persona construyó 20 apps y 75 procesos en diez meses.

¿Cómo trabaja un Growth Ops en Puente OS?

Un Growth Ops trabaja en tres fases: el Diagnóstico levanta y prioriza los procesos, el Sprint deja uno corriendo en producción en 2 a 4 semanas y el Partnership lo opera, lo mide y suma el siguiente. Cada fase parte con lo que dejó la anterior. Con clientes nuevos, el Diagnóstico y el primer Sprint caben en un piloto de un mes.

Diagnóstico: encontrar el proceso que vale la pena rediseñar

El Diagnóstico decide qué se construye antes de construir. El Growth Ops se sienta con quienes ejecutan cada proceso y anota cada paso: herramienta, tiempo, persona y frecuencia. Después escribe, para cada proceso, cuatro cosas: su disparador, la información que cruza, las reglas de lo claro y el dueño de cada excepción.

Luego lo clasifica con nuestra taxonomía de procesos, I/T/O/C/BP: de dónde vienen los datos (input), qué se hace con ellos (transformación), cómo se entrega el resultado (output), qué integraciones pide y a qué tipo de proceso de negocio corresponde, entre diez: órdenes, pricing, comunicación con clientes, catálogo, finanzas, ventas, marketing, logística, inventario e inteligencia operacional. La armamos a partir de más de 200 reuniones con empresas de comercio, y muestra que la mayoría de los procesos son variaciones de los mismos patrones. Así, cada Diagnóstico parte de lo que ya vimos en empresas parecidas.

El entregable es un mapa priorizado: los procesos clasificados, su impacto medido en horas y transacciones, y el primer proceso que va al Sprint. Conviene partir por uno con volumen, repetición, horas del equipo encima y un retorno visible en menos de 90 días.

Un consejo que nos ahorró semanas: pide los accesos de producción en la primera semana. El ambiente de prueba de un proveedor se comporta distinto al de producción, y descubrirlo el día de salir a vivo cuesta caro.

Sprint: construir, probar y poner en producción

En el Sprint, el Growth Ops construye el proceso sobre los sistemas del cliente y lo deja vivo en producción en 2 a 4 semanas. Antes de confiar en él, lo prueba con casos reales: los típicos, los raros, los que llegan con datos incompletos o contradictorios y los que tocan mucha plata o a un cliente importante. La respuesta correcta de cada caso la escribe quien más sabe del proceso, y cada resultado queda registrado.

El Sprint también define las reglas de operación: qué va siempre a una persona, qué pasa cuando falta un dato y qué pasa cuando un sistema no responde.

La primera versión sale con una persona aprobando. Lo aprendimos en una operación logística: cuando el sistema toma la decisión desde el primer día, el equipo desconfía y vuelve al Excel. Cuando el sistema propone y el coordinador aprueba, rechaza o comenta, la confianza se construye con evidencia, caso a caso.

Partnership: operar, medir y sumar el siguiente

Con el proceso en producción, el Growth Ops lo opera junto al equipo del cliente. Cada acción queda registrada, se ejecuta dentro de las reglas y aprobaciones de la empresa y tiene vuelta atrás a la versión anterior. Los cambios de regla pasan por la aprobación del equipo antes de entrar a producción.

La medición central es la tasa de intervención humana: qué porcentaje de los casos necesitó que una persona hiciera algo. La autonomía crece con esa evidencia: cuando un tipo de caso acumula semanas sin correcciones, el sistema pasa a resolverlo solo.

El resultado se ve en la operación. En el vendedor multicanal mexicano, generar las guías de despacho tomaba de 5 a 7 horas por corte, dos veces al día. Hoy un corte toma 15 minutos, y el 97,9% de las órdenes sale con su guía sin intervención humana.

Cada proceso resuelto deja a la vista el siguiente cuello de botella, y lo ya construido acelera el próximo. En un retailer pet chileno, el tiempo entre pedir un caso y verlo en producción bajó de 105 días en el primero a 7 en uno de julio de 2026. Así una operación puede crecer 2 a 5 veces sin multiplicar el headcount.

¿Cómo convertirte en Forward Deployed Engineer en 30 días?

Para convertirte en Forward Deployed Engineer en 30 días, lleva un proceso real de punta a punta en cuatro semanas: levántalo, construye la primera versión, pruébala con casos reales y ponla en producción con controles. Cada semana deja un entregable, y al día 30 tienes un caso de estudio que demuestra que puedes hacer el trabajo.

Elige un proceso de verdad: el de tu empresa, el de un negocio cercano o el de un cliente. El plan corre en paralelo con tu trabajo o tu búsqueda, y funciona con la herramienta que tengas a mano. En Puente OS lo hacemos con Puente Studio.

Semana 1 (días 1 a 7): levanta un proceso real

1. Elige un proceso con volumen, repetición y horas encima: generar guías, conciliar pagos, sincronizar stock entre canales o responder "¿dónde está mi pedido?".
2. Siéntate con quien lo ejecuta y pídele que te lo muestre paso a paso, en su pantalla.
3. Anota cada paso: herramienta, tiempo, persona y frecuencia.
4. Escribe el diseño actual: el disparador, la información que cruza, las reglas de lo claro y las excepciones.
5. Mide una semana: cuántos casos, cuántas horas y cuántos errores.

Entregable del día 7: el mapa del proceso actual y su costo en horas.

Semana 2 (días 8 a 14): diseña y construye la primera versión

1. Decide paso por paso qué corre con reglas, qué necesita un agente y qué queda en manos de una persona.
2. Conecta las fuentes de datos por la vía que ofrezca cada sistema: API, archivo o reporte exportado.
3. Construye el flujo de punta a punta sobre datos reales, en un ambiente de prueba.
4. Dale a la persona una pantalla para decidir las excepciones, con el contexto a la vista.
5. Registra cada acción: qué entró, qué decidió el sistema, qué hizo y cuándo.

Entregable del día 14: un flujo que corre de punta a punta y deja registro de cada paso.

Semana 3 (días 15 a 21): pruébalo y mídelo

1. Junta casos reales y escribe, con quien más sabe del proceso, la respuesta correcta de cada uno: casos típicos, casos raros, casos con datos incompletos o contradictorios y casos que tocan mucha plata o a un cliente importante.
2. Corre el sistema sobre esos casos y registra cada acierto y cada falla.
3. Agrupa las fallas por tipo: dato faltante, cruce con la venta equivocada, regla mal escrita, sistema caído.
4. Define las reglas de operación: qué escala siempre a una persona y qué pasa cuando un sistema no responde.
5. Mide el costo y el tiempo de cada ejecución.

Entregable del día 21: un reporte de evaluación con la tasa de acierto, los tipos de falla y el costo por ejecución.

Semana 4 (días 22 a 30): ponlo en producción y defiéndelo

1. Sal a producción con aprobación humana: el sistema propone y la persona aprueba cada acción.
2. Activa alertas y una vuelta atrás a la versión anterior.
3. Escribe el caso de negocio: horas recuperadas, errores evitados, costo, riesgo y qué queda en manos de personas.
4. Preséntalo a quien opera el proceso, con el detalle de cómo funciona, dónde falla y qué cambiaste en cada versión.
5. Preséntalo a quien lo aprueba o lo paga, en una página: problema, resultado, evidencia y riesgo.

Entregable del día 30: un caso de estudio completo, que pueden leer tanto quien opera el proceso como quien lo aprueba.

Dónde poner el foco según de dónde vienes

• Si vienes de operaciones o consultoría, ya tienes la mitad del negocio. Pon el foco en las semanas 2 y 3: aprende cómo guarda los datos cada sistema y cómo se prueba lo que construyes.
• Si vienes de ingeniería o producto, ya tienes la mitad técnica. Pon el foco en la semana 1: pasa horas con quien ejecuta el proceso y aprende cómo gana y pierde plata la operación.

¿Qué distingue a un buen Forward Deployed Engineer?

Un buen Forward Deployed Engineer se reconoce por sus hábitos: mide antes de construir, escribe las reglas con quien más sabe del proceso, pide los accesos de producción la primera semana, le da un dueño a cada excepción, suma autonomía con evidencia y cuenta el resultado en horas, errores y costo.

• Mide antes de construir. Una semana de medición le da al proyecto su línea base y su caso de negocio.
• Escribe las reglas con quien más sabe del proceso, en palabras que cualquier persona del equipo puede leer.
• Pide los accesos de producción la primera semana.
• Le da un dueño a cada excepción: la resuelve el sistema o llega a una persona con nombre y apellido.
• Suma autonomía con evidencia: sale con una primera versión acotada, con aprobación humana, y le da más autoridad al sistema a medida que acumula casos resueltos.
• Cuenta el resultado en el idioma del negocio: horas, errores, costo y volumen.

¿En qué se diferencia de un consultor, un solutions engineer o un ingeniero de producto?

Cada rol cubre una parte distinta del camino entre el problema y el sistema en producción. El consultor recomienda, el solutions engineer diseña la solución durante la venta, el ingeniero de producto construye capacidades para muchos clientes y el Forward Deployed Engineer construye para un cliente, pone el sistema en producción y responde por el resultado.

• Consultor: diagnostica y recomienda, y el equipo del cliente ejecuta.
• Solutions engineer: diseña la solución y la demo durante la venta.
• Ingeniero de producto: construye capacidades que usan muchos clientes.
• Forward Deployed Engineer: toma un cliente, construye el sistema sobre su operación, lo pone en producción y responde por el resultado.

En Puente OS, el Growth Ops cubre el camino completo: diagnostica, construye con Puente Studio, pone en producción y opera junto al equipo del cliente.

Puntos clave

• Un Forward Deployed Engineer trabaja dentro de la operación de un cliente y, con lo que aprende de su negocio, construye sistemas que operan en producción.
• El rol se volvió uno de los más buscados porque la inteligencia se abarató y la implementación pasó a ser el cuello de botella.
• El trabajo tiene tres movimientos: entender el proceso real, decidir dónde entra la inteligencia y construir el sistema sobre lo que ya existe.
• Pide dos criterios: el de negocio y el técnico. En Puente OS, el Growth Ops construye en lenguaje natural con Puente Studio, y el rol se abre a quien viene de operaciones.
• En Puente OS, el trabajo corre en tres fases: Diagnóstico, Sprint y Partnership, con un proceso en producción en 2 a 4 semanas.
• El plan de 30 días lleva un proceso real de punta a punta y termina en un caso de estudio completo.

---

¿Quieres ver este trabajo en tu operación? Partimos con un piloto de un mes: en ese mes corren el Diagnóstico y el primer Sprint, y tu primer proceso queda vivo en producción. Si decides seguir, lo invertido en el piloto se descuenta de la implementación. Agenda una demo con Puente OS.

¿Quieres hacer este trabajo? Si armaste tu caso de estudio con el plan de 30 días y quieres conversarlo, escríbeme a cugarte@getpuente.com.