Forward deployed engineer: por qué ya no basta con saber programar

El ingeniero más valioso ya no es el que más código escribe, sino el que sabe qué no construir.

LAURA SORIA
HR Manager Orbitant

La IA ha hecho que escribir código sea barato, pero lo que sigue siendo caro —y escaso— es saber qué construir, para quién y por qué. De esa escasez ha nacido un perfil que el sector ha empezado a llamar forward deployed engineer: alguien que no se queda esperando un ticket bien definido, sino que se mete dentro del problema del cliente, entiende el negocio casi tan bien como su propio código y decide con ese contexto en la mano. Esto no responde a una etiqueta de marketing, sino a una redefinición real de qué hace valioso a un ingeniero cuando generar código ya no es el cuello de botella.

Esa definición no puede quedarse en la teoría, y por eso, como HR Manager en Orbitant, mi trabajo es convertirla en algo que se pueda evaluar en una entrevista, escribir en una oferta de empleo y mantener durante los primeros meses de alguien en el equipo, no dejarla como una frase bonita para una publicación de LinkedIn sobre cultura de empresa.

De dónde viene el concepto de forward deployed engineer y por qué lo adoptamos

El término no lo hemos inventado nosotros: según recoge The Pragmatic Engineer, nace de cómo determinadas compañías de IA sitúan a sus ingenieros directamente dentro de las operaciones del cliente —empresas como Stripe, Databricks o Palantir llevan años con equipos dedicados a esto—, en lugar de mantenerlos detrás de un backlog y un product manager.

En España, según Manfred, el concepto ha empezado a aparecer con fuerza en el último año, y es un perfil del que llevamos tiempo hablando en distintas conversaciones del equipo, porque conecta de manera muy natural con algo que ya forma parte de nuestro ADN como compañía: la idea de que, en un mercado donde escribir código cuesta cada vez menos, el ingeniero que aporta valor no es el que ejecuta mejor un ticket, sino el que entiende por qué existe ese ticket.

De esas conversaciones se han ido consolidando cuatro rasgos que definen el perfil:

• Conocimiento de negocio real.
• Autonomía para decidir sin necesidad de escalar cada detalle.
• Capacidades genuinas de IA: no solo usarla para ir más rápido, sino saber cuándo confiar en ella y cuándo no.
• Bases sólidas de ingeniería y buenas prácticas asentadas.

Ningún rasgo sustituye a los otros tres: un ingeniero con mucho contexto de negocio pero sin fundamentos técnicos puede tomar decisiones acertadas que después construya mal, mientras que uno con fundamentos sólidos pero sin contexto de negocio puede construir bien algo que no había que construir.

Convertir estos cuatro rasgos en un criterio operativo, y no solo en una intención, es lo que explico a continuación, conectándolos con los tres pilares de Orbitant.

Los tres pilares que convertimos en criterio de contratación

Ingeniería, innovación y comprensión de negocio son los tres pilares sobre los que está construido Orbitant y, cuando diseñamos una vacante o preparamos una entrevista técnica, es en esos términos en los que conectamos cada uno de los rasgos anteriores:

• Ingeniería: buscamos y reforzamos una base de conocimiento técnico sólida y buenas prácticas asentadas, de las que dependen los equipos de ingeniería de alto rendimiento, y que permiten trabajar con código heredado sin perder calidad, incluso bajo presión; sin esta base, la IA no compensa, sino que amplifica cada atajo que ya se tomaba antes de tener un agente escribiendo código.
• Innovación: valoramos el uso real de la IA en el día a día por encima del discurso de entrevista, porque tener licencias de Claude no convierte a un equipo en AI-first; por eso preguntamos por herramientas concretas, por decisiones que se hayan tomado usando IA y qué se aprendió de ellas, y por resultados medibles en proyectos reales.
• Comprensión de negocio: buscamos la capacidad de preguntar el porqué antes que el cómo, ya que no basta con ejecutar bien lo que pide el cliente, sino que hay que entender si es realmente lo que necesita, incluso cuando eso implique cuestionar el propio encargo.

El cuarto rasgo —el empoderamiento— no es un pilar aparte, sino la consecuencia de mantener los tres anteriores a la vez: dar autonomía sin fundamentos sólidos es un riesgo para el proyecto, mientras que exigir fundamentos sin conceder autonomía es desperdiciar el talento, que acaba buscándola en otro sitio. Por eso no evaluamos los tres pilares por separado, sino si conviven en la misma persona al mismo tiempo.

Esto cambia las preguntas que hacemos en una entrevista. En lugar de preguntar qué tecnologías conoce alguien, preguntamos por qué decidió no usar IA para una tarea concreta en un momento dado, o por qué defendió una decisión técnica frente al cliente cuando no servía al resultado de negocio. Las respuestas a ese tipo de preguntas dicen mucho más sobre el criterio de una persona que cualquier lista de tecnologías en un currículum.

Cómo se traduce esto en una descripción de puesto real

En Orbitant, «forward deployed engineer» no es el título de un puesto, sino la forma de trabajar que buscamos en cualquier rol técnico hoy en día, y el ejemplo más concreto de cómo se traduce esto es la descripción que escribimos para un puesto de AI Engineer, donde no pedimos «experiencia con IA» en genérico, sino que pedimos, entre otras cosas, que la persona sea capaz de:

1. Llevar un proyecto de piloto a producción: definir qué evaluaciones importan, instrumentar trazabilidad, observabilidad (y buenas prácticas en general) y asegurarse de que lo que se despliega cumple el resultado de negocio acordado, no que «la demo funciona» en una pantalla compartida.
2. Diseñar arquitecturas de agentes multi-paso con gestión de estado, uso de harness y recuperación de errores, en lugar de encadenar prompts sueltos y confiar en que aguanten.
3. Construir evaluaciones offline y online con métricas y datasets reales, comparadas contra resultados de negocio y no contra la sensación subjetiva de que «funciona bien».
4. Cuestionar el por qué antes que el cómo: colaborar con perfiles de negocio para definir el resultado esperado antes de tocar la arquitectura, no después.

Estos puntos no se limitan a pedir seniority en el sentido tradicional: describen un perfil distinto, alguien cómodo moviéndose entre una conversación de negocio y una decisión de arquitectura en la misma tarde, que entienda que el trade-off entre coste, latencia y capacidad del modelo es una decisión de producto además de técnica, y que sepa defenderla delante del cliente sin necesitar el visto bueno de alguien más senior.

Por eso, en el filtro inicial no priorizamos a quien ha usado más herramientas de moda, sino a quien puede explicar por qué eligió una arquitectura de agentes frente a otra en un proyecto concreto, o por qué decidió no usar fine-tuning cuando parecía la opción obvia: esa respuesta no se prepara de memoria la noche antes.

Qué cambia en cómo evaluamos y acompañamos a este perfil

Adoptar este criterio en la contratación no sirve de mucho si no cambia también lo que pasa después de firmar el contrato: seguimos un plan de incorporación de 30-60-90 días, con formación y primeras tareas pequeñas en el primer mes, autonomía y primer proyecto propio entre el 30 y el 60, y responsabilidades y KPIs definidos, con revisión formal, entre el 60 y el 90.

La diferencia con un onboarding tradicional está en el acompañamiento. Desde el primer día, cada persona tiene asignado un buddy —no su manager ni un mentor técnico— durante sus primeros 90 días, con contacto diario la primera semana y encuentros semanales después; su función es transmitir la cultura de Orbitant y el contexto de negocio antes de que lleguen las herramientas, no al revés.

Esto también afecta a cómo evaluamos el desempeño más adelante, donde no medimos solo la velocidad de entrega, sino si la persona sigue haciendo preguntas de negocio seis meses después de haber entendido ya la arquitectura del proyecto, o si ha dejado de preguntar porque ya «sabe cómo va esto»; la segunda señal es la que nos preocupa, y la primera es la que buscamos reforzar en cada revisión de desempeño. Pero este acompañamiento resuelve la adaptación de una persona, no la del equipo entero, y esa es otra cuestión.

Por qué entrenamos al equipo para pensar en términos de negocio

La agilidad de un equipo no depende solo de sus procesos, sino de lo cerca que esté cada persona del negocio: cuanto menos dependa una decisión técnica de escalarla a alguien de producto, más rápido se mueve el equipo entero, y ese acercamiento no ocurre solo, hay que entrenarlo.

Por eso llevamos doce semanas con un programa interno de formación en producto con ejercicios prácticos en cada sesión, no solo teoría: la parte de discovery, por ejemplo, se trabaja con el marco del doble diamante, explorando primero el problema real del cliente antes de converger en una solución, exactamente la secuencia que le pedimos a un forward deployed engineer que siga en su día a día.

Cada persona, además, evalúa su propio nivel de competencias de product manager y de tech lead en una plataforma de evaluación dedicada a ello. No es un curso puntual ni contenido genérico: es la vía por la que alguien que entró sabiendo defender una arquitectura acaba defendiendo también por qué merece la pena construir una funcionalidad antes que otra.

Esa misma lógica de formación constante se repite fuera del programa de producto a través de Knowledge Sharing y Asteroids: sesiones y píldoras breves, de cinco a quince minutos, que cualquier persona del equipo puede proponer y dar sobre cualquier tema —de arquitectura de agentes a negociación con cliente—, porque compartir lo que se aprende es un objetivo del equipo, no una actividad que depende de que sobre tiempo.

Es esta combinación —criterio en la contratación, acompañamiento real y formación continua en negocio— la que hace posible que alguien dentro de Orbitant piense y actúe como un forward deployed engineer, y no se quede en una definición bonita sobre el papel.