El servicio como software necesita forward deployed engineers

Es un ingeniero que trabaja para un solo cliente y construye todo lo que ese cliente necesita, y el nombre viene de Palantir. Allí, los ingenieros de producto construyen una misma función para muchos clientes. Y los forward deployed engineers, a los que Palantir llama Deltas, hacen justo lo contrario.

Trabajan codo con codo con el equipo del cliente, aprenden cómo se hace de verdad el trabajo y hacen que el software lo haga. Y Palantir los mide por el resultado del cliente, no por el código que entregan.

La diferencia con un consultor es que el consultor recomienda, mientras que este ingeniero construye, lo pone en marcha y se queda hasta que funciona.

El trabajo terminado no se puede dejar en una estantería, porque si no llega, no hay nada que facturar. Con una herramienta es distinto, ya que se puede vender y dejar ahí, y hacerla funcionar es cosa del comprador.

Y ese trabajo vive en los sistemas del cliente: su CRM, sus hojas de cálculo y las excepciones que no están escritas en ninguna parte. Así que ningún modelo de IA las conoce hasta que alguien va y las mira de cerca.

Por eso las empresas que venden agentes de IA contratan a estos ingenieros. En junio de 2025, el fondo de inversión a16z llegó a llamarlo el puesto más codiciado de las startups.

El modelo falla cuando se copia a medias. En enero de 2026, Marc Andrusko, socio de a16z, dio la voz de alarma en «The Palantirization of everything».

Según él, si copias solo a los ingenieros en el cliente, acabas con un montón de desarrollos a medida que luego no hay quien mantenga ni actualice. Y eso, en sus palabras, es un «Accenture for X» con una fachada más bonita.

Además, la mayoría de los problemas no justifican meses de ingeniería en el cliente. Y la gente que entiende a la vez el negocio y el código escasea bastante.

Por eso su consejo es tratarlos como un andamio: trabajo en el cliente con fecha de fin, un límite de personas y piezas que se puedan reutilizar.

Trabajo como lo hacen los forward deployed engineers, metido en los sistemas de tu empresa, con sus datos reales y junto a tu equipo. Es como ya trabajo en Sesame HR, donde cada equipo es un cliente interno, y desde el primer día me pongo tres límites.

El primero es que el trabajo en tu empresa tiene fin. El diagnóstico elige una tarea, y la construcción termina cuando el sistema cumple el criterio acordado. Después me encargo de mantenerlo, ya sin construir más.

El segundo es que lo que no es específico de tu empresa se construye para reutilizarse, como las revisiones y el informe de resultados. Y solo lo que es de verdad tuyo se hace a medida.

Y el tercero es que el coste de cada tarea se mide desde el primer día. Ese número es el que te dice cuándo la ingeniería deja de ser el coste principal y si el servicio sale a cuenta.

Antes de firmar, te propongo hacerle tres preguntas a cualquier proveedor.

¿Quién va a trabajar con mi equipo, y durante cuánto tiempo?

¿Qué se construye solo para mí y qué se reutiliza?

¿Cuándo termina la construcción y empieza el mantenimiento?

Y si la respuesta es «lo que haga falta», seguramente estás comprando horas en vez de resultados.