Do Fazer para o Decidir: o segundo pilar do Outcode Thinking
Como decisões certas aumentam seu reconhecimento (e o seu salário)
Se você trabalha com desenvolvimento, sabe bem como é.
O backlog nunca acaba, tudo é urgente e a cobrança é sempre pela entrega mais rápida.
No meio dessa rotina, é fácil cair na armadilha de acreditar que o seu valor está em fazer mais: entregar mais features, fechar mais tickets, parecer mais produtivo.
Mas chega uma hora em que essa lógica começa a travar.
Você percebe que, por mais que entregue, continua no mesmo lugar.
Enquanto isso, outros profissionais, às vezes menos técnicos que você, estão evoluindo mais rápido, sendo ouvidos, ganhando espaço.
Por quê?
Porque eles não estão apenas fazendo. Eles estão decidindo.
E é aqui que entra a diferença entre executar e pensar estrategicamente.
Quando o fazer não basta
Sempre que alguém fala sobre pensar estrategicamente, eu aposto que a maioria das pessoas não sabe explicar o que isso realmente significa.
Na verdade, muitas vezes, nem quem fala sabe. É um conceito abstrato, e por isso mesmo, tão mal interpretado.
Mas aqui vai um ponto importante: todo profissional técnico, mesmo no operacional, está decidindo o tempo todo. O trabalho intelectual exige decisões.
E é justamente por isso que você precisa entender o que é pensar estrategicamente, porque decidir bem é o que muda o impacto do que você faz.
O que significa pensar estrategicamente
Pensar estrategicamente não é um dom nem uma fórmula pronta. É uma jornada de compreensão.
Questionar e buscar clareza são apenas o ponto de partida. Quanto mais perguntas você faz, mais insumos tem para entender qual é o objetivo que quer alcançar e o que pode ser estratégico para te ajudar a chegar no objetivo.
E quanto mais clareza você tem sobre o objetivo, mais possibilidades surgem. O caminho deixa de ser uma linha reta e passa a ser uma jornada de descoberta, onde cada decisão molda o próximo passo.
Pensar estrategicamente é isso: planejar um caminho que vai além do fazer por fazer.
É investigar, conectar pontos e enxergar o que realmente tem potencial de gerar impacto, e esse processo só começa quando você se permite questionar.
Aqui vai uma história real que eu sempre uso para ensinar devs menos experientes sobre a importância de questionar antes de executar.
Em uma das startups em que trabalhei, surgiu a necessidade de extrair um relatório mostrando quantos usuários tinham criado conta em determinado período, com algumas condições específicas.
Uma tarefa simples, mas que foi tratada como um pequeno projeto.
A demanda foi passada para um desenvolvedor que, como todo bom profissional, quis fazer o melhor trabalho possível.
Ele criou um sisteminha para exportar os dados, aplicou boas práticas, tornou o processo flexível e preparado para receber futuras opções de filtro.
Foram mais de duas semanas de trabalho.
O resultado?
O sistema foi usado apenas uma vez.
Sabe onde ele errou? Em não questionar. Em não buscar clareza sobre a demanda.
Com duas ou três perguntas, ele teria descoberto que era um relatório pontual, simples, que poderia ser feito em uma ou duas horas.
Ele apenas fez, mas não decidiu.
E com isso, perdeu uma excelente oportunidade de mostrar que sabia pensar.
De provar que conseguia enxergar o que valia o esforço e o que não valia.
De ganhar respeito intelectual e abrir portas (dentro da empresa e fora dela).
Ser bom em fazer te ajuda.
Mas mostrar que você sabe decidir te leva para outro patamar.
A transição do fazer para o decidir
Todo dev excepcional que conheci sempre entregou muitas tarefas. Pareciam que iriam destruir o teclado. Alguns eram tão rápidos na execução que tinham a IDE configurada para nem usar o mouse. Tudo era tecla de atalho, código e velocidade.
Pareciam que, ao fazer uma feature, saíam escrevendo como um escrivão. E fim.
O problema é que esqueciam que o trabalho não é só sobre código. É sobre pessoas.
E pessoas percebem quando alguém tem boas ideias, sabe se posicionar e fala com clareza. Isso gera respeito.
De todos os devs excepcionais com quem trabalhei, poucos conseguiram atingir outro patamar.
Não que não tenham evoluído, mas demoraram mais para chegar ao mesmo nível financeiro daqueles que aprenderam a se comunicar melhor.
O que mais vejo hoje são pessoas que se comunicam bem em posições de decisão, mesmo sem o mesmo preparo técnico de quem está executando.
Mas tem um detalhe importante: só saber falar também não é suficiente.
Aposto que você já viu alguém que fala super bem, mas em algum momento deixa escapar que não sabe do que está falando.
Alguns são fáceis de identificar: os “sabichões” e “falastrões”. Mas outros passam despercebidos.
E é aqui que está o ponto: você não quer apenas saber falar. Quer saber o que falar.
A sequência é essa: saber falar, saber o que falar e decidir.
É assim que as pessoas que saíram do operacional e se tornaram excelentes no tático e no estratégico fazem.
E essa transição não acontece de uma vez, começa nas pequenas situações.
Como quando você explica uma decisão técnica de um jeito que qualquer pessoa entende.
Ou quando questiona uma demanda antes de aceitar, em vez de simplesmente executar.
Ou quando propõe uma solução mais eficiente, em vez de seguir o plano original só porque foi o que pediram.
Esses momentos são o treino real do pensamento de decisão.
É onde você começa a sair da mentalidade de execução e entra na de decisão.
Quer um exemplo concreto?
Decidir exige parar antes de agir, pensar no contexto, entender o impacto e se perguntar:
“Se eu fizer isso, o que muda de fato? O que essa entrega resolve para o negócio, para o time ou para o usuário?”
Quem tem esse modo de operar, mesmo no operacional, é percebido como alguém de valor.
E, sinceramente, nenhuma AI vai substituir alguém assim.
Essa pessoa inevitavelmente toma decisões melhores, mesmo nas tarefas do dia a dia.
Gera bons debates, ajuda quem está acima (tático e estratégico) a gerar mais impacto e, principalmente, muda o jogo.
Enquanto o profissional que faz muitas tarefas continua sendo o profissional que faz muitas tarefas, você pode, com uma única decisão certa, mudar o jogo da empresa e o da sua vida.
Dilemas e exemplos reais
Se você chegou até aqui, é porque já entendeu que decidir é maior do que fazer em termos de resultado.
Você pode encontrar alguém que execute o trabalho, mas é muito mais difícil achar quem saiba decidir o que realmente precisa ser feito.
O problema é que decidir é fácil quando o contexto é simples.
O desafio é quando tudo parece urgente, e cada escolha traz consequências.
Talvez você ache que essas situações só acontecem com gestores, mas elas estão no dia a dia de quem coda.
Elas aparecem quando o cliente pede algo que não faz sentido, quando o gestor quer priorizar tudo, ou quando o time técnico quer qualidade e o negócio quer velocidade.
Todo dev vive esse conflito.
Lembro de uma conversa com um gerente de TI que me marcou.
Ele disse:
“Eu tive que fazer minha decisão. Ninguém sabe se vai ser a melhor, mas eu tive que escolher.”
O cenário era o seguinte: uma equipe de cerca de trinta desenvolvedores, dividida em vários times.
O gestor decidiu contratar um tech lead mais experiente para ocupar um cargo que vinha sendo assumido temporariamente por um dev interno.
O resultado foi um efeito dominó.
O dev interino pediu demissão, o novo tech lead não foi bem recebido pelo time e, de repente, o gerente teve que lidar com um problema técnico, político e emocional ao mesmo tempo.
A lição é simples: toda decisão tem prós e contras.
Quem ignora a complexidade envolvida acaba caindo nos efeitos colaterais que estavam nos “contras” da escolha.
Quem está de fora tende a julgar de forma simplista, sem ver as nuances e as pressões envolvidas.
E isso vale para todos os níveis: do dev que decide priorizar uma entrega até o gestor que define um novo caminho.
Eu costumo dizer que o segredo está em entender o cenário e trabalhar para reduzir os contras enquanto maximiza os prós.
É nesse processo que surgem os dilemas reais:
Dizer sim para tudo ou escolher o que realmente importa.
Corrigir um problema técnico ou destravar o negócio.
Focar em qualidade ou velocidade.
Esses dilemas não são um erro do sistema. Eles são o sistema.
E quanto mais consciente você for sobre eles, mais preparado estará para decidir melhor e crescer com cada decisão.
O aprendizado por trás das decisões
Com o tempo, eu aprendi que decidir bem não é sobre estar sempre certo.
É sobre entender o contexto, avaliar o impacto e ter consciência de que toda decisão tem prós e contras.
O erro mais comum é se encantar com os prós e esquecer dos contras.
Aí, quando eles aparecem, vem a sensação de que a decisão foi ruim.
Mas, na verdade, o problema não foi a escolha, foi a falta de preparo para lidar com o que ela traria junto.
O primeiro passo para decidir melhor é olhar o todo, e não apenas a parte técnica.
Antes de agir, pergunte-se:
Qual é o impacto disso para o negócio?
Qual é o custo dessa decisão se der errado?
Quem será afetado e como posso reduzir os contras para essas pessoas?
No dia a dia, isso pode ser simples:
Em vez de sair refatorando um módulo inteiro, entender se ele realmente precisa mudar agora ou se o risco é maior que o ganho.
Antes de adotar uma nova tecnologia, pensar se a equipe vai conseguir manter e se isso não cria dependência futura.
Quando o prazo aperta, escolher onde vale comprometer qualidade e onde não dá pra abrir mão.
Essas pequenas análises são o treino real de quem quer sair do “modo executor” e começar a decidir com consciência.
É assim que você começa a atuar como alguém que pensa no todo e não só no seu código.
No fim, o verdadeiro aprendizado é simples, mas poderoso:
Decidir bem é aprender a minimizar os contras para aproveitar melhor os prós.
Quem desenvolve essa mentalidade começa a enxergar o sistema de outro jeito.
Não é mais sobre tarefas. É sobre impacto.
Quando você começa a pensar assim, algo muda. As pessoas passam a te ouvir de outro jeito. Você deixa de ser o dev que só faz o que pedem e vira o profissional que ajuda a decidir o que deve ser feito.
Conectar ao Negócio
Se até aqui você entendeu que decidir é o novo código, o próximo passo é conectar suas decisões ao que realmente move as empresas: o negócio.
O segundo pilar do Outcode Thinking mostra que decidir é o novo código.
Quem aprende a decidir certo começa a ser visto de outro jeito, como alguém que entende o que realmente gera resultado.
Mas ainda falta um passo.
Decidir bem no seu escopo é ótimo.
Agora imagine quando suas decisões começarem a influenciar o negócio em si: orçamento, produto, e direção.
Muito bom seu texto! Isso serve para qualquer área. Em um laboratório, somente fazer o ensaio solicitado é a pior decisão, porque normalmente o cliente não sabe exatamente qual ensaio resolve o problema.
A sequência de perguntas que faço para meu cliente:
1) Para quando você precisa do resultado?
2) O uso do resultado é para uma área técnica ou para gestão?
3) Qual é o problema?
Aqui já tenho um pano de fundo para tomar minhas decisões.
E só a partir desse ponto que começa a discussão técnica.
Por fim a tomada de decisão vem em conjunto com o cliente, para dividir a responsabilidade. Porque o mais interessado pelo melhor resultado laboratorial é o meu cliente.