Skip Levels: una práctica sencilla que pocos líderes utilizan


Una práctica de gestión que he estado recomendando con frecuencia en mis mentorías es el skip level.

La idea es simple: conversar directamente con las personas que reportan a quienes lideras.

Por ejemplo, si eres CTO y tienes cuatro Engineering Managers, organizas reuniones periódicas con los desarrolladores y tech leads de esos equipos, sin la presencia de los managers.

¿Pero por qué?

Porque, a medida que una organización crece, la información pasa por varias capas antes de llegar a la dirección. Y en ese camino se pierde mucha información.

El skip level ayuda a mejorar la comunicación en ambos sentidos.

Por un lado, tienes la oportunidad de explicar directamente la estrategia, las prioridades, las decisiones y el contexto de la empresa.

Por otro, las personas pueden hacer preguntas, aclarar dudas y compartir perspectivas que difícilmente llegarían hasta ti por los canales tradicionales.

Cuando era CTO, siempre me gustaba que el CEO hiciera skip levels con mi equipo.

Esas conversaciones me ayudaban a identificar cosas que yo debería estar comunicando mejor. A veces, el CEO recibía preguntas sobre temas que yo creía que estaban claros, pero que las personas desconocían o no habían entendido.

Además, acercaban al CEO a las personas del equipo. Se sentían más valoradas, comprometidas y parte de la empresa al tener acceso directo a quien tomaba las decisiones.

Y, para mí, era una oportunidad de identificar brechas en mi propia comunicación.

¿Cómo hacerlo en la práctica?

  • Reúne grupos relativamente pequeños, idealmente de hasta 20 personas.
  • Organiza encuentros periódicos. Una frecuencia trimestral es un buen punto de partida.
  • Comparte la estrategia, los resultados de la empresa y lo que esperas de la organización.
  • Reserva bastante tiempo para preguntas. Al menos 30 minutos.
  • Responde con transparencia, incluso cuando no sepas algo o no puedas compartir determinada información.
  • Involucra a tus managers en la organización de los encuentros, dejando claro que no se trata de supervisar su trabajo.

Y una precaución importante: un skip level no es una reunión para descubrir qué están haciendo mal tus managers.

Tampoco reemplaza las reuniones 1:1 que cada líder debe tener con las personas de su equipo.

Es un mecanismo para acercar a los líderes a las personas y mejorar la circulación de información.

Algo que me gusta de esta práctica es que también obliga a los líderes a explicar sus decisiones con claridad.

Si no puedes explicarle a un desarrollador por qué determinada prioridad es importante para la empresa, tal vez el problema no esté en la comunicación.

Tal vez esa prioridad tampoco esté tan clara para ti.

Leo Andreucci - CTO Mentor

Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.

Read more from Leo Andreucci - CTO Mentor

Uma prática simples que tenho recomendado para ajudar a esclarecer papéis e responsabilidades é o exercício É / Não é / Faz / Não faz. Funciona assim: escolha um papel, uma área ou até um time e responda a quatro perguntas: É: qual é a missão desse papel? Pelo que ele é responsável? Não é: o que está fora do seu escopo? Com quais outros papéis ele não deve ser confundido? Faz: quais atividades e decisões concretas fazem parte da sua atuação? Não faz: quais atividades não deveria executar,...

Uma prática de gestão que tenho recomendado com frequência nas minhas mentorias é o skip level. A ideia é simples: conversar diretamente com as pessoas que se reportam aos seus liderados. Por exemplo, se você é CTO e tem quatro Engineering Managers, fazer reuniões periódicas com os desenvolvedores e tech leads desses times, sem a presença dos managers. Mas por quê? Porque, conforme uma organização cresce, a informação passa por várias camadas até chegar à liderança. E nesse caminho muita...

Una frase de Max Kanat-Alexander en un podcast que escuché recientemente se me quedó grabada: La IA es un amplificador. Amplifica todo lo bueno que existe en tu proceso de desarrollo. Y también todo lo malo. Si tu equipo tiene buenos tests, CI/CD confiable, código bien estructurado y procesos eficientes, los agentes pueden trabajar mucho más rápido dentro de ese sistema. Pero imagina lo contrario: Los tests son flaky. El pipeline tarda 40 minutos y falla con frecuencia. El código es difícil...