De especialista a bom gerente: um plano de ação para lideranças de tecnologia

O livro Managers, Not MBAs, de Henry Mintzberg, traz muitas provocações úteis para quem atua em tecnologia: gestão não é apenas análise, decisão, método ou ferramenta. Gestão é uma prática. E essa prática se desenvolve com experiência real, reflexão, mentoria, contexto e responsabilidade.

Esta é uma síntese sobre o livro “MBA, não obrigado!” (ou em inglês Managers, Not MBAs), e transforma essas ideias em um guia prático para gerentes, coordenadores, tech leads, tech managers, engineering managers e pessoas que desejam migrar para liderança em tecnologia.

A proposta aqui é responder uma pergunta mais objetiva:

Como desenvolver gestores melhores em tecnologia sem cair em regras dos frameworks, da agenda lotada e da liderança heroica?

Muita gente entra na gestão achando que precisa encontrar “o modelo certo”. Scrum, Kanban, OKR, DORA, Team Topologies, matriz RACI, one-on-one, feedback contínuo, gestão por competências, roadmap trimestral.

Tudo isso pode ajudar. Mas nada disso substitui o julgamento.

A primeira virada de mentalidade é entender que não existe uma melhor forma universal de administrar. O que existe é uma forma mais adequada para determinado contexto.

Antes de aplicar qualquer método, faça um diagnóstico simples:

Um time sênior, com domínio técnico forte e produto bem definido, pode funcionar bem com alta autonomia e pouca intervenção.

Um time júnior, em um sistema legado crítico, sem documentação e com incidentes frequentes, talvez precise de mais orientação, padrões, revisão técnica e acompanhamento.

A mesma “autonomia” pode ser maturidade em um lugar e abandono em outro.

Uma confusão comum: pessoas interessadas em estratégia, mercado, produto, lucro ou crescimento acreditam automaticamente que têm perfil para gestão. Nem sempre.

Gestão exige interesse por pessoas, conflitos, coordenação, desenvolvimento, comunicação, responsabilidade e ambiguidade. Nem todo mundo que gosta de negócio quer lidar com isso.

Antes de buscar um cargo de liderança, responda com honestidade:

Um desenvolvedor sênior quer virar gerente porque “já está no topo técnico”. Esse motivo é fraco.

Uma motivação melhor seria:

“Quero criar ambientes onde pessoas técnicas consigam tomar melhores decisões, crescer, colaborar e entregar sistemas mais sustentáveis.”

Essa diferença parece pequena, mas não é!

Um erro comum é imaginar o gerente como “a pessoa que decide”.

Em tecnologia, isso cria gargalos. O gerente passa a aprovar tudo, participar de tudo e ser copiado em tudo. No início parece controle, depois vira dependência.

O papel mais maduro do gestor é melhorar a capacidade do próprio time tomar boas decisões.

Crie critérios explícitos de decisão:

Problema: todo deploy precisa de aprovação do gerente.

Ação melhor: definir critérios.

Isso cria autonomia sem virar faroeste.

Gestores de tecnologia adoram ferramentas. Métricas, dashboards, frameworks, modelos de maturidade, matrizes de priorização.

O problema não é usar técnica. O problema é usar técnica para evitar pensar.

Um time começa a medir a quantidade de tickets entregues por sprint. A métrica parece objetiva.

Efeito colateral: o time quebra entregas em pedaços artificiais, evita tarefas complexas, entrega mais itens pequenos e reduz conversas sobre valor.

Métrica boa não é a que parece precisa. É a que melhora a decisão sem distorcer demais o comportamento.

Existe uma ansiedade em acelerar lideranças. Pessoas são promovidas rapidamente porque entregam bem, falam bem, seguram crises ou têm visibilidade. Mas liderança exige maturidade.

A provocação aqui é antiga: bons líderes precisam de formação intelectual, prática, exposição progressiva, testes reais e tempo. Não necessariamente décadas, mas também não apenas um curso de fim de semana.

Um tech lead brilhante tecnicamente pode não estar pronto para gerenciar se:

Nesse caso, a empresa não deveria simplesmente promover. Deveria desenvolver.

Um erro comum em empresas de tecnologia: promover alguém e agir como se a pessoa só tivesse mudado de nível. Na prática, a pessoa muda de profissão.

Antes, ela entregava principalmente por contribuição individual. Depois, passa a entregar por meio de contexto, pessoas, prioridades, decisões e sistemas de trabalho.

A pressa para “mostrar serviço” é uma das primeiras armadilhas. Às vezes o melhor movimento inicial é parar de mexer onde você ainda não entendeu.

Muitas empresas promovem alguém para gestão e oferecem quase nada: talvez um treinamento genérico, uma planilha de metas e acesso a reuniões novas. Depois, esperam que a pessoa aprenda sozinha.

Isso não é desenvolvimento, é abandono com crachá.

A nova gerente precisa lidar com uma pessoa de baixa performance.

Modelo ruim: “Vai lá e resolve.”

Modelo melhor:

A pessoa aprende fazendo, mas não aprende abandonada.

Gestores crescem quando enfrentam contextos variados. Quem só liderou um tipo de time tende a achar que sua experiência é universal, mas não é!

Um gerente que passou por produto maduro, legado crítico, plataforma, operação, crise, fornecedor e crescimento acelerado desenvolve um repertório mais amplo.

Um gerente que lidera apenas squads de feature pode passar seis meses próximo de SRE e plataforma. Ele provavelmente voltará com outra visão sobre confiabilidade, custo, padrões e impacto de decisões locais no sistema inteiro.

Experiência é necessária, mas não suficiente. Uma pessoa pode viver sob pressão e aprender maturidade. Também pode aprender brutalidade. Pode passar por crise e aprender clareza. Também pode aprender controle excessivo.

A mentoria ajuda a transformar experiência em aprendizado.

Um gerente relata: “Meu time não tem autonomia.”

Mentor pergunta:

A mentoria boa não entrega resposta pronta. Ela melhora a qualidade da pergunta.

Acompanhar o desenvolvimento de gerentes é necessário. Mas há risco de transformar avaliação em teatro.

Feedback 360, pesquisas, metas, performance review e assessments podem ajudar. Também podem virar instrumentos de política, medo e autopromoção.

Um gerente entrega todas as metas, mas o time perde pessoas, aumenta incidentes e depende dele para toda decisão.

A avaliação não deveria ser positiva sem ressalvas. Resultado de curto prazo com sujeira embaixo do tapete é dívida gerencial.

Treinamento no trabalho não deveria significar “aprenda apanhando”. O modelo mais saudável combina observação, prática, orientação e responsabilidade progressiva.

Antes de um novo gerente conduzir sozinho uma conversa de desligamento ou performance crítica, ele deveria observar uma conversa conduzida por alguém experiente, discutir o contexto, entender os cuidados e depois fazer debriefing.

Não é burocracia, é cuidado e responsabilidade.

Casos de usos genéricos, ensinados em treinamentos ajudam, mas têm limite. O aprendizado mais forte vem dos problemas reais da empresa.

Gestores deveriam estudar os próprios casos: incidentes, conflitos, atrasos, reestruturações, decisões ruins, falhas de comunicação e sucessos relevantes.

Caso: time de checkout tem incidentes recorrentes em produção.

Discussão superficial: “precisamos de mais testes.”

Discussão melhor:

Casos de uso reais forçam a organização a parar de tratar sintoma como causa.

Gerentes já vivem sobrecarregados e cercados de ação: reuniões, decisões, incidentes, cobrança, alinhamentos, mudanças, conflitos e urgências.

O problema raramente é a falta de movimento. O problema é a falta de tempo para transformar o movimento em aprendizado.

Toda sexta-feira, o gerente responde:

Depois de um atraso, o gerente pode apenas cobrar mais previsibilidade.

Ou pode refletir:

A segunda abordagem desenvolve gestão. A primeira só aumenta o volume da cobrança.

Reflexão não precisa ser solitária. Gestores aprendem muito quando compartilham casos reais com pares.

O melhor modelo combina três níveis:

Grupos de reflexão podem virar reclamação coletiva. Para evitar isso:

Às vezes a empresa realmente não deixa. Mas nem toda impotência é estrutural. Algumas são só falta de conversa difícil mesmo.

Gestão em tecnologia exige um conjunto amplo de competências. Não basta ser bom em arquitetura, entrega ou comunicação executiva.

Antes de liderar outras pessoas, o gerente precisa entender como lidera a si mesmo.

Isso inclui observar ego, ansiedade, necessidade de controle, medo de perder relevância técnica, busca por reconhecimento e dificuldade de aceitar erros.

Responda sem floreio:

Um gerente diz que o time “não assume responsabilidade”. Ao refletir melhor, percebe que toda decisão importante passa por ele, toda falha gera cobrança dura e toda iniciativa fora do esperado é corrigida publicamente.

Conclusão: o time não evita responsabilidade por imaturidade. Evita porque aprendeu que autonomia tem punição.

Essa é a utilidade de gerenciar o ego: enxergar como o próprio comportamento cria o sistema que depois você critica.

Abaixo está um modelo que uma organização poderia aplicar.

Use esta tabela como revisão periódica.

Gerenciar tecnologia não é apenas organizar tarefas, cobrar prazos ou aplicar frameworks. É desenvolver pessoas, criar contexto, melhorar decisões, sustentar qualidade, negociar com a organização e aprender continuamente com a prática.

O bom gerente não é o herói que resolve tudo. Também não é o analista que transforma toda decisão em modelo. É alguém capaz de agir, refletir, ajustar e desenvolver outros em um ambiente real, ambíguo e cheio de restrições.

A frase final poderia ser:

Inspirado pelas provocações de Managers, Not MBAs, o caminho para formar melhores gerentes não está em trocar prática por teoria, nem teoria por prática, mas em combinar experiência real, reflexão honesta, mentoria, contexto e ação responsável.