From Zero to Hero
Durante el mes de agosto me dediqué a preparar mi charla “From Zero to Hero”. Tuve el honor de presentarla en la PulpoCon 2023, que se celebró en Vigo en el mes de septiembre , y unas semanas después, la volví a compartir en la comunidad de AlmeriaJS.
Por lo general, siempre he preparado material más técnico, pero esta vez quería hacer algo diferente y hablar sobre liderazgo, gestión de equipos, sesgos cognitivos y gestión de expectativas en roles de management.
En este artículo intentaré resumir los puntos clave que abordé en la charla, incluyendo bibliografía y referencias para profundizar más en el tema e inmortalizar el contenido.
¿Cuántos habéis estado en un proyecto sin objetivos?
Con esta pregunta quise empezar a remover sentimientos en la audiencia.
Y quería profundizar en cuestiones como:
- ¿Por qué estamos desarrollando esta feature?
- ¿Quién tomó esta decisión y por qué?
- ¿Por qué elegimos esta tecnología?
- ¿Cuál es el propósito de este cambio?
A veces, veo equipos poco cohesionados en los que cada miembro persigue sus propios intereses. El típico desarrollador que se enfoca en herramientas y problemas técnicos, pero no en las necesidades del proyecto. Los roles de management que dan opiniones de manera random, sin un criterio claro. Equipos que muestran una falta de cohesión y una clara brecha entre sus miembros.
El problema más común que encuentro en los equipos es la falta de un objetivo claro. Para mí, es fundamental definir objetivos tanto a nivel colectivo como individual. Establecer objetivos nos permite dirigir nuestras acciones y esfuerzos hacia lo que deseamos lograr y darle sentido al conjunto.
Caer en la rutina y realizar tareas por inercia, sin cuestionar el “por qué”, nos llevará a la desidia.
Sin embargo, tampoco debemos obsesionarnos con los objetivos; es importante encontrar un equilibrio entre metas realistas y disfrutar del camino que nos lleva a alcanzarlas.
En un equipo de desarrollo, el papel del Engineering Manager es fundamental. Este rol debe identificar estos problemas y buscar soluciones, establecer losobjetivos, cuestionar lo que se hace y mantener al equipo enfocado en un horizonte claro. Además debe de conocer en qué punto del camino se encuentra cada miembro de su equipo.
Parte 1. El camino del developer
¡DISCLAIMER! Cualquier parecido con la realidad es mera casualidad. No pretendo herir sentimientos, sino compartir mi humilde visión y experiencia adquirida durante estos años como ingeniero de software.
La verdad es que nunca me han gustado las etiquetas de “junior”, “mid” o “senior” que se utilizan para determinar tu salario, jerarquía o incluso para incluirlas en tu perfil de LinkedIn. Creo que estas etiquetas no se ajustan de la misma manera en todas las empresas y están más relacionadas con lo que aportas y tu madurez profesional que con lo que sabes.
Considero que se pueden poseer diferentes habilidades en diferentes niveles. Pero, ¿dónde está la línea que separa uno de otro? ¿Solo se define mediante un aumento salarial o un nuevo contrato?
Por desgracia o por fortuna, los seres humanos tendemos a etiquetar y categorizar desde nuestros orígenes. Lo hacemos para simplificar la complejidad de nuestro entorno, tomar decisiones de manera más eficiente y buscar patrones.
Es importante tener en cuenta que cada persona es única y que siempre existen matices. En el siguiente texto, intentaré describir lo que entiendo y espero de cada uno de estos tres niveles.
Junior
Los juniors suelen ser personas enérgicas y con alta motivación, acaban de salir de su formación, están descubriendo algo nuevo y les llena.
Cada pequeño logro representa para ellos una gran recompensa, pero también es común que anhelen resultados inmediatos. Es importante reconocer que todos enfrentamos desafíos y errores en nuestro camino, y para un junior, estos obstáculos pueden llegar a ser paralizantes. Es fundamental brindarles el apoyo necesario para superar estos bloqueos.
También son personas con reglas fijas (el famoso Golden Hammer). Cuando descubren una nueva solución para resolver un problema, a menudo intentan aplicarla a todas las situaciones posteriores. Esto se debe en parte a su falta de contexto y a una visión más amplia para comprender completamente la complejidad de un problema. Gran parte de su aprendizaje se basa en la metodología de prueba y error.
Los roles junior requieren supervisión y orientación. No debemos olvidar que necesitan un buen mentor y una incorporación efectiva en los equipos. Es esencial que los otros miembros del equipo brinden el apoyo y la paciencia necesarios, ya que, de lo contrario, podrían caer en la frustración.
El junior de hoy será el senior del mañana
Mid
El mid es un animal mid-tológico, pocos se identifican con este nivel. Tampoco existen muchas ofertas laborales que busquen específicamente este nivel, pero existen y están entre nosotros. ¡A veces somos nosotros!
En esta etapa, uno se vuelve cada vez más autónomo, competente y resolutivo. Se comienza adquirir una visión más completa de lo que se está construyendo y se necesita menos orientación. Puede enfocarse en una parte específica del problema y asumir la responsabilidad de la misma.
Sin embargo, el desafío en este nivel es que puede caer en la complacencia si siempre se le asignan las mismas tareas. Es crucial motivarlos con nuevos retos y fomentar una cultura de aprendizaje y desarrollo de investigación para que puedan probar cosas nuevas y descubrir nuevas herramientas.
Los profesionales en el nivel “Mid” a veces pueden caer en la falta de humildad y sobreestimar sus habilidades. Aquí es donde se aplica lo que se conoce como el efecto Dunning-Kruger, un sesgo cognitivo que identifica a personas incompetentes que no son conscientes de su incompetencia.
¿Cuántos de nosotros conocemos el síndrome del impostor? ¿Cuántos lo hemos experimentado? Pues este sesgo es precisamente lo contrario; es esencialmente lo que tradicionalmente se conoce en nuestros tiempos como “cuñadismo”.
¿Alguna vez has ignorado una advertencia porque “ya lo sabías” o has ignorado una crítica porque sentías que sabía más? Cuidado con el exceso de confianza y mantener la humildad bajo control. En tecnología estamos en constante aprendizaje, la beta perpetua del ser humano.
Pero esto no es algo nuevo, grandes pensadores descubrieron este sesgo hace muchos años:
Daría todo lo que sé por la mitad de lo que ignoro. (Descartes)
Solo se que no se nada (Socrates)
¿Se esconde una inhabilidad cognitiva bajo la prepotencia de los individuos “dominantes” y bajo la excesiva humildad de los individuos «dominados»?
Senior
¿Qué es ser senior? Es una respuesta complicada, cada empresa tiene su propia visión de la seniority. En algunas consultoras, dos años trabajando con una tecnología pueden considerarte como el “senior” del equipo, mientras que en procesos de selección te pueden descartar si no tienes al menos cinco años de experiencia con una tecnología en particular.
¿Una persona muy buena técnicamente que se cierra una semana en una solución, genera cuellos de botella y no la comparte con nadie es ser Senior?
Si quieres ir rápido, ve solo, si quieres llegar lejos, ve acompañado.
A veces llegamos a senior, somos los mejores, no escuchamos a nadie y nos centramos en la solución. Pasamos del síndrome del impostor al arrogante.
Un aspecto fundamental es que la seniority no está exclusivamente relacionada con el conocimiento técnico específico. Desde mi perspectiva, un “senior” es alguien que ha convertido el conocimiento en intuición, lo que a mi me gusta llamar un “perro viejo”.
Está capacitado para alinearse con las necesidades reales, servir al equipo, saber cuándo es el momento de intervenir, mentorizar a sus compañeros y tener una visión sobre las decisiones que se toman.Es resolutivo, se comunica bien y entiende el valor del negocio, y comienza a tener buenas soft skills. Asume el liderazgo cuando nadie lo asume. Se comporta de manera proactiva, no espera a que los problemas aparezcan.
En este nivel se poseen habilidades de comunicación sólidas, se comprende el valor del negocio y se desarrollan buenas habilidades interpersonales. Además, asume el liderazgo cuando nadie más lo hace y se comporta de manera proactiva, anticipándose a los problemas en lugar de esperar a que aparezcan.
Es fundamental que los managers estén muy cerca de estos perfiles y promuevan los valores y la cultura de la empresa. Deben proporcionar los mecanismos adecuados para que la comunicación fluya y estar atentos a sus preocupaciones.
Es importante evitar a toda costa que el “senior” se convierta en el héroe del equipo, ya que la responsabilidad debe ser compartida por todos los miembros del equipo.
Parte 2. Arquetipos de Engineering Manager
¿Y ahora qué? Has alcanzado el nivel senior, te interesa el management y te han ascendido/promocionado (esto no es del todo cierto, es un cambio de rol).
Sin embargo, el rol y la etiqueta de “manager” pueden variar significativamente según la empresa. Asumes tu nuevo puesto, pero te surgen miles de preguntas:
- ¿Cuales son ahora tus responsabilidades?
- ¿Cómo sabes si lo harás bien?
- ¿Estás cubriendo todas las necesidades?
- ¿Qué necesita el equipo?
- ¿Cómo sabré enfrentarme a un nuevo problema?
- ¿Cómo me adelanto a los conflictos?
- ¿Tengo que seguir programando?
¿Y qué etiqueta deberías poner en tu perfil de LinkedIn? Identificar qué nombre darle a tu rol e identificar tus responsabilidades puede ser complicado y depende de cada empresa. Te invito a visitar el sitio web progression.fyi, donde muchas compañías comparten públicamente los nombres de sus roles, los diferentes niveles y los caminos de carrera.
Los career path proporcionan transparencia y visibilidad sobre tu plan de desarrollo profesional, así como claridad sobre lo que se espera de ti tanto en tu rol actual como en el futuro. También pueden ayudarte a crecer y avanzar dentro de una empresa, brindando un propósito, significado y una sensación de pertenencia.
Además, están surgiendo frameworks para definir habilidades y diferentes niveles de responsabilidad para los managers. Esto es una forma interesante de medir y establecer las expectativas para cada rol. Ver el ejemplo de https://www.engineeringladders.com/
Entre los atributos importantes a considerar para evaluar el desempeño y el nivel de seniority en el equipo se encuentran:
- Experiencia en la industria.
- Conocimiento técnico.
- Mentoría.
- Influencia.
- Construcción de consenso.
- Resolución de conflictos.
- Comunicación.
- Eficiencia.
- Responsabilidad.
- Planificación y estrategia.
- Presupuesto.
- Motivación.
- Autenticidad.
Estos atributos son esenciales para medir y evaluar el rendimiento y la seniority de los equipos y seguir evolucionando en los puntos en los que no destaquemos.
Los arquetipos de Patrick Kua
Esta sección está inspirada en el artículo “5 engineering manager archetypes” de Patrick Kua, en el cual define diferentes tipos de Engineering Managers según sus responsabilidades dentro de un equipo.
Patrick Kua es un líder tecnológico que descubrí mientras leía su libro “Talking with Tech Leads: From Novices to Practitioners”. Ofrece un material valioso y presenta puntos clave de su libro y en conferencias como esta: Enlace a la conferencia.
Las responsabilidades de un manager dentro del equipo pueden variar significativamente según la madurez de la compañía, el tamaño del equipo y su estructura.
Podemos pensar en estos arquetipos como patrones de diseño en el mundo del software, es decir, estructuras comunes que se pueden encontrar una y otra vez. Cada arquetipo ofrece una combinación diferente de fortalezas que resultan útiles en distintas circunstancias.
- El “Tech Lead EM” es un líder técnico que también asume el rol de un “Engineering Manager” (EM). Se encarga de guiar la dirección técnica de un producto, escribir código y liderar a los miembros del equipo. Además, se enfoca en la arquitectura y la deuda técnica, creando un equipo de alto rendimiento.
- El “Team Lead EM” es una combinación de líder técnico y líder de equipo. Mientras que el Tech Lead se enfoca en aspectos técnicos, el líder de equipo se concentra en el crecimiento y la gestión de personas. Pueden trabajar juntos para equilibrar estos roles y crear un equipo sólido.
- El “Delivery Manager EM” se encuentra en organizaciones orientadas a proyectos o fechas. Se enfoca en cumplir plazos y manejar múltiples partes interesadas. A menudo, tiene experiencia en gestión de proyectos y puede delegar tareas técnicas o de equipo.
- El “Product Manager EM” trabaja junto a un manager de producto para decidir qué y cómo desarrollarlo. Se centran en el “cómo” y pueden especializarse en productos técnicos. Pasan tiempo con usuarios finales y partes interesadas para refinar el roadmap producto.
- El “Leads of Leads EM” lidera grupos más grandes, de 9 a 30 personas. Coordina equipos y estructuras de soporte, trabajando estrechamente con equipos de negocios y productos para maximizar la efectividad. Puede ser una evolución de otro arquetipo y a menudo se le llama “Head of Engeneering” o similar.
En resumen, estos arquetipos describen diferentes roles de liderazgo en ingeniería y gestión de equipos, cada uno con un enfoque particular en aspectos técnicos, de equipo o de entrega, según las necesidades de la organización y el tamaño del equipo.
Es esencial reflexionar sobre la necesidad real de la compañía y del equipo mas allá del nombre del rol y estar dispuesto a adaptarse, alineando siempre las expectativas con lo que se necesita lograr. La flexibilidad y la adaptabilidad son cualidades valiosas en el liderazgo de equipos.
Parte 3. Herramientas
Y para terminar, hablemos de herramientas. Herramientas que pueden ser útiles en tu camino como manager, y que desearía haber conocido cuando asumí este tipo de rol por primera vez.
Si bien tenemos a nuestra disposición miles de plataformas, cursos y artículos sobre cómo trabajar con tecnología, a menudo carecemos de suficiente formación y conocimiento compartido sobre cómo liderar.
Architecture Decision Records
Un registro de decisión arquitectónica (ADR) es un documento que describe una elección que hace el equipo sobre un aspecto importante de la arquitectura de software que planean construir. Cada ADR describe la decisión arquitectónica, su contexto y sus consecuencias. Los ADR tienen estados y, por lo tanto, siguen un ciclo de vida. Para ver un ejemplo de ADR, consulte el apéndice.
El proceso ADR genera una colección de registros de decisiones arquitectónicas. Esta colección crea el registro de decisiones. El registro de decisiones proporciona el contexto del proyecto, así como información detallada sobre la implementación y el diseño. Los miembros del proyecto hojean los titulares de cada ADR para obtener una visión general del contexto del proyecto. Leen los ADR para profundizar en las implementaciones de proyectos y las opciones de diseño.
Cuando el equipo acepta un ADR, se vuelve inmutable. Si los nuevos conocimientos requieren una decisión diferente, el equipo propone una nueva ADR. Cuando el equipo acepta el nuevo ADR, reemplaza el ADR anterior.
La generación de consenso utilizando Architecture Decision Records (ADR) es una práctica importante en el proceso de toma de decisiones arquitectónicas en el desarrollo de software. Los ADR son un mecanismo que ayuda a documentar y comunicar decisiones críticas sobre la arquitectura de un sistema, y también pueden servir como una herramienta efectiva para lograr el consenso entre los miembros del equipo de desarrollo.
Delegation Board
Es una herramienta que ayuda a asignar tareas y responsabilidades de manera equitativa entre los miembros del equipo. La matriz de delegación permite identificar las fortalezas y habilidades de cada persona y asignarles tareas en función de sus capacidades, promoviendo así un equilibrio en la carga de trabajo y el crecimiento profesional.
También ayuda a establecer expectativas claras. Te ayuda a asegurarte de que las expectativas para cada persona estén claras. Define claramente qué se espera de cada miembro del equipo en términos de resultados, responsabilidad y cualquier otro detalle relevante.
Kudo box
Es un reconocimiento escrito y público a un compañero por algo que ha aportado al equipo.
Un Kudo no solo se otorga de arriba hacia abajo, sino de igual a igual y de abajo hacia arriba. En todos los departamentos y organizaciones, cualquiera puede reconocer el trabajo de otra persona. Es una forma de romper las limitaciones jerárquicas y alentar a todos a ofrecer comentarios positivos instantáneos.
Los incentivos aseguran que las personas dejen de hacer cosas solo por el placer de trabajar, pero las recompensas que desencadenan una motivación intrínseca son más efectivas, más sostenibles y, por lo general, cuestan menos dinero.
Mood chart
Los gráficos de estado de ánimo, también conocidos como gráficos emocionales o de sentimientos, pueden ser herramientas valiosas para que los equipos de desarrollo de software realicen un seguimiento y comprendan el estado emocional de los miembros del equipo a lo largo del tiempo. Estos gráficos ayudan a los equipos a identificar patrones, abordar problemas y mejorar la colaboración y la productividad. Así es como se pueden usar los gráficos de estado de ánimo en los equipos de desarrollo de software:
Con el tiempo, estos datos se pueden agregar y visualizar para identificar tendencias en las emociones de los miembros del equipo. Si la mayoría del equipo constantemente reporta estados de ánimo bajos, podría indicar problemas subyacentes que deben abordarse.
La incorporación de gráficos de estado de ánimo en los equipos de desarrollo de software puede ayudar a crear un entorno de trabajo más empático y solidario, lo que en última instancia conduce a una mejor colaboración, una mejor moral y una mayor productividad.
Sin embargo, es fundamental complementar los datos del gráfico de estado de ánimo con otras formas de comunicación y retroalimentación para obtener una comprensión integral de la dinámica del equipo y las necesidades individuales.
Conclusión
Es esencial reconocer que liderar equipos es una habilidad que se puede aprender y mejorar con el tiempo. Al invertir en tu desarrollo como líder, podrás enfrentar los desafíos de manera efectiva y brindar un ambiente de trabajo más productivo y satisfactorio para tu equipo. Conocer a tu equipo es esencial y tu capacidad de adaptarte a las necesidades y características de tu compañía harán que el camino sea mas fácil.
Aquí dejo el video de la charla que se grabó en El Cable (Andalucia Open Future)👇
https://www.youtube.com/watch?v=iPsMv2f7hpY
Bibliografía
https://www.patkua.com/blog/the-definition-of-a-tech-lead/
https://medium.com/@kurtisnusbaum/what-makes-a-senior-software-engineer-b65c88c539c
