Existem 5 perguntas de liderança para entrevista em TI que revelam rapidamente como um gestor realmente trabalha. Eu aprendi isso da pior forma possível.
A água do café da máquina era sempre a mesma, meio morna, com aquele gosto de plástico queimado no final. Sentado na frente do monitor, revendo o backlog que não andava, a frustração não vinha do código, mas do silêncio. Um silêncio que parecia concordância, mas era só ausência de conversa. Na verdade, era só ausência de liderança.
O que me pegava, e ainda me pega, é como a gente entra nesses lugares achando que está avaliando, quando, na real, estamos sendo avaliados sobre a nossa capacidade técnica e a nossa resiliência a ambientes tóxicos. O RH vende o “desafio”, a “cultura de aprendizado”, e a gente, na nossa ingenuidade técnica, foca na stack. A gente devia focar em quem vai nos liderar.
Estou cansado de reuniões longas e improdutivas, aquelas que começam sem pauta clara e terminam com três novos to-dos vagos, sem dono e sem prazo. Já passei por isso demais. O pior não é a perda de tempo, é a sensação de que ninguém está no comando da conversa, ou pior, que quem está, não se importa. No fundo, é uma falha de sistema que drena a energia de quem realmente produz. Se a empresa não tem uma cultura de objetividade, talvez seja hora de aplicar um detox de reuniões antes que o time perca o fôlego completamente.
Se eu pudesse voltar a algumas entrevistas, eu teria ignorado algumas perguntas sobre frameworks e teria focado em tentar entender a cabeça do meu futuro gestor. Não sobre a visão de mundo dele, mas sobre como ele opera.
Os Sinais Silenciosos na Execução
A gente sempre ouve falar em “visão”, em “inspirar pessoas”. Balela corporativa. O que eu quero saber é como a falha é tratada. Porque ela vai acontecer. Um deploy que quebra, um bug que passa. É aí que a liderança aparece, não nos happy hours.
Comecei a rascunhar umas perguntas que, para mim, dizem mais do que qualquer slide de onboarding. Elas buscam o processo, a rotina, o mecanismo da liderança, não a filosofia.
- “Quando um projeto grande falha em entregar o que prometeu no prazo, qual é a primeira coisa que você faz? Quem você chama para conversar?” Não quero a resposta “eu absorvo a culpa”. Quero saber se a primeira reação é buscar a cabeça de alguém ou se é abrir o post-mortem para entender a falha sistêmica. A diferença entre um líder reativo e um analítico está nesse primeiro movimento. Em lugares ruins, a resposta é sempre uma caça às bruxas silenciosa que acaba em “feedback” para o técnico.
- “Descreva a última decisão técnica controversa que você precisou tomar. Como você garantiu que todos no time se sentiram ouvidos, mesmo que a decisão final fosse diferente da opinião deles?” O silêncio interpretado como desinteresse é um câncer na equipe. Às vezes, a gente só não sabe como se colocar sem parecer arrogante, mas existem formas de construir autoridade técnica sem precisar falar muito, garantindo que sua análise seja levada a sério.
- Você expõe um problema, dá um alerta no code review, e a resposta é um silêncio protocolar. O deploy segue, e o problema volta depois. É o tipo de situação que exige uma postura diferente para ser notado; às vezes, precisamos de uma técnica de escuta ativa não para ouvir, mas para forçar o outro a processar o que estamos dizendo.
- Quero entender se o meu futuro líder sabe que ser ouvido não significa ser atendido. Significa que a discussão foi real.
- “Como você lida com prazos que a gerência de nível superior determina sem envolver a equipe técnica no planejamento?” Essa é a minha favorita. A realidade de TI são os prazos mal definidos, que vêm de cima como um trovão, sem contexto. Um líder de verdade não aceita isso passivamente. Ele refatora o prazo. Não é “bater o pé”, é comunicar o custo do atalho. Se a resposta for um encolher de ombros e um “a gente se vira”, já sei que o sofrimento vai ser meu.
- Qual é a sua métrica mais importante para saber se a equipe está funcionando bem? E qual é o seu principal indicador de que ela está à beira do burnout?” Se a métrica for só “entregas” ou “velocidade”, a gente já sabe o caminho: débito técnico empurrado para debaixo do tapete. Se o líder só olha para velocidade e ignora o estado mental do time, o erro sistêmico é inevitável. Proteger o foco profundo e evitar o burnout deveria ser prioridade de qualquer gestão que se diz técnica. Se o líder não conseguir nomear um sinal de exaustão que não seja um pedido de demissão, ele não está prestando atenção. É o bug silencioso que mata o sistema. É o dev introvertido que para de ligar a câmera na daily.
- “Na sua visão, qual é o propósito de uma reunião de acompanhamento de projeto (‘status meeting’)?” Parece boba, mas é profunda. Se a resposta for “dar status” ou “garantir que as pessoas estão trabalhando”, corra. O objetivo de uma status meeting deveria ser remover bloqueios, refatorar prioridades e alinhar o risco. Se é só um palco para exposição, é mais uma hora roubada do dia de quem precisa codar.
O que eu busco nessas perguntas não é a resposta perfeita, mas o processo de pensamento por trás. Quero ver a honestidade crua de quem já viveu uma falha, e não o texto polido de um livro de negócios. O profissional técnico, especialmente o introvertido, não se sente à vontade com a ambiguidade. Precisa de limites claros e de um processo lógico. E isso começa com a liderança.
Pensando agora, muitas vezes a gente foca tanto na complexidade do sistema, no design da arquitetura, que a gente ignora a arquitetura humana do time. E essa é a mais frágil, a mais cara de se refatorar depois. E é a que a gente menos tenta entender na entrevista. A gente tem que parar de só vender nosso passe e começar a analisar o campo.
No fim das contas, acho que a gente gasta muita energia tentando decifrar o comportamento das pessoas no time, mas esquece que o jogo muda quando o interlocutor é outro. Ainda não sei bem como traduzir esse sentimento de “eficiência técnica” para quem só enxerga planilhas e retorno sobre investimento. É estranho como desenhar uma solução elegante parece não bastar quando o que está na mesa é o cifrão, e isso me faz pensar se a forma como apresentamos nossos sistemas não está precisando de uma refatoração completa. Talvez eu ainda não tenha entendido como conectar o código ao bolso de quem assina o cheque.
