Este texto foi inspirado em “How I Find Problems to Solve as a Staff Engineer”, de Lalit Maganti. Não é uma tradução: é uma leitura aplicada do método descrito pelo autor.
A transição para staff engineer não acontece quando alguém recebe problemas maiores. Ela começa quando a pessoa passa a perceber problemas antes que eles virem demandas formalizadas.
Isso não significa reservar uma hora na agenda, encarar uma página em branco e tentar “pensar estrategicamente”. A prática descrita por Lalit Maganti é mais concreta: prestar atenção ao ruído cotidiano da organização, guardar os atritos e esperar até que apareça evidência suficiente para saber se existe algo relevante ali.
Escute problemas, não pedidos
Times costumam chegar com uma solução já embutida: “precisamos de um botão”, “precisamos de uma integração”, “precisamos de mais um painel”. O pedido é útil como pista, mas raramente é a definição completa do problema.
Uma conversa melhor começa por perguntas que expõem o contexto: o que a pessoa tenta fazer? Onde o fluxo trava? O que ela já tentou? Por que a ferramenta atual não resolve? Se uma alternativa existisse, ela realmente eliminaria o atrito?
Esse tipo de escuta acontece nas reuniões normais, nas mensagens de chat, nas apresentações e nos incidentes. Quando o assunto toca a sua área, vale acompanhar um pouco mais de perto: observar o fluxo real, revisar o bug com quem o investiga ou tentar reproduzir a situação. Isso separa a necessidade do usuário da primeira solução que ele imaginou.
Também ajuda conversar com quem enxerga mais longe: responsáveis por sistemas críticos, pessoas que circulam por vários times e quem recebe as consequências do seu produto. São essas pessoas que costumam notar a repetição antes de ela aparecer no roadmap.
Não transforme o primeiro sinal em projeto
Uma solicitação urgente para um time pode ser irrelevante para o produto inteiro. A prioridade daquele grupo pode mudar na semana seguinte; o pedido pode ter surgido de uma investigação pontual; ou a solução pode atender apenas um caso muito particular.
Por isso, deixar problemas em espera não é indecisão. É uma forma de coletar evidência.
- O mesmo obstáculo reaparece de forma independente em outros times?
- Pedidos diferentes apontam para a mesma limitação?
- As pessoas improvisam planilhas, scripts ou atalhos para contornar o produto?
- O custo aparece no trabalho diário, e não só na opinião de quem pediu a mudança?
Não há um único mecanismo correto para isso. Pode ser uma nota, uma lista de hipóteses, tickets marcados ou uma rotina curta de revisão. O importante é não apagar problemas não resolvidos antes que eles possam se repetir, mudar de forma ou se revelar parte de algo maior.
Procure a forma comum
O caso contado por Maganti no Perfetto ilustra bem a diferença entre acumular pedidos e entender o problema. Vários times pediam pequenos ajustes na interface: manter itens fixos, abrir uma visualização já ampliada, criar agregações próprias. À primeira vista, eram funcionalidades distintas.
O padrão por trás delas era outro: cada time queria adaptar a ferramenta ao próprio fluxo sem impor essa adaptação a todos os demais. A resposta não precisava ser uma lista de recursos sob medida; podia ser uma forma de extensão.
Essa etapa exige cuidado. Uma explicação elegante para vários pedidos ainda é uma hipótese, não uma confirmação. Em outro exemplo do autor, uma proposta de cache parecia conectar dois problemas, mas o protótipo mostrou que eles precisavam de soluções diferentes. A hipótese foi dividida antes de virar uma arquitetura difícil de sustentar.
Teste a hipótese antes de comprometer o roadmap
O próximo passo depende de risco, custo e grau de certeza. Uma melhoria pequena e reversível pode ser feita logo. Uma ideia ainda nebulosa pede um protótipo descartável, que revele limites técnicos e dê aos usuários algo concreto para contestar. Uma iniciativa maior pede RFC, conversas com os times afetados e tempo para refinar a proposta.
O ponto não é convencer os outros a qualquer custo. É tentar derrubar a própria ideia cedo. Se a demanda não se sustenta, se o custo técnico é alto demais ou se o momento da organização não é aquele, interromper ou estacionar o trabalho é um bom resultado.
Quando a hipótese resiste, quem a identificou não precisa necessariamente implementá-la. Encontrar, enquadrar e validar um problema já pode mudar a direção do time. Essa é uma das formas mais úteis de influência técnica: melhorar a qualidade das decisões antes que a implementação comece.
O efeito acumulado
Resolver problemas reais cria confiança. Pessoas que foram ouvidas voltam mais cedo na próxima vez; líderes passam a considerar sua avaliação com mais peso; conexões entre áreas ficam mais fáceis de perceber. O ciclo melhora tanto a capacidade de execução quanto a leitura do que merece ser executado.
Para quem mira uma atuação de staff, a prática pode começar de modo simples: em vez de responder imediatamente a cada pedido, registre o atrito, entenda o trabalho que ele interrompe e observe se ele reaparece. O problema certo quase nunca se anuncia com um ticket perfeito. Ele aparece aos poucos, em lugares diferentes, até que a forma comum fique difícil de ignorar.
Fonte: Lalit Maganti, “How I Find Problems to Solve as a Staff Engineer” (25 jul. 2026).
Top comments (1)