- Texto que apresenta estratégias práticas para que engenheiros participem de forma eficaz da política organizacional em empresas de tecnologia, abordando como superar o sentimento de impotência política que muitos engenheiros têm
- Engenheiros não são jogadores do jogo político, mas ferramentas; ainda assim, podem exercer influência política apoiando ativamente o sucesso de projetos de alta visibilidade ou propondo ideias técnicas alinhadas às mudanças de prioridade da organização
- Como os interesses da organização mudam como ondas, a estratégia central é preparar com antecedência programas técnicos em várias frentes, como estabilidade, experiência do desenvolvedor e melhorias de desempenho, e propô-los no momento certo
- Quando a necessidade política entra em choque com a ausência de boas ideias, são tomadas as piores decisões técnicas; engenheiros seniores têm a responsabilidade de apresentar a ideia certa na hora certa
- De forma cínica, isso pode ser visto como tornar-se uma ferramenta da disputa por poder, mas, de forma otimista, como uma maneira de atingir seus próprios objetivos técnicos respeitando a definição de prioridades da liderança
A crença comum na impotência política dos engenheiros
- Muitos engenheiros de software têm uma postura fatalista em relação à política da empresa e acreditam que participar não faz sentido
- Decisões técnicas frequentemente são tomadas por motivos totalmente egoístas, então engenheiros bem-intencionados não conseguem influenciar
- Stakeholders poderosos são incompetentes e disfuncionais demais, de modo que entender suas demandas e oferecer soluções é praticamente impossível
- O jogo político depende de informações privadas às quais engenheiros não têm acesso, então tentar participar só leva a agir no escuro
- Gerentes e executivos passam a maior parte do tempo com política, enquanto engenheiros passam com engenharia, então engenheiros já começam em grande desvantagem política
- É verdade que engenheiros de software não conseguem jogar no mesmo nível que os verdadeiros operadores políticos
- Quando engenheiros começam a tramar como em Game of Thrones, isso é um erro terrível, e esse tipo de manobra é imediatamente percebido e usado contra eles
- Para tramar, é preciso prática e poder, e engenheiros de software não têm nenhum dos dois
Formas práticas de participar da política
- Em grandes empresas, é um fato simples que engenheiros de software não são jogadores do jogo político, mas ferramentas; ainda assim, existem muitas formas de participar da política sem recorrer a manobras
- A forma mais fácil é trabalhar ativamente pelo sucesso de projetos de alto perfil
- Isso é quase igual ao que já deve ser feito como parte do trabalho normal
- Se a empresa está investindo muito em um novo projeto (hoje em dia, provavelmente um projeto de IA), usar sua capacidade de engenharia para fazê-lo dar certo é um movimento politicamente vantajoso para o VP ou executivo que o lidera
- Em troca, você recebe as recompensas que um executivo pode oferecer em uma empresa de tecnologia, como bônus, ajuda com promoção ou posições em futuros projetos de alta visibilidade
Usando ideias técnicas em campanhas políticas
- Um método um pouco mais difícil, mas que dá mais controle, é tornar suas ideias preferidas úteis para campanhas políticas já existentes
- Suponha que você queira separar uma funcionalidade existente em um serviço à parte; há duas formas de fazer isso
- Forma difícil: gastar seu capital político para reunir apoio, convencer seu gerente de que isso é importante e persuadir lentamente os céticos até conseguir aprovação para o projeto
- Forma fácil: deixar que um executivo use seu capital político (muito maior) no projeto
- Esperar até haver uma orientação para toda a empresa em torno de um objetivo alinhado ao projeto (por exemplo, foco em estabilidade após um incidente importante)
- Depois, sugerir ao seu gerente que seu projeto pode se encaixar nisso
- Se você avaliou corretamente, a organização apoiará o projeto e, em vez de consumir capital político, ele passará a aumentar
Surfando as ondas de interesse da organização
- O interesse da organização vem em ondas
- Quando chega um período de foco em estabilidade, os VPs ficam desesperados para mostrar ação, querem encontrar algum projeto de estabilidade plausível para apresentar aos seus chefes, mas não têm capacidade de fazer isso sozinhos
- Em geral, eles ficam dispostos a financiar praticamente qualquer coisa que um time de engenharia proponha
- Por outro lado, quando a atenção da organização está voltada para outro lugar (por exemplo, um grande lançamento de produto), eles não querem que engenheiros gastem tempo com refatorações internas focadas em estabilidade que o cliente não vê
- Para concluir trabalho técnico em uma empresa de tecnologia, é preciso esperar a onda certa
- É uma boa ideia preparar com antecedência programas técnicos em várias direções
- Engenheiros fortes normalmente identificam isso automaticamente no curso do trabalho cotidiano
- Exemplos de planos:
- Migrar o código de cobrança para dados armazenados atualizados por webhooks em vez de chamadas de API em cache
- Remover um antigo pipeline de build artesanal e substituí-lo por Vite
- Reescrever em Golang um serviço Python bagunçado e de alto tráfego
- Trocar um frontend lento de CMS que dá suporte à documentação pública por um site estático rápido
A importância de propor na hora certa
- Quando executivos estiverem preocupados com cobrança, você pode propor a refatoração da cobrança como melhoria de estabilidade
- Quando estiverem preocupados com experiência do desenvolvedor, você pode propor a substituição do pipeline de build
- Quando clientes reclamarem de desempenho, você pode apresentar a reescrita em Golang como uma boa opção
- Quando o CEO olhar o estado da documentação pública e ficar constrangido, você pode defender uma reconstrução em site estático
- O importante é manter pronto um programa de trabalho detalhado, eficaz e imediatamente executável, seja qual for a moda do mês
O momento em que surgem as piores decisões técnicas
- Mesmo sem seguir essa abordagem, algum programa receberá orçamento, mas, se você não agir assim, não terá controle sobre qual será
- É exatamente aí que empresas tomam as piores decisões técnicas: quando a necessidade política de fazer alguma coisa colide com a ausência de uma boa ideia
- Quando não há boas ideias, até ideias ruins acabam sendo usadas, mas ninguém prefere esse resultado
- É ruim para o executivo: ele precisa vender um resultado técnico decepcionante como se fosse sucesso
- É ruim para o engenheiro: ele precisa gastar tempo e esforço construindo a ideia errada
- Se você é um engenheiro muito sênior, VPs vão culpá-lo silenciosamente por isso, e eles estarão certos
- É sua responsabilidade ter a ideia certa pronta na hora certa
Duas perspectivas
- Perspectiva cínica: isso pode ser lido como um convite para se tornar uma ferramenta conveniente para sociopatas que comandam a empresa em uma disputa interna de poder sem fim
- Perspectiva otimista: isso pode ser lido como uma proposta para deixar que executivos definam as prioridades gerais da empresa (afinal, esse é o trabalho deles) e alinhar seus planos técnicos a isso
- De qualquer forma, promover o plano certo na hora certa permite atingir mais objetivos técnicos
Reação no Hacker News e citações relacionadas
- O texto recebeu atenção no Hacker News e teve uma reação muito mais positiva do que outros textos sobre política
- Um comentário menciona uma citação de Milton Friedman e aplica a ideia do texto à política pública em geral
- "Apenas uma crise — real ou percebida — produz mudança verdadeira. Quando essa crise acontece, as ações tomadas dependem das ideias que estão por perto. Essa é nossa função básica: desenvolver alternativas às políticas existentes e mantê-las vivas e disponíveis até que o politicamente impossível se torne politicamente inevitável"
- Alguns comentários criticaram essa abordagem por ser excessivamente estratégica e egoísta, mas o autor considera que isso depende do objetivo
- Um comentário resume bem o ponto central do texto: "Em vez de ficar esperando instruções, agir com cinismo diante de ideias ruins quando surge um vazio e não fazer o que quer, o autor mantém um backlog de ideias boas e importantes para levantar quando alguém importante disser que algo virou prioridade. Ele abre mão de rigidez no timing para conseguir realizar o que quer"
1 comentários
Comentário do Hacker News
O ponto principal deste post é o seguinte
O primeiro ponto pode soar óbvio, mas é um tema sobre o qual já orientei muita gente em início de carreira várias vezes Muitas pessoas que estavam com dificuldade ou caminhando para um PIP tiveram uma virada só por executar bem este ciclo:
Eu interpreto o item 2 como preparar minha própria agenda. Por exemplo, se eu quiser tornar a codebase mais minimalista, preparo um PoC e os detalhes relevantes para poder propor isso imediatamente quando surgir a oportunidade Graças a essa preparação, se aparecer um problema de velocidade do site, SEO ou algum bug, também posso propor essa ideia minimalista como solução Acho esse conceito interessante, mas penso bastante em como aplicá-lo na prática. Muitas vezes considero manter documentos preparados para usar no futuro. Seria como tocar um blog, documentando meu trabalho de forma contínua e esperando a oportunidade certa Muito desse trabalho extra pode acabar não servindo para nada, mas na verdade acho que já faço bastante disso de qualquer forma
Uma coisa que eu acrescentaria é: não faça levianamente algo a que pessoas com mais poder político do que o seu gerente se opõem. A exceção é se alguém ainda mais poderoso mandar isso publicamente Não quer dizer que você deva necessariamente fazer o que essas pessoas querem, mas é importante tomar cuidado para não irritá-las à toa Quase nunca vale a pena criar inimigos, e a maioria dos gerentes, numa crise, também pode me transformar em bode expiatório para se proteger
Eu prefiro ser a pessoa que propõe diretamente ao gerente “o que deve ser feito”. Coloco questões importantes na mesa e defendo por que elas importam É preciso agir de forma proativa para que o gerente se beneficie da minha especialidade Eu ainda não tenho tanta experiência nisso, mas já tive alguns casos de sucesso
Esse tipo de conselho fica mais importante quanto mais alto você sobe. Vale também para engineering manager, e eu tentava aplicar esse princípio até quando era diretor reportando diretamente ao CTO
Uma das minhas citações favoritas é: "Somente uma crise real, ou percebida, produz mudança de verdade. As ações tomadas nesse momento dependem das ideias que estão circulando ao redor. Nossa função básica é desenvolver políticas alternativas, mantê-las vivas e disponíveis, até que o politicamente impossível se torne politicamente inevitável" - Milton Friedman Escrever 1 Pager e documentos técnicos, compartilhá-los com antecedência e citá-los de novo quando a crise chegar funcionou bem para fazer minhas ideias ganharem tração Já consegui empurrar gradualmente a direção de arquitetura que eu queria, me aproximando do objetivo aos poucos, e construir consenso é importante Claro, muitas vezes fui atropelado por VPs ou diretores com mais habilidade política do que eu Mas foi muito mais eficaz manter uma biblioteca de 1 Pagers, compartilhá-los discretamente e deixá-los “no ar” até surgir motivação para executar
Eu me identifiquei com a parte de “perdi a disputa política”. Uma coisa surpreendente que percebi depois de virar gerente intermediário ou acima disso é como fica muito visível quando funcionários de nível mais baixo fazem politicagem Muitos ICs ou EMs de primeiro nível superestimam seu próprio instinto político ou seu social IQ Além disso, a profundidade e a amplitude da comunicação dentro da organização são diferentes, então alguém pode achar que está convencendo uma pessoa, mas esse stakeholder depois comenta discretamente o contexto com o gerente Vi esse tipo de cena muitas vezes enquanto nós, na equipe de gestão, tentávamos controlar discretamente politicagens mal executadas
Tenho curiosidade sobre o que significa, na prática, “deixar 1 Pager e documentos técnicos circulando por aí”
Concordo com essa citação e acho que esse método pode funcionar. Só que, na realidade, a escala de tempo é insana e pode ser desgastante Além disso, muitas vezes a crise é simplesmente ignorada, então ela nem chega a ser percebida ou acaba sendo normalizada
Tenho curiosidade se os 1 Pagers ajudaram você a ganhar reconhecimento e crescer na carreira, ou se só ajudaram a fazer as ideias virarem realidade
Este é o melhor caminho na minha opinião
Fazer deploy em produção com frequência (foco em entrega real, não em trabalho teórico)
Alcançar resultados significativos (wins), medidos por métricas combinadas
Ter alguém da gestão ou de PM que saiba “vender” bem meus sucessos Mas ainda assim surgem problemas. Sempre aparece um VP ou líder novo querendo mostrar inovação. A equipe que mantém os sistemas existentes acaba sendo rotulada como errada, e o novo VP reforça sua linha com ideias progressistas como IA. A partir do momento em que meu código entra em produção, ele já passa a ser tratado como "legado" Então o VP começa a prometer um futuro brilhante, e a minha função de manter a realidade atual nunca consegue competir com isso. A realidade não é sexy nem divertida. Aí você vira a velha guarda No fim, a essência é relação de patrocínio: ajudar o VP acima de mim a ter sucesso e criar uma posição para ir junto quando ele mudar de empresa
Acho isso muito verdadeiro. Indo um nível além, como staff engineer é importante deixar claro que “eu não sou o código em si”. O código vira dívida/legado no momento em que entra em produção O ideal é eu me posicionar não como “advogado do código”, mas como PARCEIRO EM PÉ DE IGUALDADE com liderança, produto, tomadores de decisão etc. Isso é basicamente uma questão de perspectiva/frame. Mesmo com o mesmo comportamento, se eu for visto como “parceiro do negócio”, os líderes me enxergam como um facilitador ativo; caso contrário, viro um obstáculo que precisa ser convencido à força, e a diferença é enorme
Concordo muito com “é preciso ter alguém de PM que venda bem meus resultados”. Olhando para trás, acho que uma das maiores mudanças positivas da minha carreira foi a velocidade com que consegui me afastar de PMs ruins Um bom PM melhora tudo, mas é difícil de encontrar. Por outro lado, quando o PM aponta a direção errada, tudo desanda, e no momento em que esse PM sai, o clima muda completamente
A expressão “não dá para competir com promessas de futuro” foi excelente. Isso acontece com frequência demais. Mesmo quando essa promessa já falhou 26 vezes antes, o “futuro glorioso” sempre parece grandioso
No trabalho real, a ideia de fazer deploy em produção com frequência (rep = foco em execução, teoria proibida) é boa, mas fico em dúvida por que promessas vagas de futuro feitas por VPs são mais valorizadas do que viabilidade real
Nunca ouvi a expressão “trabalho teórico”, mas certamente há lugares que fazem deploy todo dia. Ainda assim, não acho que fazer deploy com frequência seja o ideal. Tenho dúvidas sobre como se poderia colocar algo realmente substancial em produção em apenas um dia. Projetos como os meus, que trazem receita adicional para a empresa, não podem ser concluídos em um dia. Se desse para terminar em um dia, isso equivaleria a dizer que a empresa só precisa de engenheiros quatro vezes por ano. Por isso, esse “fazer deploy com frequência” acaba sendo mais uma vanity metric
Eu também nunca trabalhei numa empresa dysfunctional, então não me identifico em nada com a primeira parte deste texto Na minha experiência, sempre houve muita comunicação top-down e, mesmo quando eu desenvolvia em uma direção com a qual não concordava, aquilo era discutido com antecedência em profundidade suficiente para eu achar interessante entender por que colegas inteligentes viam diferente de mim Não sei se isso acontece porque só trabalhei em empresas fundadas por engenheiros ou se apenas dei sorte
Os VPs seniores de grandes empresas têm metas mais amplas e também uma noção mais ampla dos meios para alcançá-las. Isso não é necessariamente ruim. Dá espaço para tentar vários caminhos antes de se fixar em uma tecnologia ou metodologia específica. Claro, há desperdício, mas isso também pode ser eficiente para responder imediatamente a mudanças sísmicas na indústria e cumprir a missão da liderança executiva
Tenho curiosidade sobre em empresas de que porte você já trabalhou
"Uma forma um pouco mais difícil, mas que dá mais controle, é encaixar a minha ideia dentro de uma campanha política que já exista" Aprendi a arte de me acoplar bem a projetos liderados por VPs. É amargo, mas funciona com certeza
A frustração que se ouve com frequência desse lado é: “eu refatorei a base inteira de código de forma perfeita e ninguém reconhece isso” Um conhecido meu se gabou de ter limpado perfeitamente um pipeline de dados ao longo de vários meses, mas ninguém reconheceu o valor daquilo, e isso me fez pensar bastante Como engenheiro, eu sei que esse tipo de trabalho tem valor, mas do ponto de vista de PM/EM isso se parece com um PM passar um mês inteiro organizando e pontuando toda a documentação interna de engenharia e, no final, ouvir “tá, e qual é o impacto disso para a empresa?” Do ponto de vista do PM, fica ambíguo como distinguir um engenheiro influente de um engenheiro que só faz “trabalho de formatação” No fim, o importante é explicar com clareza, antes, o trabalho que você planeja fazer em um formato adequado para uma audiência não técnica No passado eu tentei promover testes unitários e testes de integração, mas como faltava vontade política isso nunca entrava em prioridade. Depois que estourou um SEV grande, eu disse “precisamos de testes para evitar isso”, e só então todos concordaram com o valor. Agora qualquer pessoa entende a necessidade de testes
Concordo totalmente. Se eu estiver tentando priorizar alguma ação, preciso explicá-la na lógica e na linguagem de quem decide as prioridades para que meu argumento funcione Por exemplo, PM normalmente pensa em termos monetários. Se eu apresentar meu objetivo técnico, como ampliar cobertura de testes, dizendo que isso exigirá 200 dev hours por ano, mas economizará 400 dev hours por ano, reduzirá tickets de suporte em 15% e viabilizará cenários futuros de negócio, fica muito mais fácil convencer Um truque de que gosto é empacotar trabalho de tech debt não como “trabalho técnico”, mas como um efeito claro de negócio, a ponto de o próprio PM colocar isso no roadmap por iniciativa própria Esse tipo de coisa fica mais fácil conforme a carreira avança. Mesmo que no início haja ceticismo, com o tempo a confiança nas minhas estimativas e nos meus resultados se acumula, e o que antes exigia várias reuniões agora se resolve em uma conversa de 10 minutos
Também concordo com esse comentário. Mas sinto que também dá para pensar pelo lado contrário Por exemplo, em uma obra, alguém pode verificar e manter cuidadosamente os sistemas de segurança e, graças a isso, prevenir acidentes, e ainda assim a gestão não reconhecer esse valor nem recompensá-lo Se nenhum benefício é reconhecido a menos que possa ser mostrado quantitativamente como ROI, isso por si só já é uma enorme falha de gestão e, quando segurança envolve vidas, também uma falha moral Na prática, isso é o que está acontecendo na Boeing agora
O ponto é explicar em termos de valor que o público consiga entender. Isso no fim é habilidade de vendas, e acho que a maioria dos desenvolvedores não tem experiência com isso nem percebe facilmente. O ideal é ter apoio de um bom gerente, e quando um staff dev ou engineering manager alinhado comigo trabalha junto, o resultado realmente cresce muito Eu sempre sou grato quando colaboro com colegas assim
Se eu preciso explicar a necessidade de lavar as mãos para conseguir aprovação de investimento, então há algo errado com o time. Do mesmo jeito que um chef de restaurante de primeira não precisa ser convencido a comprar sabão, entrar numa organização em que isso é o padrão faz parte de um próximo nível de carreira. Um SWE bem-sucedido trabalha em equipes em que esse nível já é o básico
Concordo. Refatoração é uma responsabilidade natural do desenvolvedor. Se ela for feita de forma orgânica junto com o desenvolvimento de funcionalidade e com a atualização dos prazos, fica muito mais fácil convencer, porque a conversa pode acontecer só entre técnicos, e no longo prazo a qualidade da codebase melhora muito. Como resultado, a manutenção fica mais fácil e o desenvolvimento de novas funcionalidades acelera
O maior capital político que eu consigo acumular é meu entendimento técnico e minha capacidade. Mas esse poder só é útil quando eu consigo aconselhar e entregar de forma concreta dentro da estratégia e do contexto da empresa como um todo Se eu der o conselho certo e agir em benefício da empresa, as pessoas passam a me ouvir e a depender de mim. No fim, isso cria autoridade para eu ajudar a definir a direção Preparar um tipo de plano B de gestão de risco e, quando necessário, propô-lo e executá-lo é a melhor maneira
Há um livro de carreira bem radical, mas com bons pontos Um deles é que competência técnica pode, na verdade, prejudicar minha carreira e meu poder. Se eu gastar meu tempo e minha energia realmente fazendo algo, um gerente competente vai se esforçar ativamente para me manter preso na minha posição e impedir que eu ganhe influência política Em contrapartida, se eu virar gerente, basta não fazer de fato nenhum trabalho e iniciar o maior número possível de iniciativas (projetos, políticas, mudanças), coordenando habilmente o capital político que eu tiver Não importa se essas iniciativas criam valor real ou não; eu nem preciso me preocupar com isso. Eu já saí do tabuleiro, e quem continua aqui trabalhando e se importando com sucesso e valor acaba ficando para trás Se for preciso, o gerente ainda pode pegar o crédito depois e dizer que “foi ele que fez”
"É preciso ter times dedicados a mudar de direção conforme o flavor of the month para as coisas acontecerem" — essa é a minha teoria política. Em Washington DC é igual. Não existe um grande plano; há sempre uma tropa de gente pronta para fazer o pitch assim que surge uma oportunidade
Se eu preciso praticar disputa política e acumular poder, então o certo é procurar outra empresa Você pode me achar ingênuo, mas nem toda empresa é assim. A minha não é