A Proposta Certa Perdeu de Novo: Sobre Disputas de Poder Disfarçadas de Decisão Técnica

#career #productivity #leadership #softwareengineering

Você já viu isso acontecer, provavelmente mais de uma vez. Duas propostas de arquitetura na mesa. Uma é mais barata, mais simples de operar, com menos pontos de falha e menos dependência de um único especialista. A outra custa mais, exige mais gente, mais tempo, mais reunião. O comitê aprova a segunda.

Ninguém na sala vai dizer "escolhemos a opção pior porque o autor dela almoça com o VP toda quinta". O que sai é sempre tecnicamente respeitável: "a outra solução escala melhor no longo prazo", "essa reduz débito técnico", "está mais alinhada com a governança de dados que o time de plataforma está cobrando". Frase por frase, nada ali é mentira. E ainda assim nenhuma delas é o motivo real da decisão.

Você sai da reunião sabendo, com uma certeza incômoda no estômago, que perdeu por um motivo que não estava em nenhum slide. Aí vem a parte pior: você não consegue nomear esse motivo sem parecer paranoico, ou amargurado, ou "político demais" — justamente o adjetivo que a pessoa que venceu jamais vai receber, porque ela teve o cuidado de nunca usar a palavra "poder" em voz alta.

Esse padrão não é um acidente raro de processo malfeito. É o processo. Ele se repete em decisão de arquitetura, em prioridade de roadmap, em quem assina o RFC, em quem fica com o crédito do projeto que deu certo e em quem fica com a culpa do que deu errado. É frequente e regular o suficiente para virar lei. Foi esse padrão que virou o livro "As Leis do Poder em Projetos".

O mecanismo: poder usando crachá de competência

Toda empresa de tecnologia roda dois sistemas operacionais em paralelo. Um está documentado: arquitetura, métricas, OKRs, post-mortems, comitês de segurança, RFCs, critérios de promoção. O outro nunca aparece em ata, mas decide tanto quanto o primeiro: quem ganha território, quem é poupado quando o projeto explode, quem tem permissão de discordar em público e quem só tem permissão de discordar "depois, em particular".

A razão pela qual esse segundo sistema é quase impossível de apontar com o dedo é simples: ele fala exatamente a língua do primeiro. "Débito técnico" é uma categoria real de engenharia — e também é a etiqueta perfeita para qualquer decisão antiga que alguém quer revisitar por motivos que não têm nada a ver com dívida nenhuma. "Esse serviço não escala" pode ser um fato de capacidade — ou pode ser a frase que mata o projeto do time concorrente sem que ninguém precise admitir que o problema nunca foi a escala. Métrica, segurança, compliance, governança: cada uma dessas palavras tem a mesma propriedade. Vistas de fora, são indistinguíveis de competência técnica pura. É exatamente por isso que funcionam tão bem como arma — e por isso ninguém jamais é responsabilizado por usá-las assim.

Questionar um veto de segurança em público, por exemplo, não parece rigor técnico. Parece imprudência. Então ninguém questiona, e o veto vira o instrumento de poder mais eficiente da empresa — protegido pelo simples fato de que discordar dele é socialmente caro, mesmo quando ele está sendo usado fora de propósito.

Nada disso exige conspiração de sala fechada. É estrutura, não complô: qualquer hierarquia que distribui orçamento, prestígio e sobrevivência de carreira de forma desigual vai gerar disputa por esses recursos. A particularidade de tech é que essa disputa quase nunca é chamada pelo nome. Ela é chamada de arquitetura.

O livro: 34 leis, seis partes, do diagnóstico à defesa

"As Leis do Poder em Projetos" organiza esse padrão em 34 leis, divididas em seis partes que vão de "isso está acontecendo com você agora, só que ninguém usou essa palavra" até "o que fazer sobre isso sem se tornar a próxima pessoa que faz isso com os outros".

I · Fabricar o Problema

Antes de qualquer disputa de poder ter um vencedor, alguém precisa primeiro convencer todo mundo de que existe um problema — e, de preferência, que só uma solução específica resolve esse problema. Esta parte mapeia como narrativas de crise são fabricadas, infladas e cronometradas antes de qualquer decisão técnica de fato entrar na mesa.

Há quem acenda incêndios para vender extintores
"Débito técnico" é arma retórica, não só conceito de engenharia

II · Dominar a Narrativa

Quem decide qual versão dos fatos sobrevive ao próximo trimestre tem mais poder do que quem efetivamente resolveu o problema. Esta parte trata de como a história de um projeto é escrita — e reescrita — por quem controla os documentos, os canais e, acima de tudo, o vocabulário usado para descrever o que aconteceu.

Quem escreve o post-mortem escreve a história
Quem controla o vocabulário controla o debate

III · Capturar Território

Mérito técnico e ascensão dentro da empresa raramente seguem a mesma régua, e fingir que seguem só atrasa o momento em que você percebe isso. Esta parte é sobre como território — escopo, headcount, visibilidade, acesso — é conquistado e defendido, e por que estar no lugar certo na hora certa costuma valer mais do que ter feito o trabalho certo.

O crédito vai para quem está no palco no dia da demo
Tartaruga não sobe em árvore: mérito e ascensão são coisas diferentes

IV · O Jogo do Executivo

Lá no topo, as regras mudam de novo. Decisões que parecem puramente estratégicas são, com uma frequência desconfortável, sobre a sobrevivência pessoal do executivo dentro do próprio mandato — que costuma durar menos do que qualquer roadmap de três anos. Esta parte olha o tabuleiro a partir de quem só tem alguns trimestres para mostrar resultado antes da próxima reorganização.

O CIO não escolhe a melhor tecnologia; escolhe a que sobrevive à próxima troca de comando
Decida quais incêndios deixar queimar

V · Segurança, Risco e Compliance como Poder

Quando uma disputa não pode ser vencida no mérito técnico, ela costuma migrar para o único terreno onde questionar parece imprudência em vez de rigor: segurança, risco, conformidade. Esta parte expõe como esses domínios — criados para proteger a empresa — também funcionam como o veto mais eficiente disponível para qualquer pessoa disposta a usá-lo.

Segurança é o único veto que ninguém ousa contestar em público
Toda exceção vira precedente — e todo precedente vira poder

VI · Sobreviver Sem Ser Ingênuo (a defesa)

A última parte muda de lado. Depois de mapear o jogo, o livro trata de como jogá-lo sem se tornar aquilo que ele próprio descreve — como proteger bom trabalho, aliados e reputação sem recorrer às mesmas táticas sujas que o resto do livro passou cinco partes documentando.

Não vença discussões; vença antes delas
Ter razão é necessário; ter narrativa, timing e aliados é o que faz a razão valer

Isto não é manual de manipulação

Vale repetir, porque é fácil ler a lista acima e concluir o contrário: isto não é um livro sobre como manipular pessoas para ganhar disputas internas. As mesmas ferramentas que atravessam as 34 leis — controlar a narrativa, escolher o timing, construir aliados, nomear o problema antes que alguém o nomeie por você — não pertencem por natureza a quem age de má-fé. Pertencem a quem as usa primeiro e usa melhor.

A diferença entre usar essas ferramentas para defender um trabalho honesto e usar as mesmas ferramentas para sabotar o de outra pessoa não está na ferramenta. Está em quem decide o que carregar com ela. Dá para escrever um post-mortem rigoroso e, ainda assim, escrever a história. Dá para construir aliados para proteger uma decisão certa, e não para enterrar uma pessoa certa. O livro não finge que essa linha não existe — só argumenta que fingir que o jogo inteiro não existe é a forma mais rápida de perder para quem joga sem essa hesitação.

Lucidez política não é a mesma coisa que cinismo. É a diferença entre ser surpreendido pelo jogo e escolher, de olhos abertos, o que fazer com as cartas que ele te dá.