Anti-patrones para líderes de ingeniería

• El tema de conversación más frecuente con CTOs y líderes de ingeniería es la presión del CEO por “acelerar la velocidad de ingeniería”
• A diferencia de ventas o contratación, en ingeniería no hay métricas de resultados claramente definidas
• Desde la perspectiva de un líder de ingeniería, es difícil decirle al CEO que “la ingeniería es un arte y es difícil predecir sus resultados”
• Causas de los desacuerdos entre líderes de ingeniería y ejecutivos
  • Los líderes de ingeniería tienden a seguir con demasiada rigidez los consejos convencionales de liderazgo
  • Generalizar que cierta práctica es útil o no útil dificulta aplicarla según el contexto de la organización
  • La clave de un liderazgo de ingeniería efectivo es decidir según la situación si conviene seguir una práctica o probar un enfoque nuevo
• Artículo que resume lo que contó Will Larson, CTO de Carta, en un pódcast

3 anti-patrones del liderazgo de ingeniería

1. Evitar el micromanagement
2. Evitar medir métricas imperfectas
3. Que el líder sea un paraguas para el equipo

[Anti-patrón #1: evitar el micromanagement]

Tres roles contradictorios para convertirse en el mejor ejecutivo de ingeniería

• Un ejecutivo de ingeniería debe desempeñar tres roles opuestos entre sí, y los mejores ejecutivos saben moverse con soltura entre ellos
  • Rol como parte del equipo ejecutivo: buscar cómo hacer avanzar el negocio
    • A veces puede ser necesario tomar decisiones “malas para toda la ingeniería”, como recortar el presupuesto de ingeniería
    • Eso también puede incluir pasar a un modelo por unidades de negocio en el que la voz de ingeniería tenga menos peso en ciertos temas
  • Rol como gerente de ingeniería
    • Entender la estructura de políticas necesaria para operar la organización de ingeniería y buscar cómo convertirse en un líder efectivo de talento
  • Rol como ingeniero
    • Asumir la responsabilidad por la excelencia técnica y la ejecución de ingeniería, pese a factores de estrés externos
    • Hay que mantener un estándar alto de excelencia técnica
• Muchos ejecutivos tienden a inclinarse demasiado hacia uno de esos tres roles
• Sin importar qué rol desempeñen, los líderes se equivocan cuando se aferran a prácticas de gestión que ya no ayudan
• Cuando de pronto te conviertes en manager de un equipo, tienes el mayor contexto técnico sobre todo lo que hace el equipo, pero al mismo tiempo pasas a ser gerente de personas
• En ese punto, la gente empieza a recibir constantemente el consejo de alejarse de los detalles
• A los nuevos engineering managers muchas veces les dicen que “se alejen del código”
• Se reconoce que para algunas personas ese consejo puede ser útil
• Pero los ejecutivos altamente competentes tienen cierto nivel de entendimiento detallado del dominio que operan
• Si te alejas demasiado de los detalles, te conviertes en burócrata, y esa es una de las razones por las que demasiados engineering managers terminan siéndolo

Cultivar estilos de liderazgo

• Larson recomienda a los ejecutivos de ingeniería olvidarse por completo del término micromanagement y concentrarse en cultivar distintos estilos de liderazgo entre los que puedan elegir
• Cuando no hay un camino claro hacia adelante o cuando personas con contexto sobre ese camino no están de acuerdo de forma intensa, ayuda meterse en los detalles y tomar la decisión uno mismo
• Eso permite entender las palancas que realmente pueden cambiar el negocio, los resultados que el equipo debe lograr, el plazo para conseguirlos y cómo servir mejor a los usuarios
• Desarrollar una convicción más fuerte para la toma de decisiones es algo que se practica toda la vida, y Larson dice que él mismo sigue trabajando en ello
• Hacer preguntas mensuales o trimestrales como “¿Qué estamos haciendo? ¿Por qué lo hacemos? ¿Cuáles son los datos? ¿De dónde vienen realmente esos datos?” ayuda a profundizar más en los detalles

Dos tácticas para acercarse a los detalles

1. Entender el contexto mediante “minería de conflictos”

   • En un entorno nuevo, incluso perder pequeñas diferencias de contexto puede dañar el éxito operativo
   • Aunque tome tiempo hablar con personas que tienen puntos de vista opuestos, es importante el proceso de encontrar las “semillas del conflicto”
   • Un líder exitoso pregunta “¿Cómo debo cambiar yo para adaptarme a la organización?” y no “¿Cómo debo cambiar la organización para que se adapte a mi forma?”

2. Documentar los detalles

   • La estrategia está en todas partes, pero casi nunca está documentada
   • Muchas veces no está documentado el fundamento de las decisiones importantes
   • Construir una cultura de documentación es clave para una organización de ingeniería que se mueve rápido
   • Un líder nuevo debe investigar primero todo lo existente y tomar como benchmark los casos de éxito de otras empresas antes de crear su propia estrategia
   • Al redactar documentos estratégicos, se recomienda usar el framework de Richard Rumelt de “Good Strategy, Bad Strategy”
   • Por mal que esté redactada una estrategia, el simple hecho de documentarla puede mejorarla de la noche a la mañana

[Anti-patrón #2: evitar medir métricas imperfectas]

• Los anti-patrones abundan en la medición
• En un mundo ideal se podría decir de forma tajante “no deberíamos medir eso”, pero hacerlo solo ralentiza el aprendizaje de las organizaciones que te rodean
• Lo más valioso que puede hacer un ejecutivo de ingeniería es educar a otros ejecutivos sobre cómo funciona la ingeniería

Enfocarse en mejorar los modelos mentales

• Uno espera que las métricas muestren la realidad, pero las métricas no solo sirven para mostrar la verdad, también sirven para educar a las personas
• Debería preocuparte más iluminar el modelo mental del CEO o del directorio que sentir que están ofendiendo tu propio modelo mental

Llevar al CEO a los detalles

• En vez de decir “esta es una manera terrible de medirlo”, hay que decir “empecemos por aquí y profundicemos hasta entender las limitaciones de medirlo de esta forma”
• Obligar a la gente a salir de los detalles nunca es una buena manera de hacerlo. Hay que llevarlos a los detalles y educarlos ahí

[Anti-patrón #3: ser un paraguas para el equipo]

• Antes se creía en actuar como un “paraguas” para proteger al equipo
• Pero proteger al equipo de la realidad termina perjudicándolo a largo plazo
• Tanto managers como ingenieros deben poder participar en conversaciones importantes

Hace falta una nueva perspectiva para la toma de decisiones estratégicas

1. Estrategia Bottom-Up
   • Ventaja: permite que el equipo se mueva rápido y controle sus herramientas
   • Desventaja: no hay capacidad de hacer inversiones tecnológicas concentradas y la información llega con algo de retraso
2. Estrategia Top-Down
   • Desventaja: es ineficiente que el CTO o un grupo de arquitectura tome todas las decisiones
   • Casi nunca un comité toma la mejor decisión

Usar “navegadores” para acelerar la toma de decisiones

• Se acelera la toma de decisiones colocando “navegadores” que actúan como “mini CTOs” por cada unidad de negocio
• Así, quienes tienen más contexto en el terreno pueden tomar las decisiones más adecuadas sobre el stack tecnológico
• Lecciones para tener éxito:
  1. No omitir la documentación
  2. Hacer revisiones posteriores
  3. Ser muy cuidadoso al elegir a quién confiar
• Las organizaciones son la acumulación del criterio de unas pocas personas, y no hay forma de escapar de eso

Cierre

• Los riesgos de seguir reglas con demasiada rigidez
  • Cuando el equipo de ingeniería empieza a crecer junto con la empresa, los líderes no deben olvidar aquello que antes metió en aprietos a muchos ejecutivos bien intencionados
  • El objetivo final es crear mecanismos de alta calidad para que la gente mantenga la curiosidad y busque excepciones
• Círculo de aprendizaje (Learning Circle)
  • Larson ha organizado un “círculo de aprendizaje” cada dos semanas durante los últimos tres años y medio
    • Entre 6 y 10 CTOs, VP of Engineering u otros ejecutivos senior de ingeniería de empresas tecnológicas se reúnen para compartir novedades e intercambiar problemas tácticos y de procesos
    • Cada reunión empieza con una ronda de 1 minuto por persona para decir en qué se están enfocando esa semana y de qué tema quieren hablar
    • Tras hablar unos 5 minutos de los temas, el grupo elige uno y lo analiza a fondo durante unos 20 minutos
    • Los temas van desde “este proyecto me está metiendo en problemas” hasta “acabo de contratar a alguien realmente excelente y estoy entusiasmado”
• Aprender a través de la práctica
  • Quienes aprenden mediante la práctica pueden apoyarse en reflexiones regulares como los círculos de aprendizaje o la reflexión personal para forzarse a la introspección necesaria para ajustar las reglas con delicadeza
  • Larson dice: “Me convertí en un mejor líder aprendiendo de las lecciones de otras personas que cometieron errores parecidos a los míos”

[geniuskey]

La última parte, donde dice algo como "Larson dijo: '... me convertí en un mejor líder'", me da un poco de vergüenza. Creo que habría sido más agradable de leer si hubiera sido algo como: "Un líder debe esforzarse continuamente para... Yo también sigo teniendo carencias y estoy tratando de mejorar". ¿Será una perspectiva demasiado coreana? ^^;;

[savvykang]

Por cómo pregunta si es una perspectiva coreana, parece que usted lo entiende bien. Desde mi punto de vista, el hablante ni siquiera está mostrando narcisismo, así que esta reacción me parece un poco desconcertante.

[tofumaker]

Centrarse en la actitud del hablante, en lugar de en la esencia o el contenido de tu texto, es algo muy coreano.

[savvykang]

Es "Antipatrón #1: evitar la microgestión", pero luego dice que hay que olvidarse de la microgestión, así que el desarrollo del contenido se siente raro.

[frog08]

El antipatrón es considerar la micromanagement como algo malo, algo que no debe hacerse, y evitarla incondicionalmente. La idea es no juzgar si es o no micromanagement, sino revisar los detalles según sea necesario.

[savvykang]

Al menos, si hubieran dicho algo como "anti-patrón: considerar el micromanagement como una opción" o "pensar que cuidar los detalles y hacer micromanagement son lo mismo", el contexto habría fluido un poco mejor. Entiendo la intención del texto, pero al final el mensaje que quiere transmitir es que, en vez de "micro"gestionar, hay que gestionar cuidando los detalles.

[kandk]

Cuando me reúno con CTOs o líderes de ingeniería, el tema de conversación que más surge es la presión del CEO para "aumentar la velocidad de ingeniería"
A diferencia de ventas o contratación, en ingeniería no hay métricas de desempeño claramente definidas
Desde la perspectiva de un líder de ingeniería, es difícil decirle al CEO que "la ingeniería es un arte y es difícil predecir los resultados"

[xguru]

Consulta también las opiniones en Hacker News sobre este artículo.

• La opinión de que el enfoque de Will Larson, aplicado en varias organizaciones, no ha sido tan efectivo. Su metodología provoca conflictos entre ingeniería y negocio.
• Recomendación del libro de Ron Jeffries: recomienda The Nature of Software Development, enfatizando el valor incremental, el liderazgo desde ingeniería, la retroalimentación continua y la flexibilidad.
• Es positivo que Larson tenga capacidad de autorreflexión y autocrítica. Sus textos no siempre son correctos ni incorrectos, pero está profundamente comprometido con resolver problemas.
• Por la naturaleza de los productos web, los errores no suelen ser fatales, y los cambios frecuentes muchas veces se hacen por razones de marketing. Por eso se forma una cultura de moverse rápido y tolerar errores.
• El lado positivo de la microgestión: un buen líder de ingeniería entiende bien los detalles y sabe comunicarse con el equipo. Eso es distinto de la microgestión.
• Hay demasiado personal técnico, lo que genera problemas. Si se desarrollan mejores herramientas, incluso equipos pequeños podrían hacer suficiente trabajo.
• El problema no es la medición en sí, sino sacar conclusiones equivocadas a partir de sus resultados. Las métricas deberían usarse como herramientas para hacer preguntas.
• En el desarrollo de software a gran escala, la colaboración es clave. El colapso de la comunidad es una causa principal de la desaceleración de los proyectos.
• Si en el pipeline de desarrollo no están claros los roles y las expectativas de cada quien, surgen problemas. Los gerentes deben resolver estas situaciones.
• Es un buen artículo, pero hay opiniones de que sería mejor si se redujera su extensión en un 25%.