El ascenso a tech lead casi nunca viene con instrucciones. Un viernes sos el que mejor resuelve problemas técnicos y el lunes sos responsable de que los resuelva otro. Esa primera semana define expectativas que después cuesta mucho corregir.

Los errores que siguen no son fallas de carácter: son respuestas lógicas a una situación nueva. Casi todos nacen de la misma tensión —seguir demostrando valor con lo que sabías hacer, mientras el trabajo pasó a ser otro—. Verlos antes de cometerlos ahorra meses.

Error 1: micromanaging por inseguridad

Es el más frecuente. Como todavía no confiás en tu propio criterio para liderar, compensás controlando lo único que dominás: el código. Revisás cada pull request con lupa, pedís cambios de estilo, reasignás tareas.

El equipo lo lee como desconfianza y reacciona previsiblemente: deja de tomar decisiones y empieza a preguntarte todo. Terminás siendo el cuello de botella que querías evitar.

Qué hacer: definí explícitamente qué decisiones toma cada quien. Por ejemplo: cambios dentro de un módulo, decisión del autor; cambios de arquitectura o de contrato de API, conversación previa. Ponelo por escrito en la primera semana. En las revisiones de código, separá lo que bloquea de lo que es preferencia personal, y marcá esta última como opcional.

Error 2: dejar de programar de golpe

El extremo opuesto y también común: asumir que liderar significa no volver a tocar código. En equipos chicos y medianos, un tech lead que pierde contacto con la base de código pierde en pocos meses la capacidad de estimar, de evaluar riesgos y de discutir de igual a igual.

Qué hacer: reservá entre el 20% y el 30% de tu semana para trabajo técnico, pero elegí bien qué. No tomes tareas del camino crítico —tus interrupciones las van a retrasar—. Tomá lo que nadie quiere y todos necesitan: herramientas internas, deuda técnica, mejoras del entorno de desarrollo, revisiones profundas de diseño técnico.

Error 3: no establecer los 1:1 desde el día uno

Postergar las reuniones individuales porque "todavía no hay nada que hablar" es el error más caro a mediano plazo. Cuando finalmente las agendás, ya es tarde: el 1:1 aparece asociado a un problema y genera tensión.

Qué hacer: agendalos la primera semana, treinta minutos cada quince días como mínimo. En el primero no hables de tareas: preguntá qué le gustaría estar haciendo dentro de un año, qué le frustra del día a día y cómo prefiere recibir feedback. La agenda la propone la persona; vos escuchás. Las investigaciones sobre gestión de equipos que publica Gallup son consistentes en un punto: la calidad de la relación con el jefe directo es el factor que más explica el compromiso y la rotación.

Error 4: querer cambiar todo en la primera semana

Llegás con una lista de mejoras acumulada desde antes del ascenso y arrancás a ejecutarla. El problema no son las ideas: es que cada práctica que querés cambiar tiene una historia que no conocés, y modificarla sin entenderla te cuesta credibilidad.

Qué hacer: primera semana, escuchar y documentar. Preguntá "¿por qué se hace así?" antes de proponer alternativas. Elegí un solo cambio, el de mayor impacto y menor resistencia, e implementalo bien. Un cambio exitoso te compra permiso para los siguientes; cinco cambios simultáneos que fallan te lo quitan todo.

Error 5: seguir siendo "uno más" del equipo

Cuando ascendés dentro del mismo equipo aparece la tentación de negar el cambio: "somos los mismos de siempre". Es cómodo por unos días y problemático después, porque ahora tenés información que ellos no tienen y tomás decisiones que los afectan.

Qué hacer: nombrá el cambio de forma explícita en la primera conversación grupal. Algo simple: "cambió mi rol, no la relación; hay cosas que ahora decido yo y otras que voy a poder contarles y otras no". La claridad incomoda menos que la ambigüedad. Este artículo sobre cómo gestionar tu primer equipo tech profundiza en esa transición.

Error 6: no gestionar hacia arriba

Toda la atención va al equipo y ninguna a la relación con tu propio jefe, con producto y con las áreas que dependen de ustedes. El resultado típico: te enterás tarde de un cambio de prioridades, o tu equipo trabaja tres semanas en algo que ya no era prioritario.

Qué hacer: acordá en la primera semana con quién reportás qué expectativas tiene de vos, con qué frecuencia querés actualizarlo y qué decisiones necesitás poder tomar sin consultar. Y construí una comunicación regular con producto: la mayoría de los conflictos entre desarrollo y producto son de información, no de intereses.

Un plan concreto para la primera semana

Lo que en realidad se está evaluando

Un tech lead no se mide por cuánto código escribe sino por lo que produce su equipo, por cuánta gente crece bajo su conducción y por la calidad de las decisiones técnicas que sostiene. Es un cambio de métrica que lleva meses internalizar.

Vale recordar que las competencias que más crecen en demanda según el Future of Jobs Report del World Economic Forum incluyen liderazgo, influencia social y gestión del talento junto a las técnicas. La conducción de equipos no es un desvío de la carrera técnica: es la habilidad que la vuelve escalable. Si querés ordenar tu estilo antes de asumir, esta guía sobre estilos de liderazgo y cuándo aplicar cada uno es un buen punto de partida.

Cursos recomendados de Coderhouse

• Para la base de conducción: el Curso de Liderazgo y Gestión de Equipos trabaja delegación, feedback y manejo de conflictos, que es exactamente donde se traba la primera etapa.

• Para comunicar mejor: el Curso de Oratoria ayuda con lo que más cuesta al principio: presentar decisiones técnicas a audiencias no técnicas y sostenerlas.

• Para entender el otro lado de la mesa: el Curso de Product Manager te da el vocabulario de producto que necesitás para negociar alcance y prioridades sin fricción.

Preguntas frecuentes

¿Un tech lead tiene que seguir programando?

En equipos chicos y medianos, sí, aunque en menor proporción: entre el 20% y el 30% del tiempo es un rango razonable. Lo importante es qué tipo de trabajo tomás. Evitá tareas del camino crítico, porque tus interrupciones las retrasan, y priorizá deuda técnica, herramientas internas y revisiones de diseño.

¿Cómo manejo liderar a gente que antes era mi par?

Nombrando el cambio de forma explícita en lugar de fingir que no pasó nada. Definí qué decisiones ahora te corresponden, sé consistente con todos —el favoritismo con excompañeros cercanos es el riesgo más grande— y usá los 1:1 para reconstruir la relación sobre la base nueva.

¿Qué hago si alguien del equipo sabe más que yo técnicamente?

Aprovecharlo. Tu rol no es ser el mejor técnico, es que el equipo produzca. Delegá en esa persona las decisiones de su área de dominio, hacela visible ante el resto de la organización y usá su criterio como insumo. Fingir que sabés más de lo que sabés destruye la credibilidad más rápido que admitir lo que no dominás.

¿Cada cuánto conviene hacer los 1:1?

Cada quince días como mínimo, treinta minutos. Semanal si el equipo es chico o si alguien está atravesando un cambio importante. Lo que no funciona es agendarlos solo cuando hay un problema: eso convierte la reunión en una señal de alarma.

¿Cuánto tarda la transición a tech lead?

El período de mayor incomodidad suele durar entre tres y seis meses. Es el tiempo que lleva dejar de medir el propio día por líneas de código y empezar a medirlo por lo que el equipo entregó y por cómo evolucionó cada persona. Si a los seis meses seguís sintiendo que "no hiciste nada" cuando el equipo entregó bien, todavía estás usando la métrica anterior.