- Um texto que trata do conceito de "conselhos perigosos (dangerous advice)", útil para engenheiros sêniores competentes, mas potencialmente prejudicial para engenheiros menos experientes
- Coisas como permissões de acesso a SQL em produção são "ferramentas afiadas (sharp tools)"
- Exemplos concretos de conselhos perigosos incluem definir por conta própria as prioridades do trabalho, às vezes quebrar intencionalmente regras da empresa e assumir uma posição firme mesmo em cenários incertos
- A maior parte dos conselhos de carreira é falsa, escrita para evitar responsabilidade ou causar boa impressão, enquanto fazer o trabalho de fato exige agir fora das regras oficiais
- Existe uma limitação estrutural que impede gestores de dar esse tipo de conselho diretamente por causa do risco que recai sobre eles
- Conselhos perigosos têm natureza de alto risco e alta recompensa, e o ponto central é compreender a área invisível (illegible) que existe além das regras formais da organização
A metáfora entre "ferramentas afiadas" e "conselhos perigosos"
- "Sharp tools" são ferramentas como
ssh, kubectl e consoles SQL de produção com leitura e escrita, que podem ser extremamente úteis ou causar grandes danos dependendo da capacidade de quem as usa
- Os "conselhos perigosos" têm a mesma característica: só podem ser usados adequadamente com competência e discernimento
- Dar conselhos perigosos à pessoa errada é como dar acesso ao SQL de produção para a pessoa errada
Exemplos concretos de conselhos perigosos
- Decidir por conta própria em que trabalhar
- Às vezes, quebrar deliberadamente regras formalizadas da empresa
- Assumir uma posição firme mesmo quando houver incerteza
- Identificar-se um pouco como um "grifter"
- Evitar deliberadamente toda atividade que não esteja relacionada a entregar produto (shipping)
Por que a maioria dos conselhos de carreira é falsa
- Engenheiros competentes anseiam por conselhos perigosos pelo mesmo motivo que querem ferramentas afiadas
- A maior parte dos conselhos de carreira é escrita com foco em evitar responsabilidade (liability avoidance) ou impressionar pessoas (impress people)
- Quem realmente quer fazer o trabalho acontecer acaba adotando esses comportamentos perigosos porque eles ajudam de forma óbvia
- Saber que, na prática, as coisas não funcionam oficialmente daquele jeito, mas ninguém dizer isso em voz alta, provoca uma profunda sensação de alienação
- Na época de júnior, os poucos colegas que falaram com franqueza de maneira informal foram de grande ajuda
A estrutura que impede gestores de dar conselhos perigosos
- Se um gestor aconselha ignorar a política da empresa e o engenheiro executa isso mal (por exemplo, publicando no Slack que o gestor autorizou), o prejuízo para o gestor é ainda maior
- Lideranças de empresas de tecnologia tendem a ver engenheiros como "idiotas úteis (useful idiots)", enquanto esperam comportamento profissional dos gestores
- Muitos gestores gostariam de dar esse tipo de conselho e valorizam muito quando o engenheiro age assim por conta própria
- Para um gestor, é extremamente frustrante gerenciar engenheiros fortes que seriam muito mais eficazes se abordassem o trabalho de forma mais estratégica e menos presos à descrição formal do cargo
A essência dos conselhos perigosos: alto risco, alta recompensa
- Seguir conselhos perigosos exige coragem
- Por terem natureza de alto risco e alta recompensa, eles são desproporcionalmente úteis para engenheiros fortes e prejudiciais para engenheiros fracos
- Se isso não lhe parece confortável, você nunca deve seguir esse tipo de conselho; mas se você já trabalha assim e teme estar cometendo erros de longo prazo, provavelmente esse não é o caso
Reações no Hacker News e os elementos ilegíveis da organização
- No Hacker News, houve uma mistura de reações muito positivas e muito negativas
- O erro central dos comentários negativos é enxergar a organização como um conjunto de regras formalizadas e presumir que o principal modo de operação dentro dela é a colaboração formal e estruturada
- Esse é o mesmo erro de dar prioridade excessiva à legibilidade (legibility) descrito em Seeing Like a State, de James C. Scott
- Toda comunidade tem componentes ilegíveis, mas fundamentais (load-bearing illegible)
- Pensar com cuidado sobre essa parte ilegível no seu próprio trabalho é a principal tese deste texto e do blog como um todo
Ainda não há comentários.