(2/3) Una semana en la vida de un forward deployed engineer
Pregunta a cinco compañías qué fracción de la semana de un forward deployed engineer es de cara al cliente y tendrás cinco respuestas. Palantir ha situado históricamente el tiempo con cliente en torno al 25%; Commure lo ha estimado en hasta el 50%; las ofertas de empleo analizadas por Bloomberry anuncian todo lo intermedio, viajes incluidos. La cifra baila, y después de dirigir estos encargos desde el lado que despliega, creo saber por qué: la parte de cara al cliente no es una propiedad del rol. Es una propiedad de la semana. Las primeras semanas van cargadas de personas y ligeras de código; hacia la mitad de la misión la proporción se invierte. Quien te dé un porcentaje fijo te está describiendo su promedio histórico, no el trabajo.
Así que en lugar de un porcentaje, te doy la semana entera. En el primer artículo de esta serie defendí que el 95% de los pilotos de GenAI muere en el despliegue, no en el modelo. Esta es la anatomía de la alternativa — qué hace esa persona, hora a hora, cuando el despliegue se trata como el trabajo en sí y no como una nota al pie. Usaré nuestros propios encargos como referencia, porque son los que puedo describir sin inventar.
La semana que más cuenta ocurre antes del día uno
La parte menos visible de un despliegue forward es que empieza antes de que llegue el ingeniero. En nuestro modelo, el onboarding se prepara por adelantado: las solicitudes de acceso cursadas, el mapa del repositorio y el plan de la primera semana escritos, las personas que el ingeniero va a necesitar identificadas con nombre — antes del día uno, no descubiertas durante el día uno. He sido el contractor que pasó sus primeros nueve días esperando un token de VPN, y he sido el ingeniero de operaciones viendo a un recién llegado quemar un sprint haciendo ingeniería inversa de un pipeline de despliegue sin documentar. Las dos cosas son normales en este sector. Las dos son una elección.
Que podamos prepararlo es estructural, y es la parte de la doctrina forward-deployed que suele ignorarse: el ingeniero va respaldado. Alguien cuyo trabajo es el encargo — en nuestro caso un delivery manager, en los proyectos que lo justifican — negocia los accesos y el plan del día uno mientras se cierra el match. Las 72 horas que anunciamos para el match serían una métrica de vanidad si el día uno aterrizara en una pista sin preparar.
El lunes es de su standup, no del nuestro
El hábito que define al ingeniero incrustado: asiste a los rituales del cliente, no a los del proveedor. El lunes por la mañana es el standup del cliente, en el tracker del cliente, contra los objetivos de sprint del cliente. Los entregables son los tickets del cliente. Si la definition of done del cliente incluye una entrada en el runbook y una demo al responsable del proceso, esa es la definición que cuenta.
Suena trivial, pero ahí está toda la diferencia entre un equipo incrustado y uno externalizado. El equipo externalizado tiene su propio standup, su propio tablero y su propia definition of done, y la reconciliación entre los dos mundos ocurre en una sync semanal — y en esa sync es donde se pierde el contexto. El ingeniero incrustado no tiene segundo mundo. Lo que hace funcionar el despliegue forward es precisamente quitar cosas: eliminar la capa entre el ingeniero y la realidad.
Lo que llena el resto del lunes es trabajo poco vistoso. Ponerse al día con lo que se acumuló durante el fin de semana en el canal de incidentes. Perseguir al responsable de los datos que dio el visto bueno de palabra al acceso de lectura pero todavía no en la consola de IAM. Sentarse con el responsable de operaciones que ejecuta cada día el proceso que la funcionalidad de IA debe cambiar, y escuchar lo que el sistema de tickets nunca captura — «ese campo nos lo saltamos porque siempre está mal».
El código es la mitad pequeña, y maximizarlo es un error
La mitad de la semana es construcción: código de integración, harnesses de evaluación, los guardrails y fallbacks que separan una demo de un sistema en el que alguien confiará a las 3 de la madrugada. Es ingeniería sin atajos — nuestra validación aprueba al 3% de los candidatos precisamente porque esta parte no se puede fingir — y aun así, en una misión de despliegue, las líneas de código son la mitad pequeña del valor.
La mitad grande son decisiones que nunca llegan a un repositorio. Cuál de los cuatro procesos candidatos automatizar primero, porque uno tiene línea en el P&L y tres tienen opiniones. Si el rate limit de la API legacy significa batching esta noche o una cola el mes que viene. Qué modo de fallo recibe un fallback humano y cuál un corte en seco. Un ingeniero que optimizara el número de commits fallaría las tres — porque ni siquiera habría visto que eran preguntas. Por eso «cuánto de la semana es programar» es la pregunta de entrevista equivocada para un FDE: la respuesta honesta es «lo que la misión necesite esta semana», y el rasgo útil es saber en qué semana estás.
El check-in del viernes es un sistema de alerta temprana, no un informe de estado
Cada semana termina con un check-in — dos, y el segundo es el importante. Uno con el cliente: avance contra la misión, bloqueos, la forma de la semana siguiente. Otro con el ingeniero, por separado: cómo se ve el encargo desde dentro. Los problemas asoman en el lado del ingeniero una o dos semanas antes de aparecer en un standup — el alcance que se va inflando en silencio, el stakeholder que dejó de contestar, el bache que todavía no es un retraso. Cuando una fase del proyecto se calienta, lo semanal pasa a diario.
La cadencia es también lo que hace honesta la red de seguridad. Nuestra garantía de sustitución — un sustituto presentado en 7 días, dentro de los primeros 30, sin coste — sería papel mojado si nadie vigilara la señal que la activa. Las garantías valen lo que vale la instrumentación que llevan detrás; el check-in es la instrumentación.
La misión tiene final, y el final se planifica el día uno
La objeción más fuerte a todo lo anterior: ¿no es esto un buen contractor con reuniones extra? La diferencia es la forma del encargo. Un encargo de contractor se prolonga hasta que alguien decide lo contrario, y suele terminar como termina un alquiler — preaviso, entrega de llaves, y lo que quede en el piso es problema tuyo. Un despliegue forward tiene misión acotada: los criterios de salida se escriben al principio, y la última semana es un entregable en sí misma. Documentación de lo construido. Cuentas operativas entregadas. Credenciales cerradas, con un borrado seguro del contenido corporativo que un auditor podría reconstruir.
Concedo el contracaso: si lo que necesitas es capacidad duradera y sin final definido dentro de un equipo que ya hace onboarding serio, one-on-ones semanales y un proceso de offboarding con checklist, no necesitas la doctrina — necesitas un buen ingeniero, y el staff augmentation clásico te cubre de sobra. El arco se gana el sueldo cuando el encargo es una misión — llevar el flujo de IA a producción, montar la plataforma, cerrar la migración — donde el final es una certeza y la única duda es si alguien lo diseñó.
Qué pediría yo antes de cualquier encargo incrustado, el nuestro incluido
- El plan del día uno, por escrito, antes del día uno. Si la respuesta es «montamos una kickoff call», el despliegue lo diriges tú.
- ¿A qué standup asiste el ingeniero? Cualquier respuesta que incluya un segundo tablero del lado del proveedor significa un sobrecoste de reconciliación que pagarás cada semana.
- ¿Quién habla con el ingeniero cuando yo no estoy delante, y con qué frecuencia? Un check-in es un informe de estado; dos son un sistema de alerta temprana.
- ¿Qué dispara la cláusula de sustitución, y quién vigila el disparador? Una garantía sin instrumentación es decoración.
- Enséñame la última semana de una misión terminada. Pide la checklist de esa entrega, no la anécdota.
La semana de un forward deployed engineer no se deja reducir a un porcentaje redondo, y esa es la señal de que el despliegue es real: la mezcla sigue a la misión. Lo que no cambia es la estructura alrededor de la semana — preparada antes de empezar, instrumentada mientras está en marcha, diseñada para terminar. El siguiente artículo le pone números a esa estructura: qué cuesta la doctrina, qué cuesta la capacidad a secas, y cuándo conviene comprar cada una. Y si la semana que acabo de describir es la que le falta a tu roadmap de IA, este es el rol que desplegamos.
