Las 5 competencias de un Tech Lead en equipos de producto (y en cuál fallamos casi todos)

TL;DR: Ser Tech Lead no es ser "el senior que además va a las reuniones". En un equipo de producto, el Tech Lead tiene que cubrir cinco frentes: discovery, equilibrio entre discovery y delivery, estrategia técnica, comunicación y multiplicación del equipo. La mayoría sobreinvertimos en la parte técnica, que es donde nos sentimos cómodos, y nos quedamos cortos justo en las dos que más impacto tienen.

🤔 Planteamiento del problema

Os cuento una situación que he visto repetirse muchas veces, tanto en mi etapa como CPO como en las clases y mentorías que doy: alguien es el mejor ingeniero del equipo, la organización le "premia" nombrándole Tech Lead, y a partir de ahí nadie le explica muy bien qué se espera de él o de ella. La definición que circula por los pasillos cabe en una frase: el que más sabe y además organiza el trabajo.

Es una definición muy cómoda, pero también es el motivo por el que muchos Tech Leads se pasan años siendo el mejor programador del equipo… y poco más. Y no es culpa suya: si nadie te dice cuál es el trabajo, haces lo que sabes hacer bien.

Seguro que os suena el caso típico, porque yo lo he visto más veces de las que me gustaría: ascienden a alguien a Tech Lead y sigue centrado exclusivamente en la tecnología. Elige el stack, decide la arquitectura y marca las prioridades técnicas sin mirar qué necesita el negocio, y poco a poco acaba secuestrando a la organización: el roadmap se mueve al ritmo de sus preferencias técnicas y no de los problemas de los clientes.

Como ya sabréis los que me habéis leído antes, para mí la tecnología es un medio para un fin. Y eso cambia por completo cómo hay que mirar el rol: un desarrollador senior impacta con lo que construye; un Tech Lead impacta con lo que construye el equipo y con qué se decide construir. Marty Cagan lo dice muy claro en Inspired: si solo usas a tus ingenieros para programar, obtienes más o menos la mitad de su valor. El Tech Lead es quien tiene que reclamar la otra mitad.

🎯 Las 5 competencias

Cuando diseñamos el framework de competencias para Tech Leads de PM4Engineers partimos de cuatro pilares: entender problemas (discovery), construir soluciones (delivery), excelencia técnica (craft) y multiplicar a otros (liderazgo). De ahí salen cinco competencias. Os las cuento con lo que se ve en el día a día cuando están y cuando no.

1. Discovery e impacto en producto 🔍

La tesis: el Tech Lead que participa activamente en discovery construye mejores soluciones, evita retrabajo y gana una influencia desproporcionada en la dirección del producto.

En un trío de producto (PM, diseño y tech), el Tech Lead aporta cosas que nadie más puede aportar: ve oportunidades que nacen de posibilidades técnicas, detecta limitaciones antes de invertir semanas en algo inviable y valida la viabilidad en tiempo real, durante la conversación con el usuario, y no tres sprints después.

• Cuando está: va a entrevistas con usuarios con cierta regularidad, se mira los analytics y los logs por iniciativa propia y, al evaluar una oportunidad, se pregunta por los cinco riesgos (valor, usabilidad, viabilidad técnica, viabilidad de negocio y ético), no solo por "¿se puede construir?".
• Cuando no: solo aparece en discovery cuando le convocan para validar algo que ya está decidido. Para entonces, la mitad de su valor se ha perdido por el camino.

👉 Más detalle en Discovery e Impacto en Producto.

2. Liderazgo dual-track ⚖️

La tesis: el Tech Lead efectivo equilibra discovery y delivery, gestiona la deuda técnica de forma estratégica y participa en las decisiones de producto.

Esta es la tensión del día a día. El sprint aprieta, el roadmap aprieta, y lo primero que se sacrifica "solo esta semana" es el discovery. Y la deuda técnica se queda esperando a un "proyecto especial" que nunca llega hasta que algo explota en producción. Ya os lo he contado otras veces cuando hablaba del ancho de banda de los equipos: la capacidad es finita, y tener una estrategia es decidir qué no vas a hacer (Rumelt approves).

• Cuando está: hay un porcentaje de capacidad acordado y visible para deuda técnica, y el Tech Lead participa en la definición de objetivos y OKRs en lugar de limitarse a recibirlos.
• Cuando no: el equipo vive en modo "todo es delivery" y la deuda solo se ataca cuando duele.

👉 Más detalle en Liderazgo Dual-Track.

3. Estrategia técnica y habilitación 🏗️

La tesis: la credibilidad técnica es el cimiento de todo lo demás. Un Tech Lead que pierde profundidad técnica pierde la capacidad de influir, de decidir bien y de mentorizar.

Ojo, que esto no significa escribir más código que nadie. Significa tomar decisiones de arquitectura que aguanten los próximos dos o tres horizontes del producto sin caer en la sobreingeniería, y construir sistemas observables y fiables.

• Cuando está: presenta las decisiones como opciones con sus compromisos explícitos (coste, tiempo, flexibilidad, riesgo), documenta las importantes con ADRs y el resto del equipo puede extender el sistema sin pasar por él.
• Cuando no: diseña para escenarios hipotéticos que nunca llegan, o lo decide todo en su cabeza y genera conocimiento tribal.

👉 Más detalle en Estrategia Técnica y Habilitación.

4. Comunicación e influencia 💬

La tesis: el impacto de un Tech Lead está limitado por su capacidad de comunicar. Una idea brillante que no se comunica bien no genera valor.

Sobre esto ya escribí hace tiempo en Comunicación estratégica para ingenieros, y sigo pensando lo mismo: las habilidades técnicas generan valor funcional, pero para influir en una decisión hay que entender a quién tienes delante y qué quiere conseguir. El Tech Lead traduce constantemente, de complejidad técnica a impacto de negocio y de necesidad de negocio a decisiones técnicas, y cada vez más por escrito y en asíncrono.

• Cuando está: cuando dice "esto es caro", lo cuantifica y trae alternativas; los stakeholders entienden los trade-offs sin necesitar una clase de arquitectura.
• Cuando no: "eso no se puede hacer", sin contexto, sin números y sin opciones.

👉 Más detalle en Comunicación e Influencia.

5. Multiplicación de equipo 🚀

La tesis: el Tech Lead más efectivo no es el que más produce, sino el que más habilita a otros. El impacto escala a través de personas, no de horas.

Esta es la que más cuesta, porque te obliga a soltar justo lo que te hizo destacar. Como diría Will Larson en Staff Engineer, el impacto viene más de habilitar a otros que del heroísmo personal. Y aquí, desde mi faceta de coach y mentor, os diría que delegar bien no es repartir tareas, es delegar problemas con contexto.

• Cuando está: hay personas del equipo que crecen visiblemente y los conflictos técnicos se resuelven con criterios explícitos, no por jerarquía.
• Cuando no: el Tech Lead es el cuello de botella; todas las PRs importantes, todas las decisiones y todos los incendios pasan por él o por ella.

👉 Más detalle en Multiplicación de Equipo.

🧐 En cuál fallamos casi todos

Si tuviera que resumir el patrón más común en una frase: sobreinvertimos en la competencia 3 y nos quedamos cortos en la 1 y en la 5. Es muy humano. La excelencia técnica es lo que nos trajo hasta aquí y es lo que sabemos medir; discovery y multiplicación son terreno nuevo, con un feedback lento y difícil de ver.

Coincide bastante con lo que veo en los programas, y suele tener dos caras. La primera: el Tech Lead no participa para nada en el discovery y su relación con el PM se resume en "tú dime qué quieres y yo te lo implemento", sin preocuparse por entender el problema de primera mano ni hablar con los clientes. La segunda: se queda las tareas más difíciles y no deja crecer a los demás. Se infla en la habitación, responde a todas las preguntas, no deja que el equipo asuma responsabilidad y, cuando aprietan los plazos, pone la presión en las personas en lugar de en los procesos.

🛠️ Cómo autoevaluarte sin engañarte

Tres preguntas rápidas para cada competencia:

1. ¿Qué hice la semana pasada que demuestre esta competencia? Si no encuentras nada concreto, probablemente no la estás ejerciendo.
2. ¿Qué diría mi PM (o mi equipo) si le preguntaran? Vuestra percepción y la suya suelen diferir más de lo que creéis.
3. ¿Qué anti-patrón se parece más a mí? Siempre hay uno, no os preocupéis, a mí también me pasa.

Si queréis algo más estructurado, hemos convertido este modelo en una evaluación gratuita de 35 preguntas que se hace en 10-15 minutos. Al terminar tenéis vuestro perfil en las cinco competencias, vuestras fortalezas y recomendaciones concretas para trabajar las áreas más flojas.

❓ Preguntas frecuentes

¿Qué diferencia hay entre un Tech Lead y un Engineering Manager? El Tech Lead es responsable de la dirección técnica y de cómo construye el equipo; el Engineering Manager, de las personas (carrera, contratación, desempeño). En equipos pequeños muchas veces una misma persona hace las dos cosas, y de ahí viene buena parte de la confusión.

¿Un Tech Lead tiene que seguir programando? Sí, pero no como antes. Lo justo para mantener la credibilidad técnica y el contexto real del sistema, sin convertirse en el camino crítico del equipo.

¿Estas competencias aplican a un Staff Engineer? En parte. El Staff Engineer comparte la estrategia técnica y la multiplicación, pero suele operar a escala de varios equipos y con menos peso en el discovery de un producto concreto.

Conclusión

En resumen, ser Tech Lead en un equipo de producto es un rol distinto, no una promoción del rol de desarrollador. Incluye la excelencia técnica, pero no se acaba ahí: discovery, equilibrio dual-track, comunicación y multiplicación son las que marcan la diferencia, y precisamente son las que nadie nos enseña.

Espero que os haya resultado útil. ¿En cuál de las cinco os veis más fuertes? ¿Y en cuál os duele más? Escribidme y lo comentamos.

---

Este artículo se basa en el framework de competencias para Tech Leads de PM4Engineers, construido sobre el trabajo de Marty Cagan (SVPG), Teresa Torres (Continuous Discovery Habits), Will Larson (Staff Engineer) y Gergely Orosz (The Product-Minded Engineer).