El rol de un Tech Lead más allá de escribir código

Cuando me convertí en Tech Lead por primera vez, pensé que el trabajo era simple: ser el mejor programador del equipo y tomar las grandes decisiones técnicas. Me equivoqué en prácticamente todo.

El rol de Tech Lead es una de las posiciones más malinterpretadas en la ingeniería de software. No es un ascenso por escribir buen código. Es un trabajo fundamentalmente distinto. Y nadie te prepara para él.

Después de años liderando equipos en varios sistemas de producción, esto es lo que el rol realmente implica: las partes de las que nadie habla en las descripciones de puesto.

Las decisiones de arquitectura son decisiones organizacionales

Cada decisión de arquitectura que tomas tiene consecuencias organizacionales. ¿Eliges microservicios? Ahora necesitas límites entre equipos, contratos de API y coordinación de deploys. ¿Eliges un monolito? Ahora necesitas disciplina modular y estrategias para resolver conflictos de merge.

He visto equipos adoptar arquitecturas orientadas a eventos porque era “el patrón correcto”, sin considerar que nadie en el equipo tenía experiencia con la consistencia eventual. La arquitectura era sólida sobre el papel. En la práctica, provocó meses de sesiones de depuración y un backlog de bugs de inconsistencia de datos.

Como Tech Lead, tu trabajo no es elegir la mejor arquitectura en teoría. Es elegir la mejor arquitectura para tu equipo, tus plazos y las restricciones de tu negocio.

Esto significa hacerte preguntas como:

• ¿Podrá nuestro equipo mantener esto dentro de 6 meses, cuando yo no esté revisando cada PR?
• ¿Esta arquitectura se ajusta a nuestras capacidades de deploy?
• Si contratamos a dos desarrolladores junior el próximo trimestre, ¿podrán contribuir a esto?
• ¿Cuál es el costo de equivocarnos con esta decisión?

La mejor decisión de arquitectura que he tomado no fue elegir un patrón elegante. Fue elegir uno aburrido y bien entendido con el que todo el equipo pudiera trabajar de forma independiente. Lo aburrido está subestimado.

Mentoría: tu efecto multiplicador

Aquí va un problema de matemáticas: puedes escribir 8 horas de código al día, o puedes dedicar 2 horas a hacer mentoría a tres ingenieros que luego escriben cada uno 6 horas efectivas de código al día. La primera opción produce 8 horas de output. La segunda produce 18.

Este es el efecto multiplicador, y es lo más impactante que hace un Tech Lead.

Pero la mentoría no es solo responder preguntas o hacer pair programming (aunque ambos importan). La mentoría de verdad implica:

• El code review como enseñanza: no te limites a aprobar o pedir cambios. Explica por qué algo debería ser distinto. Enlaza a la documentación. Muestra las consecuencias del enfoque actual. Un comentario en un PR que dice “usa inyección de dependencias aquí” no vale nada. Uno que dice “si inyectamos esta dependencia, podemos probar el flujo de pago sin llamar a Stripe — así se hace” enseña un principio.
• Delegar los problemas difíciles: esto es contraintuitivo. Tu instinto es quedarte con las tareas complejas porque las harás más rápido. Resiste ese instinto. Dale el trabajo desafiante a ingenieros en crecimiento, con tu apoyo. Sí, va a tomar más tiempo. Sí, la primera implementación no será tan limpia. Pero ahora tienes a dos personas que pueden resolver ese tipo de problema en lugar de una.
• Crear espacios seguros para fallar: los ingenieros que le temen a los errores no crecen. Les digo explícitamente a mi equipo: “Esta es una zona segura para experimentar. Si se rompe, lo arreglamos juntos.” Los mejores ingenieros a los que he hecho mentoría cometieron errores espectaculares al principio porque se sintieron seguros para intentarlo.

Uno de mis momentos de mayor orgullo como Tech Lead no fue entregar una funcionalidad. Fue ver a un ingeniero de nivel intermedio al que llevaba un año haciendo mentoría liderar una discusión de arquitectura y tomar mejores decisiones de las que yo habría tomado.

Navegar las tensiones entre producto e ingeniería

Cada sprint planning es una negociación entre lo que quiere el equipo de producto y lo que el equipo de ingeniería sabe que es sostenible. Como Tech Lead, eres el traductor entre esos dos mundos.

Producto dice: “Necesitamos esta funcionalidad para el próximo sprint.” Ingeniería sabe: el modelo de datos no la soporta, y forzarla creará una deuda que va a frenar todo durante meses.

Tu trabajo no es decir “no”. Tu trabajo es decir “estas son las opciones con sus trade-offs”.

Un marco que uso constantemente:

• Opción A: hacerlo de la forma rápida. Entregar en 1 sprint. Genera X cantidad de deuda técnica. Costo estimado de arreglarlo después: Y sprints. Riesgo: Z.
• Opción B: hacerlo bien. Entregar en 2 sprints. Sin deuda. Habilita las funcionalidades futuras P y Q sin retrabajo.
• Opción C: entregar un alcance reducido en 1 sprint. Cubre el 80 % de la necesidad del usuario. Arquitectura adecuada. Iterar sobre el 20 % restante en el siguiente sprint.

Nueve de cada diez veces, gana la opción C. Pero solo puedes presentar la opción C si entiendes a fondo tanto el objetivo de negocio como el panorama técnico.

Los Tech Leads que terminan quemados son los que simplemente dicen “sí” a todo. Aprende a presentar opciones. Deja que los stakeholders decidan con toda la información. Eso no es resistencia: es colaboración.

Decir “no” al scope creep

El scope creep es el asesino silencioso de los proyectos. No llega como un gran cambio. Llega como una serie de adiciones “pequeñas” que parecen razonables por separado.

“¿Podemos agregar también filtros a esta página?” “¿Y si soportáramos también la exportación a CSV?” “¿Podría esta API manejar también el caso de uso del administrador?”

Cada pedido son 2-3 días de trabajo. Diez de ellos son un mes de trabajo no planificado que nadie presupuestó.

Como Tech Lead, muchas veces eres la única persona en la sala que puede ver el costo técnico acumulado. Es tu responsabilidad hacerlo visible.

Mantengo un documento permanente al que llamo el “scope ledger”. Cada adición se registra con su esfuerzo estimado. Cuando los stakeholders preguntan por qué el proyecto se retrasó, puedo señalar 15 adiciones “pequeñas” que sumaron 6 semanas de trabajo extra. Los datos cambian las conversaciones.

La deuda técnica como conversación de negocio

Esto me tomó años aprenderlo: los ingenieros hablan de deuda técnica en términos de ingeniería. “El código es un desastre.” “Necesitamos refactorizar este módulo.” “Nuestra cobertura de pruebas es muy baja.” Estas frases no significan nada para los stakeholders de negocio.

La deuda técnica hay que traducirla a impacto en el negocio:

• No digas: “Necesitamos refactorizar el módulo de pagos.”

• Di: “Agregar cualquier método de pago nuevo al módulo de pagos toma 3 días. Nuestros competidores agregan métodos nuevos cada trimestre. Refactorizar lo reduce a medio día.”

• No digas: “Nuestra cobertura de pruebas es del 20 %.”

• Di: “Este trimestre tuvimos 4 incidentes en producción que las pruebas habrían detectado. Cada incidente nos costó en promedio $X en transacciones perdidas y Y horas de ingeniería.”

• No digas: “El código está muy acoplado.”

• Di: “Agregar la funcionalidad que quieres requiere modificar 12 archivos en 4 servicios por cómo están conectadas las cosas. Por eso las estimaciones siguen siendo más altas de lo esperado.”

Cuando planteas la deuda como un problema de negocio con costos medibles, consigues presupuesto para resolverla. Cuando la planteas como una preferencia de ingeniería, te dicen que “lo hagas funcionar igual”.

La soledad de liderar

Nadie te advierte sobre esta parte. Como Tech Lead, ocupas un terreno intermedio extraño. No eres management, pero tampoco eres ya “uno de los desarrolladores”. Estás en reuniones en las que tu equipo no está. Te enteras de reorganizaciones, recortes de presupuesto y giros estratégicos antes que nadie. Y no siempre puedes compartir lo que sabes.

A veces tu equipo se frustrará con decisiones que tomaste o aceptaste. No siempre tendrán el contexto de por qué. Y no siempre podrás dárselo.

Hay días en los que eres el escudo entre tu equipo y el caos organizacional, y nadie lo sabrá jamás. El mejor elogio que puede recibir un Tech Lead no es “gran arquitectura”. Es que un miembro del equipo diga “no sé por qué, pero aquí las cosas simplemente fluyen”. Esa fluidez es que tú absorbes una fricción que ellos nunca ven.

Busca un grupo de pares. Habla con otros Tech Leads. Este rol es aislante si no tienes a personas que entiendan las presiones específicas bajo las que estás.

Cuándo programar y cuándo dar un paso atrás

Esta es la calibración más difícil. Si programas demasiado, te conviertes en un cuello de botella: el equipo depende de ti para el trabajo del camino crítico. Si programas muy poco, pierdes contacto con el código, y tu guía de arquitectura se vuelve cada vez más teórica.

Mi balance actual:

• Escribo código para: pruebas de concepto de decisiones de arquitectura, piezas críticas de infraestructura donde hay que establecer los patrones, depuración de problemas de producción que requieren un conocimiento profundo del sistema.
• No escribo código para: trabajo de funcionalidades que un miembro del equipo podría hacer (aunque tarde más), cualquier cosa en el camino crítico de un compromiso del sprint, tareas que serían mejores como oportunidades de aprendizaje para otra persona.

Una regla práctica: si quitarme del tablero del sprint bloquearía la entrega, estoy programando demasiadas cosas equivocadas. El equipo debería poder entregar sin que yo escriba una sola línea de código de funcionalidades.

La transición: de mejor programador a mejor facilitador

El cambio más difícil al convertirte en Tech Lead es redefinir qué significa ser “productivo”. Durante toda tu carrera, productividad significó líneas de código, funcionalidades entregadas, problemas resueltos con tus propias manos.

Ahora, productividad significa:

• Un ingeniero junior que entrega con confianza su primera funcionalidad en producción
• Una arquitectura que le permite al equipo avanzar de forma independiente
• Una cultura de code review donde los ingenieros se enseñan unos a otros
• Un sprint que termina a tiempo porque identificaste los riesgos temprano
• Un sistema en producción que maneja los fallos con elegancia porque invertiste en patrones de resiliencia

Tu producción de código va a bajar. Tu impacto se va a multiplicar. Eso no es un trade-off. Es todo el punto.

Reflexiones finales

Ser Tech Lead cambió mi forma de pensar sobre el software. Antes optimizaba por código elegante. Ahora optimizo por la velocidad del equipo, sistemas sostenibles y el crecimiento de las personas.

Si estás haciendo la transición a este rol, este es mi consejo honesto: suelta la idea de ser el mejor programador de la sala. Invierte en ser la persona que hace mejores a todos los demás. El código que escribas será olvidado. Los ingenieros que hagas crecer construirán cosas que tú jamás habrías podido construir solo.

Eso no es un descenso. Es apalancamiento.