No es un Tech Lead común: ¿Qué significa ser TL en una empresa de software Lean?

Rate this content
Bookmark
Slides

La experiencia de ser un Tech Lead puede variar de una organización a otra, desde ser un arquitecto en una torre de marfil hasta quedarse atrapado en los detalles con desafíos técnicos complejos. Una empresa de software Lean es aquella cuyo enfoque está profundamente arraigado en optimizar el valor para el cliente a través del estudio de las técnicas utilizadas en el Sistema de Producción de Toyota.

El Agile de la vieja escuela también tiene muchas raíces en los principios Lean: Kanban, por ejemplo, es una herramienta utilizada en la línea de producción de Toyota. Pero, ¿qué nos puede enseñar la fabricación de automóviles sobre el desarrollo de software?

Únete a mí en esta exploración a través del mundo de un TL tal como se experimenta en una empresa de software Lean, mientras revelo algunos de los secretos que permiten a estas empresas entregar software de mayor calidad a mayor velocidad.

This talk has been presented at TechLead Conference 2024, check out the latest edition of this Tech Conference.

James Haworth Wheatman
James Haworth Wheatman
20 min
15 Jun, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla analiza el papel de un Tech Lead en una empresa de software Lean. Destaca la importancia de comprender la distinción entre un desarrollador senior y un Tech Lead. El orador comparte su experiencia de centrarse en problemas inmediatos en lugar de abordar las causas fundamentales, lo que lleva al agotamiento. La charla enfatiza el modelo de mentoría de gestión y el cambio de perspectiva que conlleva. También explora los principios Lean y las técnicas de resolución de problemas en una empresa Lean. El papel de un Tech Lead es implementar soluciones, estandarizar procesos y crear condiciones óptimas para los desarrolladores.

1. The Role of a Tech Lead

Short description:

Hoy quiero hablarles sobre el rol de un líder técnico en una empresa de software ágil. Como líder técnico, tienes la responsabilidad de definir la arquitectura del proyecto, ayudar a los miembros del equipo, generar confianza con los clientes y llevar el proyecto hacia el éxito. Sin embargo, es importante entender que el rol de un líder técnico no es simplemente ser un desarrollador senior. Cometí este error en mi primer proyecto y tuvo consecuencias costosas. Permítanme compartir mi experiencia con ustedes. En un proyecto de plataforma de comercio electrónico desde cero, constantemente era interrumpido por otros desarrolladores buscando ayuda. Debido a mi malentendido del rol, me enfoqué en resolver problemas inmediatos en lugar de abordar la causa raíz. Esto llevó a un ciclo de apagar incendios y eventualmente al agotamiento.

Hoy quiero hablarles sobre el rol de líder técnico. Es posible que ya tengan algunas impresiones sobre el rol, tanto positivas como negativas. Tal vez sean desarrolladores que aspiran a dar el siguiente paso, o recientemente han sido ascendidos y están encontrando su lugar en el rol, o tal vez han sido líderes técnicos durante años. Quiero compartir lo que considero una perspectiva poco representada en la industria y espero que puedan obtener algo de valor de ello.

Eso es lo que significa ser un líder técnico en una empresa de software ágil. Mi nombre es James y he estado trabajando como líder técnico durante los últimos dos años, construyendo aplicaciones web y móviles de pila completa en Theodo.uk, que es una consultora de software ágil. Pero en realidad, me uní a Theodo como desarrollador, así que esto era yo, no esto. En consecuencia, construí una imagen de lo que significaba ser líder técnico prestando atención a los líderes técnicos que había tenido a lo largo de los años.

Había algunas cosas que los vi hacer. Ellos definían la arquitectura del proyecto y resolvían cualquier incertidumbre técnica difícil. Me ayudaban cuando estaba atascado. Siempre eran la persona que me sacaba de una situación complicada. Lograban generar una muy buena confianza con nuestros clientes y también podían llevar el proyecto en su conjunto hacia el éxito. Así que básicamente, veía al líder técnico como un desarrollador senior, una persona con la experiencia técnica para resolver cualquier problema técnico que pudiera surgir, en lugar de un rol completamente diferente dentro del equipo. Y este fue un malentendido fundamental del rol que fue muy costoso para mí personalmente.

En mi primer proyecto como líder técnico novato, estaba trabajando internacionalmente con una gran consultora de gestión y viajábamos para ver a nuestros clientes cada dos semanas más o menos, construyendo una plataforma de comercio electrónico desde cero para vender células fotovoltaicas para ser instaladas en propiedades privadas. Veamos cómo esta idea errónea de que los líderes técnicos son básicamente desarrolladores senior afectó mi trabajo diario. Tomaba un ticket y comenzaba a codificar. Después de todo, soy un desarrollador, así que debería estar trabajando en tickets. A menudo esto podía ser algo bastante complejo. Por ejemplo, estábamos trabajando en algunos componentes de React bastante únicos que permitían a un usuario seleccionar su techo en un mapa y ver una representación visual de los paneles solares que se instalarían en su techo. Luego, un problema interrumpía mi flujo, y generalmente era un desarrollador que pedía ayuda con algo.

Tal vez uno de los desarrolladores estaba teniendo dificultades para manejar los datos que venían directamente de nuestro CMS. Después de un tiempo depurando, al final resultaba que alguien había realizado un cambio en el tipo de datos en Contentful sin actualizar los tipos de TypeScript en el frontend, y esto había causado un error. Actualizamos TypeScript y solucionamos el error. Pero ahora estoy atrasado con mi propio trabajo. Los componentes que estoy construyendo son fundamentales para nuestro flujo, así que me apuro a codificar e intento volver al ritmo después de cambiar de contexto. Sin embargo, debido a que solo abordé los síntomas, el problema vuelve a ocurrir y dos semanas después tenemos otro error porque alguien más hizo un cambio en Contentful sin actualizar TypeScript. Como resultado, después de aproximadamente seis meses en el proyecto, me di cuenta de que estaba comenzando a agotarme. A esto lo llamamos el ciclo de apagar incendios.

2. The Role of a Tech Lead (Continued)

Short description:

Desde el exterior, parecía que éramos un equipo altamente funcional, lanzando nuevas características diariamente. Sin embargo, estaba trabajando más duro y no más inteligentemente. Después de una interacción crucial con el CEO, aprendí sobre el modelo de mentoría de gestión. Estaba luchando porque estaba tratando de hacer dos trabajos: desarrollador y líder técnico. El modelo de mentoría distingue entre creadores y gestores, siendo los líderes técnicos los gestores que crean y mantienen las condiciones para el éxito del equipo. Este cambio de perspectiva me hizo darme cuenta de que estaba viendo todo a través de los ojos de un desarrollador, no de un líder técnico.

Claro, desde el exterior parece que éramos un equipo altamente funcional y nuestros clientes estaban realmente satisfechos. Estábamos lanzando nuevas características a diario y yo estaba manteniendo a flote a los desarrolladores. Pero el esfuerzo era mucho y definitivamente estaba trabajando más duro y no más inteligentemente.

Afortunadamente, tengo varios mentores en el trabajo que me ayudan a crecer en el rol de líder técnico y me ayudan a aclarar un modelo de mentoría de lo que debería estar buscando. Así que después de este punto bajo, tuve una interacción crucial que cambió mi comprensión de lo que significa ser líder técnico.

Durante una capacitación en toda la empresa, el CEO preguntó casualmente a los gestores que levantaran la mano, y estaba haciendo un punto dirigido hacia ellos, y yo no levanté la mano. Así que ella miró alrededor de la habitación, un poco confundida, y me notó. Dijo: `Vamos, James. ¿Por qué no tienes la mano levantada? Por supuesto que eres un gestor. Eres un líder técnico`. El problema era que no me veía a mí mismo como un gestor. Para mí, eso parecía una palabra sucia. Pensaba que un gestor era alguien que coordinaba el trabajo dentro de su equipo, pero que en realidad no hacía el trabajo ellos mismos. Y resulta que nuestra CEO tenía una comprensión completamente diferente de lo que debería ser la palabra gestor.

Después de esa capacitación, a través de la discusión con ella y otros, aprendí sobre el modelo de mentoría de gestión que utilizamos en nuestro grupo. La razón por la que estaba luchando con este ciclo de apagar incendios y agotamiento era porque estaba tratando de hacer dos trabajos. Por un lado, estaba luchando por ser un desarrollador y terminar mis tareas, porque podía ser interrumpido en cualquier momento del día, teniendo que intervenir y ayudar con las tareas de los desarrolladores, lo que interrumpía mi propio flujo de desarrollo. Por otro lado, debido a que siempre estaba atrasado con mi desarrollo, descuidaba algunas de las responsabilidades del líder técnico para ponerme al día con mis tareas. Y esto significaba que el equipo se encontraba con problemas una y otra vez, y era una batalla constante mantener nuestra velocidad como equipo a medida que avanzaba el proyecto.

Así que aquí está el modelo de mentoría que utilizamos en el trabajo. Podemos dividir los trabajos en dos categorías. Aquellas son el creador y el gestor. El creador crea directamente el producto o servicio que brinda valor al cliente, mientras que por otro lado, tenemos al gestor, que crea y mantiene las condiciones para que los creadores entreguen ese valor sin esfuerzo. Y esto está muy precisamente formulado. Se trata de crear las condiciones holísticas para que un equipo de alto rendimiento crezca y asegurarse de que todos los insumos que su equipo necesita para tener éxito estén presentes. Se trata del éxito del equipo, en lugar de centrarse en sus propias contribuciones dentro del equipo. Y mantener esas condiciones donde las personas realmente disfrutan trabajando en tus proyectos, porque pueden ver que el esfuerzo que ponen es directamente proporcional a los resultados de su trabajo, donde no se ven obstaculizados por los problemas diarios de una mala experiencia de desarrollo o pequeños problemas. Esto no es un trabajo fácil en absoluto, especialmente cuando hay factores externos a considerar. Entonces, en el contexto de los roles técnicos en nuestra empresa, podemos ver cómo encajan el líder técnico y el desarrollador en este modelo de mentoría, siendo los desarrolladores los creadores dentro del equipo y los líderes técnicos los gestores. Y este fue el cambio de perspectiva principal que me hizo darme cuenta de que estaba viendo todo a través de la perspectiva del desarrollador, en lugar de a través del enfoque de un líder técnico.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top Content
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Principios para Escalar el Desarrollo de Aplicaciones Frontend
React Summit 2023React Summit 2023
26 min
Principios para Escalar el Desarrollo de Aplicaciones Frontend
Top Content
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Luchando contra la Deuda Técnica con la Refactorización Continua
React Day Berlin 2022React Day Berlin 2022
29 min
Luchando contra la Deuda Técnica con la Refactorización Continua
Top Content
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
Construyendo equipos interculturales de alto rendimiento
React Day Berlin 2022React Day Berlin 2022
25 min
Construyendo equipos interculturales de alto rendimiento
The Talk discusses the importance of effective communication and collaboration in cross-cultural teams. It emphasizes the impact of culture on communication and performance evaluation. The speaker highlights the differences between low-context and high-context communication styles and the need to understand cultural nuances. It also explores the challenges of giving feedback in multicultural teams and suggests ways to improve communication and create a feedback culture. The influence of language on communication and the importance of transparency and honesty in feedback are also discussed.
Escala tu aplicación de React sin micro-frontends
React Summit 2022React Summit 2022
21 min
Escala tu aplicación de React sin micro-frontends
This Talk discusses scaling a React app without micro-frontend and the challenges of a growing codebase. Annex is introduced as a tool for smart rebuilds and computation caching. The importance of libraries in organizing code and promoting clean architecture is emphasized. The use of caching, NxCloud, and incremental build for optimization is explored. Updating dependencies and utilizing profiling tools are suggested for further performance improvements. Splitting the app into libraries and the benefits of a build system like NX are highlighted.
Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados
TechLead Conference 2023TechLead Conference 2023
27 min
Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados
This Talk discusses the measurement and interpretation of tech lead, focusing on tech debt. Tech debt is a tool to temporarily speed up development but can have negative consequences if not managed properly. Various tech debt metrics, including heuristic metrics and second-tier metrics, can help identify and manage tech debt. Tech debt interest is crucial for measuring the impact of tech debt and allows for prioritization. It is important to collect and analyze tech debt metrics to ensure software and team health.

Workshops on related topic

De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
TechLead Conference 2024TechLead Conference 2024
144 min
De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
Workshop
Andrew Murphy
Andrew Murphy
Transicionar de un rol de contribuidor individual a una posición de liderazgo, especialmente en la industria tecnológica de ritmo acelerado, es enormemente desafiante. La mayoría de los nuevos líderes no reciben ningún tipo de capacitación en los primeros 10 años de sus nuevas responsabilidades.Nuestro completo masterclass está diseñado para ayudar a los nuevos y emergentes líderes tecnológicos a comprender sus nuevos roles y adquirir las habilidades para convertirse en líderes seguros, felices y efectivos.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
Una Guía para Desarrolladores sobre Cómo Comunicar, Convencer y Colaborar Efectivamente con los Stakeholders
Es una historia tan antigua como el tiempo: la colaboración entre desarrolladores y stakeholders de negocios ha sido durante mucho tiempo un desafío, con una falta de comunicación clara que a menudo deja a ambas partes frustradas. Los mejores desarrolladores pueden comprender profundamente las necesidades de sus contrapartes de negocios, comunicar efectivamente la estrategia técnica sin perder a la audiencia no técnica y convencer al negocio de tomar las decisiones correctas. Trabajando en una consultoría, he fallado y tenido éxito en arquitectar y “vender” visiones técnicas, aprendiendo muchas lecciones en el camino.Ya sea que trabajes en una empresa de productos, seas consultor/freelancer, o quieras aventurarte más allá de ser solo un desarrollador, la capacidad de convencer y comunicar claramente con los stakeholders puede diferenciarte en la industria tecnológica. Esto se vuelve aún más importante con el auge de GenAI y el mercado de desarrolladores cada vez más competitivo, ya que la resolución de problemas y la comunicación efectiva son clave para posicionarte.En esta masterclass, compartiré ejemplos del mundo real, tanto buenos como malos, y te guiaré a través de poner la teoría en práctica mediante dojos.
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
TechLead Conference 2024TechLead Conference 2024
35 min
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
Workshop
Andrew Coleburn
Andrew Coleburn
Integrarse a un nuevo proyecto puede ser difícil, sin importar tu experiencia y antecedentes. Pero puede ser especialmente desafiante para los nuevos desarrolladores recién salidos de la escuela o de un bootcamp de programación. Basándose en su experiencia personal como graduado de un bootcamp y consultor de JavaScript, esta charla discutirá consejos y estrategias para que los gerentes ayuden a los nuevos desarrolladores de sus equipos a familiarizarse con un código desconocido, para que puedan tener un impacto más rápido y efectivo.