Lo que los grandes libros de gestión técnica nunca cubren — y la práctica siempre revela
Un Tech Lead recién ascendido hereda un equipo de nueve ingenieros repartidos en cuatro husos horarios. Su primera semana la pasa haciendo lo que sabe hacer: revisa cada pull request, responde en cada hilo, participa en cada decisión de diseño. Los primeros quince días el equipo entrega más que nunca. La velocidad sube. Los tickets se cierran.
En la semana cinco, el mismo equipo entrega menos que antes de su llegada. Y él trabaja el doble.
La pregunta que tiene delante es qué está midiendo cuando cree que está produciendo. Porque leyó a Grove — o lo tiene en la lista — y recuerda la frase que todo el mundo cita: el output de un manager es el output de su organización. La entiende. Puede repetirla. Y aun así hizo exactamente lo contrario durante cinco semanas.
Ese hueco entre entender la frase y aplicarla es el caso de hoy.
Dos formas de leer la misma frase de Grove
High Output Management de Andrew Grove se sostiene sobre una ecuación: el output de un manager es el output de las unidades bajo su supervisión más el de las unidades vecinas bajo su influencia. La frase parece cerrada. Pero admite dos lecturas que llevan a comportamientos opuestos, y el Tech Lead del caso eligió la equivocada sin saber que había otra.
La primera lectura es cuantitativa. Si mi output es el del equipo, entonces mi trabajo es maximizar la producción del equipo, y la forma más directa de hacerlo es inyectar mi criterio en cada decisión. Reviso todo. Corrijo todo. Elevo el estándar de cada pieza porque yo veo cosas que ellos no ven. Bajo esta lectura, el manager es un multiplicador porque su calidad se propaga a todo lo que toca.
La segunda lectura es estructural. Si mi output es el del equipo, entonces mi trabajo es que el equipo produzca bien sin mí en el camino crítico. Mi criterio importa, pero no como filtro que todo atraviesa, sino como condición que doy una vez y se replica sola.
Las dos leen la misma frase. Las dos suenan a Grove. Y en un equipo pequeño y co-localizado, la primera hasta funciona un tiempo — por eso es tan peligrosa. El Tech Lead que revisa cada PR de cinco personas en la misma sala puede sostenerlo. El costo aparece cuando el equipo crece o se dispersa, y para entonces el hábito ya está instalado.
¿Cuál de las dos lecturas eligió nuestro protagonista? La primera. ¿Por qué le pareció obvia? Ahí empieza el desempaquetado.
Por qué la primera lectura se siente como productividad
Fíjate en qué produjo aquellas dos primeras semanas de subida. No fue casualidad. Cuando el Tech Lead revisa cada PR y corrige cada decisión, el equipo produce trabajo con su criterio incorporado. La calidad sube de verdad. El dato es real.
El problema es qué mide ese dato. Mide la producción del equipo cuando él está en cada decisión. No mide la capacidad del equipo de producir. Son dos cantidades distintas que en la semana dos coinciden y en la semana cinco divergen.
Piensa en qué pasa dentro del equipo mientras él es el filtro de todo. Cada ingeniero aprende, sin que nadie lo diga, que su decisión no es final hasta que el Tech Lead la valida. Entonces deja de decidir. ¿Para qué invertir en un diseño cuidado si de todas formas va a pasar por un filtro que lo va a rehacer? El ingeniero empieza a entregar borradores en lugar de propuestas. Espera la corrección en vez de anticiparla. Y el Tech Lead, que ve borradores llegar, confirma su creencia de que sin él la calidad se cae — sin ver que él la está causando.
Grove tiene una palabra para lo que hace este Tech Lead con su tiempo libre cuando no lo tiene ocupado en algo de mayor leverage: meddling. Meterse. El manager sin un inventario de proyectos propios de fondo termina, inevitablemente, interviniendo en el trabajo de sus subordinados. No porque haga falta. Porque su tiempo está disponible y su instinto lo lleva ahí.
Aquí es donde la primera lectura revela su falla profunda. Asume que el conocimiento relevante para cada decisión está en la cabeza del Tech Lead. Que él sabe, mejor que el ingeniero que escribió el código, cuál es la decisión correcta.
¿Es cierto eso?
El conocimiento que el Tech Lead no tiene y no puede tener
En un equipo distribuido en cuatro husos horarios, el ingeniero que trabaja en el módulo de pagos lleva semanas dentro de ese código. Conoce los casos límite que rompieron en producción el mes pasado, la razón por la que cierta abstracción que parece fea existe, el compromiso que se hizo con otro equipo y que no está documentado en ningún sitio.
El Tech Lead que revisa ese PR a las nueve de la noche, en su huso, con el contexto de otras seis revisiones encima, no tiene nada de eso. Tiene una foto del diff. Puede evaluar estilo, patrones, olores de código. No puede evaluar la decisión, porque la información que la justifica no está en el diff — está en la cabeza del ingeniero y en el historial que solo el ingeniero vivió.
Esta es la razón por la que la primera lectura de Grove no escala, y no es una razón de capacidad ni de tiempo. Es una razón sobre dónde vive el conocimiento. El conocimiento que hace buena una decisión técnica está distribuido en las personas que están más cerca del problema. Está fragmentado, es parcial, cambia cada día. Ninguna cabeza central lo contiene. Cuando el Tech Lead se pone como filtro de todas las decisiones, no está sumando su criterio a un conocimiento completo — está sustituyendo conocimiento local rico por conocimiento central pobre.
Thinking in Systems de Donella Meadows lo formula desde la teoría de sistemas: la información que llega tarde o incompleta a quien decide produce oscilación. El sistema sobre-corrige, sub-corrige, nunca se estabiliza. El Tech Lead como filtro central es precisamente eso: un punto de decisión al que la información llega degradada, y que por tanto decide peor que quien tiene la información fresca.
Entonces la pregunta cambia. Si el Tech Lead no puede ni debe estar en cada decisión, ¿qué hace exactamente con su output? ¿Dónde aplica su criterio, que es real y sí vale?
Qué se replica solo y qué hay que decidir cada vez
Vuelve a la segunda lectura de la frase de Grove: el equipo produce bien sin el Tech Lead en el camino crítico. Eso no significa que el Tech Lead desaparezca. Significa que su criterio se aplica una vez y se propaga sin que él vuelva a intervenir.
Distingue dos tipos de intervención. La primera es la decisión puntual: este PR, este diseño, este bug. Si el Tech Lead la toma, aplica su criterio a un caso y el efecto muere ahí. Mañana hay otro caso y vuelve a hacer falta. Es leverage cero — o negativo, cuando además desplaza el conocimiento local.
La segunda es la decisión sobre el contexto: qué señales ve el equipo, qué límites tiene claros, qué significa "bueno" en este equipo sin que nadie tenga que preguntar. Si el Tech Lead establece que ningún servicio nuevo entra sin un runbook, que la latencia por encima de cierto umbral bloquea el merge automáticamente, que las decisiones de arquitectura se escriben en un documento corto antes de codificar — eso aplica su criterio una vez y se replica en cada decisión futura del equipo, incluso en las que él nunca verá.
Esta es la diferencia entre diseñar cada decisión y diseñar las condiciones para que las decisiones se tomen bien. Liz Wiseman lo describe en Multipliers: el multiplicador no es quien es más inteligente en cada sala, es quien hace que las demás personas sean más inteligentes. El que da todas las respuestas crea gente que espera respuestas. El que da el marco correcto crea gente que encuentra respuestas.
La analogía útil aquí es la de un sistema de tipos en un lenguaje de programación. Un buen sistema de tipos no revisa cada línea que escribes — establece las reglas una vez, y a partir de ahí una clase entera de errores se vuelve imposible de escribir sin que nadie tenga que revisarlos manualmente. El Tech Lead que diseña bien el contexto hace lo mismo: no revisa cada decisión, hace que una clase entera de malas decisiones sea difícil de tomar. La analogía se rompe en un punto — el sistema de tipos es rígido y el contexto de un equipo tiene que evolucionar. Pero el mecanismo es el mismo: criterio aplicado una vez, efecto propagado sin intervención.
Lo que ningún libro cubre porque no se puede escribir
Aquí está lo que Grove, Fournier, Wiseman y Meadows describen con precisión pero que la práctica revela de una forma que ningún libro puede anticipar: cuáles son, en tu equipo concreto, las señales y los límites correctos.
Los libros te dan la forma del razonamiento. No pueden darte el contenido, porque el contenido depende de información que solo existe en tu equipo, en tu semana, con tus personas. Ningún autor sabe que el ingeniero de pagos de tu equipo necesita un límite distinto que la ingeniera de infraestructura, porque valoran cosas distintas, tienen contextos distintos, responden a señales distintas. Grove no puede escribir eso. Tú tampoco puedes decidirlo de antemano — solo puedes descubrirlo observando cómo el equipo responde a los límites que pones.
Por eso el diseño del contexto no es un plan que se traza una vez. Camille Fournier insiste en The Manager's Path en que el Tech Lead siga escribiendo código, pero no demasiado — y la razón profunda de ese equilibrio es epistemológica. El Tech Lead que se aleja del todo pierde la información que necesita para saber si sus límites siguen teniendo sentido. El que se mete demasiado se convierte en el filtro central del caso de apertura. El punto medio no es un porcentaje fijo de tiempo en código. Es la cantidad justa de contacto con el trabajo real para seguir viendo si el sistema que diseñaste sigue produciendo buenas decisiones sin ti.
Fíjate en lo que esto le pide al Tech Lead del caso. No que revise más ni que revise menos. Que cambie qué observa. En lugar de mirar cada PR preguntándose "¿está bien esta decisión?", mira el patrón de las decisiones preguntándose "¿qué señal le falta a este equipo para que esta clase de decisión salga bien sola?". La primera pregunta lo mantiene en el camino crítico para siempre. La segunda lo saca de él una decisión cada vez.
Y cuando el equipo empieza a tomar decisiones que él no habría tomado — pero que resuelven el problema con información que él no tenía — ahí sabe que el sistema funciona. No cuando el equipo decide como él decidiría. Cuando decide mejor de lo que él podría, con conocimiento que nunca estuvo en su cabeza.
La lección que sobrevive al caso
Lo que este caso generaliza a cualquier Tech Lead, en cualquier equipo, con cualquier stack, es esto: tu leverage no crece cuando aplicas tu criterio a más decisiones. Crece cuando aplicas tu criterio a las condiciones bajo las que otros deciden — porque ahí tu criterio se replica sin ti, y el conocimiento local que tú no tienes entra en cada decisión en lugar de quedar fuera.
Los grandes libros de gestión técnica te dan esa distinción con claridad. Lo que no pueden darte, y lo que solo la práctica revela, es qué señales y qué límites son los correctos para las personas concretas que tienes delante esta semana. Eso no se lee. Se descubre observando cómo tu equipo responde a lo que pones, y ajustando lo que la respuesta te enseña.
La próxima vez que abras un PR para revisarlo, hazte una pregunta antes de escribir el primer comentario: ¿esta corrección la voy a tener que hacer otra vez la semana que viene en otro PR? Si la respuesta es sí, el comentario no es el trabajo. El trabajo es la señal o el límite que hace que esta corrección deje de hacer falta.
Para mapear en qué punto de esta transición está tu propia forma de liderar — de filtro central a diseñador de contexto — el framework de los cinco estadios de madurez del Tech Lead te da las señales concretas de cada nivel.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.