Staff augmentation: cuándo conviene, cuándo es una trampa, y cómo distinguir

Una guía para el fundador no técnico sobre el modelo que toda agencia vende y que pocos fundadores realmente necesitan.

Un fundador con quien hablábamos hacía tres meses llamó un miércoles y soltó la frase que escuchamos al menos una vez por trimestre: “Creo que lo que necesito es staff augmentation. ¿Pueden conseguirme dos devs senior por seis meses?”

Devolvimos una sola pregunta. ¿Quién dirige el proyecto?

Pausa larga.

Staff augmentation es un modelo de contratación en el que alquilas ingenieros individuales a una agencia externa para que se integren a tu equipo, bajo tu gestión, por un período definido. Es el modelo de entrega más sobrevendido y menos comprendido del mercado del software. Toda agencia lo vende porque la cuenta cierra de su lado. Todo fundador al que le fue mal con un contrato fixed-price termina llegando a él porque parece el punto medio más seguro. Y la mayor parte del tiempo, para la mayor parte de los fundadores no técnicos, es la respuesta equivocada vestida de razonable.

Esto no es una diatriba contra staff augmentation. Es un modelo que funciona en casos puntuales, con equipos que ya saben usarlo. El problema es que quien necesita leer sobre él casi nunca es ese equipo, y la SERP no lo dice. Lo decimos nosotros.

Qué es staff augmentation, en concreto

Staff augmentation es un modelo de contratación en el que contratas ingenieros individuales (o diseñadores, o PMs) a través de una agencia para trabajar dentro de tu equipo por un período definido, bajo tu dirección. Usan tus herramientas, entran a tu daily, toman tickets de tu líder técnico y facturan por hora o por día. No son empleados. No son un proveedor entregando un proyecto. Son capacidad extra alquilada de la nómina de alguien más.

La característica que define al staff augmentation, la que lo separa de cualquier modelo adyacente, es esta: tú sigues siendo el project manager. La agencia aporta cuerpos. Tú aportas dirección, priorización, estándar de code review, deploy y la responsabilidad por el resultado. Si el proyecto se atrasa, es problema tuyo. Si una feature está mal, tú escribiste la spec.

La mayoría de los fundadores no técnicos lee ese párrafo y piensa suena bien. No está bien. Esa es la trampa. Volvemos a ella.

El espectro que nadie te dibuja

Todo fundador descubre, tarde o temprano, que existen más de dos opciones para construir software. Existen al menos cuatro. Alinearlas según cuánta responsabilidad de entrega se traspasa al lado externo hace evidentes las diferencias:

In-house. Contratas empleados. Eres dueño de todo: código, proceso, reclutamiento, retención, nómina, toda la pila de costos. Control máximo, overhead máximo, ramp-up más lento.

Staff augmentation. Individuos externos se integran a tu equipo. Tú eres dueño de la entrega; la agencia es dueña del reclutamiento, la nómina y el banco. Los gestionas como si fueran empleados, pero no los cargas en tu nómina.

Managed services / equipo dedicado. Un partner externo entrega un equipo (ingenieros + tech lead + PM) que opera como unidad. La responsabilidad por la entrega es compartida. El partner dirige al equipo; tú das la dirección y priorizas. (Es el modelo que la mayoría llama “software house” cuando está bien hecho.)

Outsourcing / fixed-bid. Entregas un alcance y una fecha. El proveedor entrega un producto contra un contrato. Apenas tocas al equipo. La responsabilidad recae enteramente en el proveedor.

Deslizándose de izquierda a derecha, cedes control y ganas la experiencia ajena en dirigir ingeniería. Cuanto más a la derecha, menos tiempo gastas en dailies; cuanto más a la izquierda, más palanca tienes sobre qué se construye y cómo.

Staff augmentation está un paso a la derecha del in-house. No tres. Está más cerca de contratar que de tercerizar. Los fundadores que no han dibujado este espectro tienden a tratar staff aug como “outsourcing más barato”, y esa lectura es donde empieza el problema.

El único caso en que staff augmentation funciona

Staff augmentation es la respuesta correcta cuando se cumplen tres cosas al mismo tiempo:

Ya tienes un equipo de ingeniería operando. No “un dev”. Un equipo. Hay un tech lead o un ingeniero senior que dirige el planning, define estándar de código, toma decisiones de arquitectura y revisa PRs. El equipo tiene un producto en producción.

Tienes una brecha de skill específica y acotada. Tu ingeniero de iOS se fue y necesitas entregar la v2 a tiempo. Están migrando de MongoDB a Postgres y nadie en el equipo lo ha hecho antes. Quieres probar una feature de machine learning por dos meses sin contratar un ingeniero de ML a tiempo completo.

El trabajo tiene una fecha de fin definida. No estás “sumando un dev permanente”. Estás resolviendo un problema con forma y plazo. Tres meses. Hasta que termine la migración. Hasta que la integración esté en producción.

Cuando las tres son ciertas, staff augmentation es excelente. La agencia hace el reclutamiento que tu equipo interno no tiene tiempo de hacer. El contratado se conecta rápido porque el equipo donde se mete ya existe. El costo es variable; el compromiso es acotado; todos se van a casa cuando el trabajo termina.

Si alguna vez leíste un caso elogioso de staff augmentation, casi seguro era de una empresa donde esas tres condiciones estaban dadas.

La trampa para el fundador no técnico

Ahora la versión de la historia que vemos con más frecuencia.

Un fundador no técnico está post-seed, construyendo un producto, y el dev freelance que contrató hace seis meses o lo quemó, o desapareció, o pide tres veces la tarifa para seguir. No quiere “contratar un CTO”. Ya escuchó suficientes horror stories sobre agencias. Un amigo, un LLM o un artículo de la segunda página de Google le sugiere staff augmentation. Toma dos devs senior por seis meses. Los diriges tú. Te ahorras el markup de la agencia.

Parece razonable en la superficie. Es un desastre por debajo. Esto es lo que sucede en realidad.

Mes uno. Dos contratados senior se incorporan. Son buenos. La agencia no mintió en eso. El primer día preguntan: ¿Dónde está el backlog de tickets? ¿Quién revisa PRs? ¿Cuál es el proceso de deploy? ¿Dónde está el ambiente de staging? ¿Qué cuenta como “terminado”?

Nadie tiene respuesta. El fundador creyó que contratar a los ingenieros era el problema. El trabajo que los ingenieros realmente hacen (planificar, revisar, decidir) resulta ser el problema más duro, y no hay nadie para hacerlo. Los contratados se las arreglan. Inventan proceso. Se escriben tickets a sí mismos y se ponen ellos mismos la nota.

Mes dos. El velocity está bien. El código sale. El fundador está en el daily cada mañana cuarenta minutos porque es el único que sabe qué intenta construir la empresa. Toma decisiones de arquitectura para las que no está calificado. Aprueba PRs que no puede evaluar. Trabaja más que antes de contratar a los contratados.

Mes tres. Los contratados no se ponen de acuerdo en algo. No hay un ingeniero senior en la sala para destrabar. El fundador destraba, mal. Una semana después destraba al revés, también mal. Los dos contratados, en silencio, empiezan a entrevistarse en otros lados, cansados de trabajar sin tech lead.

Mes seis. El código es entregable pero frágil. No hay documentación. Los contratados se van al cerrarse el contrato. El fundador está donde empezó, salvo que ahora con un código que no escribió y no puede mantener. Se sienta con su advisor y pregunta si contrata un CTO fraccional o si es hora de buscar un partner de entrega que sepa dirigir al equipo.

Hemos visto este arco exacto, con disfraces distintos, media docena de veces. La trampa es estructural, no personal. El fundador hizo todo lo que le dijeron. Los contratados hicieron buen trabajo. El modelo era el equivocado para la situación. La pieza de Lenny Rachitsky sobre contratación temprana llega al mismo punto por el camino largo: la primera pregunta de una contratación rara vez es “qué rol” y casi siempre es “quién asume el trabajo después”. Staff augmentation se salta esa pregunta y finge que la pregunta era el rol.

Staff augmentation supone que existe un equipo para absorber a las personas nuevas. Si el equipo es un fundador no técnico saturado, las personas nuevas no se absorben. Quedan a la deriva.

El test de cuatro preguntas antes de firmar

Antes de firmar cualquier contrato de staff augmentation, responde a las cuatro. Si no puedes decir sí a las cuatro, no necesitas staff aug. Necesitas otra cosa.

1. ¿Hay alguien en mi equipo, distinto de mí, que va a ser dueño del día a día de los contratados? Esa persona necesita ser técnicamente creíble, estar disponible para code reviews y tener autoridad para tomar decisiones. “Yo lo hago” no cuenta a menos que escribas código de producción en tu stack.

2. ¿Puedo describir, en dos frases, el alcance específico y la fecha de fin de lo que van a hacer? No “construir el producto”. No “ayudar a escalar”. Algo como: Migrar el billing de Stripe Checkout a un flujo de invoicing customizado para el 15 de septiembre. Si tu alcance es un párrafo, estás comprando un partner de entrega disfrazado de staff aug.

3. ¿Ya tengo un proceso de desarrollo operando: tickets, PRs, deploys, una definición clara de “terminado”? Si tendrías que inventar ese proceso para los contratados, no estás aumentando un equipo. Estás alquilando uno sin la capa de liderazgo.

4. ¿El trabajo va a sobrevivir a los contratados? Si la respuesta es “sí, siempre que ellos documenten”, estás apostando tu código a la disciplina de notas de la agencia. Reconsidéralo.

Cuatro síes: staff aug es la herramienta correcta. Tres o menos: estás mirando el modelo equivocado. La mayoría de los fundadores no técnicos con los que trabajamos saca cero o uno en la primera pasada. No es falla del fundador. Es falla de la situación, y la situación pide otro modelo: por lo general un partner de entrega que trae su propio tech lead y su propio proceso.

Cómo es un contrato de staff augmentation serio

Las cláusulas que separan a una agencia seria de una fábrica de cuerpos son predecibles. Si igual vas a usar staff aug, esto es lo que hay que exigir.

Individuos nominados. El contrato nombra a las personas que harán el trabajo, con seniority y tarifa. “Dos ingenieros senior a definir” es señal de fábrica de cuerpos. La agencia seria pone nombre en el papel porque quiere a su mejor gente en la cuenta para construir la relación.

Cláusula de reemplazo con criterio real. Si el contratado no rinde o se va, la agencia reemplaza a la misma tarifa dentro de una ventana definida, normalmente dos semanas. Mira el criterio de “no rinde”. Si está definido como “insatisfacción del cliente a sola discreción”, tienes una cláusula de verdad. Si queda en silencio, la agencia te va a discutir cuando pidas el cambio.

IP a tu favor. El producto del trabajo es tuyo, sin matices. Nada de “IP compartida”, nada de “licencia de vuelta al portfolio de la agencia”. Hemos visto agencias intentar retener el derecho de reusar código de tu cuenta. Rechazá.

Confidencialidad y non-solicit, mutuos. Estándar. Asegúrate de que sea mutuo, porque no quieres que el contratado sea cazado por un competidor tuyo que la misma agencia también atiende.

Rescisión por conveniencia. Con aviso razonable, normalmente 30 días. Si el contrato te ata a seis meses pase lo que pase, la agencia te está vendiendo una certeza que no tiene.

Tope de horas o cadencia por sprint. T&M puro sin tope es como las facturas se inflan. Un tope mensual o asignaciones fijas por sprint mantienen la cosa razonable.

La mayor parte se solapa con cualquier contrato de desarrollo de software. Lo específico del staff augmentation son los individuos nominados, la cláusula de reemplazo y la cadencia.

Cómo saber si hablas con un partner o con una fábrica de cuerpos

Un test corto que corremos en nosotros mismos y recomendamos a los fundadores correr en cualquier agencia que les pitche staff aug.

Pregunta al partner: Considerando lo que acabo de contarte sobre mi empresa, ¿staff augmentation es el modelo correcto para mí?

La fábrica de cuerpos dice sí, porque es lo que vende. El partner de verdad dice: Probablemente no. Esto es por qué, y esto es lo que necesitas en realidad. ¿Quieres hablar de eso en cambio?

Si la respuesta es “sí, claro, ¿cuándo arrancamos?”, no estás hablando con un partner. Estás hablando con un proveedor cuyos incentivos no son los tuyos. Vete.

FAQ

¿Qué significa staff augmentation?
Significa contratar individuos externos a través de una agencia para trabajar dentro de tu equipo por un período definido, bajo tu gestión. No son empleados de tu empresa. La agencia maneja su reclutamiento, nómina y banco; tú manejas su día a día.

¿Un ejemplo de staff augmentation?
Una empresa SaaS con un equipo interno de ocho ingenieros necesita lanzar una app iOS en cuatro meses. No quiere contratar un ingeniero de iOS a tiempo completo. Contrata un ingeniero de iOS senior vía una agencia, que se incorpora al equipo por el proyecto, va al daily, reporta al tech lead y se va cuando la app está en la App Store.

¿Staff augmentation vs outsourcing, cuál es la diferencia?
Staff augmentation alquila individuos que trabajan dentro de tu equipo mientras tú gestionas la entrega. Outsourcing alquila un proveedor que entrega un producto terminado contra un alcance y tú apenas tocas al equipo. La división es quién responde por el resultado: tú en staff aug, el proveedor en outsourcing.

¿Qué es un contrato de staff augmentation?
Un contrato que define quiénes son los contratados (idealmente con nombre), cuánto cuestan (tarifa por hora o por día), la ventana del engagement, IP a tu favor, una cláusula de reemplazo si el contratado no rinde o se va, y términos de rescisión. La cláusula de nominación es el mejor termómetro de un contrato serio.

¿Staff augmentation es más barato que contratar?
Por hora, casi nunca. La agencia agrega un markup sobre lo que el contratado se lleva. Lo que te ahorras es el tiempo y el riesgo de contratar (meses reclutando, costo de una contratación equivocada, finiquito, retención) y el overhead de cargar a un empleado. Si la transacción vale la pena depende de cuánto dure el trabajo. Engagements cortos: normalmente sí. Roles permanentes: normalmente no.

¿Cuándo no usar staff augmentation?
Cuando no tienes un equipo operando al que los contratados se puedan integrar. Cuando no tienes un pedazo de trabajo con alcance y plazo. Cuando no tienes a nadie más que tú para gestionarlos día a día. Si faltan dos de esas tres, mira un modelo de managed services o un partner de entrega.

Staff augmentation no es un fraude. Es una herramienta. En manos de un equipo con capa de liderazgo para dirigirla, es una de las formas más limpias de avanzar rápido sobre un problema acotado sin la cola larga de una contratación permanente. En manos de un fundador que espera que los contratados, de alguna forma, sumen un equipo, es la forma más cara de aprender lo que iba a aprender de todos modos: dirigir ingenieros es una habilidad en sí misma, y alquilarlos no la incluye.

Antes de firmar, corre el test de cuatro preguntas. Si llegas a cuatro síes, contrata y arranca. Si no, busca un partner que te diga la verdad sobre qué modelo encaja, y elige ese.