Por que um time técnico que nunca discorda do fundador é motivo de alerta

Pesquisas da McKinsey e da Bain mostram que líderes superestimam a própria mesa de decisão. Para founders de tecnologia, confundir silêncio com alinhamento custa decisões técnicas erradas e caras.

Nota da redação: este artigo usa como analogia a caricatura do "gestor Zorro", de Pedro Mandelli, e a expressão "discordar e se comprometer" para descrever a fase pós-decisão de um debate técnico. A fonte original (Exame) descreve o Zorro como alguém que "aparece só quando há problema, espanta, mas não resolve", e não usa literalmente a expressão "discordar e se comprometer". Mantivemos o texto como produzido, mas registramos aqui que esses dois pontos são formulações e leituras do autor do artigo, não citações exatas da fonte, para que o leitor possa considerar isso ao avaliar os exemplos.

Pesquisas da McKinsey e da Bain mostram que líderes superestimam a própria mesa de decisão. Para founders de tecnologia, confundir silêncio com alinhamento custa decisões técnicas erradas e caras.

A mesa que concorda rápido não prova que você está certo

Todo founder chega a uma reunião de arquitetura, de contratação ou de corte de escopo esperando alinhamento. O problema aparece quando o alinhamento vem rápido demais, sempre. Um artigo recente do conselheiro e ex-executivo Jean Klaumann (passagens por Neogrid, Linx, TOTVS e Oracle↳Oracle22 conteúdosOracle lança Java 26 para aumentar produtividade de desenvolvedoresDev (Back & Front) · mar 2026Oracle oferece o primeiro cluster de computação em nuvem em escala ZettaDevSecOps · jan 2025Oracle abre inscrições para o ONE, programa gratuito de formação em tecnologia e inteligência artificialData · dez 2024Ver tudo em Data →) na Exame resume o ponto numa frase que vale para qualquer board, inclusive o técnico.

Uma mesa que concorda rápido não prova que o CEO está certo. Prova que ninguém ali é pago para dizer que ele está errado.

Jean Klaumann, conselheiro e ex-executivo de tecnologia, em artigo na Exame

Troque CEO por CTO, board por staff de engenharia, e a frase não perde uma vírgula de validade. A pergunta que todo founder técnico deveria fazer não é se o time concorda com ele. É se alguém ali é pago, protegido e ouvido quando discorda com dados na mão.

O que a McKinsey e a Bain mediram, e o que isso significa para quem lidera código

O artigo cita dois dados que merecem atenção de quem está construindo um time de engenharia, não só um C-level. A McKinsey, em 2025, mediu times de alta liderança de 28 grandes empresas e encontrou um padrão: CEOs avaliam a efetividade do próprio time de forma consistentemente mais favorável do que os integrantes desse time avaliam a si mesmos. A Bain, em pesquisa de 2026 com cem CEOs, achou menos da metade confiante de ter as pessoas certas nos papéis certos, e listou como escassos justamente senso de dono, curiosidade e disposição para assumir risco.

Em startups de tecnologia, esse viés tem um efeito prático específico: o founder técnico costuma julgar a própria arquitetura, a própria stack e o próprio roadmap com mais benevolência do que o time que vive o código todos os dias. Se ninguém na reunião de decisão técnica tem orçamento, cargo e segurança psicológica para dizer "esse desenho não escala" ou "essa contratação é a pessoa errada", a avaliação otimista do founder nunca é testada antes de virar prejuízo em produção ou em runway.

Os três tipos de engenheiro sênior na sua mesa

Klaumann descreve três perfis que compõem qualquer mesa de liderança: quem segue, quem aprova e quem desenvolve o líder. A tradução para um time técnico ajuda a enxergar o próprio org chart com outros olhos.

Nenhum time funciona só com o terceiro grupo. O problema, como aponta o artigo, não é a existência dos dois primeiros perfis: é quando a contribuição do time termina neles. Um staff engineer que nunca questiona a escolha de banco de dados, um head de segurança que nunca bloqueia um deploy por risco, um líder de dados que nunca discute a qualidade do pipeline antes de alimentar um modelo de produção, todos esses são sinais de uma mesa que só segue e aprova.

O gestor Zorro da infraestrutura

O artigo resgata uma caricatura de Pedro Mandelli, em Muito Além da Hierarquia: o gestor Zorro, que aparece só quando há incêndio, resolve sozinho e ensina ao time que esperar pelo chefe é a opção mais segura. Em engenharia, essa figura é o tech lead↳Liderança técnica5 conteúdosLiderança técnica: a arte de inspirar desenvolvedores e gerar transformações 🚀Gestão Dev & TI · mai 2024Full Cycle lança pós-graduação que capacita devs para cargos de liderança técnicaDev (Back & Front) · mar 2024De Dev a Tech Leader: caminhos para se tornar um Tech Leader excepcionalGestão Dev & TI · ago 2024Ver tudo em Gestão Dev & TI → ou founder técnico que só participa de decisões arquiteturais quando algo já quebrou, e que resolve o incidente sozinho em vez de abrir espaço para o time propor a correção. Cada resgate heroico reforça o hábito de não discordar antes do problema acontecer.

Deborah Ancona e colegas do MIT escreveram sobre o "líder incompleto": quem contrata e promove apenas pessoas que pensam como ele acaba com uma organização que pende para um lado só. Um founder de produto que só contrata engenheiros que concordam com a própria visão de UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX → constrói um time cego para o mesmo ângulo que ele é cego. A diversidade de discordância técnica não é um valor abstrato de cultura: é o mecanismo que detecta o ponto cego antes do cliente.

O contra-argumento: discordância sem dono vira paralisia

Nem todo founder que lê isso deveria sair da reunião abrindo espaço irrestrito para debate técnico infinito. Esse é o risco real do outro lado: times de engenharia são famosos por discussões intermináveis sobre linguagem, framework ou padrão de arquitetura que nunca convergem em decisão, o clássico bikeshedding. Discordância que nunca termina em dono e em prazo é tão cara quanto o silêncio, só que mais lenta de perceber.

A resposta que o próprio artigo de Klaumann aponta, resumida no princípio de "discordar e se comprometer", é separar duas fases. Na fase de debate, a discordância técnica com dados é bem-vinda e deve ser ativamente cobrada de quem está mais perto do código. Depois que a decisão é tomada, alguém responde por ela e o time inteiro responde pela execução, mesmo quem discordou. É isso que separa um time que desenvolve o founder de um time que só produz ruído.

Quatro perguntas para o founder fazer ao próprio time técnico

Adaptando o espelho proposto no artigo original para uma mesa de engenharia, quatro perguntas valem mais do que qualquer pesquisa de clima:

1. Para cada pessoa sênior do time técnico, o que predomina: seguir, aprovar ou desenvolver a sua decisão?
2. Quem mudou uma decisão técnica sua com dado concreto neste trimestre, e o que aconteceu com essa pessoa depois?
3. O seu time de engenharia assume junto o resultado de produção, ou espera que você resolva o que acontece entre backend, dados e segurança?
4. Existe alguém na sua mesa cuja função explícita é discordar de você antes que o cliente, o regulador ou a imprensa discordem por ele?

A composição do time técnico revela a régua do founder. A forma como ele contribui revela o espaço real que o founder oferece para ser contrariado. As duas merecem revisão antes que a startup precise escalar além das respostas que já estão sentadas na mesa.

Fonte: Exame