En staff augmentation sumas ingenieros sueltos a tu equipo y los diriges tú: toman tareas de tu tablero, abren pull requests en tus repositorios y están en tu reunión diaria. En un equipo dedicado, el proveedor te da un grupo pequeño con su propio líder que se hace cargo de una parte de tu producto; tú fijas prioridades y ese líder organiza el día a día. En el outsourcing entregas un alcance definido y recibes un resultado terminado; cómo se construye lo decide el proveedor.
Lo que separa a los tres es quién dirige el trabajo de cada día y dónde queda el conocimiento cuando termina el contrato. La experiencia de la gente, el país y la tarifa pesan menos de lo que se suele creer.
Antes de seguir, una aclaración. Mi empresa, Softronic, coloca ingenieros senior de uno en uno dentro de equipos de clientes. No vendo equipos dedicados: armar un grupo coordinado (un líder técnico, dos seniors, alguien de DevOps) exige tener ingenieros esperando en la banca, y una firma de mi tamaño no los tiene. Es decir, tengo un sesgo a favor del staff augmentation. Voy a intentar ser justo igual, y te voy a decir cuándo te conviene otra cosa, que pasa bastante.
Los tres modelos, uno al lado del otro
| Staff augmentation | Equipo dedicado | Outsourcing (proyecto) | |
|---|---|---|---|
| Quién dirige el trabajo diario | Tú | El líder del equipo | El proveedor |
| Qué controlas | Cada tarea | Prioridades y resultados | Alcance y aceptación |
| Dónde queda el conocimiento | En tu equipo | Repartido entre tú y ellos | Sobre todo en el proveedor |
| Qué tienes que poner tú | Un líder con tiempo para dirigir | Un área de trabajo clara y separable | Una especificación escrita |
| Cómo suele fallar | Nadie tiene tiempo de dirigirlos | El equipo se queda parado esperando tus decisiones | No puedes cambiar el sistema sin ellos |
¿Cuándo conviene el staff augmentation?
El staff augmentation tiene sentido cuando ya tienes un equipo de ingeniería con líder, con una lista de trabajo priorizada y una forma de trabajar, y lo que falta son manos. Necesitas dos personas más de backend que sepan leer un plan de consulta de Postgres, o alguien que haya operado Kubernetes en producción. No necesitas que nadie venga a organizar nada.
Lo que casi siempre se subestima es que al ingeniero lo diriges tú. Las primeras dos semanas alguien de tu lado tiene que explicarle por qué el módulo de facturación está estructurado así, revisar con cuidado sus primeros pull requests y contestar bastantes preguntas por Slack. Después, debería pedirte la misma atención que cualquier buen empleado remoto. Pero si tu líder técnico ya es el cuello de botella, sumarle gente que le reporta a él solo lo aprieta más.
En mi versión, yo me encargo de lo que hace pesada la contratación en otro país. Las entrevistas técnicas las hago yo (son tres, y después hay dos semanas de prueba pagada antes de que la persona entre a tu equipo), y mi empresa tiene el contrato, paga la nómina y cumple con las obligaciones laborales locales. Tú recibes una sola factura mensual en dólares. Hay proveedores, y me incluyo, que a esto le dicen “hiring as a service”. Sigue siendo staff augmentation: cambia quién carga con la validación y el papeleo, pero la dirección del trabajo sigue siendo tuya.
Como referencia, mis tarifas publicadas para un ingeniero senior a tiempo completo van de 6.000 a 8.000 dólares al mes, y puedes terminar con 30 días de aviso, sin penalización. Está todo en la página de contratar ingenieros LatAm.
¿Cuándo conviene un equipo dedicado?
Un equipo dedicado es la compra correcta cuando hay un área entera que quieres construir y mantener sin cargarle más gestión a tu gente. Una app móvil cuando no tienes a nadie que sepa liderar desarrollo móvil. Una línea de producto aparte. Una plataforma interna que necesita su propio ritmo.
Aquí conviene tener presente la ley de Conway, de un artículo de 1968: el diseño de un sistema termina copiando la estructura de comunicación de la organización que lo construye. Si pones a un equipo externo sobre una parte de tu producto, tarde o temprano esa parte se convierte en un componente separado, con una frontera entre “su” código y el “tuyo”. No pasa nada si es una frontera que habrías elegido de todas formas. Una app móvil que consume tu API es una frontera limpia. “La mitad del backend” no lo es.
Por eso, antes de contratar un equipo dedicado, intenta describir esa frontera en un párrafo: de qué se hacen cargo, qué usan de tu lado y qué no deben tocar nunca. Si no te sale, el equipo va a pasar los días esperando que tus ingenieros decidan cosas, y vas a pagar por una coordinación que no puedes aprovechar.
Cuando la frontera está clara, un buen equipo dedicado rinde más que la misma cantidad de contratistas sueltos, porque la coordinación entre ellos ya viene resuelta. Tú revisas resultados, no commits.
¿Cuándo conviene tercerizar?
Tercerizar es distinto a los dos anteriores, porque lo que compras es un entregable, no personas. Defines el alcance, el proveedor lo construye y tú lo aceptas. El riesgo de entrega pasa a ellos, y el cómo también.
Sirve muy bien para trabajos acotados: un sitio web, una integración con especificación clara, una herramienta interna con pantallas conocidas, una primera versión que quieres validar antes de invertir más. Así planteo los proyectos de software a medida: primero dejo el alcance por escrito y luego cotizo a precio cerrado, porque solo funciona cuando las dos partes pueden ponerse de acuerdo en qué significa “terminado”.
Lo que cedes es contexto. Las personas que mejor entienden el sistema no trabajan para ti, y las razones detrás de la mitad de las decisiones se quedan en sus cabezas. Para algo que vas a terminar y casi no vas a tocar, es un precio razonable. Para el sistema del que depende tu negocio, que va a seguir cambiando durante años, sale caro y lento.
Los errores que más cuestan
Estos son los que le advertiría a un amigo:
- Tercerizar el núcleo del negocio. Si el sistema es central y sigue cambiando, dárselo a un proveedor de proyecto significa que cada cambio de rumbo arranca con una cotización nueva y un traspaso de contexto.
- Sumar ingenieros sin nadie que los dirija. Van a estar ocupados, pero no necesariamente en lo que importa.
- Un equipo dedicado sin frontera. Contratas una unidad que se organiza sola y la pones a trabajar dentro de tu módulo más enredado, donde cada decisión pasa por tu arquitecto.
- Meter gente en tu equipo para un trabajo de una sola vez. Si el trabajo tiene un final claro y no lo vas a mantener, tener ingenieros en tu reunión diaria durante seis meses es gestión que te podías ahorrar. Un proyecto cerrado habría sido más limpio.
Ninguno de estos modelos es para siempre. Es normal empezar con un senior integrado y sumar un equipo cuando el área crece, o reducir un equipo a una sola persona cuando el proyecto pasa a mantenimiento.
Mídelos a los tres con la misma vara
Elijas lo que elijas, evalúalo como evaluarías a tu propio equipo. Las métricas de entrega de software de DORA sirven justamente porque no les importa quién firmó el contrato: tiempo de entrega de cambios, frecuencia de despliegue, tiempo de recuperación tras un despliegue fallido, tasa de cambios fallidos y tasa de retrabajo en despliegues. Si la relación funciona, esos números mejoran. Si no, ningún informe semanal lo va a tapar por mucho tiempo. Y un proveedor que se resiste a que lo midan por lo que entrega ya te está dando una respuesta.
Una prueba que puedes hacerte a ti primero
Antes de hablar con cualquier proveedor, contesta por escrito tres preguntas, una por modelo:
- Staff augmentation: ¿quién, con nombre y apellido, va a revisar los primeros diez pull requests del ingeniero nuevo? Si no hay nadie con tiempo, el modelo se va a estancar.
- Equipo dedicado: ¿puedes describir en un párrafo la frontera del equipo, incluido lo que no debe tocar? Si no, todavía no estás listo para un equipo.
- Outsourcing: ¿puedes escribir criterios de aceptación que un desconocido pueda verificar? Si no, el precio cerrado va a quedar cerrado sobre lo que no era.
La pregunta que te resulte más fácil de contestar suele señalar el modelo correcto. Cuando sepas cuál estás comprando, las preguntas para mandarles a los proveedores están en la guía para evaluar un proveedor nearshore. Si es staff augmentation y quieres un ingeniero senior que pasó por mis entrevistas, cuéntame del rol.