Não peça “sim”; peça “não” (2022)

• Em empresas pequenas, ao tocar um trabalho dentro do seu escopo, dar uma chance e um prazo para recusarem em vez de esperar autorização pode acelerar a execução
• Pedidos de aprovação como “posso instalar a action X?” podem empurrar para o gestor a revisão do problema, a avaliação da solução e o ajuste de prioridades, atrasando a resposta
• Dizer “vou instalar a action X na segunda-feira. Se você pensar diferente, me avise” mostra intenção de executar e ainda deixa espaço para o gestor intervir
• Essa abordagem é adequada quando o trabalho está dentro do seu papel, você aceita feedback, mas tem confiança suficiente na direção para seguir mesmo sem resposta
• Ao indicar também um prazo próximo, aumenta a chance de quem precisa responder reagir mais rápido, e você consegue manter os envolvidos informados sem parar a execução

---

Dar oportunidade de recusa sem esperar permissão

• Um viés para a ação, mesmo em passos muito pequenos, ajuda a romper a inércia
• O hábito central é não pedir “sim”, mas pedir “não”
  • A experiência relatada vem de empresas pequenas, com menos de 200 funcionários
  • Não é certo que isso funcione da mesma forma em empresas grandes, organizações sem fins lucrativos ou órgãos do governo
• Quando você quer fazer algo que considera dentro do seu escopo, mas busca segurança ou quer avisar o gestor, o normal é pedir permissão antes
• Em vez disso, dê ao gestor a oportunidade de recusar e junto apresente um prazo claro para que ele possa tomar essa decisão

A diferença vista no exemplo de GitHub Action

• O exemplo é a situação de instalar em um repositório uma nova GitHub Action considerada útil para melhorar a qualidade do software
  • Não é um impulso qualquer; já houve pesquisa e testes locais
  • Você pode até ter perguntado a colegas anteriores sobre a experiência deles com essa GitHub Action
• Perguntar “posso instalar a action X? Ela ajuda com o problema XYZ que estamos enfrentando” faz o gestor ter trabalho extra antes de dizer “sim”
  • Ele precisa revisar novamente o problema XYZ
  • Precisa avaliar como X resolveria o problema
  • Pode querer comparar a prioridade disso com outras tarefas ou compartilhar antes algo que ele sabe
  • Para um gestor ocupado, isso pode ficar para depois, e talvez seja preciso lembrar várias vezes
• A alternativa é dizer “vou instalar a action X para resolver o problema XYZ. Se você pensar diferente, me avise; caso contrário, faço isso na segunda-feira”
  • Isso sinaliza que a pessoa responsável vai lidar diretamente com o problema
  • O gestor pode intervir se quiser, mas sem a obrigação de responder
  • Mesmo que o gestor esqueça ou surja outra demanda, o andamento não para
• Essa abordagem pode ser aplicada não só individualmente, mas também a grupos compostos por várias pessoas

A pressão de resposta criada pelo prazo

• O prazo é um elemento central dessa abordagem
  • Em 15 de janeiro, dizer “vou fazer a tarefa X” pode gerar menos reação do que “vou fazer a tarefa X em 17 de janeiro”
  • Um prazo para o futuro próximo tende a gerar resposta mais imediata do que algo distante, como “vou fazer a tarefa X em 15 de fevereiro”
• Funciona melhor quando o espaço para feedback continua aberto, mas você tem confiança suficiente na direção para executar mesmo sem receber retorno

[GN⁺]

Opiniões no Hacker News

• Em grandes empresas, onde todo mundo está ocupado e é fácil as coisas ficarem soterradas, isso é uma competência essencial
  Depois de explicar o problema no e-mail, escrevo: “Se não houver resposta em [N] dias, em [dia N] farei XYZ”. Em vez de pedir aprovação e ficar esperando impotente ou cobrando, é uma forma de deixar registrado que, se ninguém se manifestar, XYZ vai seguir adiante
  Às vezes, algumas semanas depois, aparece alguém irritado perguntando por que fiz sem avisar, mas sempre dá para mostrar o registro que a pessoa deixou passar

  • A formulação “se não houver resposta, farei XYZ” soa desnecessariamente confrontativa
    Basta dizer algo como: “Pretendo fazer XYZ por estes motivos e vou prosseguir em [data]. Se houver objeções ou preocupações, me avisem”
    Esse método força você a apresentar uma base sólida de antemão e também permite receber feedback para evitar restrições que você desconhece ou erros
    Também é estranho esse comportamento de culto à carga de seguir os princípios de liderança da Amazon como se fossem uma solução de problemas. O “viés para ação” funciona na Amazon porque quem age de forma unilateral e fracassa vira bode expiatório e é demitido, e essas pessoas não escrevem posts em blog exaltando as virtudes do viés para ação
  • Tenho curiosidade de como isso é formulado na prática
    Seria algo como: “Em 1º de março, pretendo desfragmentar o thingamajig. Estou avisando com antecedência as pessoas para quem esse trabalho pode causar problemas. Se houver preocupações, avisem. Se não houver resposta até 1º de março, o thingamajig será desfragmentado”?
  • Isso soa um pouco como fantasia, ou algo que só parece possível quando a regra violada não tem nenhuma importância para o negócio
    Dizer “se não houver resposta em 5 dias, farei X” não serve de defesa nenhuma se você fez algo passível de punição disciplinar
    Onde isso funciona, no máximo, é para violar alguma decisão interna de design que não tem relação com o negócio
  • A parte “às vezes, algumas semanas depois, alguém fica irritado porque XYZ foi feito sem aviso” é suspeita
    A pessoa diz que “sempre faz isso” e escreve uma frase mágica como se fosse um template; fico em dúvida se é experiência real dela ou uma projeção de como ela gostaria de trabalhar, como no texto principal
    Quando imagino a cena de mostrar os registros e vencer colegas irritados, meu detector de besteira vai até o vermelho
  • Também gosto porque tem o efeito de deixar registrado quem está bloqueando ou recusando o avanço

• Chamo isso de “não pergunte, informe”, e é muito útil dentro e fora da empresa
  É uma habilidade básica de comunicação e torna os resultados concisos e decisivos
  Tenho esse tipo de conversa frequentemente com minha esposa; ela costuma mandar perguntas abertas para um grupo de 8 pessoas, tipo “Que horas vocês chegam?”. Como sabíamos que chegaríamos uma hora mais cedo por causa da agenda de deixar a criança com alguém, eu disse para ela simplesmente informar: “Vamos chegar neste horário e quem quiser beber antes estará no bar”
  Não era preciso exigir resposta, todo mundo chegou cedo e tudo deu certo com o mínimo de comunicação
  Tem alguma relação com “é melhor pedir perdão do que permissão”, mas lugares em que várias pessoas colaboram, como um repositório do GitHub, não são um bom contexto para simplesmente jogar grandes mudanças que afetam outras pessoas

  • Eu também faço isso. Não é só uma comunicação melhor, é também um jeito melhor de viver
    Em vez de ficar em um estado em que só consigo aproveitar algo se outras pessoas coordenarem tudo, começo o que quero fazer e aviso aos outros que podem se juntar

• Quando colegas perguntam como conseguir aprovação para uma proposta, dou um conselho parecido: “torne o mais fácil possível para a outra pessoa dizer sim”
  Não dá para despejar 14 parágrafos em alguém e esperar que a pessoa acompanhe imediatamente o nível de aprofundamento que você teve depois de horas investigando o problema
  Se você está confiante na abordagem, explique de forma concisa por que o problema e a solução fazem sentido, e adicione um link para a documentação para quem quiser se aprofundar. É bom já ter obtido concordância dos membros da equipe ou do responsável pelo produto
  Exemplo: “Pretendemos resolver X com Y. A equipe toda concordou. A proposta detalhada está em [link]. Se não houver feedback adicional a tratar, começaremos na terça-feira”
  Gestores não têm tempo para examinar todos os detalhes e agradecem quando você organiza o trabalho, inclusive com o apoio da equipe mais ampla, de modo que eles só precisem aprovar

  • Se um gestor trabalha desse jeito, começa uma votação de popularidade. Esse tipo de gestor é ineficiente ou inútil
  • “Se você está confiante” é a parte essencial. Eu determino confiança não com narcisismo, mas com estatísticas objetivas e incerteza
    Se a chance de sucesso é 10%, mas há motivo para tentar, eu digo isso; não embrulho em uma apresentação absurda dizendo que tenho certeza de que vai dar certo. Se a chance de sucesso é 80%, não escondo os 20%; e, se digo 98%, significa que de fato está perto disso
    O trabalho do gestor é lidar com essas estatísticas e fazer hedge dos riscos. Fundos hedge fazem isso com dinheiro; gestores fazem com pessoas e recursos
    Infelizmente, o gestor corporativo típico prefere alguém que diga 100% que vai dar certo, mas na prática fracasse 50% das vezes

• Gosto de uma expressão parecida: radiar intenção (radiating intent)
  É a prática de comunicar amplamente o que você pretende fazer e quando, dando aos stakeholders espaço para se opor explicitamente, mas sem ficar correndo atrás de consenso, alinhamento e aprovação um a um
  Funciona bem em algumas situações e, em geral, exige que você conquiste primeiro um nível básico de confiança
  https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

  • Os quatro motivos para “radiar intenção” fazem sentido. Funciona bem em organizações com confiança de moderada para alta
    Também gostei da nuance acrescentada por Eliz Ayer: “Para ser justa, com a radiação de intenção talvez você faça menos coisas. Isso porque ela dá a quem atrapalha ou se intromete uma via para interferir. Além disso, esse conselho depende muito da situação e da organização, portanto nem sempre é adequado”

• Esse tipo de comunicação parece fazer a outra pessoa enxergar você imediatamente como uma pessoa de risco
  Por fora, parece uma forma de poupar tempo, mas, na prática, é um jeito de dizer ao gestor que, se ele não ficar sempre acompanhando o que aquele funcionário está fazendo, ele pode fazer algo indesejado
  O texto trata isso como uma notificação, mas, por mais boa-fé e compreensão que exista, notificações se perdem facilmente no ruído dos sinais, e falta de resposta não significa consentimento. Também pode significar que a mensagem não foi recebida
  Pode ser aceitável se o funcionário e o gestor já discutiram o problema e agora estão executando a solução, mas é péssimo quando você está levantando pela primeira vez um problema que a outra pessoa ainda nem considerou. É egoísta e o oposto de trabalho em equipe
  Também dá a impressão de alguém copiando o que viu um lendário engenheiro 10x Rockstar fazer. Esse engenheiro sempre entrega bem, sabe o que precisa ser feito e tem entendimento e respeito mútuos com a gestão, então há espaço para deixá-lo se autogerir. Parece que alguém viu isso e presumiu que também se aplicava a si mesmo, sem entender por que a pessoa recebe esse tratamento nem como deveria conquistá-lo

  • No fim, tudo depende do relacionamento
    Se você fez isso três vezes seguidas e recebeu como resposta um “por favor, pare”, algo está errado. Se recebeu elogios três vezes seguidas, pode continuar
    A pessoa realmente perigosa é aquela que, mesmo depois de ouvir que não pode, dá um jeito de executar a maior parte e depois vai procurar um “sim”. E faz a mesma coisa no trabalho seguinte, sem reagir ao feedback
    Portanto, o ponto central é mais a relação de trabalho do que o método em si. Em um ambiente de alta confiança, em que todos estão ocupados, vale tentar
  • Se uma pessoa desconhecida fizesse isso comigo, eu provavelmente acharia arrogante e irritante
    Se fosse alguém com quem já trabalhei, em quem confio, e eu soubesse que está fazendo isso para respeitar meu tempo, seria uma história completamente diferente

• No momento em que isso quebra algo pela primeira vez, vira uma receita para o desastre
  Ter recebido um sim ou um não significa que o chefe estava ciente. Se algo der errado e perguntarem “quem aprovou?”, a resposta verdadeira é que ninguém aprovou

  • Varia muito conforme a cultura organizacional e a eficácia da gestão
    Se não há ninguém na organização que possa agir assim, é sinal de que a equipe de liderança está falhando em delegar
  • Isso não é tanto algo para usar com o chefe, mas mais um modo de lidar com pessoas de outros departamentos que precisam participar do trabalho
    Por exemplo, quando X da equipe Y se opõe a alguma coisa
    Se o chefe 1) diz que algo precisa ser feito e 2) não aprova nenhum plano, basta não fazer. Nesse caso, a responsabilidade de orientar para que o trabalho aconteça é do chefe
  • Se o chefe precisa aprovar tudo o que você faz, então ele não é um chefe, é um microgerente, e os dois estão fazendo errado
  • Pelo menos em software, ninguém deveria conseguir fazer qualquer coisa sozinho
    Dizer “vou fazer isto” é aceitável, mas isso não deve chegar à produção sem processos como revisão e testes automatizados
    Claro que isso cria gargalos. Se você abre um merge request e ninguém revisa a tempo, nada acontece. Nesses casos, é preciso definir, no nível do líder da equipe, um acordo de que as pessoas vão verificar e revisar dentro de certo prazo
  • Assumir responsabilidade por algo inclui também quebrar e consertar

• Essa abordagem parece funcionar apenas em empresas americanas ou com chefes acostumados à cultura de negócios americana
  Se o chefe não gostar, pode sair muito pela culatra. Na avaliação de desempenho, é fácil o chefe rotular isso como insubordinação, e você acaba entregando de bandeja as provas necessárias
  Às vezes, mesmo nos EUA, pedir permissão é realmente a melhor opção, especialmente quando envolve recursos

  • Insubordinação é uma palavra que combina com o exército. A própria ideia de que adultos feitos possam “insubordinar-se” é ridícula
  • Há muitas formas de trabalho que não são americanas
    Por exemplo, em culturas escandinavas, a gestão costuma ser bem mais hands-off, e muitas vezes se espera que os funcionários tomem muitas decisões de forma independente ou em consulta uns com os outros
  • Entre os chefes que tive, quase nenhum teria detestado esse método. Claro, partindo do pressuposto de que o que eu pretendia fazer não fosse idiota
    Mas todos esses chefes estavam profundamente imersos na cultura americana
  • Se a tomada de decisão independente é vista como insubordinação, fico curioso sobre como esse gestor delega e como o trabalho funciona na sociedade em geral
    Até mesmo a tomada de decisão militar eficaz depende muito da capacidade de unidades em campo se adaptarem sem telefonar para o quartel-general a cada vez
  • Em empresas não americanas, onde o chefe realmente tem vida e não trabalha no fim de semana, ou até tira alguns dias ou semanas de folga, esse método pode não funcionar

• Chamo isso de criar padrões razoáveis
  Em vez de exigir que as pessoas tomem decisões sobre cada detalhe, você define um conjunto de padrões razoáveis que demonstram que entende a situação e informa que vai seguir adiante com eles
  Isso constrói confiança, e, quando algo realmente exige atenção, as pessoas prestam mais atenção, porque sabem que você normalmente não desperdiça o tempo delas

  • Gosto do enquadramento de “padrão”. Ele deixa espaço para sugestões e mudanças

• Gosto desse estilo de comunicação, mas a parte do prazo não me agrada
  Se um subordinado está fazendo algo sobre o qual talvez eu exerça poder de veto, basta me avisar. Talvez eu tenha mais contexto e conclua que aquilo é perda de tempo ou não é prioridade
  Dar um prazo ao gestor é estranho e soa como uma ameaça sutilmente irritante
  Para algo pequeno como um GitHub Action, eu gostaria de acreditar que dei autonomia suficiente para a pessoa da equipe decidir por conta própria

  • A abordagem de pedir um não, como em “se eu não devo prosseguir, me avise”, é realmente boa
    Mas acrescentar “vou fazer nesta data, salvo manifestação em contrário” soa um pouco agressivo
    Só mencionar quando pretende trabalhar nisso e deixar algo como “acho que vou terminar por volta dessa época” ainda dá espaço para a pessoa avaliar que talvez seja melhor não prosseguir
    Ainda assim, há muito tempo meu objetivo tem sido ser mais assertivo. Só se encolher tem seus limites
  • Se você não disser quando vai trabalhar nisso, como a outra pessoa saberá se disse não ou não?
    Você pode achar que um dia é suficiente e prosseguir, mas, se a pessoa responder dois dias depois, você já terá feito algo contra a orientação dela
    Incluir a data evita isso: “Vou migrar o sistema de build na quarta-feira (26). Se houver alguma preocupação, me avise”
  • O texto saiu perdendo ao chamar isso de prazo
    Só entendi depois de ler o exemplo; na prática, está mais para data planejada de execução do que para prazo
  • Um prazo para a própria ação também pode ser uma questão de cortesia
    Porque informa à outra pessoa o período de aviso e permite que alguém que leia um e-mail antigo depois julgue se aquilo ainda é relevante
  • Fixar um prazo para algo que ainda é só uma ideia é estranho e agressivo
    Normalmente, prazo é usado no sentido de “já decidimos fazer, a aprovação ou o acordo já foi obtido, então agora estou informando a execução”

• Parte da técnica de “se você não me disser o contrário, vou fazer isto” está em não formular isso como uma pergunta, reduzindo o custo de comunicação
  Assim, quem recebe não precisa escrever uma resposta, e nem eu nem as pessoas em cópia precisamos ler e-mails adicionais
  Nesse sentido, gosto de recursos como as reações com emoji do GitHub ou do Google Docs, que permitem marcar com um joinha que você leu e concorda. Estranhamente, em algumas partes do HN isso não é muito popular, mas é uma forma leve de comunicação que evita ter que passar pelo processo de escrever um comentário como “Ótimo, faz sentido!” toda vez. É parecido com um upvote