Llevo desde Septiembre de 2023 ejerciendo como Tech Lead de un equipo de SREs. Si bien no creo que acumule tanta experiencia como para ir dando clases, sí que aprendido mucho. Muchísimo tanto a nivel técnico como de liderazgo. Aquí las softskills son tan importantes como las hard. Recuerdo que al recibir la propuesta lo primero que hice fue buscar mucha información ¿cómo es eso de Tech Lead? ¿cómo es eso de liderar un equipo tan altamente técnico? Encontré mucho, y leí mucho. Después a lo largo de este primer año aprendí aún más. Poco a poco, igual que con la parte técnica de mi trabajo, fui condensando en notas rápidas las keys que disparasen en mi memoria el contenido almacenado en mis dicts. Sin darme cuenta, he acabado armando una especie de cheatsheet. Y como este blog va de compartir y contribuir de vuelta -a la Red y al mundo-, byte a byte, quiero compartir mi experiencia y esa cheatsheet. Junto con otra reflexión sobre liderar a un equipo.

Una reflexión sobre mi camino de Junior a Tech Lead

Adoro leer, y siempre confieso que soy un historiador frustrado. Alrededor de los veintipocos leí “El Arte de la Guerra” y hubo una cita que quedó inmediatamente grabada en mi mente, para siempre: “A él corresponde ser justo, metódico y reservado”. Resonó muchísimo conmigo y de alguna manera la he intentado aplicar en lo que hago. ¿Cómo aplica una cita de hace más de 2500 años en una industria que no ha cumplido los 80 aún? Bueno, ser metódico es increíblemente útil en todas las facetas de IT.

Ser metódico es ser organizado, diseñar un sistema, validarlo y aplicarlo para luego ceñirse a él. ¿No es eso esencialmente lo que hacemos? Un rockstar puede ser muy bueno, pero si no es consistente ni organizado no es tan bueno como podría llegar a ser. Y todos tenemos historias del rockstar que un día rompió Producción. En un momento de sobrecarga, emergencia, o incertidumbre, ser metódico nos da la capacidad de reacción que el aturdimiento y lo desconocido nos ha quitado. Un runbook claro que asume conocimiento previo cero ante una alerta que se dispara, un framework para Incident Management en las primeras etapas clave de un incidente, una takeoff checklist para no pasarnos nada cuando iniciamos nuestro turno… Todos son ejemplos de un acercamiento metódico a algo tan caótico como es el trabajo de Reliability Engineering. Es por eso por lo que, en mi experiencia, tratar de ser metódico me ha ayudado manejar todas las aristas tanto técnicas como soft del rol de liderazgo. Volviendo a la cita de Sun Tzu y su paralelismo con IT: alguien metódico se adapta e improvisa, pero lo hace en base a un sistema. Exactamente como deberíamos hacer nosotros. Las partes de justo y reservado me las guardo para algún futuro post :P.

Mi reminder en modo cheatsheet

  • El trabajo de priorizar, planificar (scheduling) y dispatch de tareas/(tickets) tiene un gran impacto en el equipo. Y no hacerlo tiene un gran impacto el doble de negativo: Cuellos de botella, desalineamiento entre el trabajo del equipo y las prioridades del cliente y sobrecarga, ya sea overload real o percibido.
  • Prioriza, luego delega y deja al equipo hacer lo que hacen mejor: su trabajo. Si haces micromanagement sin necesitarlo, hay un problema. Si tienes que hacer micromanagement porque no puedes delegar confiablemente, hay un problema.
  • Como SREs no podemos ser reacios al cambio, nos gusta y lo gestionamos. Encontrar el equilibrio entre capacidad de cambio y riesgo aceptable a la estabilidad es la clave. Un proceso de gestión del cambio es la clave.
  • Si no estás ON-CALL está bien priorizar el trabajo profundo y tardar más de 10 minutos en responder a un email o mensaje.
  • Encontrar cuellos de botella en el workflow del equipo -primero encuentra los KPI para detectarlos- tiene mucho mayor impacto que resolver uno o dos tickets atascados.
  • Tech Lead mezcla liderazgo y trabajo técnico. Permite liderar desde el frente. Una oportunidad única para hacer coaching y apoyar el crecimiento de todos. Win-Win.
  • Saca siempre tiempo para trabajar la parte técnica. No dejes de codear, no dejes de automatizar. No dejes de aplicar nuevas soluciones. Nunca dejes de optimizar y solucionar problemas.
  • Pero a veces no hay tiempo para la parte técnica, y eso está bien. Sólo si es crónico debes preocuparte (una semana sin espacio para ello).
  • Eres el puente entre el equipo y el cliente (sea este interno o externo). A veces significa tomar equidistancia.
  • Identificar algo que no “está bien” y mencionarlo no sirve. Elevar una queja no sirve. Lo que funciona: Detectar algo que según nosotros es mejorable, ofreciendo pruebas y métricas de ello; en el mismo informe presentar una solución.
  • EXTRA: Este es un reminder muy para mí, pero igual sirve para otros que compartan mi hobby -nerd aunque ya no tan nerd como en los 90- de los videojuegos. “Liderar no es un RTS con minimapa, interfaz maravillosa, visión zenital y reacciones instantáneas. Liderar es un FPS donde necesitas una visión clara usando un campo de visión limitado, después explicas y señalas el objetivo. Debes tener confianza en que va a cumplirse cuando el instante siguiente toque mirar hacia otra parte, hacia el próximo desafío”.

Hablemos de métricas

SRE es una posición muy enfocada y basada en métricas, debería serlo. Son la base de la observabilidad. Para mí esto no cambia cuando lo que estamos queriendo observar son los compañeros de nuestro equipo y nuestra carga de trabajo. Pero medir la carga de trabajo de los SRE, en mi experiencia, tiene un problema fundamental: Manejamos requerimientos muy diversos en los que es dificil estimar inicialmente el timepo o el esfuerzo que deberá emplearse. Hay decomms rutinarios que acaban convirtiendose en auténticas odiseas, hay updates que se meten en requerimientos en cascada y requieren hacer un fork de una librería sin soporte para actualizarla…

Por lo cual, me temo que las métricas con las que trabajo actualmente no son tan precisas como me gustaría. Mencionaré algunas, muy por encima, para quizás expandir esto en otro post dedicado sólo a métricas más adelante. Mi equipo y yo trabajamos en Jira, pero voy a tratar de definirlas de manera vendor-agnostic.

  • Número de tickets asignados al equipo (total) y a cada miembro (valor y % sobre el total): Como varíe este número en el tiempo y entre miembros del equipo nos da una idea muy básica de cómo de equilibrada esta la carga de trabajo. Es algo clave para poder empezar. Además, a mayor número de tickets, más rotación de tareas y cambio de contexto. Y ahi empezamos a perder mucho debido al context switching que causa atención residual.
  • Listado de tickets ordenados por prioridad. O volumen (%) de tickets en cada nivel de prioridad: Esto depende de que tan buenos seamos en la organización priorizando tareas y cómo de buenos sean quienes nos piden las tareas asignandoles una prioridad real y honesta. Cuando todo es urgente, nada lo es. Por suerte, en nuestro caso, puedo priorizar en base al feedback del cliente. A más tickets de alta prioridad, más riesgo de fallar en una deadline o impactar. Aumentar la prioridad de algo significa bajar la de otra cosa, por eso de que las personas y el tiempo son recursos finitos. Si hemos visto que podemos manejar X tickets de alta prioridad, la entrada de otro debe ser postpuesta, o alguno de los ya existentes tiene que bajar de prioridad.
  • Mean Time To Resolution (MTTR): el tiempo desde que una petición es formalizada hasta que queda resuelta. En nuestro caso, debido a que además de la parte técnica debemos compaginarla con el scheduling en ventanas de mantenimiento concretas (y otras cosas como aprobar presupuestos y costes) no es tan directa de medir ni tan informativa. Además de nuevo los diferentes niveles de complejidad hacen difícil decidir cuando algo está tardando más de lo necesario. Pero en general puede dar una idea de la “agilidad” del equipo en el contexto de la organización.
  • Average Age de los tickets: No soy amigo de las medias para ninguna estadística porque pueden alterarse bastante con algunos outliers. En general cuanto mayor sea esta media o bien tenemos muchos tickets que estan durando más de lo ideal, o tenemos algunos que están durando muchísimo. Ambas cosas son a corregir. También puede dar una idea muy generalizada de si el equipo está saturado: Si la edad de los tickets crece de modo constante es muy probable que sea porque estamos recibiendo peticiones constantemente y nunca hay tiempo suficiente para trabajar en el backlog. Pasamos a ser cada vez más reactivos y menos proactivos.
  • Tickets completados, mensual: Esta me escama hasta mencionarla, no quiero convertir a nadie en una máquina de cerrar tickets. Porque no somos máquinas y estamos para resolver problemas y manejar el cambio, no cerrar tickets. Pero da, de nuevo, una idea muy general y no precisa del ritmo de trabajo. Si hacemos buen dispatch y el equipo tiene una carga equilibrada, el output debería ser parecido. Si no, toca ver si es porque alguien tiene tareas mucho más complejas y de mayor duración, o está en un momento menos productivo.
  • Tickets asignados VS Tickets completados, mensual: De nuevo, y volviendo a lo de no somos máquinas de completar tickets, esto da una idea muy elemental del “rendimiento”. En un equipo bien equilibrado debería tender a ser constante. Si en un momento la tendencia se desequilibra (muchos más tickets asignados que resueltos) podríamos estar sobrecargando, y si vemos que hay muchos menos asignados y muchos menos resueltos, podríamos tener a alguien idle

Mejora constante

Se que las métricas anteriores son un poco generalistas e imprecisas, y aisladas no son capaces de decir mucho. Pero combinadas pueden dar una idea general que nos permita saber si debemos tomar alguna accion. Además están ahí para irlas refinando porque me gusta el principio de “Mejor hecho ahora que perfecto luego” que no es sino la mejora iterativa y constante. Todas estas métricas las tengo en un dashboard al que he llamado “Workload HUD” con la única intención de tener de un vistazo como estamos mi equipo y yo de carga de trabajo. Porque no me gusta intuir o creer cosas, sino medirlas.