- En un entorno donde se reúnen expertos de distintas áreas, el líder se encarga menos de conocer cada detalle técnico y más de conectar los problemas y marcar la dirección de la solución
- En el liderazgo, más que el conocimiento técnico puro, importan la capacidad de traducir perspectivas y las habilidades sociales; también hay que coordinar conflictos y reforzar objetivos comunes
- Lo importante no es la profundidad de la especialidad de cada persona, sino dejar claras la definición real del problema y la dirección de la solución, y hacer que la discusión termine conectando con las necesidades del usuario y los resultados
- Un líder efectivo no finge saberlo todo, sino que tiene el valor de decir “no lo sé” y crea un espacio para que los expertos puedan aportar con autonomía
- El verdadero valor de un líder está en la traducción de perspectivas, el contexto del problema y la creación de espacios de colaboración, y eso es un factor clave para lograr los mejores resultados
Algo que entendí recientemente
- Estuve en una sala de reuniones con desarrolladores expertos de distintas áreas y el equipo de producto
- No soy la persona con la mayor especialización en una tecnología en particular, pero hoy cumplo el rol de desarrollador líder
- Mi rol como líder entre especialistas no es conocer todas las respuestas, sino encontrarlas y conectarlas
Technical Leadership
- Más que por la profundidad del conocimiento técnico, el líder actúa como un traductor efectivo que habilita la comunicación entre equipos
- Ya sea al explicar el cronograma del equipo de backend o los requerimientos del equipo de producto, interpreta cada perspectiva para hacer posible la colaboración del equipo
Leading is a Social Skill
- La credibilidad técnica por sí sola no basta; son las habilidades sociales las que realmente generan productividad
- Hace falta saber leer las discusiones entre desarrolladores y decidir cuándo mediar un debate o cuándo dejarlo avanzar
- La comunicación efectiva no ocurre solo en documentos, sino también mediante conversaciones activas
Leading is Remembering the Goal
- Cuanto más experto es alguien, más tiende a sumergirse en los detalles técnicos, pero el líder debe mantener el foco en el objetivo general
- Más que centrarse en la discusión técnica, su papel es definir con claridad el problema esencial de la experiencia del usuario y el propósito del negocio
- Si la esencia del problema no se define con claridad, los miembros del equipo pueden perder de vista el problema real según su propia forma de analizarlo
- El líder tiene la responsabilidad de traducir para que el equipo entienda bien el problema y mire hacia el mismo objetivo
Leading is Saying "I Don't Know"
- Más que fingir que conoce todas las respuestas, decir "no lo sé, averigüémoslo juntos" ayuda a crear confianza y una cultura abierta
- Esa actitud permite preguntas y discusión entre los expertos, y les da espacio para mostrar sus capacidades
- El líder da autoridad para decidir y voz a los especialistas de cada tema, y marca una dirección productiva para la conversación
- Cuando dos expertos discrepan sobre cómo implementar algo, el rol del líder no es elegir la "respuesta correcta", sino dar un marco desde la perspectiva de los trade-offs y del impacto en el usuario
The Translation Challenge
- El líder debe poder traducir según el contexto el lenguaje de los desarrolladores, el lenguaje de producto y el lenguaje de la dirección
- Desarrolladores: "Si el servicio de autenticación no tiene un circuit breaker adecuado, podría producirse una falla en cascada bajo carga"
- Equipo de producto: "Si hay un problema en el sistema de login, podría afectar a toda la app, así que necesitamos incorporar protecciones y eso extenderá el calendario una semana"
- Dirección: "En este sprint vamos a priorizar la estabilidad del sistema para reducir el riesgo de negocio"
- No hace falta que los especialistas aprendan también el lenguaje de otras áreas; el líder debe actuar como el puente que cierra esa brecha
Beyond "Because, that's why!"
- Tomar decisiones con la lógica de "soy el líder, así que se hace así" daña la confianza, deteriora la cultura de colaboración y reduce la productividad del equipo
- Es importante tratar al equipo como adultos y explicar con claridad las razones y el contexto de cada decisión
- "Elegimos un enfoque conservador porque el costo de equivocarnos es alto; después podremos mejorar de forma iterativa"
- "Puede sentirse como trabajo extra, pero está alineado con el objetivo de arquitectura y ayudará a desarrollar las siguientes funciones"
- "No es la solución más elegante, pero nos permite desplegar con confianza dentro del plazo acordado"
- Cuanto más se deja de lado la necesidad de aparentar pericia total, más posible se vuelve ejercer un liderazgo real
El valor que un líder debe aportar al equipo
- Definición clara del problema
- Explicación suficiente del contexto de las decisiones
- Traducción de diferencias de perspectiva entre equipos
- Protección frente a la complejidad innecesaria
- Creación del entorno para obtener los mejores resultados
Conclusión
- El liderazgo técnico en organizaciones llenas de especialistas va más allá del mando y control, y se enfoca en conectar y dar contexto
- El líder no es quien toca directamente los instrumentos, sino más bien un director que ayuda a la orquesta a completar una misma pieza
- Es un desafío mucho más interesante que simplemente ser la persona más inteligente de la sala
4 comentarios
Pensándolo al revés, da la impresión de que en un entorno sin expertos, no queda más que convertirse uno mismo en el experto.
Claro, además de ejercer un liderazgo técnico, también dan ganas de liderar de otras maneras, pero cuando te toca trabajar con compañeros que no comparten bien la información, hasta eso se vuelve difícil; así que parece que depende de cada situación.
Qué perspectiva tan genial.
Así es como debo trabajar.
Opiniones en Hacker News
Como líder de un equipo, suelo evitar al máximo tomar decisiones del tipo “yo soy el líder y decidí que se hará así”, pero recalco que, cuando hace falta, no hay que dudar en hacerlo. Dedico tiempo a escuchar a todos y decidir con cuidado, pero cuando el equipo cae en discusiones interminables sobre detalles no esenciales, entendí que como líder debo poner orden. Me hace pensar en esa frase atribuida a Steve Jobs: “si quieres hacer felices a todos, en vez de liderar vende helados”. También es importante, una vez que pasa ese momento, reconstruir la confianza y explicar al equipo por qué no hubo otra opción más que actuar así
Yo también aprendí esa lección a los golpes. Cuando me convertí en manager por primera vez, ingenuamente pensaba que siempre lograría consenso y que el equipo se alinearía de forma natural. Al principio funcionó con un gran equipo, pero después me tocó trabajar con ingenieros que insistían solo en métodos de hace 25 años de otros equipos, y perdí demasiado tiempo esperando un punto de acuerdo. Al final entendí que, una vez que todos ya expusieron bien su postura, llega el momento en que el líder tiene que marcar dirección y decidir
En mi experiencia, pasé por algo parecido trabajando varios años en una F50. En un dominio con 3 personas clave, solo nosotros sabíamos que la opción A, aunque se veía bien por fuera, en realidad tenía muchos problemas. Aunque lo explicábamos, no lográbamos convencer al equipo, así que al final ignoramos la votación y hablamos con el jefe para poder tomar la decisión correcta. En ese proceso entendí muy a fondo que, si se sigue la opinión mayoritaria (opción A) en vez de la dirección que quiere quien realmente tendrá que lidiar con el resultado (opción C), el proyecto sigue acumulando problemas y retrasos. Lo importante es que quienes asumen directamente la responsabilidad y las consecuencias deben tener “derecho de veto”, no una simple votación de popularidad, para que el proyecto avance. En proyectos grandes, varios leads deberían tomar decisiones por dominio, y solo cuando hay un empate o bloqueo el jefe debería decidir con claridad. Cuando un líder evita decidir, todos terminan solo quejándose y la moral del equipo cae de forma muy frustrante
También me acordé de la anécdota de Steve Jobs encerrando a su equipo en un cuarto para que discutieran hasta encontrar una visión común. Llevar a todos en una misma dirección es difícil, pero si falla, la capacidad de ejecución cae muchísimo. Además, si ignoras la opinión del equipo, la gente siente que la están ignorando, así que aunque el resultado importe, no es una forma sostenible de trabajar a largo plazo
Me impactó la diferencia entre “escuchar la voz de todos” y “darle derecho de veto a todos”. Creo que cortar un punto muerto es una función esencial del líder. Claro, si el líder tiene que decidir absolutamente todo, eso también es una señal de problemas de gestión, motivación o de que el equipo no entiende la estrategia
La forma que prefiero es decir: “si esto dependiera de ti directamente, dime cuál sería tu decisión”. La tarea del líder no siempre es tomar la decisión por sí mismo, sino asegurarse de que haya una decisión
Creo que tengo algo de experiencia en este tema. En el pasado me nombraron líder de un proyecto que ya había fracasado tres veces, y trabajé con 6 de los mejores ingenieros de distintos equipos. Todos tenían opiniones muy marcadas y razones sólidas, pero traté de seguir una actitud parecida a “no interrumpas a un enemigo cuando está cometiendo un error”, solo que en versión “no interrumpas a un amigo cuando está haciendo algo grandioso”. Mi postura era: “si no es tu parte, entonces construye otra cosa en la que sí puedas aportar”. Repartimos roles de forma natural, nos influíamos mutuamente de manera suave y aceptábamos que las partes menos importantes no tenían que quedar perfectas. El resultado fue exitoso, y me da mucho orgullo haber creado una estructura donde un equipo lleno de gente talentosa podía aprender entre sí y enfocarse solo en los temas que de verdad requerían debate
Creo que lo que describes se parece al liderazgo llamado Servant Leadership(enlace relacionado en Wikipedia). También es el tipo de liderazgo que más me gusta
Creo que para darles a ingenieros sobresalientes el espacio de liderar sus propias ideas sin intervenir de más, hace falta verdadera confianza, autocontrol y seguridad como líder
Cada vez que el equipo de producto pide una función “simple”, en mi cabeza aparece que probablemente harán falta al menos 3 equipos y actualizar cada uno de sus microservicios. En ese sentido, a veces de verdad detesto los sistemas web modernos
Creo que el problema aquí no es tanto la web moderna en sí, sino una arquitectura donde una sola función “simple” depende de 3 microservicios distintos y las dependencias están dispersas. Al final, la causa principal es un mal diseño del sistema
Entonces me pregunto cuál sería la alternativa
En mi experiencia, conviene evitar frases como “yo soy el lead”, porque pueden sonar a falta de confianza. Más bien, cuando ya reuniste toda la información y tomaste una decisión, deberías poder decir con seguridad: “bien, entonces vamos a hacerlo así” o “quiero que esto se haga de esta manera”
El corazón del problema no es el malentendido, sino la falta de confianza entre las personas. Si un equipo dice que algo tomará 2 semanas, otro equipo piensa que eso debería hacerse en un día y no les cree. Si hubiera suficiente confianza, se aceptaría que el otro equipo tiene más experiencia en ese tema, pero en la realidad se sospecha que la estimación no refleja el trabajo real sino un colchón de tiempo. En esos casos, compartir suficiente explicación y fundamentos ayuda a aumentar la confianza
Hace alrededor de un año me ascendieron a lead developer. Estaba confundido sobre cuál era exactamente mi rol y mi responsabilidad, pero me tranquilizó ver que he venido trabajando con ideas parecidas a las del texto original. Hace unos días leí un artículo sobre “cómo leer tutoriales desde la perspectiva de alguien no desarrollador” y me identifiqué mucho, así que siento que probablemente voy en la dirección correcta
Yo también viví 3 casos en equipos de desarrollo de producto cercanos al software donde el lead dirigía de forma autoritaria, y en todos los casos el resultado fue malo. Después de liderar equipos yo mismo algunas veces, entendí que mi papel no debe ser el de “comandante”, sino el de “hub y mediador”. Cuando hay choques entre integrantes, ayudo a resolver el conflicto; si alguien tiene dudas, reduzco su ansiedad; si surge una idea, evalúo su viabilidad y su valor; y si hacen falta recursos, ayudo a encontrar a quien sea necesario. Si surge un problema, asumo la responsabilidad y animo al equipo a resolverlo. Me tomó más de 10 años aprender todo esto. No soy el mejor ni la mayoría de la gente conoce mi nombre, pero cuando trabajo como un “miembro” del equipo, los resultados son mejores y también baja la rotación de talento. Y como líder, siento que es realmente importante poder decir: “yo tampoco lo tengo del todo claro, pero busquemos la respuesta juntos”. Eso permite que los expertos se sientan con permiso de estar en la incertidumbre, evita que se pongan a la defensiva y además les hace sentir que no están solos. Para quienes alguna vez se sintieron aislados o como piezas reemplazables por culpa de líderes anteriores, ojalá esto les sirva de consuelo. Si un líder quiere guiar bien a su equipo por mucho tiempo, no puede pensar en las personas como máquinas; hace falta cuidarse mutuamente
Me impresionó que el autor grabara personalmente el audio del texto principal
Dijo que le gusta la frase “It's because that's why”, y comentó que si te interesa este tema, los libros de Vanessa Van Edwards le ayudaron mucho para aprender cómo transmitir, según la situación, señales adecuadas de calidez y profesionalismo. Aunque es difícil que una sola persona tenga todas las respuestas, tuvo varias experiencias positivas con ese enfoque
Sobre tomar decisiones, siento que hay algo más —y también nada menos— que “asegurarse de que una decisión ocurra”. Primero, recomiendo que, si es posible, otra persona tome directamente la decisión. Contaron una anécdota de Jean-Louis Gassee en Apple: cuando dos managers le llevaban una disputa, él les daba una decisión que probablemente disgustaría a ambos, y entonces ellos mismos volvían con una alternativa consensuada. Segundo, hace falta lograr que todos los involucrados realmente se comprometan con la decisión, empezando por uno mismo. Añade que esto es muy difícil para managers que se mueven según el viento. Usa como analogía que los estudiantes de derecho siempre piensan de forma cautelosa y analítica, pero los abogados deben defender una postura con firmeza y saber convencer a los demás. Como no siempre se logra un consenso ideal, también comparte el consejo de fijar un punto concreto, como el cliente o un objetivo de resultados, para empujar la decisión y facilitar su ejecución