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)
Hehe.
Once they offered me promotion and a slight pay raise.
They said they need my confirmation.
I said to boss, I wanted to functional test it, so we're not gonna go happy path, so I choose decline.
Hehhe, he said that payroll etc. already did the thing, so I should stop my game and be a good little cubiclist and confirm.
I said that since we uncovered this anomaly in the system, let's trigger other bugs, so let's see how resign works.
Next place was fun too, I saw code from 90s.
All in all, I think the problem with engineers in private sector is that since they don't have anything to show for, they are unconsciously giving respect to empy and shallow notions like titles, seniority, certs etc. I mean look at these aws certs, then Amazon footguns its codebase, it fails to properly launch a mmo infra wise.
Anyways, my role on dev.to is to find a single dev who can solve a programming puzzle from me.
This isn't about belittling people, but rather to elevate them: make them heroes.
To offer them the chance of becoming Johnny Silverhand to my little heart.
I contacted a lot of people over circa 2 years. It started off on gh, now it is a bit of reddit and dev.to too.
Thus far 0 devs solved it.
What's really funny is that I always explicitly say: You can ask for hints, little tiny guiding questions.
Most devs don't take advantage of that.
Puzzle works this way:
I pose challenge.
Dev has the option to decline the challenge, and walk away without any face loss.
If dev accepts challenge, I expect at least a bare minimum social contract:
If dev loses interest/quits, dev should notify me about that fact.
I have to explicitly write this down, since devs take on the challenge then ghost me most of the time.
Further information and ygritte gifs are located in my article titled:
The Evil Spellbook of Sasslery and Teaseomancy.
'S ann leatsa a tha an roghainn, a Jon Snow.