Cómo construir tu primer equipo de ingeniería: de 3 a 15
Con tres ingenieros, todo es sencillo. Todos conocen la base de código entera. Las decisiones se toman en un hilo de Slack. No hay proceso porque no hace falta. La arquitectura es lo que el ingeniero fundador decidió un martes por la noche, y no pasa nada porque sigue ahí para explicarla.
Con quince, nada de eso funciona. El conocimiento vive en silos. Las decisiones se toman en reuniones de cuya existencia la mitad del equipo ni se entera. Y si no has ido construyendo estructura por el camino, te ahogas en deuda organizativa.
La diferencia entre los equipos que escalan bien y los que implosionan casi nunca es el talento — he visto de cerca ambos desenlaces. Es la secuencia: contratar los roles adecuados en el orden adecuado e introducir estructura en el momento justo.
La etapa de 3 a 5: generalistas que entregan
Tus primeras contrataciones deberían ser generalistas sólidos: ingenieros capaces de escribir backend por la mañana, depurar CSS después de comer y montar un pipeline de CI antes de acabar el día. No necesitan ser expertos en un dominio. Necesitan competencia en muchas áreas y comodidad con la ambigüedad.
Contrata: ingenieros full-stack senior, o de nivel medio con mucho recorrido, que hayan lanzado productos, no solo funcionalidades. Gente que resuelve las cosas por su cuenta en lugar de esperar a que le asignen tareas.
No contrates: especialistas. No necesitas un ingeniero de DevOps dedicado, un especialista en móvil para un producto que es web primero, ni un ingeniero de datos cuando tienes 200 usuarios. Cada especialista temprano es capacidad bloqueada en un dominio que quizá nunca sea tu cuello de botella.
Error común: contratar demasiado junior. El CTO piensa que puede mentorizar a dos juniors por menos dinero. En la práctica, acabas dedicando la mayor parte de tu tiempo a revisar código y a desbloquearlos — tiempo que deberías invertir en decisiones de producto y en entregar. En esta etapa, cada ingeniero tiene que aportar en neto desde la segunda semana.
La etapa de 5 a 8: primera estructura
La base de código crece. Las funcionalidades tocan varios servicios. Las revisiones de código se alargan. Empiezan los conflictos de despliegue. Es el momento de introducir procesos ligeros:
- Ciclos de planificación cortos. Semanales o quincenales. ¿Qué estamos construyendo? ¿Quién hace qué?
- Propiedad del código. Sin rigideces, pero cada área principal debería tener un referente claro.
- Una estrategia de ramas de verdad. Todo el mundo sigue el mismo flujo. Se acabó el push directo a main.
La contratación clave entre 5 y 6: un ingeniero de nivel staff que se haga cargo de la arquitectura técnica. No un manager: el ingeniero que garantiza que el sistema se sostiene. Revisa los PRs críticos, define patrones y frena al que propone añadir otra base de datos «porque sería más fácil».
Qué no contratar: un VP de Ingeniería. Lo veo constantemente. El CEO ficha a alguien cuyo último puesto era gestionar a 50 ingenieros. Esa persona llega, se encuentra con 6 ingenieros que no necesitan gestión e introduce procesos diseñados para un equipo diez veces mayor. Los standups se convierten en reuniones de estado de 30 minutos. Los ingenieros que adoraban el ritmo de startup empiezan a actualizar su LinkedIn.
Con 6 personas necesitas un líder técnico que programe el 60-80% del tiempo, no un gestor de personas.
La etapa de 8 a 12: la comunicación se rompe
Con 7 personas, el equipo se mantiene más o menos alineado por pura ósmosis. Con 9, eso se rompe. El ingeniero A no sabe que el ingeniero B ya resolvió el problema en el que está trabajando. Dos personas construyen funcionalidades que se pisan sin darse cuenta.
Es el momento de dividir en squads. Dos o tres equipos, cada uno dueño de un dominio. No microservicios: propiedad de dominio. Cada squad necesita una misión clara ligada a un resultado de negocio, un líder técnico, autonomía suficiente para planificar su trabajo y estándares compartidos para que la base de código no diverja.
La contratación clave entre 8 y 10: tu primer engineering manager. Un buen primer EM ha sido ingeniero, entiende el trabajo técnico y le importa de verdad el crecimiento de las personas. Lleva los 1:1, las conversaciones de carrera, la coordinación de las contrataciones y la alineación entre equipos.
Error común: ascender a tu mejor ingeniero a gestión. Muchas veces pierdes a un gran ingeniero y ganas un manager mediocre. Son habilidades distintas. Pregunta a la persona si de verdad quiere gestionar antes de dar por hecho que el ascenso es un premio.
La etapa de 12 a 15: organización de verdad
Las funcionalidades ya requieren trabajo de varios squads. El trabajo del CTO ha cambiado de raíz: menos código y más revisión de arquitectura, contratación y diseño organizativo.
- Las revisiones de arquitectura se formalizan. Los cambios transversales se discuten en ADRs antes de implementarse.
- La contratación se vuelve continua. Siempre estás entrevistando, siempre buscando candidatos.
- La respuesta a incidentes necesita estructura. Propiedad clara de lo que se rompe y una rotación de guardias que no queme a la gente.
La contratación clave entre 12 y 15: un Head of Engineering que se haga cargo de la estructura organizativa y del desarrollo de las personas mientras el CTO se centra en la estrategia técnica. Este es el rol que el VP fichado prematuramente con 6 personas habría desperdiciado. Con 15, hay complejidad suficiente para justificarlo.
Errores que cuestan meses
Contratar demasiado rápido. Doblar el equipo en un trimestre significa que la mitad de tus ingenieros lleva menos de tres meses de contexto. Los senior se pasan el día haciendo onboarding en lugar de construir.
No contratar con suficiente seniority. Si todos son de nivel medio, nadie marca el estándar y la base de código va a la deriva. Necesitas anclas senior en cada squad.
Ignorar la cultura. La cultura no son los pufs. Es cómo tomas decisiones, cómo gestionas los desacuerdos y cómo das feedback. Con 15 personas, si no has sido deliberado, tienes 15 suposiciones distintas sobre cómo funcionan las cosas.
Copiar el proceso de las grandes. El modelo de squads de Spotify y las prácticas SRE de Google se diseñaron para organizaciones varios órdenes de magnitud mayores. Roba ideas sueltas, no copies frameworks enteros. Tu proceso debería ser el mínimo necesario para coordinar al equipo con eficacia.
La verdad incómoda para los cofundadores técnicos: el trabajo con 3 personas no es el trabajo con 15. Si con 15 ingenieros sigues siendo quien más código escribe, el cuello de botella eres tú.
¿Estás escalando tu equipo y necesitas ingenieros senior que se integren desde el primer sprint? Habla con un CTO — te ayudamos a encontrar los ingenieros adecuados para la etapa exacta en la que estás.
