Acércate
al trabajo real.

La solicitud dice «crea una herramienta».
El trabajo dice otra cosa.

Un equipo pide un panel de datos. Pasa una mañana con ellos y quizás descubras que las cifras no cuadran porque tres personas introducen la misma información en tres lugares. Una gráfica más bonita solo hará que el enredo se vea mejor.

Ese es el tipo de desconexión que debería detectar alguien que trabaja en FDE. Forward Deployed Engineering, o FDE, significa acercar la ingeniería al trabajo real del cliente: entender el problema, construir la solución y seguir involucrado cuando se pone en producción y empieza a usarse. FDE también nombra a la persona que lo hace. El alcance exacto del rol varía según la organización.

En la descripción del puesto de OpenAI, la responsabilidad va desde investigar la necesidad y diseñar el sistema hasta desplegarlo en producción. Lo aprendido en el campo alimenta el producto. Lo importante es que quien descubre qué falla también pueda ayudar a cambiar el software.

Hay puntos en común con la consultoría, la ingeniería de producto y la arquitectura de soluciones. El título no define la diferencia. Pregunta si el equipo responde por la implementación, aprende del uso real y deja algo que funciona. «Forward deployed» debería describir esa responsabilidad, no solo dónde está el escritorio.

Las empresas están contratando.
Y están invirtiendo en este modelo.

Ya no es un rol asociado a una sola empresa. En la fecha de revisión de este artículo, OpenAI está reclutando profesionales FDE para llevar el trabajo desde la investigación inicial hasta su despliegue en producción. Anthropic también los está reclutando para construir aplicaciones con Claude dentro de los sistemas del cliente. Ambas descripciones combinan ingeniería con criterio para trabajar de cara al cliente.

El 30 de junio de 2026, AWS anunció una organización dedicada a FDE con una inversión de mil millones de dólares, con planes de integrar miles de profesionales de ingeniería y extender el enfoque mediante socios. Es un compromiso anunciado, no un conteo de contrataciones completadas.

Son señales concretas de contratación e inversión. No prueban una tasa de crecimiento de toda la industria, una escasez universal de talento ni una carrera garantizada. Sí muestran que grandes empresas tecnológicas están invirtiendo en cerrar la distancia entre un modelo capaz y una operación útil.

Menos relevos.
Mejores preguntas.

El valor potencial de FDE es acortar la ruta entre descubrir un problema y probar una respuesta. Quien opera puede mostrar la excepción que rompe el flujo previsto. Quien programa puede cambiarlo. Ambos pueden comprobar si el cambio ayudó.

El resultado debe medirse en el propio trabajo: tiempo para completar una admisión, errores que obligan a repetir tareas, preguntas resueltas, adopción después del lanzamiento o esfuerzo para corregir un fallo. Define un punto de partida y una prueba útil antes de celebrar el sistema. Son medidas que debemos acordar, no ahorros que podamos prometer por el nombre de un puesto.

También puede salir mal. Una persona integrada al cliente puede convertirse en el parche permanente de un producto frágil. Un despliegue apresurado puede dejar un sistema que nadie más sabe operar. Un equipo dedicado puede ser una respuesta cara a algo que ya resuelve una herramienta estándar. FDE se justifica cuando la incertidumbre, la integración y las consecuencias de equivocarse requieren esa cercanía.

Profundidad técnica.
Una mirada amplia.

Las descripciones de puestos de OpenAI y Anthropic revisadas para este artículo piden ingeniería de producción, experiencia con modelos de lenguaje, comunicación clara y buenas decisiones ante la ambigüedad. Nuestro criterio lleva esa combinación a la práctica:

• Construye más allá de la demostración. Trabaja con interfaces, APIs, datos y despliegues. Lee código que no conoces. Pruébalo, monitórealo y permite recuperarse de un fallo.
• Aprende la operación. Pídele a quien hace el trabajo que te lo muestre. Fíjate en la hoja de cálculo, la conexión que falta, la aprobación que nadie mencionó y la excepción de todos los viernes.
• Aplica criterio de producto y diseño. Separa la solicitud de la necesidad. Haz comprensible la próxima acción. Reconoce cuándo comprar, simplificar o eliminar algo es mejor que construirlo.
• Usa la IA con disciplina. Entiende los límites del modelo, la recuperación de información, la evaluación y el costo de una respuesta incorrecta. Decide qué necesita aprobación humana y qué debe seguir siendo código determinista.
• Conecta personas y disciplinas. Explica qué se gana y qué se sacrifica con cada decisión. Hazlo comprensible para quien programa, quien dirige y quien va a usarlo. Cambia la explicación, no los hechos. Respeta el idioma, el contexto y la experiencia de las personas con quienes trabajas.
• Deja un trabajo que se pueda entender. Documenta decisiones, define responsables y enseña a otra persona a operar lo que construiste. Ser indispensable para siempre es un mal plan de transferencia.

Nadie tiene que ser el mejor especialista en todas las disciplinas. Sí necesita suficiente profundidad para cumplir y suficiente humildad para reconocer quién más debe estar en el equipo.

Mantener la cercanía.
Ampliar la responsabilidad.

Nos gusta lo que FDE exige. También creemos que Mutiny puede llevar esa forma de trabajar más lejos para las organizaciones a las que servimos.

El equipo FDE de un proveedor suele partir de una plataforma que conoce a fondo. Esa profundidad puede ser justo lo que el cliente necesita. Mutiny parte de la decisión de la organización: ¿qué debería existir, qué debería cambiar y qué combinación de herramientas y personas puede hacerlo útil? A veces la respuesta usa IA. Otras veces es una aplicación operativa, una mejor experiencia pública, una conexión entre sistemas o la decisión de no añadir software.

Nuestro trabajo reúne estrategia de innovación, diseño de experiencias, ingeniería de software, IA aplicada, narración interactiva y operación continua. Un archivo cultural necesita criterio editorial además de búsqueda. Una plataforma de servicios necesita una experiencia clara para el público y un proceso viable para su equipo. Ninguno cabe por completo en la lista de funciones de un solo proveedor.

Los equipos FDE consolidados también valoran los resultados, la colaboración y la independencia del cliente. No afirmamos haber inventado esos principios. Nuestra apuesta es reunir varias disciplinas, poner la experiencia al frente y elegir las herramientas según el problema. Así podemos acompañar una misma idea desde la estrategia hasta el uso diario, sin quedar atados a una sola plataforma. Ser mejor se demuestra en el trabajo. No se gana por escribirlo en un titular.

Pensarlo bien. Hacerlo real.
Seguir mejorándolo.

Así organizamos nuestros servicios para que puedas empezar por donde nos necesites. No tienes que contratar los tres.

Dirección de innovaciónPor mes o por hora

Dirección de innovación integrada a tu equipo. Un socio con experiencia te ayuda a establecer prioridades, reunir a las personas indicadas y tomar decisiones difíciles. Acompaña la ejecución con la dedicación que necesitas, sin crear un puesto a tiempo completo.

Proyectos que toman formaHonorarios por proyecto

Una plataforma, una herramienta con IA, una experiencia interactiva. Definimos el alcance, diseñamos, construimos y probamos con quienes la van a usar. Entregamos algo funcionando, medimos los resultados y preparamos al equipo para recibirlo.

Operación y mejora continuaServicio mensual

El lanzamiento no resuelve lo que viene después. Mantenemos la plataforma al día, ayudamos al equipo a aprovecharla y priorizamos las próximas mejoras. Incluye guías de uso, monitoreo, actualizaciones y pruebas de recuperación, con un calendario, alcance y capacidad acordados.

Dirijo personalmente cada colaboración y reúno a los especialistas que necesita: ingeniería, dirección creativa, diseño de producto o 3D cuando la experiencia lo pide. El equipo cambia con el reto. Yo sigo al frente, sin pasarte de una persona a otra.

El método tiene cinco pasos.

Nuestro proceso publicado es deliberadamente sencillo. Cada etapa debe aportar información para decidir mejor la siguiente.

1. Entender

   Cuestionar la solicitud. Encontrar el problema real junto a quienes lo viven. Entender las limitaciones antes de elegir una solución.

2. Definir

   Definir tres apuestas concretas. Considerar crear, comprar o colaborar. Decidir qué vale la pena probar y qué evidencia cambiaría la decisión.

3. Prototipar

   Poner código funcional en manos de usuarios. Nuestro proceso propone lograrlo en la tercera semana; el servicio de proyectos describe ciclos de unas seis semanas. El alcance y los accesos necesarios deben quedar en el plan acordado.

4. Probar

   Usarlo con clientes reales. Medir lo que ocurre. Decidir si continuar, cambiar de rumbo o detener. Un piloto también sirve cuando refuta la primera idea.

5. Transferir

   Documentar el trabajo y preparar al equipo para operarlo. Acordar quién responde, cómo aprenderán a usarlo y qué apoyo habrá después. Las mejoras que sigan pueden atenderse mediante el servicio de operación y mejora continua.

Los límites importan: el servicio de operación y mejora continua no es una mesa de ayuda, TI administrada ni cobertura de emergencias las 24 horas. Las plataformas heredadas se consideran después de una revisión técnica pagada. «Seguir involucrados» necesita un alcance, no una promesa ilimitada.

El diseño empieza
por entender los límites.

Estos proyectos no se hicieron para ilustrar un puesto. Muestran el tipo de trabajo del que hablamos.

Rimas: ¿qué pasa cuando desaparece la conexión?

Para Fundación Rimas construimos flujos de inscripción, consentimiento y encuestas que permiten capturar información sin conexión y sincronizarla al recuperar señal. Los datos personales se separan del análisis seudonimizado, con roles de acceso distintos. Las condiciones del campo dieron forma a la arquitectura. Lee el caso de Rimas →

PSI: ¿qué pasa después de pulsar Enviar?

Para Platform for Social Impact, el sitio público se conecta a una capa operativa donde cada envío se convierte en trabajo asignable y rastreable, con estado, responsable, notas e historial de auditoría. La experiencia incluye al equipo que responde, no solo a quien llena el formulario. Lee el caso de PSI →

La Voz del Centro: ¿quién puede corregir a la máquina?

El archivo tiene un proceso recurrente de transcripción, anotación y búsqueda, con respuestas vinculadas a la grabación. Su anfitrión puede describir una corrección en español, revisar el cambio propuesto, aplicarlo y deshacerlo. La persona experta en el tema tiene una forma práctica de cuestionar el sistema. Lee el caso del archivo →

Estas decisiones permiten examinar nuestro criterio: la herramienta debe responder a su entorno, respetar a sus usuarios y poder corregirse.

La próxima oportunidad quizás
todavía no tenga nombre.

Parte del trabajo que viene no llegará como una categoría de software bien definida. Una capacidad nueva se encontrará con una limitación vieja, y alguien cerca del problema verá una posibilidad que los demás no vimos.

Buscamos socios dispuestos a explorar con nosotros: líderes que cuestionen la solicitud, nos permitan trabajar con quienes hacen la tarea, prueben algo real y cambien de rumbo cuando la evidencia lo pida. Agencias, instituciones, fundadores y equipos especializados pueden aportar lo que no podemos suplir solos. La idea es subir la vara juntos.

Lo desconocido invita a experimentar con cuidado. Ponle límites a la prueba, define qué necesitamos aprender y decide qué puede llegar a usuarios reales. Podemos cuestionar los hábitos de una industria sin cargar a quienes dependen de ella con riesgos que no hemos examinado.