¿Qué es un forward deployed engineer? Respuesta de primera mano
Un forward deployed engineer es un ingeniero de software que trabaja donde está el problema, no donde está el backlog. Me siento con las personas que tienen el problema, averiguo qué lo resolvería de verdad, lo construyo, lo despliego y me quedo hasta que funciona en producción. El título dice ingeniero y va en serio: lo que se entrega es software que funciona, no una presentación ni un documento de requisitos que otra persona tendrá que construir.
"Forward Deployed Engineer" es el título de mi página de inicio, de mi página Acerca de y de la pestaña de este sitio, y hasta ahora ninguna página aquí lo explicaba. Esta lo hace desde dentro: cómo es el trabajo semana a semana, en qué se diferencia el rol de los puestos con los que se confunde, qué habilidades exige y qué preguntar antes de contratar a uno.
TL;DR
- Un forward deployed engineer (FDE) se hace cargo del problema de un cliente de principio a fin: escucharlo, acotarlo, construir el software y desplegarlo.
- Frente a un ingeniero de software, la diferencia está en de dónde vienen los requisitos: un FDE los levanta de primera mano en lugar de recibirlos.
- Frente a un ingeniero de soluciones, la diferencia está en qué pasa después del sí: un FDE construye la solución en lugar de demostrar una.
- Frente a un consultor, la diferencia está en qué queda después: software desplegado que funciona y las especificaciones para cambiarlo.
- Antes de contratar a uno, pide ver algo que haya desplegado y siga manteniendo, y pregúntale cómo decide qué no construir.
Qué significa forward deployed engineer: de dónde viene el título
El título viene de Palantir, que enviaba ingenieros a trabajar dentro de las organizaciones de sus clientes en lugar de construir desde la sede central. Empresas de IA como OpenAI y Anthropic también contratan hoy para este rol, por la misma razón: un producto potente vale poco hasta que alguien lo hace funcionar con la realidad desordenada de un cliente concreto.
Quitando los nombres de empresas, el significado es sencillo. Forward es la posición: junto al cliente, lo bastante cerca para ver el problema en lugar de leer sobre él. Deployed es el compromiso: el trabajo no termina hasta que funciona en producción para quienes lo pidieron. Engineer es el oficio: quien ocupa esa posición escribe, prueba y despliega el código con sus propias manos.
Trabajo como forward deployed engineer independiente. No hay una plataforma detrás de mí que esté implantando; el "producto" es el software que el problema necesite, construido sobre un stack que conozco bien —Next.js, TypeScript y Tailwind CSS en el front end, AWS Amplify Gen 2 para autenticación, datos, funciones y hosting sobre AWS serverless— y con agentes de programación con IA sujetos a estándares de ingeniería.
Cómo es el trabajo, semana a semana
Cuando estoy en un proyecto, las semanas tienen una forma reconocible, aunque no haya dos problemas iguales.
La primera semana es sobre todo escuchar. Empieza con una llamada corta sobre el problema en sí: cuánto cuesta, a quién afecta y qué tendría que hacer una solución para contar como tal. Después voy a verlo. La hora más útil de cualquier proyecto es la que paso viendo a alguien hacer la tarea por el camino lento, porque el apaño que la gente ha montado dice más que cualquier descripción.
Luego escribo antes de programar. El problema se convierte en un pequeño conjunto de issues de GitHub, y cada issue en una especificación escrita: requisitos, luego un diseño, luego una lista de tareas, con una aprobación entre cada fase. Esa especificación es lo que acordamos. No se construye nada a partir de una conversación que ninguno de los dos pueda volver a leer.
Las semanas del medio son de construcción, a la vista. La implementación avanza contra esa lista de tareas en una rama de feature. Trabajo con Kiro y Claude Code como compañeros de programación agénticos, conectados a herramientas reales mediante MCP, de modo que el agente maneja un navegador de verdad para comprobar una funcionalidad en lugar de afirmar que funciona. Cada cambio llega primero a un entorno de staging, donde quien lo pidió puede recorrerlo y decirme qué está mal mientras todavía es barato arreglarlo.
El tramo final es el lanzamiento y la entrega. Cuando staging está bien, una promoción deliberada lo lleva a producción. Lo que entrego es el software desplegado, el repositorio y las especificaciones: el razonamiento detrás de cada decisión, para que la siguiente persona, o el siguiente agente, pueda cambiarlo con seguridad.
En todo el proceso, buena parte del trabajo es traducir en las dos direcciones: convertir "este informe se come todo el viernes de alguien" en requisitos que un ingeniero pueda probar, y convertir "el callback de autenticación necesita una URL por rama" en una frase sobre la que el dueño de un negocio pueda decidir.
De dónde salen los problemas
Los mejores problemas son los poco vistosos. Uno de los proyectos de mi portafolio, Perishable Shelf Stacking, salió de un trabajo que tuve: los reponedores trabajaban los perecederos con una lista de vida útil en papel, calculando a mano las fechas de las etiquetas y la ubicación en los estantes. La solución no tenía nada de ingeniosa —una ficha de producto con buscador, con la fecha de etiqueta ya calculada y la ubicación exacta en el estante— pero nadie la había construido, porque ningún minuto ahorrado parecía importante por sí solo. Ese es el tipo de problema de última milla para el que existe el trabajo forward deployed: nunca recibe presupuesto y, en silencio, le cuesta horas a un equipo cada semana.
Un ejemplo práctico: el ciclo que sigo en cada proyecto
La forma más clara de mostrar el rol es el propio ciclo, así que lo publiqué: cómo despliego software recorre cada paso, de un problema real a producción.
- Problema. Empieza como una queja, no como un ticket, en las palabras del propio negocio.
- Issue. El problema se convierte en issues de GitHub priorizados, lo bastante pequeños para terminarlos, visibles antes de que nadie abra un editor.
- Especificación. Kiro convierte cada issue en requisitos, diseño y tareas, y cada fase se aprueba antes de la siguiente.
- Construcción. Claude Code trabaja la lista de tareas: pruebas antes del código, estándares de diseño para todo lo visual, herramientas reales mediante MCP.
- Verificación. Lint, pruebas unitarias y un navegador real recorriendo la funcionalidad de punta a punta; el build de staging es el árbitro, nunca mi optimismo.
- Producción. Un pull request de promoción lleva staging a main, y AWS Amplify lo despliega.
Nada de esto es exótico, y esa es la idea. Un forward deployed engineer vale porque puede recorrer el ciclo completo solo, al lado del cliente, sin bajar la calidad en ningún paso.
Forward deployed engineer vs. ingeniero de software
Un ingeniero de software y un forward deployed engineer escriben el mismo código. La diferencia está en todo lo que lo rodea.
| Aspecto | Ingeniero de software | Forward deployed engineer |
|---|---|---|
| Requisitos | Llegan en un ticket, ya definidos | Se levantan de primera mano con quienes tienen el problema |
| Contacto con el cliente | Ocasional, a menudo a través de un product manager | Constante; el cliente es el principal colaborador |
| Alcance | Una parte de un sistema más grande | El problema completo, de principio a fin |
| Terminado significa | Integrado y con la revisión aprobada | Desplegado y resolviendo el problema |
En un equipo de producto, al ingeniero de software se le protege de la ambigüedad a propósito: product managers, diseñadores e investigadores dan forma al trabajo para que los ingenieros puedan concentrarse. Un forward deployed engineer es esa forma. Si el requisito está mal, es mi requisito, y lo descubro delante del cliente. Eso hace que el rol encaje mal con quien quiere meses de concentración profunda e ininterrumpida en un solo sistema, y muy bien con quien disfruta viendo su código en uso la misma semana en que se despliega.
Forward deployed engineer vs. ingeniero de soluciones
Esta es la comparación que más se confunde, porque los dos roles están junto al cliente.
Un ingeniero de soluciones (a menudo llamado ingeniero de preventa) trabaja antes de la venta. Entiende las necesidades del cliente, demuestra cómo un producto existente las cubre, responde objeciones técnicas y diseña cómo encajaría. Su éxito se mide en ventas cerradas e integraciones sin sobresaltos.
Un forward deployed engineer trabaja después del sí. La pregunta ya no es "¿puede esto funcionar para ustedes?", sino "hazlo funcionar para nosotros", y la respuesta es código que el día anterior no existía. Un ingeniero de soluciones te muestra un producto; un forward deployed engineer te construye una solución y sigue ahí cuando se enfrenta a datos reales.
Las habilidades se solapan —los dos tienen que hablar con personas no técnicas y entender un negocio rápido—, pero lo que se entrega es distinto, y también la responsabilidad.
Forward deployed engineer vs. consultor
Un consultor y un forward deployed engineer llegan los dos de fuera, aprenden un negocio rápido y se van. La diferencia está en lo que queda después.
Lo que entrega un consultor suele ser consejo: un diagnóstico, una recomendación, una hoja de ruta. Después alguien tiene que construirlo, y en el hueco entre la recomendación y el sistema funcionando es donde vive la mayor parte del valor y del riesgo.
Un forward deployed engineer cierra ese hueco en persona. Lo que queda es software desplegado, el repositorio y las especificaciones que explican por qué se construyó así. Esa última parte me importa: deberías poder cambiar lo que construí sin llamarme. Si un proyecto te deja dependiendo de mí para tocar tu propio código, lo hice mal.
Habilidades de un forward deployed engineer
Las habilidades se dividen en tres grupos, y el rol necesita los tres a la vez.
Amplitud técnica. Eres dueño de todo el stack porque no hay nadie más para hacerse cargo de la otra mitad. Para mí eso significa front end (React, Next.js, TypeScript, Tailwind CSS), backend y nube (AWS Amplify Gen 2: autenticación con Cognito, datos, funciones serverless, hosting), despliegue y pruebas, incluidas las pruebas de punta a punta en un navegador real.
Plantear bien el problema. La mayor parte del valor se decide antes del primer commit. Eso exige escuchar el problema que hay detrás de la petición, escribir requisitos con los que alguien pueda discrepar y acotar el alcance a algo que de verdad se pueda terminar: semanas, no un proyecto sin final. La habilidad más difícil y más valiosa es saber qué no construir.
Velocidad con disciplina, con IA. Los agentes de programación con IA permiten que una persona haga el trabajo de un equipo pequeño, y esa es buena parte de la razón por la que este rol funciona para un ingeniero independiente. Pero la velocidad sin disciplina solo produce errores más rápido. El desarrollo guiado por especificaciones —requisitos, diseño y tareas acordados antes del código—, las pruebas antes de la implementación, la revisión de código y un entorno de staging que tiene que dar el visto bueno antes de dar nada por terminado son lo que hace que el trabajo asistido por IA sea fiable, y no solo rápido.
Por debajo de los tres está la comunicación sencilla: explicar un compromiso técnico en una frase sobre la que el dueño de un negocio pueda decidir, y decir "esto no vale la pena construirlo" cuando es verdad.
Qué preguntar antes de contratar a un forward deployed engineer
Si eres fundador o responsable de un equipo y estás decidiendo si traer a uno, estas preguntas separan el rol de sus imitaciones:
- "Enséñame algo que hayas desplegado y que la gente siga usando." No una demo ni un prototipo: software desplegado con usuarios reales. Pregunta quién lo mantiene ahora.
- "¿Qué recibo al final además del software?" La respuesta debería incluir el repositorio y el razonamiento —especificaciones, decisiones, pruebas— para que tu equipo pueda cambiarlo.
- "¿Cómo decides qué no construir?" Quien nunca dice que no te construirá todo, y despacio.
- "¿Cómo voy a ver el avance antes de que esté terminado?" Busca un entorno de staging que puedas recorrer, no informes de estado.
- "¿Cómo usas la IA y qué impide que despliegue errores?" La respuesta correcta nombra los controles —pruebas, revisión, staging—, no las herramientas.
- "¿Qué te haría decirme que esto no encaja?" Un buen forward deployed engineer rechaza el trabajo demasiado grande para terminarlo o demasiado pequeño para que importe.
Si tienes un problema así
El trabajo que mejor hago empieza como una queja, no como un ticket: la herramienta interna, el traspaso por hoja de cálculo o el informe manual que nunca recibe presupuesto y, en silencio, le cuesta a tu equipo cada semana. Si tienes uno, cuéntamelo. Si puedo ayudar, te diré cómo lo abordaría. Si no puedo, también te lo diré.