El mapa que ningún bootcamp te dio: las 5 capas del Tech Lead
Te promovieron a Tech Lead un martes. El miércoles seguías escribiendo el mismo código, en el mismo IDE, con el mismo equipo. Nadie te dio un manual. Y sin embargo, algo había cambiado de forma que tardarías meses en nombrar: ahora se esperaba que supieras cosas que nadie te había dicho que tenías que saber.
Esa es la parte que ningún bootcamp cubre. No porque sea difícil de enseñar, sino porque el rol no es una posición fija. Camille Fournier lo dice sin rodeos en The Manager's Path: el Tech Lead carece de una definición común. Cambia de empresa a empresa, de equipo a equipo, a veces de proyecto a proyecto dentro del mismo equipo. Es un conjunto temporal de responsabilidades, no un nivel en el organigrama.
Lo que casi nadie te explica es por qué cambia tanto. Y ahí está la idea que quiero dejarte hoy.
Por qué dos Tech Leads de la misma empresa hacen trabajos distintos
Está en algo más estructural: cada equipo tiene un agujero de conocimiento distinto, y el Tech Lead existe para taparlo.
Piénsalo desde la organización, no desde el individuo. Una empresa de ingeniería es una máquina que toma decisiones con información incompleta. Ningún manager tiene todos los datos. Ningún arquitecto conoce cada detalle del sistema. Ningún ingeniero ve el cuadro completo del negocio. El conocimiento que hace falta para decidir bien está repartido entre decenas de cabezas, y ninguna lo tiene entero.
El Tech Lead es la persona a la que la organización empuja hacia el hueco más caro. El hueco que, si nadie lo cubre, hace que el proyecto se descarrile en silencio.
Fournier cuenta un caso que reconocerás. Un ingeniero brillante, gran código, pero que odiaba hablar con gente y se perdía en detalles técnicos. Mientras él bajaba a un rabbit hole de refactoring tras otro, el product manager aprovechó su ausencia para comprometer al equipo con un roadmap mal diseñado y demasiado agresivo. El proyecto se volvió un desastre. ¿Y qué hizo el Tech Lead? Persiguió el siguiente refactor, convencido de que el problema estaba en la estructura del código.
El agujero de conocimiento que su equipo necesitaba cerrar era otro: nadie estaba traduciendo entre lo que el negocio pedía y lo que el sistema podía sostener. Él tenía las manos en la capa equivocada.
Las cinco capas, y por qué importan en ese orden
Si el trabajo del Tech Lead es cerrar gaps de conocimiento, entonces el rol no es una cosa. Son cinco trabajos distintos, y cada uno cierra un gap diferente. Los llamo capas porque se apilan: cuesta operar en una si la de abajo está rota.
La primera es la capa de ejecución. El gap que cierra es el más concreto: ¿este código resuelve el problema que dice resolver? Aquí el Tech Lead sigue siendo ingeniero. Escribe, revisa, decide trade-offs de implementación. Fournier insiste en que la mayoría de managers esperan que el Tech Lead siga produciendo casi tanto código como antes. Esa expectativa es real y no desaparece. Pero es solo la base.
La segunda es la capa de arquitectura. El gap aquí ya no es si una pieza funciona, sino si las piezas encajan a lo largo del tiempo. ¿Esta decisión nos cierra puertas dentro de dieciocho meses? El ingeniero del caso de Fournier vivía atrapado en esta capa, refactorizando estructura mientras el proyecto se hundía por razones que no eran estructurales. La arquitectura importa. Pero importa menos que la capa que casi nadie ve.
La tercera es la capa de proyecto. El gap que cierra es de coordinación: ¿quién hace qué, en qué orden, y qué pasa cuando la realidad no coincide con el plan? Fournier es directa al señalar que esta es la habilidad técnica nueva que el Tech Lead tiene que desarrollar — project management, no más profundidad técnica. Y es justo aquí donde el ingeniero brillante falló. No por incompetencia. Porque tenía las manos en las dos primeras capas mientras el agujero estaba en la tercera.
La cuarta es la capa de negocio. El gap es de traducción. El negocio habla en plazos, ingresos y riesgo de mercado. La ingeniería habla en deuda técnica, latencia y capacidad. Will Larson, en An Elegant Puzzle, describe esta capa como el punto donde un líder técnico deja de optimizar su equipo y empieza a optimizar el sistema más grande del que su equipo forma parte. El que opera aquí no pregunta "¿cómo construimos esto?". Pregunta "¿deberíamos construir esto, y qué dejamos de construir si lo hacemos?".
La quinta es la capa de organización. El gap más invisible de todos: el conocimiento que existe en una cabeza y no en ninguna otra. Tanya Reilly lo desarrolla en The Staff Engineer's Path — el trabajo de nivel senior consiste cada vez menos en saber cosas y cada vez más en hacer que el resto de la organización sepa lo que tú sabes. Documentar lo que solo tú entiendes. Conectar al ingeniero de un equipo con la decisión que otro equipo tomó hace seis meses. Cerrar este gap no escala tu trabajo. Escala el de todos los demás.
El error que comete casi todo Tech Lead recién promovido
Mira otra vez el caso de Fournier con las cinco capas delante.
El ingeniero operaba con excelencia en la capa de ejecución y en la de arquitectura — las dos donde ya era fuerte antes de la promoción. El gap real de su equipo estaba en la de proyecto y en la de negocio, las dos que más le incomodaban. Así que hizo lo que casi todos hacemos bajo presión: volvió a la capa donde se sentía competente.
Esto es lo que el organigrama no captura. La promoción te cambia el título de inmediato. No te cambia la capa donde tu instinto te lleva a refugiarte. Y bajo estrés, todos volvemos al gap que sabemos cerrar, no al que el equipo necesita que cerremos.
El instinto traiciona el rol. El instinto te lleva al código limpio cuando el equipo necesita que negocies un plazo. El instinto te lleva al diagrama de arquitectura perfecto cuando el equipo necesita que alguien diga en voz alta que el roadmap es inviable.
El mapa de las cinco capas no existe para decirte en cuál eres bueno. Existe para mostrarte cuál está abandonada. Porque el gap que tu equipo tiene abierto rara vez coincide con el que a ti te resulta cómodo cerrar.
Lo que el mapa hace que el organigrama no
Un organigrama te dice a quién reportas. No te dice qué conocimiento falta en el sistema que te rodea.
Las cinco capas son una herramienta de diagnóstico, no una escalera que se sube en orden. No "asciendes" de ejecución a organización como quien sube de nivel en un videojuego. En una semana cualquiera operas en las cinco a la vez, y tu trabajo es leer cuál de ellas tiene el agujero más caro en este momento. La que está abierta y nadie está mirando.
Esa lectura cambia cada trimestre. Cambia cuando entra un junior al equipo, cuando el negocio pivota, cuando un servicio que diste por estable empieza a fallar bajo carga. El Tech Lead que cree haber "llegado" a la capa de organización y deja de mirar las otras cuatro es exactamente el que se sorprende cuando el proyecto se hunde por un gap de proyecto que llevaba semanas abierto.
Esta semana, antes de tu próxima reunión de equipo, haz un ejercicio incómodo. Pregúntate en cuál de las cinco capas pasaste más horas la semana pasada. Y después, la pregunta que duele: ¿era esa la capa donde tu equipo tenía el agujero, o era simplemente la capa donde te sentías a salvo?
El mapa completo de las cinco capas — con las señales que indican cuándo cada una está abandonada — es lo que ningún bootcamp te entregó el martes que te promovieron. Lo tienes a un clic.
He preparado el recurso que acompaña a este post. Los suscriptores de la newsletter lo reciben gratis.