El mapa que ningún bootcamp te dio: las 5 capas del Tech Lead
Un ingeniero senior recibe el título de Tech Lead un lunes por la mañana. Tres meses después, su equipo entrega tarde un proyecto que él mismo diseñó, revisó y en gran parte escribió. El código es correcto. La arquitectura es sólida. Y aun así el proyecto fracasó: nadie en el equipo entendía por qué se estaban construyendo esas features, el product manager había comprometido fechas imposibles sin que nadie lo frenara, y dos personas del equipo estaban resolviendo el mismo problema sin saberlo.
Cuando su manager le pregunta qué pasó, él responde con lo único que sabe hacer bien: propone refactorizar el módulo que más problemas dio.
Esa respuesta es el caso. No porque sea absurda, sino porque es la respuesta perfecta a la pregunta equivocada.
Dos formas de leer el fracaso, ambas defendibles
Hay una lectura que dice: el problema es técnico. El módulo estaba mal estructurado, la deuda técnica ralentizó al equipo, y con mejor arquitectura el proyecto habría salido a tiempo. Esta lectura tiene una virtud enorme — es accionable. El Tech Lead sabe refactorizar. Puede hacerlo hoy. Y en muchos casos, es correcta: he visto proyectos hundidos por un diseño que obligaba a coordinar cinco componentes para un cambio de una línea.
Hay otra lectura que dice: el equipo entregó tarde porque nadie tradujo la intención del negocio a decisiones técnicas, porque nadie protegió al equipo de un compromiso irreal, porque nadie detectó que dos personas duplicaban trabajo. Esta lectura también es correcta. Y es mucho menos cómoda, porque ninguna de esas cosas se arregla escribiendo mejor código.
El costo de elegir mal es real. Si el Tech Lead cree la primera y el problema era la segunda, refactorizará un módulo impecable mientras el próximo proyecto falla por las mismas razones. Repetirá el diagnóstico técnico ante cada síntoma organizativo. Y cada vez estará más seguro de que solo necesita más tiempo para arreglar el código.
¿Cómo sabe cuál de las dos lecturas aplica? Ahí empieza el trabajo.
Qué sabía cada persona que él no sabía
Empieza por la pregunta más incómoda: en el momento del fracaso, ¿quién tenía la información que habría evitado cada problema?
El compromiso de fechas imposibles. El Tech Lead no estaba en la sala cuando el product manager las prometió. Pero alguien sí sabía que eran irreales: probablemente el propio equipo, que había estimado por encima en privado y calló en público. La información existía. No estaba en la cabeza del Tech Lead, y tampoco tenía por qué estar. Estaba repartida en el equipo, y no había ningún canal por el que llegara a quien podía frenar el compromiso.
El trabajo duplicado. Dos personas resolviendo el mismo problema sin saberlo. Cada una tenía la mitad del cuadro. Ninguna tenía el cuadro completo, y el Tech Lead tampoco — porque estaba metido en su propio código, en su propio rabbit hole técnico, exactamente como el tech lead que Camille Fournier describe en The Manager's Path: el ingeniero brillante que persigue el siguiente refactor mientras el proyecto se desmorona a su alrededor.
El equipo que no entendía el porqué. Aquí el gap se invierte. La información existía en la cabeza del Tech Lead — él sí sabía por qué se construían esas features — y no llegó al equipo. El conocimiento estaba, pero atrapado en la persona equivocada.
Fíjate en lo que aparece cuando pones los tres fracasos uno al lado del otro. No son tres versiones del mismo error. Son tres gaps de conocimiento distintos, en tres direcciones distintas, cada uno pidiendo un tipo de intervención diferente. Y ninguno se cierra escribiendo mejor código.
Cada capa del rol cierra un gap distinto
Ahora la pregunta que ordena todo: si cada fracaso fue un gap de conocimiento en un lugar distinto de la organización, ¿el rol de Tech Lead no será, en realidad, la suma de las capacidades de detectar y cerrar cada uno de esos gaps?
Mira el primer gap: información técnica dentro del propio código. Cuando el problema es que nadie entiende cómo está estructurado un sistema, o dónde está el cuello de botella real, el Tech Lead lo cierra siendo el mejor ingeniero que puede ser. Esta es la capa que todo bootcamp entrena y la única que el ingeniero recién promovido domina. Es real y es necesaria. También es la más pequeña de las cinco.
El segundo gap: conocimiento que existe en el equipo pero no fluye entre sus miembros. Las dos personas duplicando trabajo, el equipo que estimó alto en privado. Cerrarlo no requiere más habilidad técnica — requiere diseñar las condiciones para que ese conocimiento circule sin que el Tech Lead sea el punto por el que todo pasa. Aquí es donde An Elegant Puzzle de Will Larson resulta más útil que cualquier manual de arquitectura: el trabajo deja de ser resolver el problema y pasa a ser diseñar el sistema donde el equipo resuelve sus propios problemas. Un Tech Lead que se convierte en el router de toda la información del equipo no cierra el gap. Se convierte en el gap.
El tercer gap: conocimiento entre el equipo y el resto de la organización. El product manager que compromete fechas, el stakeholder que no entiende por qué algo tarda, el equipo vecino que va a romper tu API sin avisar. Nadie del equipo tiene visibilidad de ese espacio salvo quien decide ocuparlo. El Tech Lead que se queda en su código deja ese espacio vacío, y alguien lo llenará — normalmente en contra de los intereses del equipo, como el product manager de la historia que aprovechó la ausencia del tech lead para atropellar al equipo entero.
El cuarto gap aparece más tarde, cuando el rol crece: conocimiento sobre hacia dónde va el negocio y qué decisiones técnicas hoy habilitan o bloquean ese futuro. Es el gap que separa a alguien que ejecuta bien un roadmap de alguien que influye en cuál debería ser. The Staff Engineer's Path de Tanya Reilly dedica buena parte de su argumento a esto: el trabajo de mirar más allá del equipo, de ver el sistema completo que nadie más está mirando.
Y el quinto, el más difícil de ver porque no cierra un gap concreto sino que construye a quienes cerrarán los futuros: el conocimiento sobre cómo hacer crecer a otros ingenieros hasta que ellos detecten y cierren gaps sin ti. Es la capa que multiplica en lugar de sumar.
¿Notas lo que acaba de pasar? No definí cinco capas y luego busqué dónde encajaban. Partimos de un fracaso concreto, encontramos que escondía distintos gaps de conocimiento, y las capas emergieron como respuesta a cada uno. El mapa no es una teoría de la carrera. Es la geografía de los gaps que un Tech Lead aprende a ver.
Por qué el mapa importa antes de recorrerlo
El error del protagonista no fue elegir mal entre las dos lecturas del principio. Fue no saber que existían cinco. Con un solo instrumento en la mano — el código — todo fracaso se le apareció como un fracaso de código. Diagnosticó lo único que sabía diagnosticar.
Esto generaliza a cualquier Tech Lead recién promovido, con o sin este caso. El primer trabajo del rol no es dominar las cinco capas — eso lleva años y probablemente nunca se completa. El primer trabajo es reconocer en qué capa vive cada problema que llega a tu mesa, porque un problema de la capa tres nunca se resuelve con la herramienta de la capa uno. El ingeniero que solo tiene un martillo no es que trabaje mal. Es que no puede ver los tornillos.
Antes de intentar avanzar por el mapa, hay que tenerlo. Es un mapa visual de las cinco capas, con las preguntas que revelan en cuál estás atascado ahora mismo. No te dirá qué hacer esta semana. Te dirá qué clase de problema estás mirando cuando algo vuelva a fallar — y eso, para alguien que solo sabe leer fracasos técnicos, es lo primero que cambia todo lo demás.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.