Una compañía de software B2B levantó su Serie B y el Board aprobó un presupuesto para "duplicar ingeniería en doce meses". El CTO interpretó el mandato literal: abrió quince vacantes a la vez, contrató rápido para mostrar avance y a los ocho meses tenía un equipo que había crecido en número pero entregaba menos por persona que antes. Los seniors estaban saturados haciendo onboarding, la arquitectura no había escalado al ritmo del equipo, y tres de las contrataciones recientes seguían sin ser productivas porque nadie tenía tiempo de guiarlas. El crecimiento del headcount había sido real; el crecimiento de la capacidad de ejecución, no. El problema no fue contratar mucho: fue contratar sin un plan que conectara cada incorporación con la estrategia, la secuencia y la capacidad de absorción del equipo.
Un plan de contratación tech, o headcount plan de ingeniería, es el documento que resuelve exactamente eso. Define cuántas personas, de qué roles y seniority, en qué orden y con qué presupuesto necesita el equipo para ejecutar la estrategia, y lo hace derivándolo de los objetivos de negocio en lugar de reaccionar a urgencias. Este reporte arma el marco completo: qué es un plan de contratación y por qué no es una lista de vacantes, cómo derivarlo de la estrategia de producto, qué ratios de composición usar, en qué orden contratar los roles, cómo planificar capacidad considerando el ramp-up, cuánto cuesta de verdad una contratación tech, cuándo apoyarse en búsqueda interna, headhunter o partner, y qué errores hacen que un plan se vuelva irrelevante en un trimestre.
El público objetivo es CTO, VP Engineering, Founder, CEO y CFO. Sin venta. Más de tres mil trescientas palabras con la regla de recomendar lo que sostiene la ejecución del negocio, no lo que conviene al autor.
1. Qué es un plan de contratación tech y por qué no es una lista de vacantes
Un plan de contratación tech es la traducción de la estrategia de negocio y producto en el equipo de ingeniería que esa estrategia requiere. Tiene cuatro dimensiones: el número y composición de roles, la seniority de cada uno, la secuencia temporal en que se incorporan, y el presupuesto asociado por costo total. La diferencia entre un plan y una lista de vacantes es la dirección de la lógica. Una lista de vacantes parte de las urgencias ("nos falta un backend", "renunció el data engineer") y reacciona. Un plan parte de los objetivos ("queremos lanzar el módulo de pagos en el segundo semestre y sostener el crecimiento de tráfico") y deriva qué equipo los hace posibles.
La consecuencia práctica de esa diferencia es enorme. Una lista de vacantes contrata para tapar el hueco más visible, lo que produce equipos desbalanceados, sin secuencia, donde se suman perfiles antes de tener quién los integre. Un plan contrata para construir capacidad de ejecución sostenible, lo que obliga a pensar en el orden, las dependencias y la capacidad de absorción. La pregunta que distingue a ambos no es "¿a quién necesitamos contratar?" sino "¿qué capacidad de ingeniería exige nuestra estrategia y cuál es la forma más eficiente de construirla?".
El headcount es consecuencia, no meta
Un error cultural frecuente, sobre todo después de un levantamiento de capital, es tratar el headcount como una meta en sí misma: crecer el equipo se vuelve señal de progreso. Pero el número de personas no es lo que el negocio necesita; lo que necesita es capacidad de ejecución. Diez ingenieros contratados sin secuencia ni estructura producen menos que cinco contratados en el orden correcto, con un líder técnico que define el camino y un entorno donde cada incorporación suma. El plan maduro mantiene la vista en la capacidad, no en el número, y resiste la tentación de medir el éxito de ingeniería por cuánta gente tiene.
2. De la estrategia de producto al headcount: cómo derivar el plan
La derivación del plan recorre cuatro pasos que no conviene saltarse. El error más común es empezar por el cuarto (la lista de roles) sin haber hecho los tres primeros, lo que produce un plan desconectado de lo que el negocio quiere lograr.
Los cuatro pasos de la derivación
- Traducir objetivos en iniciativas: convertir los objetivos del período en iniciativas de producto concretas, con horizonte temporal y prioridad. "Sostener el crecimiento" se vuelve "escalar la infraestructura para 3x de tráfico antes de Q3".
- Estimar capacidad requerida: estimar el esfuerzo de ingeniería de cada iniciativa en términos de equipos o capacidades, no de personas sueltas. Pensar en "un equipo de plataforma" antes que en "dos DevOps".
- Calcular la brecha: comparar la capacidad requerida con la capacidad actual del equipo. Parte de la brecha puede cerrarse con reorganización o reskilling interno, no solo con contratación nueva.
- Traducir la brecha en roles: convertir la brecha en roles concretos, seniority y secuencia, aplicando los ratios de composición que se describen más abajo.
El paso que más se omite es el tercero. Muchas compañías asumen que toda brecha de capacidad se cierra contratando, cuando una parte se cierra reorganizando equipos, redistribuyendo responsabilidades o desarrollando capacidades internas. Contratar para una necesidad que se resolvía moviendo a alguien internamente es caro y desmotiva a quien podía crecer en ese rol. El plan debe preguntarse, en cada brecha, si la respuesta correcta es contratar, reorganizar o desarrollar. La conexión entre estrategia, organización y contratación se profundiza en org design de ingeniería: squads y equipos de plataforma.
3. Ratios de referencia para dimensionar el equipo
Los ratios de composición son puntos de partida para la discusión, no reglas rígidas. Dependen del tipo de producto, la etapa de la compañía y la seniority del equipo. Sirven para detectar desbalances ("tenemos veinte ingenieros y ningún rol de plataforma dedicado") y para sostener una conversación informada con el Board sobre por qué el plan tiene la forma que tiene.
| Ratio | Rango referencial | Cuándo se ajusta |
|---|---|---|
| Ingenieros por Engineering Manager | 5 a 8 reportes directos | Más alto si el equipo es mayoritariamente Senior; más bajo si hay mucho Junior o sistemas críticos. |
| Backend por Frontend | ~1,5 a 2 por 1 | Invierte en productos muy intensivos en experiencia de usuario; se equilibra con perfiles full-stack. |
| QA / SDET por desarrolladores | 1 cada 4 a 6 | Menos si hay fuerte cultura de testing automatizado; más en dominios regulados o de alto riesgo. |
| Plataforma / DevOps dedicado | Aparece sobre 15-20 personas | Antes si la complejidad de infraestructura lo exige; puede ser parcial al inicio. |
| Datos / IA | Según dependencia del producto | Crece cuando el producto depende de analítica, modelos o IA como capacidad central. |
El ratio más importante de vigilar al escalar es el de management. Cuando un equipo crece más allá del rango sano de reportes por manager, la respuesta correcta no es solo sumar ingenieros: es abrir una nueva línea de gestión. Olvidar la capa de management al crecer es una de las causas más frecuentes de pérdida de productividad y de fuga de talento, porque las personas dejan de recibir feedback de calidad y crecimiento. Cuándo y cómo incorporar esa primera capa de gestión se trata en detalle en primer Engineering Manager: cuándo contratarlo.
4. Secuenciar las contrataciones: qué rol primero
El orden de contratación importa tanto como el número. Se ordena por dependencias: qué incorporación desbloquea a las siguientes y construye el entorno donde los perfiles más dependientes de estructura serán productivos. El principio es contratar primero a quien define el camino y deja el terreno listo para los que vienen después.
En un equipo que parte casi de cero, la secuencia típica empieza por el liderazgo técnico, alguien que defina arquitectura, estándares y prácticas antes de sumar volumen. Sigue con ingenieros senior capaces de trabajar con poca estructura y de construir las bases. Solo después incorpora perfiles mid y junior, que necesitan un entorno ya establecido para ser productivos y que aportan apalancamiento cuando hay quién los guíe. Contratar al revés (mucho junior antes de tener quién defina el camino y mentoree) es uno de los errores más caros: produce un equipo grande que avanza lento, genera deuda técnica y satura a los pocos seniors disponibles.
Regla de secuencia: nunca contratar un perfil que depende de estructura antes de haber contratado a quien crea esa estructura. Un Junior sin Senior que lo guíe no es una contratación productiva: es una carga de mentoría sin retorno y una fuente de deuda técnica. La excepción es cuando la estructura ya existe y el plan solo agrega capacidad a un equipo maduro.
Un plan de contratación no se mide por cuántas vacantes llena, sino por cuánta capacidad de ejecución agrega al negocio. Diez ingenieros contratados sin secuencia ni estructura producen menos que cinco contratados en el orden correcto. El headcount no es una meta: es una consecuencia de la estrategia.
Pablo Herrera · Founder & IT Headhunter, IT Workers5. Capacity planning: ramp-up y el costo de sobre-contratar
El capacity planning es la estimación de cuánta capacidad productiva real aporta el equipo en un período. Su insight central es que un ingeniero recién incorporado no produce a pleno desde el primer día: atraviesa un período de ramp-up que para un perfil tech suele ir de uno a tres meses hasta productividad plena, y más en sistemas complejos. Planificar como si cada contratación sumara capacidad inmediata es el error que llevó a la compañía del ejemplo a crecer en número sin crecer en entrega.
El ramp-up tiene un costo doble que el plan debe contemplar. Por un lado, la persona nueva produce por debajo de su capacidad durante semanas. Por otro, su incorporación consume tiempo de un ingeniero senior que la mentorea, lo que reduce temporalmente la capacidad de ese senior. La implicación es contraintuitiva: contratar a muchas personas a la vez puede reducir la capacidad total del equipo en el corto plazo, porque la carga de onboarding supera el aporte inmediato. Por eso el plan escalona las incorporaciones, distribuyéndolas en el tiempo para que el equipo absorba a cada persona sin saturarse.
El costo invisible de sobre-contratar
Sobre-contratar tiene tres costos que no se ven al inicio. El costo de coordinación: los equipos grandes no son linealmente más productivos, porque cada persona agrega comunicación y dependencias, y pasado cierto punto sumar gente ralentiza la entrega. El costo de ramp-up acumulado: incorporar a muchos a la vez sobrecarga a los seniors y baja la capacidad total. Y el costo de corregir: si la dotación quedó por encima de lo que el negocio sostiene, la corrección implica reducciones que dañan moral, marca empleadora y retención de quienes quedan. El plan responsable contrata por delante de la necesidad solo lo justo para no frenar la ejecución.
6. El costo total de un headcount tech, no solo el sueldo
El presupuesto de un plan de contratación debe calcularse por costo total, no por sueldo bruto. El sueldo es solo uno de varios componentes, y presupuestar solo por él subestima de forma sistemática lo que cuesta construir un equipo. Esto importa especialmente al conversar con el CFO o el Board, donde un plan que solo suma sueldos parece más barato de lo que realmente es y luego revienta el presupuesto.
Componentes del costo total de una contratación tech (primer año)
- Adquisición: tiempo del equipo en el proceso, fee de headhunter cuando aplica, herramientas de sourcing y evaluación.
- Compensación total: sueldo bruto, cargos sociales, beneficios y equity, no solo el líquido.
- Ramp-up: los meses hasta productividad plena más el tiempo de los seniors que mentorean.
- Infraestructura: hardware, licencias, herramientas y costos por persona.
La consecuencia más importante de razonar por costo total es entender por qué una mala contratación es tan cara. Cuando una incorporación falla, no se pierde solo el sueldo pagado: se pierde la inversión de ramp-up, el tiempo de los seniors que la mentorearon, el costo de oportunidad de la capacidad que no se construyó, y el costo de reabrir la búsqueda y volver a empezar. El desglose detallado de ese costo, incluyendo el costo de tener un puesto crítico vacante, está en el costo oculto de un puesto tech vacante. Esa aritmética es la mejor justificación para invertir en un proceso de evaluación riguroso antes de contratar.
7. Build, buy o partner: el mecanismo de búsqueda por rol
Un plan maduro no trata toda la contratación con el mismo mecanismo. Asigna a cada rol la forma de búsqueda adecuada según su criticidad, escasez y urgencia. Tratar un rol de liderazgo crítico igual que una posición de alto volumen, o pretender cubrir una necesidad temporal con headcount permanente, son errores de diseño del plan, no de ejecución.
Equipo de talento propio
Para roles de alto volumen y perfil conocido, cuando el equipo de talento tiene ancho de banda y la marca empleadora atrae candidatos por sí sola. Económico a escala, pero depende de capacidad interna y de una marca que traccione.
Búsqueda dirigida externa
Para roles críticos, escasos o de liderazgo, donde el costo de error es alto, el candidato ideal está pasivo y no responde a avisos, o la urgencia no permite una búsqueda larga. El criterio para usarlo está en cuándo conviene un headhunter.
La decisión entre construir el equipo internamente, buscar con un headhunter o complementar con un partner externo merece su propio análisis, que se desarrolla en outsourcing vs nearshore vs in-house y en cuándo conviene un IT headhunter. Lo relevante para el plan es que el mecanismo se decide rol por rol, y que la mezcla correcta cambia según la etapa de la compañía y la madurez del equipo de talento interno.
Sea cual sea el mecanismo, el plan solo se ejecuta si la empresa logra atraer al talento que definió y evaluarlo bien. Atraer al perfil senior cuando no se compite por ser quien más paga es un desafío propio, tratado en employer branding tech: cómo atraer talento senior. Y evaluar de forma estructurada a quienes llegan, para no convertir un buen plan en malas contrataciones, se aborda en scorecard de contratación tech.
8. Errores frecuentes en planes de contratación tech
Error 1: empezar por la lista de roles
Saltarse la derivación desde la estrategia y partir de "qué roles abrir" produce un plan desconectado del negocio. Sin los pasos de traducir objetivos en capacidad y calcular la brecha, el plan contrata gente sin conexión clara con lo que la compañía quiere lograr.
Error 2: ignorar el ramp-up en la planificación de capacidad
Asumir que cada contratación suma capacidad inmediata sobrestima lo que el equipo entregará y subestima la carga de mentoría. Contratar a muchos a la vez puede bajar la capacidad total en el corto plazo. La capacidad se planifica escalonada.
Error 3: confundir headcount con capacidad
Medir el éxito de ingeniería por cuánta gente tiene en lugar de cuánto entrega. Equipos más grandes no son linealmente más productivos; pasado cierto punto, sumar personas sin estructura ralentiza la ejecución.
Error 4: presupuestar solo por sueldo
Calcular el plan por sueldo bruto ignora adquisición, cargos sociales, ramp-up e infraestructura. El plan parece barato, revienta el presupuesto a mitad de año y subestima el costo de una mala contratación.
Error 5: un plan que no se revisa
Construir el plan una vez al año y archivarlo. Las prioridades de producto cambian y las contrataciones reales nunca siguen el calendario previsto. Un plan que no se revisa trimestralmente se vuelve irrelevante y las decisiones vuelven a tomarse por urgencia.
9. FAQ: preguntas frecuentes de CTOs y Founders
¿Qué es un plan de contratación tech o headcount plan?
Es el documento que define cuántas personas, de qué roles y seniority, en qué secuencia y en qué plazo necesita el equipo de tecnología para ejecutar la estrategia de producto, junto con el presupuesto por costo total. No es una lista de vacantes: es la derivación, desde los objetivos de negocio, del equipo que esos objetivos requieren. Un buen plan responde no solo cuántos ingenieros contratar, sino en qué orden, con qué dependencias, a qué velocidad puede absorber el equipo a los nuevos, y cuánto cuesta de verdad cada incorporación más allá del sueldo.
¿Cómo se deriva el plan desde la estrategia de producto?
En cuatro pasos: traducir los objetivos del período en iniciativas de producto con horizonte temporal; estimar el esfuerzo de ingeniería de cada una en equipos o capacidades, no en personas sueltas; comparar la capacidad requerida con la actual para identificar la brecha; y traducir esa brecha en roles, seniority y secuencia, considerando que parte se cierra con reorganización interna. El error más común es saltarse los primeros tres pasos y empezar por la lista de roles, lo que produce un plan desconectado de lo que el negocio necesita lograr.
¿Cuál es el ratio recomendado de ingenieros por manager?
Entre cinco y ocho reportes directos por Engineering Manager. Por debajo de cuatro, el manager tiende a sobre-gestionar; por encima de ocho o nueve, no alcanza a dar feedback de calidad y la retención cae. El número depende de la seniority del equipo y de cuánto trabajo individual conserva el manager. Cuando el equipo crece más allá del rango, el plan debe incluir abrir una nueva línea de gestión, no solo más ingenieros individuales: olvidar la capa de management es una causa frecuente de pérdida de productividad al escalar.
¿Qué ratios de composición de equipo conviene considerar?
Además del ratio de management, la proporción backend/frontend (en productos web típicos suele rondar 1,5 a 1 o 2 a 1 a favor de backend), la presencia de QA o SDET (un ingeniero de calidad cada cuatro a seis de desarrollo), la capa de plataforma o DevOps (aparece como rol dedicado sobre quince a veinte personas) y los roles de datos e IA (según la dependencia del producto). Son puntos de partida para discutir, no reglas rígidas: el plan los ajusta al producto específico y a la etapa de la compañía.
¿En qué orden conviene contratar los roles de un equipo nuevo?
Por dependencias y capacidad de desbloquear a los siguientes. En un equipo casi desde cero, el orden típico empieza por el liderazgo técnico (que define arquitectura y estándares), sigue con ingenieros senior capaces de trabajar con poca estructura, y solo después incorpora perfiles mid y junior que necesitan un entorno establecido. Contratar al revés (mucho junior antes de tener quién los guíe) es de los errores más caros: produce un equipo grande que avanza lento y genera deuda técnica. La regla es contratar primero a quien construye el entorno donde los siguientes serán productivos.
¿Qué es el capacity planning y por qué importa el ramp-up?
El capacity planning estima cuánta capacidad productiva real aporta el equipo en un período, considerando que un ingeniero recién incorporado no produce a pleno desde el día uno. El ramp-up es ese período de incorporación, que para un perfil tech suele ir de uno a tres meses hasta productividad plena, y más en sistemas complejos. Importa porque planificar como si cada contratación sumara capacidad inmediata sobrestima la entrega y subestima la carga de mentoría sobre los seniors. Contratar a muchos a la vez puede bajar la capacidad total temporalmente; por eso el plan escalona las incorporaciones.
¿Cuánto cuesta realmente una contratación tech más allá del sueldo?
El costo total incluye adquisición (tiempo del equipo, fee de headhunter si aplica, herramientas), compensación total (sueldo bruto, cargos sociales, beneficios, equity), ramp-up (meses hasta productividad plena más tiempo de los seniors que mentorean) e infraestructura por persona. El costo total del primer año suele superar de forma significativa el sueldo bruto anual. Por eso el plan debe presupuestar por costo total y no solo por sueldo, y por eso una mala contratación es tan cara: no solo se pierde el sueldo, sino la inversión de ramp-up, el costo de oportunidad y el costo de reabrir la búsqueda.
¿Cuándo conviene contratar interno y cuándo usar headhunter o partner?
Depende del rol, la urgencia y la capacidad interna de búsqueda. La búsqueda interna sirve para roles de alto volumen y perfil conocido, cuando el equipo de talento tiene ancho de banda y la marca empleadora atrae candidatos. El headhunter sirve para roles críticos, escasos o de liderazgo, donde el costo de error es alto, el candidato ideal está pasivo y la urgencia no permite una búsqueda larga. Un partner de staff augmentation o nearshore sirve para necesidades temporales o para validar una función antes de comprometer headcount permanente. El plan maduro combina los tres según el tipo de rol.
¿Cada cuánto se revisa un plan de contratación tech?
Se construye con horizonte anual pero se revisa trimestralmente. La revisión anual fija el marco: objetivos, brecha de capacidad, presupuesto total. La trimestral ajusta la ejecución a la realidad: qué roles se cerraron, qué se atrasó, cómo cambió la estrategia, qué supuestos se movieron. Un plan que no se revisa se vuelve irrelevante en un trimestre porque las prioridades de producto cambian y las contrataciones reales nunca siguen el calendario previsto. La disciplina es mantenerlo como documento vivo, de modo que cada decisión se evalúe contra un marco actualizado y no contra la urgencia del momento.
¿Cuál es el riesgo de sobre-contratar en tecnología?
Tres costos no visibles al inicio. El de coordinación: los equipos grandes no son linealmente más productivos, porque cada persona agrega comunicación y dependencias, y pasado cierto punto sumar gente ralentiza la entrega. El de ramp-up acumulado: incorporar a muchos a la vez sobrecarga a los seniors y baja la capacidad total. Y el de corregir: si la dotación quedó por encima de lo que el negocio sostiene, la corrección implica reducciones que dañan moral, marca empleadora y retención de quienes quedan. Por eso el plan responsable contrata por delante de la necesidad solo lo justo para no frenar la ejecución.
¿Estás dimensionando el equipo de ingeniería para el próximo año?
Conversación de 20 minutos para revisar tu plan de contratación tech: brecha de capacidad, ratios, secuencia de roles y qué buscar interno versus con apoyo externo. Recomendación honesta sin venta forzada.
Hablar con un consultor WhatsApp directo