Escalar un equipo técnico sin perder a las personas en el camino
Hay un momento en el crecimiento de todo equipo técnico que nadie te avisa que va a llegar.
Un día mirás para los lados y te das cuenta de que lo que antes era un equipo se convirtió en una estructura. Las conversaciones se volvieron reuniones. Las personas se volvieron recursos. Los nombres en los tickets reemplazaron a las caras en el pasillo.
No pasó de golpe. Pasó despacio, mientras todos estaban ocupados escalando.
El problema no es crecer. Es cómo crecés.
Cuando un equipo es chico, la cultura se sostiene sola. Todos saben de todo, todos conocen a todos, la confianza es el sistema operativo invisible que hace que las cosas funcionen.
Cuando ese equipo empieza a crecer, aparece la tentación — necesaria, legítima — de organizarse. De poner procesos. De definir roles. Y ahí está la trampa: si organizás sin cuidado, el proceso reemplaza a la persona. La eficiencia reemplaza a la confianza. Y terminás con una estructura que funciona en el papel pero que por dentro está vacía.
Yo lo viví cuando tuve que reorganizar mi equipo de DevOps.
Teníamos un pipeline gigante, necesidades heterogéneas, y un equipo donde todos hacían de todo. Funcionaba, pero era insostenible. Llegó el momento de organizarse.
La pregunta no era cómo dividir el trabajo.
La pregunta era cómo dividirlo sin perder lo que hacía al equipo ser un equipo.
La decisión que costó tomar
Tomé como base la separación del CI y el CD — dos mundos distintos que conviven en el mismo pipeline — y armé células especializadas. Pero no las armé por tecnología. Las armé por personas.
Antes de asignar roles, hice un mapa de calor técnico del equipo. Tomé los más de 30 temas que teníamos en danza y le pedí a cada colaborador que se autoevaluara del 1 al 5 en cada uno. Un NPS técnico interno. Sin jerarquías, sin juicios. Solo: ¿qué sabés y qué querés aprender?
El resultado me mostró algo que no esperaba: cada persona tenía una fortaleza clara y, en la mayoría de los casos, esa fortaleza coincidía con lo que más le gustaba hacer.
Organicé las células alrededor de eso.
Un colaborador era el referente de SonarQube. Otro de Jenkins. Otro de los pipelines de deploy. No porque yo lo decidí desde arriba — sino porque ellos mismos lo sabían y el mapa lo confirmó.
Lo que cambió
La primera diferencia fue inmediata: los devs sabían a quién preguntarle según el error que tenían. No había que escalar al manager ni esperar una reunión. Había una persona, con nombre y apellido, que era el referente de esa herramienta. La fricción bajó. La velocidad subió.
Pero lo más importante no fue la eficiencia.
Fue lo que pasó con las personas.
Cuando alguien es reconocido como especialista por sus pares — no por un título en un organigrama sino porque genuinamente sabe más que el resto — algo cambia en cómo se para en el equipo. Hay orgullo. Hay pertenencia. Hay una razón para estar que va más allá del salario.
El que sabía más de una herramienta le enseñaba al resto. Generamos una base de conocimiento construida desde adentro, por los mismos especialistas. No una wiki corporativa que nadie lee. Conocimiento vivo, transferido de persona a persona.
Las métricas de clima mejoraron. El onboarding de nuevos integrantes se aceleró porque había referentes claros. La rotación bajó.
Pero eso fue consecuencia, no objetivo.
Ni club de amigos ni estructura fría
Lo que aprendí de esa experiencia se puede resumir en una tensión que todo líder técnico va a enfrentar tarde o temprano:
Escalar obliga a organizar. Organizar bien obliga a conocer a las personas.
No hay proceso que reemplace ese conocimiento. Podés tener el mejor framework de gestión del mundo y si no sabés qué mueve a cada integrante de tu equipo — qué los motiva, qué los frustra, en qué son buenos, hacia dónde quieren crecer — ese framework va a ser una cáscara vacía.
El filósofo Ortega y Gasset decía “yo soy yo y mis circunstancias”. Yo creo que liderar con integridad es exactamente eso: entender que cada persona que tenés en tu equipo es inseparable de su contexto. Sus circunstancias. Su momento de vida.
Un líder transaccional ve un recurso. Un líder consciente ve una persona con circunstancias.
Y la diferencia entre los dos no es filosófica. Es práctica. Se mide en retención, en clima, en velocidad de onboarding, en la calidad del trabajo que produce un equipo que confía en su líder versus uno que simplemente le reporta.
Lo que me llevé
En una corporación grande, un líder que trata a su equipo como personas es un oasis. Lo sé porque lo viví — y porque vi la diferencia con equipos de otros sectores donde el liderazgo era puramente transaccional. La envidia era palpable. No del salario. Del ambiente.
Eso no se compra con un presupuesto de beneficios.
Se construye con decisiones pequeñas, sostenidas en el tiempo, que le dicen a cada persona: acá importás como persona, no solo como recurso.
Escalar es inevitable si hacés bien tu trabajo. Perder la esencia en el camino es una elección.
¿En qué momento de esa transición está tu equipo hoy? ¿Todavía se sienten personas o ya se sienten recursos?
Si este artículo te resonó, compartilo con alguien que esté liderando un equipo técnico en crecimiento. Y si todavía no estás suscripto a Liderazgo por Integridad, podés hacerlo desde el link en mi perfil de LinkedIn.