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

Hoy quiero hablarles sobre el rol de tech lead. 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 que recientemente han sido ascendidos y están encontrando su lugar en el rol, o tal vez han sido tech leads durante años.

Quiero compartir lo que considero una perspectiva poco representada en la industria, y espero que puedan obtener algún valor de ello. Eso es lo que significa ser un tech lead en una empresa de software ágil. Mi nombre es James y he estado trabajando como tech lead durante los últimos dos años, construyendo aplicaciones web y móviles de pila completa en Theodo UK, que es una consultoría de software ágil. Pero en realidad, me uní a Theodo como desarrollador, así que esto era yo, no esto. Y como resultado, construí una imagen de lo que significaba ser tech lead prestando atención a los tech leads que había tenido a lo largo de los años. Había algunas cosas que los veía hacer. Ellos definían la arquitectura del proyecto y aclaraban cualquier incertidumbre técnica difícil. Me ayudaban cuando estaba atascado. Ellos siempre eran la persona que me sacaba de una situación complicada. Lograban construir una muy buena confianza con nuestros clientes, y también eran capaces de impulsar el proyecto en su conjunto hacia el éxito. Así que, básicamente, veía al tech lead 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 esta fue una comprensión fundamental errónea del rol que fue muy costosa para mí personalmente. En mi primer proyecto como tech lead novato, estaba trabajando internacionalmente con una gran consultora de gestión, y viajábamos para ver a nuestros clientes cada dos semanas aproximadamente en el lugar, construyendo una plataforma de e-commerce desde cero para vender células fotovoltaicas para instalaciones en propiedades privadas. Entonces, veamos cómo esta idea errónea, de que los tech leads son básicamente desarrolladores senior, afectó mi trabajo diario. Tomaba un ticket y comenzaba a codificar.

Afortunadamente, tengo varios mentores en el trabajo que me ayudan a crecer en el rol de tech lead, y me ayudan a aclarar un modelo mental 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 tech lead. Durante una capacitación en toda la empresa, la CEO preguntó casualmente a los gerentes que levantaran la mano, y estaba haciendo un punto dirigido a ellos, y yo no levanté la mano. Entonces, ella miró alrededor de la sala, un poco confundida, y me notó. Dijo: vamos, James, ¿por qué no tienes la mano levantada? Claro que eres un gerente. Eres un tech lead. El problema era que yo no me veía a mí mismo como un gerente. Para mí, eso parecía una palabra sucia. Pensaba que un gerente era alguien que coordinaba el trabajo dentro de su equipo, pero 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 gerente. Después de esa capacitación, a través de discusiones con ella y otros, aprendí sobre el modelo mental de gestión que usamos en nuestro grupo. La razón por la que estaba luchando con el ciclo de apagar incendios y el agotamiento era porque estaba tratando de hacer dos trabajos. Por un lado, estaba luchando por ser un desarrollador que completaba mis tickets porque podía ser interrumpido en cualquier momento del día, teniendo que intervenir y ayudar con los tickets 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 tech lead para ponerme al día con mis tickets. Y esto significaba que el equipo se encontraba con problemas una y otra vez, y era una batalla constante para

Esencialmente, es un enfoque científicamente riguroso para resolver un pequeño problema a la vez con el fin de realizar mejoras incrementales en nuestro trabajo diario. Por ejemplo, teníamos una cobertura del 100% de TypeScript en un proyecto en el que trabajaba. Sin embargo, nos encontramos con un error en el que una propiedad no existía en un objeto, lo que provocaba que la página se bloqueara en tiempo de ejecución. Después de encontrar la fuente del error, fue bastante rápido solucionarlo. Sin embargo, pensé para mí mismo, TypeScript intenta ser un lenguaje de tipado estático. ¿Cómo es posible que este tipo de error pueda existir en nuestro código? Resulta que, después de buscar rápidamente en Google, esto es en realidad un problema resuelto. No deberíamos habernos encontrado con esto en primer lugar. Resulta que hay una opción de configuración llamada 'no unchecked index access' que se agregó en TypeScript 4.1 para resolver este mismo problema. Verifica que cuando accedes a una propiedad de un objeto, tenga en cuenta la posibilidad de que esa propiedad sea undefined, lo que te obliga a tener esto en cuenta en tu código. Y al agregar esta opción a nuestra configuración de TypeScript, no solo abordé los síntomas del problema, sino que también evité que volviera a ocurrir en nuestro código. Esto es lo que

Para el creador, capacitaremos a las personas en la pieza específica que produjeron. Para la máquina, solucionamos la tecnología. Por ejemplo, cuando mencioné la actualización de la configuración de TS, eso fue solucionar la máquina, y estaba evitando que alguien más fallara en el futuro. Si hubiera algo mal con el método, podemos volver atrás y actualizar nuestros estándares para estar a la vanguardia. Es posible que hayamos estado produciendo algo según el estándar correcto, según nuestra mejor comprensión de lo que era el estado de la técnica, pero resulta que nuestra comprensión de lo que era el estado de la técnica estaba completamente equivocada, y ahora necesitamos actualizar nuestra comprensión. Y si hubiera algo mal con los materiales, es decir, las entradas físicas, las cosas que le dimos al desarrollador, entonces podemos localizar dónde ocurrió el defecto original, y acudir a ese lugar para asegurarnos de que haya calidad en el punto en que se creó esa cosa. Si se tratara de diseños, volveríamos al diseñador y veríamos por qué hubo una falta de comunicación o una discrepancia entre lo que el desarrollador necesitaba y lo que el diseñador produjo. Así que pongamos todo esto junto y volvamos a analizar el ciclo de lucha contra incendios del que hablamos. De hecho, más tarde volví a enfrentar exactamente el mismo problema en el que un desarrollador estaba luchando con un ticket de CMS, y como no lo resolví correctamente la primera vez, con mi comprensión actualizada de mi rol como líder técnico, en realidad tuve una segunda oportunidad para abordar este problema. Pasamos un tiempo analizándolo juntos y nos llevó unos 10 minutos descubrir que una propiedad que esperábamos que se devolviera desde el CMS en realidad era indefinida. Así que resolvimos el problema inmediato corrigiendo el TypeScript para indicar que la propiedad había cambiado. Pero en lugar de volver a mi propio ticket esta vez, primero hicimos un rápido análisis del problema y descubrimos que, una vez más, la razón fue porque alguien había realizado un cambio en el tipo de CMS sin actualizar nuestro TypeScript. Así que en este punto, podemos elegir abordarlo de varias maneras. Podemos capacitar al creador, solucionar la máquina, cambiar el método o analizar los materiales que se ingresaron. Y considero este tipo de problema como un problema de máquina. Porque si solucionamos la máquina para que sea imposible que volvamos a fallar de la misma manera en el futuro, hemos eliminado efectivamente esta clase de problema. Entonces, en este caso, en realidad encontramos varias formas de resolverlo. La forma en que elegimos abordarlo al final es utilizando una biblioteca que genera automáticamente tipos de TypeScript a partir del tipo de datos definido en Contentful. Ejecutas TSC, o el script, que luego genera los tipos y ejecuta la compilación de TypeScript, y tu código fallará en tiempo de compilación