Um dos temas mais discutidos na trilha de gestão do TDC São Paulo foi a diferença entre autonomia real e autonomia mal desenhada — aquela que promete velocidade e entrega abandono, como resumiu um slide projetado no palco Stadium.
A provocação central: autonomia não é ausência de controle. É um redesenho de como o controle é exercido. Segundo o palestrante, toda decisão delegada precisa responder a três perguntas básicas antes de acontecer: quem decide, sobre o quê, e até onde.
"Autonomia sem capacidade é responsabilização sem proteção."
A frase, também exibida em slide, resume um problema comum em times de tecnologia: dar "liberdade total" para alguém sem antes garantir repertório, contexto e acesso a informação gera pessoas cobradas por resultados que nunca tiveram condição real de entregar — um caminho direto para o burnout, tema que teria palestra própria mais tarde no evento.
Outro ponto de atenção veio de uma frase provocativa: "se interromper exige permissão, a autonomia já falhou". Times de produto e engenharia, segundo o palestrante, deveriam ter mandato para desligar algo que não traz retorno — um produto, uma feature, até um cliente problemático — sem precisar montar comitês para validar o óbvio.
O palestrante também destacou que quem decide oficialmente nem sempre decide de fato: hierarquias formais podem mascarar decisões que na prática são tomadas por quem tem mais informação ou influência informal, e isso precisa ser mapeado conscientemente por quem lidera.
A parte mais prática da fala foi um framework de seis perguntas para times técnicos aplicarem em qualquer decisão que hoje é tratada como "autônoma":
- Contexto: que resultado precisa ser protegido?
- Autoridade: quem decide de fato?
- Limites: até onde essa decisão pode ir?
- Capacidade: há repertório, acesso e recursos?
- Sinais: como saberemos que é preciso corrigir ou interromper?
- Proteção: quem sustentará essa decisão quando ela contrariar o poder?
O palestrante citou o delegation poker — ferramenta ágil já conhecida do público do TDC — como exemplo de técnica que trata autonomia em graus, e não como algo binário.
Durante a sessão de perguntas, um desenvolvedor que trabalha com bancos de dados críticos questionou até que ponto vale a pena resistir a uma ordem de um gestor quando ela pode causar instabilidade em produção. A resposta foi direta: apostar em responsabilidade compartilhada — apresentar os fatos técnicos, a consequência prevista e uma recomendação clara, deixando explícito que o risco da decisão final deve ser dividido entre quem executa e quem manda.
Para quem lidera squads, tribes ou áreas de engenharia, o recado prático é revisitar decisões supostamente "autônomas" do dia a dia e testá-las contra essas seis perguntas — exercício que, segundo a fala, revela rapidamente onde a autonomia é discurso e onde é, de fato, estrutura.