Cloud Intelligence™
¿Qué es un Forward Deployed Engineer?
Un Forward Deployed Engineer (FDE) se integra en el entorno del cliente para construir, desplegar y mantener soluciones técnicas. Descubre qué hacen los FDE, en qué se diferencia el rol de un arquitecto de soluciones y cómo trabaja el equipo de FDE de DoiT.
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
About Josh Palmer
I'm Josh Palmer, Head of Content at DoiT, where I split my time across multiple business units including DoiT Cloud Intelligence, PerfectScale (Kubernetes cost optimization), and SELECT (Snowflake, Databricks, and BigQuery cost optimization). Before DoiT, I spent four and a half years at OnBoard building content for a board intelligence platform used by 6,000+ organizations, and before that, two years as Content Marketing Manager at Zylo, a SaaS management platform.
My personal pageTL;DR: Un Forward Deployed Engineer (FDE) es un ingeniero que se integra directamente en el entorno del cliente para construir, integrar y mantener una solución técnica, en lugar de entregar un documento de diseño y pasar a la siguiente cuenta. Los FDE se hacen cargo de todo el arco de un despliegue: descubrimiento, integración, depuración y soporte a largo plazo. DoiT opera una de las prácticas de FDE más grandes en cloud y FinOps, y pone a trabajar a arquitectos cloud senior junto a los equipos de ingeniería del cliente para resolver problemas de costos, confiabilidad y seguridad, en lugar de solo señalarlos.
La factura de la nube sigue subiendo, y el dashboard que tu equipo compró el año pasado solo suma una alerta más que nadie tiene tiempo de atender. Alguien todavía tiene que leer el trace, descubrir por qué un node pool de Kubernetes no se reduce y desplegar la solución antes de que llegue la próxima factura. Esa brecha entre "aquí está el problema" y "aquí está la solución, ya desplegada" es justamente la que viene a cerrar el rol de Forward Deployed Engineer.
¿Qué hace un Forward Deployed Engineer?
Un Forward Deployed Engineer trabaja integrado con clientes específicos, aplicando habilidades técnicas profundas en cualquier combinación de infraestructura, datos e integración que esos clientes necesiten. Un ingeniero de software típico se encarga de una funcionalidad del producto para muchos clientes. Un FDE invierte ese modelo: se encarga de un grupo reducido de clientes en muchas capacidades, y se mantiene lo suficientemente cerca de cada entorno como para entender su arquitectura, su contexto de negocio y sus restricciones.
Ese nivel de integración define el trabajo. Las responsabilidades de un FDE suelen abarcar todo el ciclo de vida de un despliegue, en lugar de una sola fase: descubrimiento de requisitos y definición del alcance técnico, integración e implementación de sistemas, despliegue y puesta en marcha, depuración continua a medida que el uso real revela casos límite, y capacitación para que el propio equipo del cliente pueda sostener el trabajo cuando el FDE pase a la siguiente prioridad. Un arquitecto de soluciones normalmente se retira cuando se aprueba el diseño. Un consultor normalmente se retira cuando se entrega el informe. Un FDE se queda hasta producción.
¿De dónde viene el título de Forward Deployed Engineer?
Palantir Technologies popularizó el término, usándolo para describir a ingenieros que despliegan software directamente dentro de entornos gubernamentales y empresariales donde la complejidad del dominio es demasiado alta como para resolverse a distancia. A medida que los proveedores de IA generativa y las empresas de infraestructura asumieron despliegues igual de complejos y de alto riesgo, el título se extendió por toda la industria. OpenAI ahora contrata directamente con el título de "Forward Deployed Engineer", mientras que otros proveedores de nube usan nombres distintos para roles comparables: Google Cloud lo llama "customer engineer" y Amazon Web Services usa "solutions architect". Las responsabilidades se superponen, pero la profundidad de la integración y la duración de la colaboración suelen variar según la empresa y el rol.
¿En qué se diferencia un Forward Deployed Engineer de un arquitecto de soluciones o un consultor?
Los tres roles ayudan al cliente a hacer que la tecnología funcione. La diferencia está en cuándo aparecen y cuánto tiempo se quedan.
| Rol | Cuándo participa | De qué se hace cargo | Cuándo se retira |
|---|---|---|---|
| Arquitecto de soluciones | Preventa y fase de diseño | Recomendaciones de arquitectura | Cuando se aprueba el diseño |
| Consultor | Un período de colaboración acotado | Un informe o roadmap | Cuando se entrega el informe |
| Forward Deployed Engineer | Todo el ciclo de vida del despliegue | La implementación y resultados medibles | Permanece integrado durante producción e iteración |
Esa última fila es la que suele generar confusión. Un FDE no es un técnico de soporte atendiendo una cola de tickets, ni un consultor que entrega una presentación de diapositivas. Trabaja dentro de la cuenta, codo a codo con los propios ingenieros del cliente, y sigue siendo responsable del resultado después de que la primera versión sale a producción.
¿Qué habilidades necesita un Forward Deployed Engineer?
El nivel técnico exigido es alto porque el trabajo abarca muchas disciplinas a la vez. La mayoría de los roles de FDE requieren experiencia práctica en producción con al menos una nube pública importante (AWS, Google Cloud o Azure), soltura con infraestructura como código (Terraform o CloudFormation) y dominio funcional de un lenguaje de propósito general como Python, Go o TypeScript. Las plataformas de contenedores, en particular Kubernetes, aparecen constantemente, y las herramientas de observabilidad importan tanto como la infraestructura misma: un FDE necesita sopesar el equilibrio entre costo, rendimiento y confiabilidad, no solo implementar una solución. A medida que los workloads de IA pasan a producción, la utilización de GPU, el control del costo de inferencia y el despliegue de modelos se han convertido en una parte estándar del conjunto de habilidades de un FDE, y no en un complemento especializado.
Las habilidades técnicas le abren la puerta a un FDE. Las habilidades blandas lo mantienen útil una vez dentro. Convertir un problema difuso como "nuestra factura de AWS volvió a dispararse" en un plan técnico concreto y acotado requiere práctica, igual que explicar ese plan a un responsable de finanzas al que no le importan los node pools y a un ingeniero al que sí. Los FDE también trabajan dentro de un equipo de cuenta ajeno, coordinándose con los gerentes de customer success y de cuenta, en lugar de ser los dueños directos de la relación con el cliente.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
¿Cómo funciona un equipo de Forward Deployed Engineers en la práctica? El modelo de FDE de DoiT
DoiT, una empresa multicloud de FinOps y operaciones en la nube, construyó una de las prácticas dedicadas de FDE más grandes del sector. El equipo comenzó como Customer Reliability Engineering (CRE) y pasó a llamarse Forward Deployed Engineering para reflejar cómo el mercado ya entendía el rol: ingenieros integrados con los clientes para entregar resultados integrales, no una mesa de soporte que cierra tickets. El cambio de nombre no modificó el trabajo de fondo, sino la manera de comunicarlo, porque "FDE" transmite una señal más clara tanto a los clientes como a los ingenieros que DoiT quería contratar.
DoiT posiciona la práctica directamente frente a la alternativa. Como lo expresan los propios materiales del equipo: "Ni una cola de tickets. Ni una presentación de consultoría." Los FDE de DoiT son arquitectos cloud senior, que trabajan en nueve zonas horarias, y colaboran mano a mano con los equipos de platform engineering y FinOps del cliente para implementar cambios en lugar de enviar alertas. La práctica se organiza en torno a seis disciplinas: optimización de IA y LLM, optimización de costos, respuesta a incidentes, ajuste de Kubernetes, soporte de migraciones, y confiabilidad y rendimiento. Cada FDE aporta además una especialización profunda, y se lo incorpora a un proyecto según lo que realmente necesita el stack del cliente.
Ejemplos de especialidades de los FDE en DoiT
- Rajan Bhave lidera los aceleradores de GenAI en EMEA, diseñando las arquitecturas de referencia de Bedrock y AgentCore que llevan a un cliente de la demo a un agente en producción.
- Sascha Heyer trabaja el lado de ML y LLM, construyendo pipelines de Vertex AI y flujos de despliegue de modelos.
- Eduardo Mota también cubre ML y LLM, enfocado en sistemas RAG sobre Bedrock y en llevar la IA generativa a producción.
- Chimbu Chinnadurai, conocido internamente como el "Kubernetes whisperer", se pasa el día logrando que los clústeres rebeldes de EMEA vuelvan a comportarse y averiguando por qué fallaron en primer lugar.
- Kate Gawron cubre el lado de las bases de datos, modernizando despliegues de Aurora, RDS y Snowflake.
Esos cinco son solo una muestra. La práctica de FDE de DoiT reúne a unos 200 ingenieros, así que la lista anterior es apenas la punta del iceberg, pero alcanza para mostrar el patrón: un proyecto con un cliente puede incorporar al especialista que realmente necesita, en lugar de un generalista adivinando sobre un stack desconocido.
Attribute by DoiT es un ejemplo concreto de cómo funciona esto en la práctica. La infraestructura compartida, como las GPU, los clústeres de Kubernetes y los servicios multi-tenant, tiende a ocultar quién está generando realmente un costo determinado, y Attribute usa telemetría eBPF para atribuir el gasto al equipo, workload, modelo, funcionalidad o cliente responsable. Lograrlo no es cuestión de una sola instalación. Los FDE de DoiT despliegan el recolector eBPF, validan que la telemetría coincida con las facturas de nube reales del cliente, diseñan un modelo de atribución que refleje cómo el negocio define sus equipos y tenants, y luego ayudan al propio equipo del cliente a conectar ese resultado con su flujo de trabajo de FinOps durante un onboarding definido de 90 días. Esa secuencia —descubrimiento, construcción, validación y capacitación continua— es el ciclo de vida de un FDE en miniatura.
¿Cuándo conviene incorporar a un Forward Deployed Engineer?
Hay algunas señales que suelen aparecer juntas cuando un Forward Deployed Engineer es la decisión correcta. La fatiga de alertas es una: un equipo tiene dashboards de sobra señalando problemas y nadie con el tiempo ni el contexto para resolverlos. Otra son los problemas de costos o confiabilidad que requieren cambios a nivel de código o de configuración, no otro informe. La infraestructura compartida o multi-tenant que mezcla muchos generadores de costos en una sola factura refuerza el caso, y los workloads de GenAI o LLM con un gasto impredecible y cambiante lo refuerzan aún más. Las migraciones a la nube también se benefician, porque el contexto se pierde cada vez que un proyecto cambia de manos entre equipos, y un ingeniero integrado que acompaña toda la migración cierra esa brecha.
Preguntas frecuentes
¿Forward Deployed Engineer es un cargo real o solo jerga interna? Es un cargo real y de cara al mercado. Palantir lo popularizó, y hoy lo usan empresas de infraestructura de IA como OpenAI y proveedores de nube y FinOps, incluido DoiT, para describir a ingenieros que se integran con los clientes en lugar de vender a distancia.
¿Cuál es la diferencia entre un FDE y un arquitecto de soluciones? Un arquitecto de soluciones normalmente asesora durante la preventa o la fase de diseño y se retira una vez aprobada la arquitectura. Un FDE permanece durante la implementación, el despliegue y la iteración continua, haciéndose responsable de los resultados y no solo de las recomendaciones.
¿Los Forward Deployed Engineers escriben código de producción? A menudo, sí. Según la empresa y el proyecto, los FDE suelen construir módulos de infraestructura como código, scripts de automatización y código de integración, y en algunas organizaciones contribuyen directamente al producto del propio proveedor bajo revisión estándar de ingeniería.
¿Qué habilidades se necesitan para convertirse en Forward Deployed Engineer? Experiencia práctica en producción con al menos un proveedor de nube importante, dominio de infraestructura como código, un lenguaje de programación de propósito general y sólidas habilidades de comunicación para traducir problemas de negocio en planes técnicos. Además de esa base amplia, suele requerirse profundidad en un dominio, como Kubernetes, plataformas de datos o ML/GenAI.
¿En qué se diferencia un FDE de un modelo tradicional de soporte o mesa de ayuda? Una mesa de soporte responde a los tickets a medida que llegan. Un Forward Deployed Engineer trabaja de forma proactiva dentro del entorno del cliente, identificando e implementando soluciones antes de que se conviertan en tickets, y haciéndose responsable del resultado en lugar de cerrar un caso.
Descubre cómo trabajan los Forward Deployed Engineers de DoiT dentro de un entorno de nube real: agenda una llamada de 15 minutos para mapear tus prioridades de CloudOps.
