El día a día de un Forward Deployed Engineer

El día a día de un Forward Deployed Engineer rara vez se parece al de un ingeniero encerrado en un backlog estable. El FDE se mueve entre código, clientes, producto, datos, integraciones y decisiones rápidas. Su trabajo empieza donde la tecnología se encuentra con una empresa real: procesos imperfectos, usuarios con poco tiempo, sistemas heredados y preguntas que todavía no están bien formuladas.

Por eso es un rol difícil de explicar desde fuera. No es solo ingeniería. No es solo consultoría. No es solo customer success. Es una mezcla práctica de construir, entender y desplegar.

Antes de escribir código: entender el contexto

Una jornada puede empezar con una llamada de discovery con un cliente. El objetivo no es recopilar una lista de deseos, sino entender qué problema operativo está detrás.

Una petición como "queremos un chatbot interno" puede significar muchas cosas:

El equipo no encuentra documentos.
Los procesos no están actualizados.
Los empleados interrumpen siempre a las mismas personas.
Hay información sensible que no todos deberían ver.
La dirección quiere medir qué conocimiento falta.

El FDE tiene que hacer preguntas concretas: quién usa el sistema, qué fuentes importan, qué decisiones se toman con esa información, qué errores serían graves y cómo sabremos si la solución funciona.

Media mañana: bajar el problema a arquitectura

Después del discovery, el FDE traduce el problema a una propuesta técnica. No siempre es una especificación formal. A veces es un diagrama, una lista de fuentes, una tabla de riesgos o un pequeño plan de implementación.

En un proyecto de IA empresarial, esto puede incluir:

Qué documentos se van a indexar.
Qué permisos debe respetar el sistema.
Qué APIs hay que conectar.
Qué modelo se usará para cada tarea.
Cómo se medirá la calidad de las respuestas.
Qué parte será prototipo y qué parte debe nacer lista para producción.

La clave es evitar dos extremos: construir sin entender el negocio o quedarse semanas diseñando sin entregar nada.

El bloque de construcción

El FDE necesita tiempo profundo para construir. Puede estar creando una integración, escribiendo un extractor de documentos, ajustando un pipeline RAG, preparando una demo con datos reales, revisando logs o resolviendo un bug que bloquea una implementación.

Su código suele estar cerca de la frontera con el cliente:

Conectores con herramientas externas.
Scripts de migración o limpieza de datos.
Interfaces internas para validar flujos.
Configuración de permisos.
Adaptadores para APIs del cliente.
Evaluaciones automáticas de calidad.

No todo lo que construye debe convertirse en producto core, pero sí debe dejar aprendizaje útil. Una mala señal es que el FDE entregue piezas imposibles de mantener o que nadie del equipo pueda entender después.

Reuniones cortas, decisiones claras

El FDE habla mucho con personas, pero no debería vivir en reuniones. Su valor está en cerrar bucles rápido. Una reunión útil suele responder una de estas preguntas:

¿Cuál es el caso de uso prioritario?
¿Qué fuente de datos es la correcta?
¿Quién puede aprobar el acceso?
¿Qué métrica define éxito?
¿Qué parte debe simplificarse para llegar a producción?

Como está cerca del cliente, el FDE también detecta tensiones que no aparecen en un ticket: un departamento que no quiere compartir datos, usuarios que no confían en la IA, directivos que quieren automatizar demasiado pronto o procesos que nadie ha documentado.

Tarde: probar con usuarios reales

Una parte importante del día puede ser probar lo construido con usuarios reales. No basta con que el sistema pase tests técnicos. Tiene que funcionar para la persona que lo va a usar en mitad de su jornada.

En esta fase aparecen preguntas muy prácticas:

¿La respuesta cita una fuente fiable?
¿El usuario entiende qué hacer después?
¿La herramienta tarda demasiado?
¿El sistema sabe decir que no tiene información?
¿La solución ahorra tiempo o solo añade otra pantalla?

El FDE observa fricción y ajusta. A veces cambia un prompt. A veces cambia una integración. A veces descubre que el problema no era técnico, sino de proceso.

Feedback a producto

Un FDE no debería ser una isla. Todo lo aprendido en el cliente tiene que volver al equipo de producto e ingeniería.

Ese feedback puede convertirse en:

Una nueva funcionalidad.
Una mejora de onboarding.
Una integración más robusta.
Una regla de permisos.
Un mensaje de error más claro.
Una plantilla para futuros clientes.
Una decisión de no construir algo que parecía urgente.

La diferencia entre un FDE estratégico y un perfil puramente custom está aquí. El buen FDE no solo resuelve un caso. Ayuda a que el producto mejore para muchos casos parecidos.

Cómo se reparte realmente el tiempo

Actividad	Peso habitual	Objetivo
Discovery y alineación	15-25%	Entender problema, usuarios y valor
Construcción técnica	35-50%	Integrar, prototipar y desplegar
Pruebas y debugging	15-25%	Llevar la solución a uso real
Documentación y handoff	5-10%	Evitar dependencia personal
Feedback a producto	10-15%	Convertir aprendizaje en roadmap

Los porcentajes cambian según la fase. En un piloto temprano hay más discovery. Cerca de producción hay más debugging, permisos y adopción.

Las habilidades invisibles del FDE

Las habilidades técnicas son obligatorias, pero las invisibles suelen marcar la diferencia.

Un FDE necesita tolerar ambigüedad sin perder rigor. Tiene que poder hablar con un CTO, una persona de operaciones y un usuario final en la misma semana. Debe explicar límites de la IA sin matar la ilusión del proyecto. Y debe saber decir "todavía no" cuando una automatización no está preparada para producción.

También necesita criterio para no confundir velocidad con improvisación. Construir rápido no significa dejar piezas frágiles por todas partes. Significa elegir bien qué validar primero.

Qué hace que un día salga bien

Un buen día para un FDE no se mide por número de commits. Se mide por avance hacia adopción real.

Puede ser:

Un cliente que pasa de demo a uso diario.
Una integración que deja de bloquear el piloto.
Una evaluación que detecta fallos antes de producción.
Un usuario que encuentra una respuesta sin pedir ayuda.
Un patrón que producto puede convertir en funcionalidad estándar.

El FDE vive en resultados, no en entregables decorativos.

Conclusión: construir donde ocurre el uso

El día a día de un Forward Deployed Engineer es exigente porque mezcla mundos que muchas empresas mantienen separados: ingeniería, cliente, producto y negocio. Esa mezcla es precisamente su valor.

Cuando el producto es complejo, especialmente en IA, alguien tiene que acompañar el salto desde capacidad técnica hasta adopción operativa. El FDE hace ese trabajo: escucha, diseña, construye, prueba, mide y devuelve aprendizaje al producto.

Polp se apoya en esa misma filosofía: la IA empresarial solo aporta valor cuando entiende los documentos, permisos y procesos de cada empresa. El trabajo no acaba en tener un modelo potente. Empieza cuando ese modelo se integra en el día a día del equipo.

Sources: