Skip Levels: uma prática simples que poucos líderes usam


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 coisa se perde.

O skip level ajuda a melhorar a comunicação nos dois sentidos.

De um lado, você tem a oportunidade de explicar diretamente a estratégia, as prioridades, as decisões e o contexto da empresa.

Do outro, as pessoas podem fazer perguntas, esclarecer dúvidas e trazer perspectivas que dificilmente chegariam até você pelos canais tradicionais.

Quando eu era CTO, sempre gostei quando o CEO fazia skip levels com meu time.

Essas conversas me ajudavam a perceber coisas que eu deveria estar comunicando melhor. Às vezes, o CEO recebia perguntas sobre assuntos que eu achava que estavam claros, mas que as pessoas não sabiam ou não tinham entendido.

Além disso, aproximavam o CEO das pessoas do time. Elas se sentiam mais valorizadas, engajadas e parte da empresa por terem acesso direto a quem estava tomando as decisões.

E, para mim, era uma oportunidade de identificar lacunas na minha própria comunicação.

Como fazer na prática?

  • Reúna grupos relativamente pequenos, idealmente até 20 pessoas.
  • Faça encontros periódicos. Uma frequência trimestral é um bom ponto de partida.
  • Compartilhe a estratégia, os resultados da empresa e o que você espera da organização.
  • Reserve bastante tempo para perguntas. Pelo menos 30 minutos.
  • Responda com transparência, inclusive quando não souber ou não puder compartilhar alguma informação.
  • Envolva seus gestores na organização dos encontros, deixando claro que não se trata de fiscalizar o trabalho deles.

E um cuidado importante: skip level não é uma reunião para descobrir o que seus managers estão fazendo de errado. Também não substitui as 1:1s que cada gestor deve fazer com seus liderados.

É um mecanismo para aproximar a liderança das pessoas e melhorar a circulação de informações.

Uma coisa que gosto nessa prática é que ela também obriga a liderança a explicar suas decisões de forma clara.

Se você não consegue explicar por que determinada prioridade é importante para a empresa, talvez o problema não esteja na comunicação.

Talvez a prioridade não esteja tão clara nem para você.

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,...

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...

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...