Guía completa para contratar un Forward Deployed Engineer (FDE)

• Un Forward Deployed Engineer (FDE) es un ingeniero que se despliega directamente en el entorno del cliente para implementar la “última milla” de productos técnicamente complejos
• No es un simple consultor, sino un desarrollador que escribe y depura código real de producción, y además detecta nuevas oportunidades de producto
• Este modelo no encaja en todas las empresas y solo funciona bien cuando se cumplen tres condiciones: clientes con contratos grandes, un ICP no estandarizado y apertura en la dirección del producto
• Los mejores FDE suelen ser perfiles en etapas tempranas de su carrera con pensamiento independiente, perseverancia, alto nivel técnico y curiosidad de negocio, y que no dependen de playbooks existentes
• Al operar un equipo de FDE, la clave es enfocarse en los problemas más difíciles de los clientes más grandes y combinar el despliegue en sitio con una gestión adecuada del alcance

---

El origen y el presente del FDE

• Alex Karp, cofundador de Palantir, ideó por primera vez el rol de Forward Deployed Engineer (FDE) hace unos 20 años, inspirado en la observación de que los meseros de un restaurante francés eran una extensión del personal de cocina
• El FDE trabaja directamente en el entorno del cliente y se encarga de construir la “última milla” del producto en producción; a diferencia de un consultor de soluciones tradicional o un sales engineer, escribe y depura código real de producción
• Durante mucho tiempo hubo escepticismo y se le veía como “consultoría premium”, pero el interés por este rol revivió después de que Palantir superara una capitalización de mercado de 300 mil millones de dólares
• Entre enero y septiembre de 2025, las vacantes para FDE aumentaron 800%, y startups de IA, incluyendo OpenAI, están formando equipos de FDE para fortalecer sus ventas enterprise

Dónde genera valor un FDE

• El FDE no cumple solo una función de implementación, sino que debe actuar como un miembro real del equipo de ingeniería de software, hablando a diario con el cliente y construyendo software directamente
  • En Serval, los FDE llegaron a convertir en producto más de 60 integraciones con apps de terceros, sistemas de feedback para desempeño de agentes, sistemas de SLA y más
• El rango de trabajo de los FDE en Palantir va desde reducir tasas de defectos en manufactura hasta desplegar software para gestionar suministros de ayuda ante desastres naturales

• Apoyo al cierre de contratos grandes

  • Looker usó FDE en ventas ofreciendo a prospectos pruebas gratuitas con datos reales junto con un fuerte soporte de preimplementación
    • El cofundador Lloyd Tabb: “No decidirnos entre producto y servicio abrió una tercera vía. Lo vendimos como producto, pero durante el periodo de prueba lo desplegábamos de forma personalizada para que se sintiera como un servicio a medida”
    • En lugar de una versión demo con datos ficticios, siempre construían PoC con el dataset real del cliente potencial
  • En Palantir también hubo casos en los que 3 o 4 FDE construyeron directamente soluciones especializadas para resolver problemas de clientes del sector energético, sin roadmap ni aprobación de headquarters, y lograron cerrar el contrato

• Descubrimiento de oportunidades de producto a través de la inmersión con el cliente

  • La inmersión en sitio permite descubrir insights profundos que es difícil obtener en una llamada de Zoom de 30 minutos
    • “Lo central del FDE es vivir en el terreno junto al cliente. No se trata de agendar entrevistas con usuarios, sino de prototipar lo que escuchaste durante el día y enseñarlo al día siguiente”
  • Algunos de los casos más exitosos de FDE surgieron en Palantir en áreas no relacionadas con su producto principal
  • Aun así, existe el riesgo de que un FDE construya funciones al azar sin relación con mejoras al producto core, por lo que hace falta criterio de producto para identificar problemas que también puedan resolverse para otros clientes

• Escalar la energía de los fundadores en etapa temprana

  • El modelo FDE es una forma de reproducir y escalar la energía de los cofundadores iniciales, cuando el CTO escuchaba directamente el feedback del cliente y lo resolvía de inmediato con código
    • En Serval casi no hay diferencia entre un FDE y un ingeniero generalista; el FDE pasa alrededor del 20% de su tiempo con clientes y se enfoca en construir capacidades de producto, no infraestructura
  • En el ciclo tradicional entre feedback y producto, pasar de solutions engineer a PM, luego a engineering manager y finalmente al sprint puede tomar meses, mientras que el modelo FDE elimina esos pasos intermedios

• Resolver funcionalidades de baja prioridad

  • El FDE puede encargarse de solicitudes de funcionalidades nivel P2 que siguen siendo postergadas en el roadmap
    • En Verkada, el equipo de ventas acumulaba pedidos de clientes en un canal de Slack llamado “Feature Garage”, pero la mayoría quedaban abandonados
  • “Si los P2 se siguen acumulando, aunque te concentres solo en lo técnicamente correcto, al final terminas con un producto inferior. En el modelo FDE, los P2 sí se revisan de verdad”

Autoevaluación antes de adoptar FDE

• Invertir en un equipo de FDE puede ser costoso, especialmente para startups tempranas, y si la matemática del modelo de negocio no cierra, el capital puede agotarse rápidamente
• Frank Bien, CEO de Looker, decidió invertir en FDE después de validar un modelo en el que podía llegar a 100 millones de dólares en ARR con 2,000 clientes
  • “Si entiendes perfectamente el modelo, puedes calcular si cada recurso que agregas está respaldado. Pero si no sabías si para llegar a 100 millones necesitabas 2,000 clientes o 100,000, entonces solo estarías quemando dinero de VC”

• Condición 1: haber conseguido o apuntar a clientes grandes

  • El FDE es intrínsecamente una estrategia upmarket, y si tu forma final es un modelo freemium PLG, probablemente FDE no sea adecuado
  • Ironclad entendió desde el principio que su cliente ideal eran los departamentos legales de grandes corporaciones globales, y adoptó FDE porque consideró que para asegurar un ACV enterprise hacía falta una implementación personalizada

• Condición 2: no tener opiniones demasiado rígidas sobre cómo debe usarse el producto

  • Si una empresa tiene una visión muy fuerte sobre cómo debe verse su producto en el futuro, probablemente encajen mejor un PM o un ingeniero orientado al cliente que un FDE
  • En un extremo del espectro está Apple, donde todos los usuarios tienen la misma experiencia; en el otro está Palantir, una plataforma adaptable a distintos problemas y organizaciones
    • En los primeros días de Palantir casi no decían “el producto debe ser así”; los FDE aprendían de casos de uso concretos y de los clientes, y así construían gradualmente un producto valioso

• Condición 3: que el ICP no sea uniforme

  • Si el criterio de cliente está definido con mucho detalle, puede reducirse la necesidad de un equipo FDE
  • Los primeros 50 clientes de Ironclad incluían empresas tecnológicas públicas, startups de YC, marcas globales de belleza y equipos deportivos profesionales, con muy poco en común entre sí
    • Un flujo de contratos para influencers japoneses y un contrato de venta de boletos de temporada de MLB tenían necesidades completamente distintas
  • Promise tiene como clientes a gobiernos de EE. UU., y está armando un equipo FDE precisamente por ese entorno de clientes heterogéneo, donde cada estado opera sus programas de forma distinta

• No intentes meter a la fuerza al FDE dentro de ingeniería o postventa

  • Muchos fundadores dicen querer un FDE, pero en realidad muchas veces lo que necesitan es un software engineer tradicional o un consultor de implementación o CSM
  • Tiffany Siu, de First Round, recomienda estas preguntas de validación:
    • “¿Qué detonó la apertura de esta posición? ¿Quién hace hoy este trabajo? ¿Qué pasa si no contratan a esta persona?”
    • “¿Cómo se ve exactamente el trabajo diario de esta persona?”
    • “¿Cuáles son sus métricas de éxito?”
  • Si “quieres que el FDE cierre X deals o haga X demos”, entonces no necesitas un FDE, sino un rol más cercano a ventas

Cómo contratar al FDE adecuado

• No hace falta obsesionarse con encontrar a alguien que ya tenga el título de FDE. Como la estructura del rol varía según la empresa, hay que mirar el trabajo real más que el título

• Cinco rasgos que comparten los mejores FDE

  • No depender de playbooks existentes (mejor si están al inicio de su carrera): en Palantir, una parte importante de los FDE eran recién graduados. Son ideales los pensadores independientes que creen que pueden resolver cualquier problema, en vez de solo hacer pattern matching
    • Un candidato con más de 10 años en FAANG y formas de trabajo demasiado rígidas puede ser incluso una señal de alerta
  • Perseverancia (grit): como el trabajo del FDE se mueve en espacios de problemas extremadamente difíciles, es indispensable la “disposición a soportar el dolor”. Los mejores FDE de Ironclad también eran descritos como “grinders”
    • El FDE cumple el rol de mini fundador dentro de la organización y necesita fuerte criterio de producto e interés real por ventas
  • Altísimo estándar técnico: los mejores FDE de Ironclad estaban al nivel de poder ser staff engineers en grandes empresas tecnológicas. En Palantir, además, los FDE debían pasar el mismo proceso de entrevista que los software engineers
  • Hábito de construir sin parar: los mejores FDE son “builders compulsivos”, el tipo de persona que no puede evitar crear herramientas, lanzar apps o contribuir a open source
  • Curiosidad profunda por el negocio: personas que se meten a fondo, por ejemplo, en los riesgos legales del influencer marketing y obtienen energía de entender cómo funciona el negocio mismo

• Diseño de entrevistas

  • En lugar de la entrevista típica de coding de big tech, Palantir hacía entrevistas centradas en resolución de problemas de alto nivel basados en problemas reales del cliente
    • Ejemplo: después de explicar insider trading, preguntar “¿Qué datos necesitarías, qué preguntas le harías al cliente y qué buscarías?”, evaluando tanto razonamiento de negocio como razonamiento técnico
  • Ironclad usaba una entrevista de presentación abierta donde el candidato debía exponer un problema vivido en su carrera y enseñar cómo lo resolvió con tecnología
    • Un caso representativo mostraba fotos de un “deal room” físico en operaciones de financiamiento aeronáutico, miles de páginas con notas adhesivas y luego un macro de Excel que automatizaba el proceso

Definir el alcance del rol FDE: 3 tácticas para usar con impacto a tu primer equipo FDE

• Asignar FDE a los problemas más difíciles de los clientes más grandes

  • Ironclad al principio enviaba FDE a todos los clientes, pero al crecer cambió a un modelo en el que solo los clientes con mayor ACV recibían FDE
    • No se trata de ser “una empresa totalmente FDE o nada”, sino de sistematizar un menú de opciones según las necesidades del cliente y estandarizar la implementación para segmentos inferiores
  • Serval también los desplegó primero con todos los clientes, pero ahora prioriza a clientes grandes, como empresas de más de 1,000 empleados

• La importancia del despliegue en sitio

  • Los FDE rinden mejor estando físicamente en el lugar. Más allá de la lista de requisitos escrita en el contrato, pueden descubrir cosas que no estaban ahí al compartir la experiencia cotidiana del cliente
    • La cultura de visitas presenciales de los FDE de Ironclad era tan conocida que responsables legales de Fortune 100 llegaron a llamarlos “The Backpacks”

• Enfoque equilibrado frente al scope creep: aceptarlo, pero evitar “tapar problemas de producto con trabajo humano”

  • Hay que aceptar el componente de servicio del rol FDE, pero evitar invertir tiempo sin límite en soluciones que no beneficien a futuros clientes
  • En la etapa inicial de Ironclad, el scope creep se interpretaba como una señal de que “había más problemas del cliente que podíamos resolver”, y gracias a su modelo de precios por workflow, la economía del software se beneficiaba de ampliar el alcance
  • El mal scope creep aparece cuando se hace trabajo repetitivo sin fin en workflows con pocos usuarios; si no se ve potencial de apalancamiento vía software, hay que detener ese trabajo
  • Un verdadero FDE está tan enfocado en resolver problemas que ni siquiera nota que se salió del alcance del contrato, por lo que la gestión del alcance es tarea del manager