O verdadeiro significado de estar 'done' em uma big tech

• Em big techs, terminar um trabalho de verdade significa levá-lo até um estado que satisfaça a empresa e seguir em frente, dentro de um sistema que pode ser melhorado infinitamente
• Engenheiros competentes, mas com falta de protagonismo, acabam repetindo apenas pequenas melhorias e deixam passar resultados reais
• É preciso entregar resultados claros e visíveis para quem toma decisões para que isso seja reconhecido como “trabalho feito”
• Você deve sempre verificar se o que está fazendo está em um formato que possa ser lido e avaliado pela alta gestão
• Nem tudo pode ser organizado até o fim; em certo momento, a capacidade de “declarar vitória e ir embora” se torna uma competência essencial

---

O 'trabalho' tem uma natureza que não pode ser concluída

• Ao contrário de um problema de matemática ou de uma tarefa escolar, o trabalho no mundo real é um sistema aberto que pode ser melhorado infinitamente
• Desenvolver um serviço é como plantar uma árvore: depois disso, continua sendo um processo que exige manutenção constante

O engenheiro competente preso na armadilha

• O engenheiro que assume tudo sozinho e repete apenas pequenas melhorias contínuas sente que está entregando resultado, mas
• do ponto de vista da alta gestão, isso pode ser visto como falta de criação de valor visível para a empresa
• Como resultado, pode acabar sendo confundido com alguém ocupado, mas sem entregas reais

O significado real de “terminar”

• Levar o trabalho até o ponto em que a empresa (ou os tomadores de decisão) esteja satisfeita e então passar para a próxima coisa
• Em vez de continuar refatorando ou repetindo pequenas melhorias, é preciso criar uma lista clara de entregas
• A capacidade de declarar “está concluído” e seguir para o próximo trabalho é importante

Garantir a ‘legibilidade’ do trabalho

• Projetos que o gestor já conhece ou pediu, ou respostas a grandes incidentes, têm alta legibilidade
• Por padrão, a maior parte do trabalho técnico não passa de ruído técnico difícil de julgar para quem gerencia
• Por isso, é preciso ajustar a forma de apresentar o trabalho para que ele seja compreensível, por exemplo tornando os resultados visíveis ou destacando o impacto financeiro

“Terminar” como conceito social

• Filosoficamente, a ideia de “está concluído” também é uma construção social, mas na prática ela tem um poder muito concreto
• Ignorar isso pode fazer com que seu trabalho não seja reconhecido e, no limite, até resultar em demissão

Resumo

• Trabalhar não significa necessariamente ter concluído
• A maior parte do trabalho não pode ser realmente concluída e pode continuar indefinidamente
• Em vez de um jardineiro, você precisa agir como um estrategista orientado a resultados
• O critério de “concluído” é a satisfação da empresa/do gestor
• Declarar vitória → sair de cena → seguir para a próxima tarefa é a estratégia central

[aer0700]

Parece que escolher um trabalho em que seja possível declarar vitória também é uma habilidade importante.

[elbanic]

Limitar o escopo é o que chamamos de scoping. A habilidade está em fazer um bom scoping para que você possa vencer.

[bakyeono]

Hanshin vs. Soha

[doolayer]

Resultados visíveis e mensuráveis, não detalhes

[GN⁺]

Comentários do Hacker News

• Não discordo totalmente do argumento deste texto, mas, pela minha experiência trabalhando em vários lugares — big techs, startups e unicórnios — isso não parece um conselho muito prático. Nos últimos 10 anos, o trabalho dos desenvolvedores ficou especializado demais, a ponto de se desconectar das necessidades de quem decide e dos clientes. Isso acontece porque o Product Manager acaba ficando no meio entre os engenheiros e o resto da empresa. Eu sempre quero gerar resultados valiosos, mas, na prática, para conseguir isso, preciso aguentar estresse constante. Minha contribuição inevitavelmente é ajustada depois de passar pelo ego de quem fala com os tomadores de decisão. Nos últimos 5 anos, a única vez em que senti realização de verdade foi quando assumi temporariamente o papel de Product Manager por 9 meses. Nesse período, nosso time concluiu com sucesso três projetos em que outros times já tinham falhado várias vezes antes. O segredo foi conversar de fato com as partes interessadas para entender as necessidades, e não tentar fazer do meu jeito. Então vou continuar entregando apenas o que pedem, levando culpa por bugs e sem receber reconhecimento pelas funcionalidades. Pelo menos a remuneração é boa. Ainda sigo procurando um lugar onde eu possa realmente contribuir direito

  • Essa parte do “pelo menos a remuneração é boa” ficou especialmente na minha cabeça. Quando penso em trabalhar em big tech, tenho uma visão própria de que ficar “estagnado” também não é tão ruim assim. Por exemplo, se você ganha US$ 300 mil por ano no Google ou na MS e passa 10 anos no mesmo projeto chato, essa experiência ainda vai ser valorizada em qualquer lugar. Para uma pessoa ambiciosa, como eu era antes, isso pode ser frustrante, mas quem tem esse perfil provavelmente tentaria ir para uma empresa menor. Com a idade, meus interesses foram mudando da empresa para a família e os amigos. Se alguém me disser que nunca vou ser promovido, minha reação seria “e daí?”. Eu ganho dinheiro suficiente para minha família e ainda mantenho equilíbrio entre trabalho e vida. Sinceramente, a melhor parte da empresa é o salário e como ele melhora o resto da minha vida
  • Já vivi isso de ver que o cargo de Product Manager, na prática, é bem diferente da descrição idealizada, porque a pessoa fica espremida no meio e não consegue representar bem nenhum dos lados. Como resultado, acabei desenvolvendo eu mesmo habilidades de gestão de produto, e isso é realmente útil para evitar trabalho desperdiçado. Então fico pensando se, para um grande engenheiro, product management não deveria ser também uma competência essencial
  • Outra coisa a considerar é que, se continuar assim, você está no caminho do burnout
  • Percebi que comunicação é o melhor conjunto de habilidades em qualquer organização. Nove meses num trabalho temporário não são suficientes para entender todo o valor disso. O texto soa como o de alguém, como tantos outros engenheiros, irritado demais e achando que é mais inteligente do que as outras pessoas da organização. Muitas vezes não é o caso, e esse tipo de mentalidade atrapalha a colaboração
  • Por trás de toda aplicação web que funciona bem sempre existe alguém fazendo o papel de jardineiro
  • Fico curioso por que você não continuou como Product Manager
  • Isso varia muito de empresa para empresa. Em muitos lugares, a influência do engenheiro é bem maior. Mesmo em big techs, existem casos em que a pessoa não fica separada do cliente
  • Isso quer dizer que deveríamos demitir os Product Managers?
  • Também já tive meu papel de Product Manager, mediando entre engenheiros e a empresa, e minha própria contribuição também passava pelo filtro do meu ego, então isso soa como alguém dizendo que foi algo bem satisfatório... e provavelmente foi mesmo

• Tenho uma objeção fundamental a usar apenas satisfazer quem tem poder como critério de sucesso. Estamos presos a uma estrutura de status ridícula, mas não acho que tudo se resuma a mudar um ticket para “done” no Jira ou eliminar avisos do compilador. Ninguém diz “não me arrependo de ter passado 40 anos apenas satisfazendo meus chefes”

  • Estou trabalhando há 30 de 40 anos, e definitivamente houve valor em satisfazer meu chefe e o chefe do meu chefe. Embora uma visão cínica não seja toda a vida, conhecer essa perspectiva cínica significa se aproximar mais da verdade
  • Na verdade, “satisfazer o chefe e o chefe do chefe” é praticamente a definição de emprego. Alguém manda você fazer algo, você faz e recebe por isso

• No geral concordo, mas acrescentaria uma coisa: para entender o que o gerente quer, é preciso entender a estrutura de negócio da empresa. Você precisa descobrir por conta própria como a empresa ganha dinheiro e o que ela considera valioso. Quando você trabalha num lugar alinhado com os valores da empresa, a recompensa é maior e a satisfação também. É importante falar diretamente com clientes, vendas, marketing e, se possível, até com a liderança executiva. Mesmo que você cuide apenas de sistemas internos, o essencial é saber onde esse sistema gera ou protege valor. Se sua área não consegue criar valor de forma clara, vale pensar em se mover para um time mais valioso. Trabalhar em algo desalinhado com as necessidades da empresa sempre foi um grande erro

  • Acho que não tem problema nenhum em se ver como um carpinteiro. Desenvolvimento é implementar conforme a especificação, mas, se a especificação for absurda ou impossível, você precisa apontar isso diretamente. Se o pessoal de negócios não consegue explicar claramente o próprio trabalho, então eles mesmos não entendem. E, além disso, se o desenvolvedor realmente precisa entender bem o negócio também, isso tem que vir acompanhado de compensação. Existe custo de oportunidade aí, porque esse tempo poderia ser usado para crescer mais tecnicamente
  • Muitas vezes nem mesmo a premissa de que “o gerente realmente entende o negócio e vai agir com consideração” se sustenta

• O autor disse que “é necessário gerar resultados visíveis para quem toma decisões”, e eu me identifico com essa mentalidade de “negócio”. Muitos desenvolvedores sofrem porque não sabem explicar qual é a utilidade de negócio do próprio trabalho. Refatoração entra nisso também. Melhorar o código pode parecer, no curto prazo, algo sem significado nenhum, mas, dependendo da situação, pode gerar benefícios enormes para a organização. No fim, o ponto central é pensar em como conectar seu trabalho à receita ou à economia da organização — e em como comunicar isso

  • Desenvolvedores precisam aprender a linguagem do negócio e enquadrar os problemas de um jeito que o pessoal de negócios entenda e considere importante. Se você olhar a maioria das decisões de negócio, no fim tudo vira custo vs benefício. Na prática, muitos empresários também tratam software simplesmente como custo. Ou seja, ao contrário da intuição dos desenvolvedores de que “como assim software não é o centro da geração de receita?”, o negócio em si não liga para software. Se desse para vender tudo de graça, todo custo seria 0 e a margem seria infinita — esse é o sentimento real do homem de negócios. Vendas é um campo que muitas vezes se fecha mais por clima, relacionamento e até suborno do que por racionalidade. Pode soar irracional, mas isso precisa ser entendido

• Fico me perguntando se “essa mentalidade é a razão de tantos engenheiros não ligarem para qualidade de código, testes e documentação”. Se a única preocupação for a satisfação imediata de quem está acima, por que alguém se esforçaria para escrever código sustentável no longo prazo? Talvez não seja necessário qualidade acima do padrão, mas um investimento mínimo já pode economizar bilhões

  • Cada vez mais gente não se importa com capricho e qualidade. O que se ouve é “eu só trabalho na medida do que me pagam”. Antigamente existia mais a sensação de fazer um trabalho bem feito independentemente do salário, e isso parece ter se perdido bastante
  • Cada um tem um motivo para estar no seu papel. Como num set de filmagem, engenheiros também podem ter objetivos diferentes. Se você impede que eles coloquem paixão no trabalho, o que sobra é gente movida apenas por dinheiro. Isso é arriscado
  • Não acho que alguém escreva código ruim de propósito. Quando desinteresse ou burnout surgem num ambiente em que esforço extra nunca é recompensado, ninguém vai além do mínimo. E muitos desenvolvedores simplesmente têm pouca habilidade. Não é uma profissão hipercompetitiva como atuária; qualquer tipo de pessoa pode entrar, e já de saída é difícil se tornar realmente competente
  • Muitos Product Managers querem apenas velocidade. Nós queremos testes e documentação, mas CFOs veem esse trabalho adicional como desnecessário, porque “não é funcionalidade”
  • Como não se parte do princípio de que o engenheiro vai permanecer muito tempo na empresa, ele também não se sente responsável pelo futuro. Pulando de emprego em emprego, a pessoa nunca vivencia os problemas do código que deixou no trabalho anterior, então não aprende com esse fracasso e repete o padrão. Estou há quase 20 anos na mesma empresa e já vi os mesmos erros se repetirem o tempo todo. Também me cansei de mudanças que só alteram a superfície enquanto os problemas essenciais continuam lá. Se não for para consertar o problema real, a mudança não tem sentido. Meu objetivo é resolver o problema de verdade

• Já vivi bastante essa realidade e esses problemas, entendo tudo isso, mas ainda assim discordo. Muitos projetos são iniciados e, com um “resolvido, done!”, o time é desfeito. Mas o produto ainda tem problemas, ainda precisa de novas funcionalidades e a empresa continua mudando. No fim, só se acumula dívida técnica por falta de manutenção. Aí chega um novo gerente, recria um projeto antigo e repete os mesmos erros. Esse jeito de fazer é ineficiente. Usando a analogia do ar-condicionado: manter a temperatura estável é mais eficiente do que desligar e depois baixar tudo de novo. Na prática, uma ferramenta de gestão que eu criei nunca interessou à diretoria, mas era necessária a ponto de ter mais de 500 usuários internos. O importante era manter a confiança nela continuamente, sem exigir grande investimento de tempo em manutenção. Se você abandona, ela se fragmenta e a confiabilidade vai embora. Bastavam alguns minutos para preservar essa consistência

  • Na verdade, a analogia do ar-condicionado está errada do ponto de vista termodinâmico. Desligar e depois resfriar de novo é mais eficiente

• Tenho sentimentos mistos sobre isso tudo. É verdade que, para visibilidade e promoção, o texto faz sentido, mas, na prática, é um conselho centrado no gerente: basta satisfazer o gestor. Mas e se não houver direção clara e as prioridades ficarem mudando o tempo todo? Aí fica difícil gerar resultado significativo, e a relação entre gestor e subordinado vira completamente uma estrutura de “yes-man”. Esse resultado é ruim

  • A resposta é simples. Se você sente que trabalha para um chefe idiota, peça demissão. O sofrimento é temporário, mas depois melhora. É muito melhor do que desperdiçar seu tempo tentando explicar seu trabalho para um idiota
  • Por outro lado, se você trabalha com um gerente realmente bom, “satisfazer o gerente” por si só já pode acelerar bastante tanto a carreira quanto a qualidade do resultado

• "unagentic engineer" significa um engenheiro sem autonomia. Se um engenheiro trabalha desse jeito, isso pode levar a ineficiências e problemas graves, como custo excessivo de nuvem, incidentes de segurança e reclamações de clientes. Como exemplos de trabalho que nunca termina, dá para citar patches de segurança, correção de erros, otimização de custos e resposta a feedback de clientes. Se a empresa não entende o valor disso, o melhor é mudar de emprego

  • Esse é exatamente o ponto do texto. Algumas organizações são orientadas para a realidade e outras para status. Organizações orientadas para a realidade tendem a ser mais racionais no longo prazo, enquanto organizações orientadas para status têm como único objetivo satisfazer o chefe. Hierarquia importa mais do que qualidade do produto ou relação com o cliente. Essas organizações não precisam necessariamente quebrar, mas às vezes entram em colapso de uma hora para outra
  • “Unagentic” se refere a um funcionário sem agency, sem autonomia. Espera-se que ele aja com iniciativa própria, mas, na prática, existe a armadilha de o desenvolvedor acabar tornando sua própria existência invisível
  • Não precisa ser sempre assim, mas, se a liderança executiva não se importa, essa cultura acaba se estabelecendo por padrão. Por exemplo, eu gosto de me concentrar nos detalhes de design de interface. Mas esse tipo de cuidado só é recompensado quando a organização reconhece isso como valor. Em muitos lugares, ninguém liga
  • “unagentic engineer” é o tipo de pessoa que não tem muita capacidade de decidir e conduzir por conta própria, e simplesmente se deixa levar pelo fluxo
  • Refere-se a um engenheiro pouco autônomo, ou seja, com pouca margem de decisão
  • Quer dizer alguém que não é “high agency”: pode até parecer inteligente e competente, mas fica sempre esperando instruções e não consegue tomar a frente por conta própria

• Eu odeio profundamente buzzwords como "alignment", mas, ainda assim, reconheço que é um conceito essencial. Idealmente, eu, meu gerente e até a liderança acima dele deveríamos concordar sobre o que é o trabalho mais importante. Se isso não acontece, para quem faz parte da organização isso é um problema. Pode não ser o certo nem o justo, mas é a isso que temos de nos adaptar. No fim, fazemos o que vem de cima porque é por isso que somos pagos. Só uma minoria muito pequena tem o privilégio de influenciar quem está acima. É isso que chamam de "managing up"

• O texto original é útil, mas acho que faltaram pontos ainda mais importantes:

  • Trabalhar no time certo é mais importante do que fazer o trabalho certo
  • Um bom PM e um bom gerente são mais importantes do que um bom trabalho
  • Uma boa cadeia de reporte é mais importante do que o valor do resultado
  • Trabalho alinhado às metas da liderança é muito mais valorizado do que apoiar a operação real do negócio
  • Você sempre precisa estar preparado para fazer tudo por conta própria, e a política de grandes empresas sempre traz desincentivos à colaboração

[heal9179]

Essas opiniões aqui estão, na verdade, tocando no ponto central.

[roxie]

Pois é kkk