Contratar más personas no siempre resuelve el problema cuando un equipo de ingeniería va lento. La mayoría de los CTOs activan la contratación como respuesta instintiva, pero un equipo puede estar atascado por cuatro razones distintas, y cada una exige una solución diferente. Aplicar la solución equivocada no solo no ayuda: empeora las cosas.
Cuándo contratar es la respuesta incorrecta
He estado en muchas reuniones donde un director de ingeniería pedía ampliar el equipo. El argumento siempre giraba sobre lo mismo: van lentos, el backlog no para de crecer, necesitamos más gente. Y la mayoría de las veces el visto bueno llegaba rápido porque la petición parecía razonable.
Lo que tardé en aprender es que la contratación era con frecuencia la respuesta incorrecta a un síntoma equivocado. El equipo iba lento, sí. Pero meter personas nuevas en un equipo que ya estaba al límite muchas veces solo incrementaba el caos: más contexto que compartir, más tiempo perdido en incorporaciones, más coordinación consumiendo el poco margen que quedaba.
Pronto empecé a analizar el coste de esas decisiones:
- El ingeniero veterano que lleva semanas formando a los nuevos y ha dejado de producir.
- El equipo que ha perdido el ritmo justo cuando más lo necesitaba.
- La moral que baja mientras todos esperan que los nuevos se pongan al día.
Se activa la contratación, llegan los perfiles, se incorporan con prisa y seis meses después el equipo sigue igual. Solo que ahora tiene tres personas más mirándose sin saber muy bien por dónde tirar.
Existe un marco que describe esto con precisión. Los equipos no están simplemente bien o mal. Están en uno de cuatro estados muy concretos, y cada estado tiene una solución distinta.
El caso del director con sesenta ingenieros: cuando repartir es la peor opción
Un director de ingeniería con sesenta personas a cargo. La mayoría de sus equipos consideraban que necesitaban contratar con urgencia. La pregunta era inevitable: ¿repartir las contrataciones disponibles entre todos, o concentrarlas en uno o dos equipos hasta resolver su situación del todo?
La respuesta instintiva es repartir. Dar algo a cada equipo, evitar el conflicto, demostrar que nadie queda olvidado.
El problema es que esa lógica produce el peor resultado para todos. Un equipo que necesita tres personas para salir del atasco no mejora con una. Sigue atascado, pero ahora tiene a alguien más que incorporar y formar. Distribuir recursos escasos entre todos los que los piden no es equidad. Es garantizar que nadie progrese.
Los cuatro estados de un equipo de ingeniería
Estado 1 — Cayendo: el equipo que trabaja mucho y no sale del hoyo
Un equipo está cayendo cuando cada semana su backlog es más largo que la semana anterior. La gente trabaja. Trabaja mucho. Pero el trabajo no se convierte en entregas. Los tickets se acumulan, las fechas se incumplen, los usuarios se quejan.
En las empresas de ingeniería españolas este estado tiene una característica particular: el equipo calla porque decir que está desbordado suena a queja. La cultura técnica asume que los problemas se resuelven trabajando más horas. Y cuanto más se tira de eso, peor se pone el sistema.
La única salida es contratar, pero con dos condiciones que casi nunca se respetan.
Primera condición: contratar gente nueva, no reasignar a alguien de otro equipo interno. Mover a un ingeniero de un sitio a otro parece más rápido y más barato. En la práctica siempre se vuelve político. Aunque todo el mundo tenga buena fe, la conversación de quién cede a quién genera fricciones que nadie necesita cuando ya hay un problema encima de la mesa.
Segunda condición: no crecer demasiado rápido. Cada vez que llega una persona nueva, el equipo tiene que volver a cohesionarse, encontrar su ritmo, redistribuir roles tácitos que nadie había escrito en ningún sitio. Si las incorporaciones se acumulan sin dar tiempo a ese proceso, los ingenieros más veteranos acaban dedicando la mayor parte de su tiempo a formar a los nuevos. Y entonces el equipo que ya iba lento va todavía más lento, con más gente.
Desde RRHH, este es el momento de asegurarse de que la incorporación de nuevas personas no destruye lo poco que queda de cohesión. El proceso de selección, el ritmo de llegada, el acompañamiento inicial: todo eso importa más de lo que parece cuando el equipo ya está al límite.
Nota 2025: Antes de abrir una posición, vale la pena preguntarse si la IA puede dar ese oxígeno primero. Hay equipos que han ganado capacidad real sin añadir una sola persona, usando agentes de código, generación automática de tests o revisión de PRs asistida.
💡 Cuando un equipo está cayendo, la solución es contratar hasta que pueda respirar. Gente nueva, incorporada con cabeza, a un ritmo que el equipo pueda absorber. Y mientras llega el refuerzo, alguien tiene que sostener la moral con algo más que promesas.
Estado 2 — Aguantando: el equipo que sobrevive pero no avanza
Un equipo aguanta cuando consigue hacer lo urgente pero no tiene margen para nada más. Cumple los compromisos críticos. Mantiene el servicio. Pero cualquier proyecto nuevo queda aparcado y la deuda técnica crece porque arreglarla requiere tiempo que no existe.
Este estado es más peligroso que el anterior en un sentido concreto: es estable. El equipo entrega suficiente para que nadie active una alarma. Los usuarios han aprendido a no pedir demasiado. Desde fuera parece que las cosas están controladas.
El problema aquí es de proceso. El equipo tiene capacidad suficiente pero la distribuye de forma que nunca termina nada del todo. Demasiados frentes abiertos, demasiado contexto cambiando constantemente.
La solución no es contratar. Es limitar el trabajo en curso. Obligar al equipo a terminar antes de empezar. En las empresas de ingeniería españolas este cambio es culturalmente complicado. Decir que no a un proyecto nuevo mientras hay otros sin cerrar requiere una conversación difícil con dirección o con el cliente. Esa conversación nadie quiere tenerla. Y precisamente por eso nadie la tiene.
Desde RRHH se puede ayudar aquí. Cuando el director de ingeniería tiene que rechazar explícitamente más solicitudes del negocio, a veces necesita a alguien que le acompañe, que valide que la decisión tiene sentido desde una perspectiva organizativa. Ese es un papel que RRHH puede jugar si ha entendido bien en qué estado está el equipo.
Nota 2025: La IA ha cambiado dónde está el cuello de botella en este estado. Antes era capacidad de escribir código. Ahora en muchos equipos es capacidad de revisar, de decidir, de mantener criterio arquitectónico. Puedes generar más código que nunca y seguir aguantando si nadie tiene tiempo de revisar lo que se genera.
💡 Un equipo que aguanta necesita hacer menos cosas a la vez. El problema es que eso requiere decisiones valientes que el líder tiene que tomar el primero.
Estado 3 — Pagando deuda: el equipo que por fin tiene algo de oxígeno
Un equipo ha llegado a este estado cuando empieza a poder dedicar tiempo a la deuda técnica acumulada. Ya no solo apaga fuegos. Tiene espacio para arreglar cosas que lleva tiempo sabiendo que están mal.
Este estado es autoacelerado. Cada pieza de deuda que se elimina libera un poco más de tiempo para eliminar otra. El efecto es lento al principio y se va acelerando. Requiere paciencia.
En las empresas tecnológicas españolas, este es el momento en que más presión externa recibe el equipo. Los stakeholders llevan meses esperando entregas nuevas. El cliente pregunta cuándo va a ver novedades. Dirección quiere saber por qué el equipo «solo está haciendo mantenimiento». Y esa presión, si no se gestiona, puede deshacer en semanas lo que ha costado meses construir.
El trabajo del líder es proteger ese espacio. Y desde RRHH, el trabajo es ayudarle a sostenerlo: acompañar al director de ingeniería en conversaciones con dirección general donde tiene que defender ese tiempo, con un argumento claro y una lógica que se pueda explicar.
💡 Cuando un equipo empieza a pagar deuda, el riesgo no es técnico. Es político. Y el líder tiene que aguantar la presión de quienes quieren resultados visibles ya.
Estado 4 — Innovando: el estado más frágil de todos
Un equipo innova cuando su deuda técnica está bajo control, la moral es alta y la mayoría del trabajo consiste en construir cosas nuevas que los usuarios necesitan. Es donde todos quieren estar. Y es el estado que se pierde más rápido.
Un equipo que funciona bien atrae proyectos porque «tiene capacidad». Se le añaden compromisos. Se reduce su margen. En pocos meses está de vuelta aguantando. En España no nos gusta que los equipos de ingeniería parezcan ociosos. En Alemania ya saben que la innovación no nace de ingenieros con demasiada presión encima.
Hay otro riesgo que en las empresas españolas se ignora sistemáticamente. Cuando se necesita reforzar un equipo que va mal, el primer impulso es mover a alguien del equipo que va bien. Parece lógico. El coste real es que el equipo que funcionaba puede dejar de funcionar. Una sola persona menos puede ser suficiente para que un equipo pase de innovar a caer. Y entonces tienes dos equipos con problemas en vez de uno.
Hay una alternativa que no se suele considerar: cambiar el scope, no las personas. Redirigir responsabilidades hacia el equipo que tiene capacidad, sin mover a nadie de sitio. Es más lento de gestionar sobre el papel. En la práctica preserva el sistema y evita tener que reconstruir la cohesión de dos equipos a la vez.
Desde RRHH ese es un momento crítico. Porque esa decisión de mover personas casi siempre pasa por nosotros. Y si no tenemos claro en qué estado está cada equipo, es muy fácil dar el visto bueno a algo que sobre el papel parece razonable y en la práctica es un error caro.
La solución es mantener slack deliberado: tiempo que no está asignado, que el equipo usa para construir con cuidado y mejorar lo que ya existe. Desde fuera parece tiempo perdido. Es lo que mantiene el sistema en pie.
💡 Un equipo que innova necesita margen para seguir haciéndolo. Y mover a alguien de ese equipo para tapar otro agujero tiene un coste que casi nunca se calcula bien. Cambiar el scope es mejor que cambiar las personas.
Lista de verificación para RRHH: ¿tu organización tiene estos patrones?
- ¿Sabes en qué estado está cada uno de tus equipos de ingeniería ahora mismo?
- ¿La última contratación que aprobaste respondía a un diagnóstico claro del estado del equipo, o fue una respuesta al malestar que transmitía el director de ingeniería?
- ¿Antes de abrir esa posición alguien se preguntó si la IA podía dar el oxígeno que se necesitaba?
- ¿Hay algún equipo que lleva más de seis meses aguantando sin que nadie haya cambiado cómo trabaja?
- ¿La última vez que reforzasteis un equipo con problemas lo hicisteis moviendo a alguien de otro equipo interno?
- ¿Los managers intermedios pueden limitar el trabajo en curso de sus equipos, o esa decisión siempre sube?
- ¿La última vez que moviste a alguien de un equipo que funcionaba bien calculaste el coste real de hacerlo?
Conclusión: el diagnóstico correcto antes que la solución correcta
Los cuatro estados de un equipo de ingeniería —cayendo, aguantando, pagando deuda e innovando— no son categorías abstractas. Son el mapa que determina qué intervención tiene sentido y cuál no. Contratar cuando el problema es de proceso, o recortar margen a un equipo que innova, no son errores de mala intención: son errores de diagnóstico.
Saber en qué estado está cada equipo antes de tomar una decisión es la diferencia entre resolver el problema y aplazarlo con más recursos.
Este artículo toma como referencia a Will Larson y su libro An Elegant Puzzle, Stripe Press, 2019. El marco original sigue siendo válido. Algunas de las soluciones que propone merecen una revisión en el contexto actual, y eso es lo que hemos intentado hacer aquí.
Alberto Marauri — HR4TechTeam. Fractional & Interim CHRO. Consultoría RRHH para empresas tech e industriales españolas.
0 comentarios