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. (View Highlight)
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. (View Highlight)
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…). (View Highlight)
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: (View Highlight)
Resuelve el problema real. Es decir, resuelve lo que realmente es importante, lo que afecta a clientes, lo que nos aprieta ahora mismo, etc. (View Highlight)
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). (View Highlight)
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. (View Highlight)
Es capaz de hablar con diferentes stakeholders, diferentes roles dentro de la empresa como Directores, CEO, CTO, VPs, managers, ingenieras, etc. (View Highlight)
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). (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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). (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
• 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 (View Highlight)
