Forward deployed engineer para pymes: por qué las empresas dirigidas por su dueño sacan lo mejor del modelo

El mismo rol que la versión de gran empresa: dentro de tu entorno, responsable de la producción. La diferencia es cuánta parte de tu empresa puede sostener un solo ingeniero.

Día a día el trabajo se parece a lo que es en cualquier sitio: el ingeniero se sitúa cerca de las personas que usarán el sistema, aprende tu negocio, y escribe código contra tus datos reales y tus excepciones reales. El rol es un híbrido de criterio de producto, ingeniería y capacidad de llevar la conversación con el cliente en primera persona. En una gran empresa esa última parte significa navegar un mapa de interlocutores. En una empresa de treinta personas nunca hubo capa de traducción, así que el híbrido puede gastarse en las dos primeras partes.

En un despliegue de gran empresa el ingeniero está integrado en una unidad de negocio y ve un flujo de trabajo entre miles, rodeado de equipos de plataforma, seguridad y datos que median cada cambio. En una empresa dirigida por su dueño el mismo ingeniero ve todo el negocio en una semana: el CRM, la hoja de cálculo que sostiene las operaciones en silencio, el buzón compartido donde de verdad se cierran los tratos, la herramienta de facturación que nadie quiere. Definir el alcance es más rápido y más seguro cuando el sistema entero cabe en una cabeza, y en una pyme cabe.

Lo que se construye es igual de concreto. No una plataforma: un flujo de trabajo que importa, llevado a producción. Cualificación de leads sobre tu pipeline real, procesamiento documental sobre tus documentos reales, triaje de soporte sobre tus tickets reales, un agente de reporting sobre las cifras con las que de verdad diriges. Cada uno entregado con el arnés de evaluación que dice si funciona, barreras de seguridad, un techo de coste y un plan B sin IA. El alcance es un hito de producción, no un backlog, y eso es lo que hace posible una fecha de fin acordada.

El recurso escaso no es la seniority. Es la fracción de semanas pagadas que llega al problema real.

Mira dónde se va la agenda de un ingeniero integrado en una organización grande: el ciclo de compras antes de que empiece el trabajo, la revisión de seguridad antes de que existan los accesos, las solicitudes de permisos que se llevan un sprint cada una, el comité de seguimiento que se reúne un jueves sí y otro no, los interlocutores que son dueños del flujo de trabajo pero no de la decisión. Nada de eso es disfunción; es lo que cuesta la coordinación a esa escala. Pero cada hora se factura a la misma tarifa que la ingeniería, y en conjunto consume habitualmente una parte grande del encargo. Ese sobrecoste es el impuesto de gran empresa que el modelo siempre ha cargado.

Una empresa dirigida por su dueño casi no lo paga. La persona que puede decir que sí está en la sala, y decide sin comité. La persona que ejecuta el flujo de trabajo está a dos mesas, o es la misma persona. Un acceso que en una gran empresa tarda seis semanas se concede en una tarde. Una pregunta que sería una convocatoria de reunión con una semana de antelación se responde antes de comer, y la corrección que provoca sale a producción el mismo día. Mismo ingeniero, mismas semanas: muchas más aterrizan sobre el sistema.

La segunda inversión es el radio de acción. Los despliegues de gran empresa necesitan equipos de forward deployed engineers porque ninguna persona sola puede sostener la arquitectura de una organización global. El stack de una pyme es lo bastante pequeño para que un solo ingeniero senior lo sostenga entero, y esa es justo la condición en la que el rol rinde mejor: todo el sentido del híbrido es que la persona que definió el problema sea la que lo construye y la que lleva la conversación, sin nada perdido entre las tres.

¿Por qué, entonces, inventaron el modelo las grandes empresas? Porque en los primeros años solo ellas podían absorber su sobrecoste; Palantir construyó el rol para entregas a la administración pública y al Fortune 500 porque eran los compradores capaces de sostenerlo. La restricción nunca fue que los problemas más pequeños fueran demasiado pequeños. Fue que el modelo de entrega estaba tarificado y moldeado para compradores con comités. Quita los comités y el modelo sale más barato de operar precisamente donde las decisiones son rápidas, una economía que las grandes empresas no pueden recomprar a ningún precio.

La comparación real no es contra no hacer nada. Es contra una contratación senior a tiempo completo que a tu empresa le costará ganar, y luego le costará mantener ocupada.

Para contratar internamente a la persona capaz de hacer este trabajo, estás pujando por uno de los perfiles más escasos del mercado, frente a los laboratorios de IA y las grandes empresas que han hecho famoso el rol. Para una empresa dirigida por su dueño eso significa una búsqueda larga, una conversación de salario que tensiona la nómina, y un riesgo de retención concentrado en una sola persona, que acaba siendo la única que entiende el sistema. A veces sigue siendo la decisión correcta. Vale la pena ser honesto sobre lo que cuesta esa puja.

El problema de fondo es que el trabajo tiene forma de proyecto. Construir un sistema agéntico exige criterio arquitectónico senior todos los días durante un periodo acotado; operarlo después exige una fracción de eso. Una contratación senior a tiempo completo está mal ajustada a esa curva: totalmente necesaria durante la construcción, infrautilizada después, momento en el que o inventas trabajo o ves cómo esa persona se va. Un encargo forward deployed se ajusta a la curva: criterio senior concentrado en la construcción, luego una transferencia deliberada al equipo que ya tienes, una ventana de operación conjunta, y un paso atrás.

El estado final es la parte que las grandes empresas rara vez hacen bien y las pymes sí pueden. La fecha de transferencia nombra a un responsable de tu lado, y en la mayoría de empresas dirigidas por su dueño esa persona ya existe: el perfil técnico orientado a operaciones al que hace meses le pidieron que mirara lo de la IA. Lo que le bloqueaba nunca fue la competencia; fue que diseñar y construir en solitario un sistema agéntico, encima de un trabajo a jornada completa, no es una petición razonable. Operar y cambiar uno que llega con runbooks, monitorización y un arnés de evaluación dentro de tu CI, sí lo es. Es un trabajo acotado y aprendible, y es suyo desde la fecha acordada.

Lo interno es la respuesta correcta cuando el sistema es el producto: cuando el trabajo es permanente en lugar de tener forma de proyecto y habrá un flujo continuo durante años. Entonces contrata, dale a la búsqueda el tiempo que necesita, y si el hito no puede esperar, usa un encargo para arrancar el sistema mientras la búsqueda avanza, con la entrega aterrizando sobre la nueva persona.

Una pyme carga con más riesgo de dependencia que una gran empresa: no hay banquillo que absorba un sistema opaco. Las protecciones son preguntas, y son gratis.

La primera pregunta es la que separa lo real de una bolsa de horas con mejor nombre: cuál es la fecha de transferencia, qué se transfiere ese día, y quién de mi lado lo sostiene después. Un proveedor que trabaja de verdad forward deployed tiene la respuesta lista, porque la fecha es la forma en que planifica el encargo. Una respuesta real nombra la fecha, nombra los activos (los repositorios, el arnés de evaluación funcionando en tu CI, los runbooks, la monitorización) y nombra a tu persona. Para una empresa dirigida por su dueño esta es la frase más protectora de toda la compra.

Dos preguntas de seguimiento rematan el trabajo. Quién escribe el código, en concreto: si la persona que definió el trabajo no es la que lo construye, estás pagando dos veces una capa de traducción, una en honorarios y otra en requisitos perdidos al cruzarla. Y dónde vive el código desde el primer día: si está en las cuentas del proveedor hasta el final, lo que has comprado es un evento de entrega, y los eventos de entrega fallan mucho más que los procesos de entrega. Añade una exigencia propia de pyme: tu responsable nombrado está dentro del ciclo de construcción desde el principio, no solo en la ceremonia final.

Las señales de alarma son la imagen invertida. Una cuota abierta sin ningún hito asociado. Una fecha de transferencia con una renovación ya escrita al lado. Un sistema que solo se puede demostrar desde el portátil del proveedor. Un precio que solo tiene sentido si el encargo no termina nunca. Ninguna de estas es necesariamente una mala compra, pero ninguna es ingeniería forward deployed, y a escala de pyme la dependencia que crean cae sobre una empresa sin holgura para absorberla.

La medida del encargo no es la demostración del día de la transferencia. Es lo que tu equipo puede cambiar con seguridad medio año después de que los ingenieros se hayan ido.

El día de la transferencia tu equipo debería poder responder a tres preguntas sin llamar a nadie: dónde vive el código, cómo sabemos que sigue funcionando, y qué hacemos cuando se rompe. Corresponden a los repositorios, al arnés de evaluación en tu CI y a los runbooks. Si alguna de las tres necesita una llamada, la entrega no ha ocurrido, diga lo que diga el contrato.

Seis meses después la prueba es más dura. Se retiró un modelo, un proveedor cambió sus precios, una persona clave se fue de baja, y el flujo de trabajo sobrevivió a las tres cosas. Tu responsable nombrado ha cambiado algo real, un prompt, un umbral, una integración, y el arnés de evaluación le dijo que el cambio era seguro antes de que se lo dijera la producción. Eso es lo que significa ser dueño de un sistema, y es toda la diferencia entre esta compra y una dependencia con mejor marca.

El rol merece comprarse cuando se cumplen dos cosas a la vez: el trabajo es lo bastante específico para que ningún producto de catálogo lo cubra nunca, y lo bastante importante para tener que seguir funcionando después de que termine el encargo. Si solo se cumple la primera, un proveedor por horas sale más barato. Si solo se cumple la segunda, compra el producto. Cuando se cumplen ambas, contrata forward deployed, e insiste en la fecha de transferencia.