Sem PM no time: o que um Senior deveria fazer?

Recentemente passei no meu período de experiência, e em um 1-on-1 meu manager disse: "Gostaria que você fosse mais proativo em explorar problemas do produto."

Isso me pegou desprevenido. Eu estava escrevendo código todos os dias, corrigindo issues e empurrando projetos para frente. Como isso ainda não era proativo o suficiente? Levei um tempo para entender o que ele realmente quis dizer.

Tudo rodando ao mesmo tempo

Passar no período de experiência não significou menos pressão. Na verdade, significou fazer malabarismo com ainda mais coisas ao mesmo tempo:

Item	Natureza	O que posso controlar
Correção de issues	Trabalho diário, com output medido parcialmente por volume	Manter um ritmo constante
Projeto A	Um projeto formal, mas o lado do usuário demora para confirmar requisitos	Limitado — principalmente esperando respostas
Pesquisa de produto	Procurar proativamente formas de melhorar o produto	Quando entregar, como apresentar, como reportar

Quando você está alternando entre três ou mais coisas em um único dia, a parte cansativa não são as horas. É o constante context switching.

Então percebi: não temos PM

Eu sabia disso desde o primeiro dia, mas nunca tinha realmente pensado no que isso significava.

Temos um BA (Business Analyst) que cuida da análise de requisitos, mas ninguém realmente é dono de perguntas como: Em que ponto isso está? Quem está bloqueado? Deveríamos repriorizar?

Na minha empresa anterior, o PM ou Tech Lead cuidava de tudo isso. Eu só precisava checar o backlog, confirmar prioridades, esclarecer requisitos do produto e focar em escrever código. O spec chegava, eu construía. Se ficasse travado, dizia pro PM e eles cuidavam do resto.

Agora esse papel não existe. Então quem assume?

O Senior.

Senior não é PM, mas você precisa de Ownership

No começo eu não entendia. Sou engenheiro — por que deveria ficar correndo atrás de usuários por respostas, reportando blocker proativamente ou alinhando prioridades com meu manager? Isso não é trabalho de PM?

Mas isso não significa que um Senior deve substituir o PM assumindo o roadmap do time, fazendo coordenação cross-funcional ou rastreando o progresso de todos. O ponto real é mais simples: você não pode tratar blocker no seu próprio trabalho como se fossem problema de outra pessoa.

Quando comparei os dois, a diferença ficou mais clara:

	PM	Senior
De quem gerenciar o progresso	O time inteiro	Suas próprias linhas de trabalho
Decidir o que construir	Roadmap, prioridades	Não decide, mas alinha
Perseguir stakeholder	Todos os envolvidos	Seus próprios blocker
Responsável perante	Objetivos de negócio	As funcionalidades que você é dono

Um Senior não precisa gerenciar outras pessoas. Você só precisa manter suas três ou quatro linhas sem deixar cair. Reporte blocker proativamente em vez de esperar em silêncio. Tenha opiniões sobre as funcionalidades que você é dono em vez de apenas esperar instruções.

Isso se chama ownership, não PM.

Não é que meu trabalho anterior fosse fácil demais

Por um momento, me perguntei se minha empresa anterior simplesmente tinha expectativas mais baixas para Seniors. Mas quanto mais pensava, mais percebia que esse não era o problema. Os ambientes eram simplesmente diferentes.

Minha empresa anterior tinha um PM me protegendo do trabalho de coordenação, e a linha de produto era mais simples. Lá, "Senior" era definido mais em termos técnicos: se você conseguia resolver problemas difíceis, era suficiente. No meu ambiente atual, parte do trabalho também é empurrar o progresso do produto para frente, porque ninguém mais vai fazer isso por você.

Em um time enxuto, isso é normal. Não é irracional. Eu só ainda não estou acostumado.

O que eu realmente fiz

Depois que entendi isso, fiz algumas mudanças:

Priorizar e alinhar com o manager. Listei tudo por prioridade e perguntei: "Essa ordem está OK para você?" É só uma mensagem, mas muda a postura de esperar passivamente por instruções para gerenciar ativamente meu próprio trabalho.

Quando bloqueado, troca de linha, mas deixa registro. Se o usuário do Projeto A não responde, faço ping uma vez por semana e deixo um rastro documentado. Meu manager sabe que o blocker não está do meu lado, e posso usar o tempo liberado para empurrar a pesquisa de produto.

Não faça context switching com muita frequência. Use prioridades para decidir no que trabalhar hoje em vez de tocar em tudo um pouco. Registre as linhas bloqueadas, coloque de lado e volte quando desbloquearem.

Reflexão final

Tudo isso parece básico, mas para um engenheiro acostumado a ter um PM cuidando da coordenação, leva tempo para se adaptar. Sob pressão, pode parecer que você está fazendo trabalho que não é seu. Mas pelo menos em um time sem PM, isso é parte do que significa ser Senior.

Como nota à parte, primeiro organizei o pensamento por trás deste post através de conversas com AI, depois rastreei através de um sistema pessoal que construí para logging diário e feedback — eu chamo de Pasiv. Vibe coding não é só sobre usar AI para construir projetos. Também inclui usá-lo para desemaranhar onde você está atualmente.