Señales de un buen Tech Lead
Alineando expectativas: de la arquitectura a la autonomía del equipo
La industria del desarrollo de software en los años 2010-2020 creó roles como los de Engineering Manager (EM) y Tech Lead (TL). Ya había gente haciendo una u otra antes, pero fue en esa década cuando, más o menos, todas las empresas lo adoptaron y, aunque distintas en cada empresa, tienen partes en común.
¿Qué es un tech lead? ¿Diferencias con EM?
Seguramente mucha gente ya lo tenga claro, pero explicaré mi visión de estos dos roles:
Engineering Manager: es el responsable del equipo y la mayor parte de su labor se centra en tres ejes de gestión:
Personas: que la gente tenga un buen desempeño y todo lo que eso conlleva (revisión de performance, planes de carrera profesional, etc)
Producto/proyecto: que haya un desarrollo sostenible de las funcionalidades requeridas (gestión de stakeholders, expectativas, negociación de scope, riesgos, etc)
Procesos: ¿cómo se priorizan los bugs frente a las nuevas funcionalidades? ¿Cómo se decide en qué trabajar esa semana? ¿Cómo se hace mejora continua? Aquí, lo importante no es añadir procesos ad nauseam. Es el equilibrio necesario para que el equipo opere de forma independiente — idealmente sin él — y para poner cierta estructura al caos natural.
Tech Lead: es el responsable de la dirección técnica del equipo. Su foco está en tres áreas:
Arquitectura: definir las decisiones técnicas clave, revisar las propuestas, asegurar que las soluciones escalan y que la deuda técnica sea manejable y, sobre todo, que se asuma de forma consciente y no por accidente.
Calidad: mantener un alto estándar en el código, las revisiones, las pruebas y la observabilidad. No es hacerlo todo él, sino elevar el listón del equipo.
Mentoría: ayudar a los ingenieros a crecer, desbloquear problemas complejos, compartir contexto y facilitar que todos puedan tomar mejores decisiones técnicas.
Como se puede ver, son roles muy diferentes y requieren un enfoque muy distinto. Es posible que la misma persona desempeñe ambos roles. En cierto modo, el fin de la era de intereses cero (ZIRP, en inglés) y el foco en la eficiencia han vuelto a otorgarle al EM un rol más hands-on.
Nota: en el diagrama he excluido el rol de Product Manager, dado el foco del artículo de hoy. Tu realidad seguramente sea más compleja.
Modelos operativos
Hay varios formatos para contar con alguien que ejerza liderazgo técnico en un equipo:
EM y TL son roles oficiales y los tienen dos personas diferentes
EM y TL son roles oficiales y los tiene la misma persona
EM es el único rol oficial y se espera que los ingenieros del equipo puedan liderar iniciativas técnicas sin ocupar ese rol. Esto hace que, implícitamente, el EM se asegure de que el equipo esté cubierto en las tres áreas del TL.
Hay otras formas de organización, pero estas son las más comunes. Exploraremos el modelo en el que hay un EM cuyo TL reporta a él. Para los demás casos, no es muy diferente, aunque con algunos matices. En el caso del EM+TL, el director debe realizar la evaluación de “¿qué significa bueno?”. En caso de no haber un rol formal de TL, es el EM quien debe ser consciente de las áreas por cubrir y evaluar a los ingenieros en sus distintas facetas.
Nota: hoy no hablaremos de los roles de Staff o de Principal Engineer que se extienden a más de un equipo. Lo dejaremos para otro artículo.
¿Cómo sé que un TL está haciendo bien su trabajo?
En los tres pilares que menciono antes hay algo en común: se espera que el TL tenga un efecto multiplicador en el equipo. Esto significa que es importante que el TL no se vuelva un cuello de botella, sino que ayude al equipo a ser autónomo. Si el equipo, después de un tiempo de adaptación, requiere la figura del tech lead para tomar decisiones, es señal de que hay que ajustar la forma de trabajar y que, seguramente, el TL no está cumpliendo con su rol.
Aun así, esto suena bastante abstracto. En la práctica, un buen TL se parece mucho a un ingeniero Staff+ — ese perfil que trasciende la ejecución de tareas y se enfoca en resolver problemas ambiguos o estructurales — que opera con claridad, criterio y amplitud. Es alguien que aporta dirección técnica, reduce la ambigüedad y empuja al equipo hacia decisiones que benefician al conjunto, no solo a su área.
Define el qué y el cómo cuando hace falta, pero también crea las condiciones para que otros lo hagan. Identifica riesgos, simplifica los problemas abiertos, frena el scope creep y alinea el trabajo técnico con los objetivos del producto. Y, sobre todo, genera velocidad: con principios operativos claros, con artefactos escritos que facilitan la reflexión (Requests for Comments, pruebas de concepto, propuestas de diseño) y con decisiones que otros pueden entender y continuar sin depender de él.
Podemos aterrizarlo con señales muy concretas en cada uno de los tres pilares: arquitectura, alcance técnico y principios operativos.
Arquitectura
Comportamientos que ayudan
Usar Requests for Comments (RFCs) u otros documentos breves para estructurar debates técnicos y forzar la claridad: problema, alternativas, trade-offs y decisión.
Identificar cuando una discusión se alarga sin avanzar y proponer una prueba de concepto (PoC) o un experimento acotado para validar los supuestos.
Hacer explícito cuándo ciertas decisiones generan deuda técnica y por qué se acepta en ese momento.
Involucrar al equipo en las decisiones clave para que todos comprendan el razonamiento y adquieran criterio.
Comportamientos que frenan
Tomar decisiones improvisadas en chats o en pasillos, sin dejar constancia.
Prolongar reuniones interminables sin una síntesis clara ni un siguiente paso.
Diseñar soluciones sin validar riesgos ni suposiciones mediante un prototipo.
Ser la única persona que sabe “cómo va todo” y convertirse en guardián del conocimiento.
Alcance (scope) técnico
Comportamientos que ayudan
Negociar activamente con el EM y el Product Manager el equilibrio entre la deuda técnica y la entrega de valor. Entender las restricciones del negocio y defender que la calidad es la única forma de mantener la velocidad a medio plazo.
Detectar scope creep técnico: añadidos de complejidad, requisitos no funcionales “extra” o decisiones que hacen que el sistema sea más grande sin aportar valor real.
Simplificar las soluciones proponiendo fases técnicas razonables: primero, algo que funciona; después, algo que escala. Esto es, identificar el mínimo cambio viable
Revisar regularmente si el diseño actual sigue alineado con el problema y eliminar piezas que ya no aportan.
Señalar las dependencias o riesgos técnicos que pueden retrasar al equipo si no se abordan a tiempo.
Comportamientos que frenan
Añadir requisitos técnicos “por si acaso” y aumentar el coste de la entrega sin motivo alguno.
Sobrediseñar sistemas que podrían ser mucho más simples.
Ignorar señales de que el equipo se está metiendo en una solución demasiado grande para el tiempo disponible.
Principios operativos y velocidad del equipo
Comportamientos que ayudan
Definir principios operativos escritos que sirvan como brújula: qué se prioriza, qué se evita y qué significa “bueno” en el contexto del equipo.
Ejercer influencia sin autoridad: convencer mediante argumentos y visión, no por la jerarquía. Facilitar el consenso cuando es posible y el “disagree and commit” cuando es necesario para desbloquear al equipo.
Usar estos principios para acelerar la toma de decisiones y reducir la dependencia del TL.
Revisarlos periódicamente con el equipo para adaptarlos a la realidad del producto.
Promover decisiones consistentes para que el equipo gane confianza y se mueva rápido sin pedir permiso.
Comportamientos que frenan
Tomar decisiones ad hoc que cambian cada semana y confunden al equipo.
Evitar conversaciones difíciles por miedo al conflicto (artificial harmony) o permitir que debates triviales (bikeshedding) detengan el avance del equipo.
Guardarse los criterios personales, dejando que cada persona optimice según su gusto sin una dirección técnica común.
El impacto real de un TL
En el fondo, el reto de un Tech Lead no va de saber más que el resto, sino de crear el entorno en el que el equipo pueda pensar mejor, decidir mejor y avanzar mejor. Cada organización y cada equipo necesita algo distinto, así que no hay una receta universal.
Lo que sí podemos hacer es observar cómo fluye el trabajo, cómo se reparten las decisiones y cómo evoluciona la autonomía del equipo. Ahí es donde se ve el impacto real de un TL. Y quizá la pregunta que cada uno debería hacerse no es “¿lo estoy haciendo bien?”, sino “¿estoy ayudando al equipo a depender menos de mí cada mes que pasa?” Esa respuesta suele ser más honesta y útil que cualquier checklist.
🎁 ¿Quieres aterrizar esto mañana mismo en tu equipo? ¡Un regalo sólo para suscriptores!
La fricción entre EMs y TLs suele surgir de expectativas no verbalizadas. Para cerrar esa brecha, he creado un toolkit de alineación GRATIS con tres herramientas prácticas:
Para Tech Leads: Un semáforo de autoevaluación para combatir el síndrome del impostor y saber exactamente dónde aportas valor (y dónde te estás quemando).
Para Engineering Managers: un semáforo de evaluación para dar feedback objetivo basado en comportamientos y no en sensaciones.
Para el equipo: un template de principios operativos para dejar de discutir las mismas decisiones cada semana.
Suscríbete, te enviaré el kit y pasarás de la intención a la acción. ¡Es GRATIS!
— João