¿Qué es un tech lead?
Antes de nada una aclaración: En muchas empresas llaman Tech Lead a lo que en realidad es un TLM (Tech Lead Manager), es decir a un Tech Lead que también tiene las responsabilidades de manager, especialmente people management. En este artículo me voy a centrar especialmente las responsabilidades de un Tech Lead. Si queréis saber las responsabilidades de un manager, aquí las describo.
Empecemos por lo obvio; no es un manager. Y sigamos por lo primero que confunde la gente con esa frase, eso no significa que no tenga responsabilidades sobre el desarrollo de carrera de otros. En realidad esto aplicaría o debería aplicarse a cualquier senior.
Es una persona técnica, sí. Pero su responsabilidad no está centrada solo en programar, todo lo contrario, sus áreas son más dirección técnica (breadth knowledge eg. testing, CI/CD, observabilidad, etc), entender las necesidades de la empresa, entender el producto (especialmente la parte/área de la que es responsable), y liderazgo (accountability, backbone, delivery…).
El impacto de un tech lead se espera que sea más allá del ámbito individual, aunque esto podría decirse de cualquier persona que trabaja en un equipo, hay una gran diferencia. En un tech lead su foco principal es el equipo, el grupo, el área y la empresa. Es decir, más allá de programar o diseñar su gran labor es estratégica. Supervisando que todo lo que sale del equipo (e incluso del área en algunas empresas), tiene sentido desde todos los puntos de vista:
Resuelve el problema real. Es decir, resuelve lo que realmente es importante, lo que afecta a clientes, lo que nos aprieta ahora mismo, etc.
Su diseño encaja dentro de la estrategia técnica (imagina hacer un componente en rust y on-premise cuando todo lo tenéis montado en Ruby y cloud).
Tiene un cuenta su mantenimiento: operabilidad, monitorización, alertas.
Comunicar
Además de eso una Tech Lead es una excelente comunicadora. Escribe bien, especialmente documentos técnicos. Tiene capacidad para hablar en público, para presentar ideas a diferentes audiencias, por ejemplo el All Hands de la empresa.
Es capaz de hablar con diferentes stakeholders, diferentes roles dentro de la empresa como Directores, CEO, CTO, VPs, managers, ingenieras, etc.
Pushback
Otra faceta clave de una Tech Lead es que no debe tener miedo a hacer pushback, dar su opinión, empujar por lo que piensa que es lo correcto (entiende perfectamente las necesidades de la empresa y eso es lo que usa para priorizar en todo momento).
Accountability
Es una persona que no solo es que tenga ownership, se haga responsable de coger un problema y llevarlo/liderarlo hasta el final, sino que hace al resto accountable de lo mismo.
No tiene problemas en hacer preguntas incómodas para asegurarse de que se está yendo en la dirección correcta, para sacar unknowns, no le incomoda hacer challenge de las ideas de otros si cree que no son buenas, que no atacan el problema real o para acabar de entender el problema.
Backbone
Una Tech Lead tiene que tener opiniones fuertes, tiene que tener determinación, empujar por sus ideas con argumentos, tiene que tomar decisiones. Es decir, se espera que tenga opiniones, que tenga convicción en ellas y que empuje fuerte. Que no ceda por contentar al grupo, que no se deja llevar por Group Thinking. Pero también tiene que saber hacer Disagree and Commitment.
Big Picture
También tiene que tener la capacidad de ver las cosas con una capa de abstracción, es decir, ver el bosque, de no perderse en los detalles que te llevan a resolver un problema que realmente no es el importante, o te llevan a resolver una parte del problema pero no te sacan del agujero en el que estás. Un ejemplo que ya conté en una newsletter: programar algo desde cero en un lenguaje nuevo porque es más rápido cuando el verdadero problema que teníamos era como escalar horizontalmente.
De un Tech Lead se espera que antes de que eso ocurra levante la mano.
Seniority
En la bibliografía sobre tech leads, incluso en libros tan célebres como The Manager 's path, se menciona que no hace falta ser la mejor ingeniera para ser tech lead pero creo que esto confunde. Sí, es importante entender que este rol no tiene porque desempeñarlo la persona más senior ni la que mejor programa. Pero tiene que tener un conocimiento bastante amplío y cierta seniority en muchas áreas del desarrollo de software. Incluso ser una experta en alguna de ellas es más que recomendable.
Hay muchos artículos que equiparan a un Tech Lead con lo que se conoce como T-Shape engineers, es decir, aquellas ingenieras que profundizan en un área y luego tiene algo de conocimiento de otras muchas. Sin embargo en mi opinión y en el momento actual donde rara vez un equipo solo toca una parte muy concreta como backend o frontend. Una Tech Lead se parece más a un M-Shape. No necesita tener un conocimiento profundo de todas las áreas (hasta llegar a ser un experto) pero desde luego no es suficiente con saber de oídas. Por ejemplo de una Tech Lead se espera que tenga un buen criterio en arquitectura, diseño de sistemas, monitoring, CI/CD, etc.
Conocimiento del producto/dominio.
También se espera que una Tech Lead tenga un conocimiento excelso del producto, especialmente de su área. Una TL colabora de manera frecuente con product managers para entender las necesidades de los clientes y las prioridades del negocio, además de para ayudar a priorizar y coordinar iniciativas. También esto es fundamental para poder tomar decisiones cuando se plantean diseños, se revisan propuestas, etc. Sin conocer el negocio es difícil poder empujar en la dirección correcta. Por eso es vital entender quiénes son tus clientes, donde cojea el negocio, qué estrategia tiene la empresa, que OKRs, KPIs tiene tu área, equipo, etc.
Es decir, tiene que tener un conocimiento total del Problem space (perdón pero no se me ocurre un término que lo defina igual de bien en castellano).
Programar
Obviamente una Tech Lead programa en el día a día y tiene un buen conocimiento del código y de la arquitectura, pero buena parte del día transcurre en actividades que algunos erróneamente consideran Management. Muchas reuniones, revisión de documentos, de propuestas técnicas de otros, de ideas de producto, reuniones de seguimiento, de diseño, arquitectura, iniciativas. ¿Cuál es su trabajo revisando esas propuestas? Mayormente intenta que la solución esté acorde con la estrategia técnica de la empresa, que resuelva el problema de negocio, que tenga en cuenta cosas como monitoring, alerting, observabilidad, etc. Y sí, en ocasiones también tiene mucho project management, asegurarse de que es factible, de que está faseado, etc. Aunque esto depende muchísimo de la empresa, en algunas esto recae totalmente en el manager, project manager, o Technical program manager.
Diría que si tu objetivo es estar 100% centrada en programar, no vas a disfrutar en este rol. Porque tienes que aprender a que no puedes estar con visión de túnel en una funcionalidad, en único problema, tienes que estar al tanto de lo ocurre dentro de tu área, de tu equipo y ser capaz de desarrollar una visión estratégica.
Política
Buena parte del trabajo de una TL es influenciar y para ello tiene que conocer la “política” de la empresa para poder mover o desbloquear iniciativas. ¿A qué me refiero con política? Pues saber qué mensaje dar, a quién dárselo, dónde exponer sus planteamientos, saber hacer buy-in.
Mentorship
Ya decía al empezar que no ser manager no significa que no tengas responsabilidades en la carrera de la gente. De una Tech Lead se espera que ayude a la gente a crecer, a mejorar haciendo cosas como pairing, reviews, etc.
La parte del coaching suele recaer más en un manager y el mentoring más en la TL, pero al final coaching es una herramienta más para ayudar a la gente a resolver problemas por si misma, así que no es inusual que una TL también la use.
Calidad y velocidad
En muchas empresas un TL es también el responsable de la calidad del equipo, es decir, asegurarse de que se siguen buenas prácticas tanto en el desarrollo de software como a nivel de arquitectura. No significa que sea quien decide cómo implementar las cosas pero sí que se espera que supervise y que haga challenge como decía arriba para que se mantenga una buena calidad y velocidad. He metido la velocidad en la parte de calidad adrede, porque de un TL se espera que sepa diseñar soluciones que no sean castillos de naipes pero que tampoco sean obras de sobreingeniería. Esto parece simple pero es de las cosas más complicadas, hay que entender muy bien el beneficio que se obtiene para el esfuerzo que requiere algo. Y saber anteponer las necesidades de la empresa a lo que nos apetece hacer o a lo que creemos que debería ser para estar bien programado/arquitecturado.
Una vez mencionadas las cualidades os comparto un ejemplo de las responsabilidades que esperamos nosotros en la gente que consideramos TL en Tinybird.
Leads conversations (with customers, with the team).
Able to successfully interact at senior and junior levels within the organization.
Communicates proactively.
Solves uncertainty (gathering info from any stakeholders, systems, docs, etc).
Develops an opinion of where the project should go.
Able to vary the direction of the project (or tactic or task) in smart ways to keep moving toward the objective.
Detail-oriented without ever losing a strong strategic perspective.
Has Backbone; Disagrees and Commits. Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion.
Calm under the pressure of implementation and deadlines.
A strong listener with great skill at asking questions.
Adept at anticipating potential problems and addressing them early.
Resilient in order to recover from setbacks.
Consistent in how they respond to comparable situations.
Able to deliver. It's able to take on any initiative small or complex from start to finish
Has a business sense - understands what we are trying to achieve as a company and keeps that in mind when making decisions
Instills a sense of urgency in the team
Por último, como ves una TL va a pasar buena parte de su tiempo revisando o haciendo propuestas técnicas. Así que este artículo que escribí hace unas semanas es el complemento perfecto.
https://blog.get-merit.com/the-role-of-the-tech-lead/
https://dev.to/thawkin3/lessons-from-a-tech-lead-roles-responsibilities-and-words-of-advice-ldj
Excelente artículo, Felix. La primera vez que leí sobre que est un Tech Lead fue en el libro the Pat Kua "Talking with Tech Leads", aunque la verdad no me gustó demasiado.
La mejor descripción de este rol la encontré que el libro de Camille Fournier que has enlazado, "The Manager's Path".
Me ha gustado tu definición del rol. Una líder técnica que entiende la Big Picture, las necesidades de negocio, sabe identificar los challenges claves y encuentra soluciones para ello. Una persona técnica con altas capacidades de liderazgo, que sabe comunicar, inspirar e influenciar efectivamente y hace todo lo posible para se haga el delivery.
Un artículo muy muy bueno ! Creo que coincido en todo, y de hecho mucho se me asemeja a los Leadership Principles de Amazon/AWS: ownership, think big, bias for action, deliver results, develop the best y have backbone, disagree and commit. Otro que me gusta mucho y no he visto explícitamente mencionado es el de Learn and Be Curious. Por ejemplo, en tu ejemplo de programar un componente en Rust cuando todo lo tenéis montado en Ruby y cloud, lo suyo es que hayas experimentado con Rust antes, que guíes al equipo y no lo digas "por probar" (a no ser que el impacto sea pequeño).
Tengo una pregunta, imagina una empresa pequeña, con su departamento de ingeniería (el que hace el producto) que involucra varias áreas (imaginemos mecánica, electrónica y software) y el departamento de operaciones e integraciones (el que tiene relación con los clientes e instala el producto en el cliente al final). Podría pensar que pueden existir uno o varios Tech Lead en cada área de ingeniería, pero ¿qué sería para ti un "Tech Lead" que guiase toda la actividad técnica de la empresa? Es decir, el que hace de intermediario entre la ingeniería e integraciones en casos concretos, el que guía el aspecto técnico, el que tiene conversaciones con el cliente, etc.