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

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.

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.

Los desarrolladores, que crean directamente el producto o servicio que brinda valor al cliente, y el líder técnico crea y mantiene las condiciones para que los desarrolladores entreguen valor sin esfuerzo. Por lo tanto, es una distinción importante. Los líderes técnicos no son simplemente desarrolladores senior. Mi consejo al respecto es comprender en qué rol se encuentra. Elija ser creador o gestor y enfoque sus esfuerzos en el rol que desee desempeñar, pero no ambos al mismo tiempo, porque tratar de hacer ambas cosas crea un conflicto en la forma en que aborda su trabajo diario.

Obviamente, el rol es diferente y está influenciado en gran medida por la cultura de la empresa en la que se encuentra. Por lo tanto, quiero compartir cómo funcionan las cosas en Theodo, lo cual proporcionará el contexto de algunos modelos de mentoría concretos que puede utilizar para abordar esta visión de lo que es un líder técnico en una consultoría de software lean. Entonces, ¿qué significa realmente cuando digo empresa lean? Si busca lean manufacturing en Google, encontrará que las raíces de lean provienen de las líneas de producción en las fábricas de Toyota. Así es, estoy hablando de cómo un fabricante de automóviles puede enseñarnos sobre el desarrollo de software.

Toyota ha sido el referente en cuanto a confiabilidad en los últimos 30 años en términos de fabricación de automóviles, por lo que es difícil creer que, en la década de 1960, los automóviles de Toyota eran terribles. Pero luego, cuando llegaron los años 80, Toyota cambió por completo su proceso de fabricación y, de repente, sus automóviles eran de los mejores. No es sorprendente que el estudio de esta mejora en la calidad haya sido fundamental en muchas metodologías que vemos hoy en día. Sin embargo, los conceptos originales se mezclan tanto con muchos otros temas relacionados que es difícil saber qué queremos decir realmente con el término lean.

En su esencia, el tipo de lean del que hablamos no tiene que ver con Agile o la startup lean. No se trata de procesos documentados o procedimientos como los que se aprenden en un curso de Lean Six Sigma. Reducir costos y optimizar procesos son solo un resultado positivo del sistema. En cambio, lo que hablamos se remonta al estudio de lo que hizo que esas líneas de producción originales de Toyota fueran tan efectivas. Es un sistema de aprendizaje que nos ayuda a pensar en mejores formas de trabajar. En el corazón de lean, tenemos el concepto de resolución de problemas. Esencialmente, es un enfoque científicamente riguroso para resolver un problema pequeño 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 trabajé. Sin embargo, nos encontramos con un error en el que una propiedad no existía en un objeto. Esto hacía 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 base? Resulta que, después de buscar rápidamente en Google, este es un problema resuelto. No deberíamos habernos encontrado con esto en primer lugar. Resulta que hay una bandera 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, tengas en cuenta la posibilidad de que ese objeto, esa propiedad, luego sea undefined, lo que te obliga a tener esto en cuenta en tu código. Y al agregar esta bandera a nuestra configuración de TypeScript, no solo abordé los síntomas del problema, sino que en realidad evité que volviera a ocurrir en nuestro código base.

Esto es lo que realmente quiero decir con resolución de problemas. Cuando capacitamos a todos en nuestra empresa para tener este enfoque metódico para resolver los problemas que surgen en su trabajo diario, estamos empoderando al equipo para mejorar sus condiciones de trabajo, la calidad de su producción y, por lo tanto, brindar más valor a nuestros clientes en un menor tiempo.

En adelante, les mostraré cómo Lean utiliza esta idea de resolución de problemas y cómo me ayuda a comprender mi propio rol como líder técnico en una empresa de software Lean. Así que volvamos a nuestra definición de líder técnico. Buscamos crear las condiciones para que los desarrolladores entreguen valor sin esfuerzo. Si este es nuestro rol como líderes técnicos, entonces nuestro enfoque debería estar en dos cosas. Primero, identificar problemas o potenciales de mejora en las condiciones de trabajo de los desarrolladores. Y luego, resolver problemas para mejorar esas condiciones y permitir que el equipo entregue más rápido.

Veamos lo que Lean nos dice sobre las formas en que podemos identificar y visibilizar los problemas que ocurren en las condiciones de trabajo. En primer lugar, tenemos el concepto de estandarización. Es decir, definir el estado del arte para algo que estamos produciendo. En este caso, estamos hablando de cosas que afectan las condiciones requeridas para que los desarrolladores entreguen valor sin esfuerzo. El objetivo de la estandarización es crear condiciones estables para el equipo. Si no creamos estabilidad, terminamos obteniendo resultados variados, lo que dificulta identificar qué es realmente un problema y qué no lo es. Resulta que Toyota dedica aproximadamente cinco veces más tiempo a detallar los métodos de trabajo y desarrollar el talento de sus empleados en comparación con una empresa típica.

Entonces hay muchas cosas que podrías estandarizar. Por ejemplo, tener una integración continua (CI) que se ejecute en menos de 10 minutos y practicar la entrega continua. La cobertura del 100% de TypeScript se ha convertido en un estándar en todos nuestros proyectos y tomar decisiones efectivas para herramientas y frameworks. Estas son todas cosas que estandarizamos en el trabajo.

Y aquí puedes ver, te he dado las plantillas que uso cuando comienzo a crear un estándar. En realidad, es muy común que nos preguntemos mutuamente en el trabajo, ¿esta cosa está dentro del estándar o está fuera del estándar? Esto realmente nos ayuda a alinear a dos personas en si creemos que estamos trabajando en el estado del arte para esas condiciones, es decir, lo mejor que pueden ser o lo mejor que sabemos que pueden ser para esa cosa de la que estamos hablando.

Una vez que hemos logrado la estandarización, es decir, hemos definido cómo se ve lo bueno, podemos comenzar a notar cuando las cosas están fuera del estándar. Lean nos presenta muchas formas de hacer esto, pero dos ideas principales que me ayudan en mi rol diario como líder técnico son, en primer lugar, Andon, que es la visibilización y visualización de problemas que ocurren en la línea de producción. Cuando un desarrollador nota que algo está saliendo mal en su tarea, es su obligación informarlo lo antes posible para que puedan resolver el problema inicial y volver al rumbo con la entrega de la tarea con la ayuda de un líder técnico y también para que podamos hacer resolución de problemas y asegurarnos de que se haya abordado la causa raíz del problema. Realmente hacemos un gran esfuerzo para asegurarnos de que los desarrolladores puedan plantear tantos problemas como necesiten y trabajar en estrecha colaboración con un líder técnico para resolverlos.

Pero incluso si como líder técnico no estás recibiendo ningún Andon, no significa que no haya problemas que ocurran en el terreno, y para descubrirlos, tenemos que ir y experimentar las condiciones reales por nosotros mismos, y este es el concepto lean de Genshi Kenbutsu. Podemos hacer esto de varias formas. Podemos sentarnos junto al desarrollador y programar en pareja con ellos en sus tareas. Podemos revisar las tareas y tener una idea del código y identificar dónde podría estar yendo mal y las posibles áreas de mejora dentro del código. Todavía trabajo en tareas a diario, pero el enfoque no es principalmente entregar valor en esa tarea específica, sino descubrir cómo podemos mejorar nuestras formas de trabajar dentro del código. También se puede hacer a través de revisiones de código, y cuando hago revisiones de código, trato de identificar qué es lo siguiente que este desarrollador necesita aprender para llegar al siguiente nivel. Y, por supuesto, esto también sucede en las fábricas de Toyota. De hecho, los gerentes ven esto como uno de sus principales trabajos, y se frustran mucho cuando los llaman a reuniones al igual que a los líderes técnicos. Quieren estar allí en el piso, entendiendo los problemas reales que enfrentan los fabricantes, y se dice que los gerentes principales en Toyota deben lavarse las manos antes de cada comida debido a la cantidad de grasa que han recogido de las veces que han estado en el piso de la fábrica, no solo administrando desde una oficina por encima de la línea de producción.

Resolver problemas de manera efectiva es realmente difícil, y la mayoría de las personas comienzan por dispararse en el pie. Al primer vistazo, están realmente tentados a priorizar sus esfuerzos para abordar los problemas más grandes primero, es decir, aquellos que son más difíciles de resolver con las causas raíz más complejas, y a esto lo llamo el problema de la roca grande. Imagina que te encargan mover un montón de rocas de diferentes tamaños de un lugar a otro. Si intentas empujar la roca más grande, vas a pasar más tiempo y esfuerzo moviéndola, y muchas veces, te lastimarás. De la misma manera, enfocarse en problemas grandes puede desanimarte cuando no logras hacer un cambio significativo. En cambio, hubiera sido mucho mejor utilizar ese tiempo que pasaste moviendo la roca grande para recoger muchas rocas más pequeñas, moviéndolas una por una, donde podemos predeciblemente e incrementalmente hacer un montón más grande en el mismo tiempo que nos llevó mover la roca grande, y todo eso, el efecto acumulativo de todas esas rocas pequeñas realmente termina construyendo un montón más grande. Aquí, Lean nos dice que abordemos esto haciendo resolución diaria de problemas, es decir, utilizar los problemas pequeños de la vida cotidiana para fortalecer el conocimiento de tu equipo sobre las condiciones que permiten una mejor calidad y una entrega más rápida. Así que enfócate en problemas específicos, no generales, y ve cómo puedes evitar que se repitan.

Ahora que hemos identificado un problema del tamaño adecuado, veamos qué podemos hacer para resolverlo. Cuando lo analizamos, estamos buscando la causa raíz de un problema, que se relacionará con uno de estos cuatro insumos que contribuyen a equipos de alto rendimiento, y en el trabajo, llamamos a esto el modelo de las cuatro M, que describe esos insumos. En primer lugar, tenemos al fabricante, la persona que produce la cosa que entrega valor, y las cosas que entran en eso son su salud, su conocimiento y sus habilidades.

En segundo lugar, tenemos la máquina. Esto incluye cosas como, para nosotros, la base de código, el equipo, el entorno de desarrollo, todas nuestras herramientas caen en la categoría de máquina. Luego tenemos los métodos, que se refieren a los estándares de trabajo, es decir, lo que está a la vanguardia en la forma en que estás haciendo algo. Y finalmente, tenemos los materiales. Estas son todas las cosas que le damos al fabricante, al desarrollador, para que puedan completar su tarea. Pueden ser requisitos, o también pueden ser diseños de un diseñador si hay alguna experiencia de usuario que se incluya en su tarea. Y dependiendo de la categoría en la que se encuentre la causa raíz, resolveremos este problema de manera diferente.

Para el fabricante, capacitaremos a las personas en la pieza específica que producen. Para la máquina, arreglamos la tecnología. Por ejemplo, cuando mencioné actualizar la configuración de TS, eso fue arreglar la máquina, y lo hice para que sea imposible que alguien más falle en el futuro. Si hubiera algo mal con el método, podemos volver y actualizar nuestros estándares para estar a la vanguardia. Es posible que hayamos estado produciendo algo de acuerdo con los estándares correctos, según nuestro mejor entendimiento de lo que está a la vanguardia. Pero resulta que nuestro entendimiento de lo que está a la vanguardia estaba completamente equivocado, y ahora necesitamos actualizar nuestro entendimiento. Y si hubiera algo mal con los materiales, es decir, los insumos físicos, las cosas que le dimos al desarrollador, podemos ubicar dónde ocurrió el defecto original y ir a ese lugar para asegurarnos de que haya calidad en el punto en que se creó esa cosa. Si se trata de diseños, volvemos al diseñador y vemos 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 ver el ciclo de lucha contra incendios del que hablamos. De hecho, más tarde volví a abordar exactamente el mismo problema en el que un desarrollador estaba luchando con una tarea de CMS. Y como no lo resolví correctamente la primera vez, con mi entendimiento actualizado 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 del CMS en realidad era indefinida. Así que resolvimos el problema inmediato arreglando el TypeScript para indicar que la propiedad había cambiado. Pero en lugar de volver a mi propia tarea esta vez, primero hicimos un análisis rápido del problema, y descubrimos que una vez más, la razón era porque alguien había realizado un cambio en el tipo del CMS sin actualizar nuestro TypeScript. En este punto, podemos elegir abordarlo de varias formas. Podemos capacitar al fabricante, arreglar la máquina, cambiar el método o analizar los materiales que se ingresaron. Considero este tipo de problema como un problema de máquina, porque si arreglamos 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. Así que 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. Entonces, básicamente, podemos tener tres tipos. Siempre están actualizados en tiempo de compilación. Ejecutas TSC o los scripts, que luego generan los tipos y ejecutan la compilación de TypeScript, y tu código fallará en tiempo de compilación en lugar de en tiempo de ejecución.

Y después de implementar esto, significó que prevenimos toda esta clase de errores, toda esta clase de problemas, y rompimos el ciclo de lucha contra incendios. En realidad, nunca volví a experimentar este problema, lo cual fue genial para mí.

Entonces, ¿qué significa ser un líder técnico? Los líderes técnicos no son desarrolladores senior. En realidad, crean y mantienen las condiciones para que los desarrolladores entreguen valor sin esfuerzo. Y si estás buscando ser un líder técnico, puedes lograrlo siguiendo el modelo de liderazgo técnico. Lo haces identificando un problema en las condiciones de trabajo a través de la estandarización y utilizando el enfoque de Genchi Genbutsu y la resolución de problemas para eliminar por completo esos problemas diarios.

Es posible que tengas algunas preguntas sobre el rol de un líder técnico en una empresa Lean, ya que solo he rascado la superficie. Además de lo que he discutido hoy, tengo un artículo que aborda algunas de esas preguntas y profundiza más en algunos ejemplos y la teoría detrás de Lean si estás interesado en aprender más. Así que no dudes en contactarme en cualquiera de estas plataformas o a través de mi sitio web. Siempre estoy interesado en recibir comentarios sobre las cosas en las que estoy pensando. Así que gracias por escuchar.