De sênior a principal: o trabalho que acontece entre os times

A pergunta que mais ouço

Nas conversas de carreira com o time, uma pergunta aparece mais que todas: "o que falta para eu ser staff?".

Quase sempre ela vem de alguém muito bom. Uma pessoa sênior que resolve qualquer problema que cai no time, que entrega com qualidade, que os outros procuram quando algo quebra. E a resposta honesta quase nunca é "aprender mais tecnologia".

Durante muito tempo eu tive dificuldade de explicar o que era, então. Até que li uma série em duas partes de Caleb Mellas e Thiago Ghisi, na newsletter Level Up Software Engineering, que organizou o que eu sentia. A primeira parte fala do que se espera de um staff. A segunda, dos comportamentos que levam até lá.

Os dois textos falam muito mais de comportamento do que de conhecimento. Conhecimento é o que você sabe. Comportamento é o que você faz com isso, repetidas vezes, sem ninguém pedir.

O que é, afinal, ser staff

Até uns dez ou quinze anos atrás, sênior era o teto para quem não queria virar gestor. Para continuar crescendo, a pessoa precisava trocar o código pela gestão de pessoas. A carreira em Y, com uma trilha técnica paralela à de gestão, surgiu para resolver isso: reter quem é muito bom tecnicamente sem obrigar essa pessoa a gerir gente.

A primeira parte da série define bem o papel: staff é quem atua além de um projeto ou de um time, em uma área maior da organização. Faz parte da liderança de engenharia, cuida de relações com outras áreas e liga o trabalho técnico às prioridades do negócio. O que define o nível não é a profundidade técnica, e sim o tamanho e a forma do impacto.

Gosto de olhar para isso pelo lado da empresa. Em cada nível, muda o tipo de resultado que a pessoa ajuda a mover: a entrega de um time, o resultado de uma linha de produtos, os objetivos de uma área inteira e, no topo, a estratégia da empresa.

Um cuidado antes de seguir: título não é régua. O mesmo "staff" pode significar coisas muito diferentes de uma empresa para outra. Sites como o levels.fyi ajudam a comparar. Por isso, ao longo do texto, prefiro falar do que a pessoa faz do que do nome do cargo.

Raio de explosão

A primeira das três expectativas que a série descreve tem um nome de que gosto muito: raio de explosão. Quem trabalha com infraestrutura conhece bem o termo. É até onde chega o estrago quando algo falha. Boa parte da arquitetura de sistemas confiáveis, como as células e os isolamentos que o AWS Well-Architected recomenda, existe para diminuir esse raio: se uma parte cai, o resto continua de pé.

Gosto de usar a mesma imagem para carreira, só que ao contrário. Em cada nível, o raio de explosão das suas decisões aumenta. E isso vale para os dois lados: uma boa decisão de um principal melhora a área inteira, e uma ruim também se espalha pela área inteira.

No time que eu lidero, esse raio tem um desenho bem concreto. Já contei em outro artigo como organizei pagamentos em três partes: a linha core, que cuida do pagamento em si, com ritmo cuidadoso e peso regulatório; a linha de cliente, que cuida de como o cliente chega até o pagamento, com ritmo rápido e foco na experiência; e os times de plataforma, que sustentam as duas.

Uma pessoa sênior cuida bem de uma das caixas. Um staff cuida das linhas entre as caixas de uma área. Um sênior staff atravessa as três partes. E um principal responde pela direção técnica de pagamentos como um todo.

Fundo ou largo

O raio de explosão tem forma, e a série descreve duas. O impacto pode ser profundo, quando muda como uma linha inteira funciona. Ou largo, quando cria uma base que muitos times passam a usar.

No desenho que eu uso, a linha core é o lugar natural do impacto profundo: redesenhar como uma liquidação funciona, por exemplo, mexe em todos os produtos de pagamento de uma vez. Os times de plataforma são o lugar natural do impacto largo: um pipeline de deploy melhor, ou uma forma padrão de observar os serviços, chega a todas as linhas.

Nos dois casos, o critério que os autores usam é o mesmo, e eu concordo: o impacto precisa aparecer no negócio. Receita, custo ou experiência do cliente. Um trabalho tecnicamente brilhante que não move nenhum desses três raramente sustenta uma promoção.

Horizontes de planejamento

A segunda expectativa é sobre tempo. Cada nível enxerga a um horizonte diferente: quem está começando pensa em horas, o sênior em semanas, o staff em trimestres e o principal em anos.

Os autores ligam essa ideia aos horizontes de foco de David Allen, do Getting Things Done, e aos horizontes de perspectiva de Tiago Forte, do Building a Second Brain. Fui conferir os dois enquanto escrevia, e a imagem que ficou para mim é a de uma escada: cada degrau olha mais longe. E mostram que a empresa tem rituais para cada horizonte: o dia a dia, as reuniões semanais, as revisões mensais, o planejamento, os OKRs e os encontros anuais da liderança.

A diferença entre sênior e staff aparece aqui com clareza. O sênior executa muito bem o plano que recebeu. O staff ajuda a escrever o plano: antecipa uma necessidade, defende um item no roadmap do ano, consegue espaço e recurso para ele.

No meu time, um exemplo seria uma pessoa da linha core que percebe, com dois trimestres de antecedência, que uma mudança regulatória vai exigir trabalho nas três partes, e leva isso para o planejamento antes que vire urgência. Ou alguém de plataforma que transforma uma dor de DevEx espalhada pelos times em um objetivo da área.

O erro comum, segundo eles, é viver de tarefas curtas e fáceis, que dão sensação de progresso e pouco impacto. Pesquisando para este texto, encontrei um artigo de Will Larson sobre isso, "Work on what matters", em que ele chama esse tipo de trabalho de lanchinho. Lanchinho é bom, mas não alimenta uma carreira, e ainda cansa.

Quatro níveis de autonomia

A terceira expectativa é sobre autonomia, e é a que mais uso nas conversas de carreira. Ela parte de um texto de Randall Koutnik, que li durante a preparação deste artigo, "Implementers, Solvers, and Finders", e os autores acrescentam um quarto nível.

• Implementador: recebe a tarefa e o jeito de fazer.
• Resolvedor: recebe o problema e escolhe a solução.
• Descobridor: escolhe qual problema vale a pena resolver, e às vezes diz que a sugestão que recebeu não é a prioridade.
• Condutor: leva o que importa até o fim e ajusta a rota quando o cenário muda.

O sênior costuma estar no papel de resolvedor, e é muito bom nele. O staff precisa atuar como descobridor e condutor ao mesmo tempo.

Os autores apontam três armadilhas, e já vi todas. Ficar para sempre no papel de resolvedor, esperando o problema chegar. Virar um descobridor solto, que aponta problemas e não ajuda a resolver nenhum. E o contrário: perder a mão na implementação. Um bom staff transita entre os quatro papéis conforme o momento pede.

O que fui consultar

Enquanto escrevia este artigo, quis checar se o que eu sentia na prática batia com o que outras pessoas já tinham escrito. Fui atrás de dois livros.

O primeiro foi Staff Engineer, de Will Larson. Ele descreve quatro formas de exercer o papel: o líder técnico, que guia a execução de um time ou de um grupo de times; o arquiteto, que responde pela direção técnica de uma área; o resolvedor, que mergulha nos problemas mais difíceis da empresa; e o braço direito, que estende o alcance de um executivo. O que me ajudou foi perceber que não existe um único jeito certo de ser staff.

O segundo foi The Staff Engineer's Path, de Tanya Reilly. Ela sustenta o papel em três pilares: visão ampla, execução de projetos grandes e elevar o nível das pessoas ao redor. Ela também é autora de uma palestra que todo sênior deveria ver, "Being Glue", sobre o trabalho de cola que mantém os times funcionando e que raramente é reconhecido.

Juntando tudo, vejo o mesmo padrão: em todos os níveis acima de sênior, o trabalho se desloca de dentro do time para o espaço entre os times.

O primeiro salto: de sênior para staff

A segunda parte da série desce para o comportamento. Para o primeiro salto, Mellas e Ghisi apontam três: decidir de forma estratégica, multiplicar os outros e influenciar além do próprio time. E os três acontecem no mesmo lugar.

Quem cuida do contrato entre o core e a linha de cliente? Quem percebe que três times estão resolvendo o mesmo problema de três jeitos? Quem nota que uma decisão boa para um time empurra custo para outro? As caixas têm dono. As linhas, não. E é ali que eu procuro sinais de staff.

Decidir de forma estratégica

O sênior pergunta como resolver bem. O staff pergunta se esse é o problema certo para resolver agora.

Revendo referências para este texto, voltei a uma ideia de uma carta de Jeff Bezos aos acionistas da Amazon, de 2015, que traduz bem essa diferença. Ele separa as decisões em dois tipos: portas de mão dupla, que dá para desfazer sem grande custo, e portas de mão única, que não dá. As primeiras devem ser rápidas e ficar perto do time. As segundas pedem calma e a participação de quem vai ser afetado.

No meu desenho, a linha de cliente vive de portas de mão dupla: um teste de tela, um experimento, uma funcionalidade ligada para uma parte dos clientes. Na linha core, muita coisa é porta de mão única: o contrato de uma API que outros times consomem, o modelo de dados de uma liquidação, uma regra regulatória.

Um sintoma claro de que alguém está pronto para staff é saber de que tipo é cada porta. Não tratar um experimento como se fosse uma decisão de arquitetura, e não tratar uma mudança de contrato como se fosse um experimento. Quando a porta é de mão única, o staff registra a decisão, e aqui os ADRs, os registros de decisão de arquitetura propostos por Michael Nygard, ajudam muito: a decisão, o contexto e as alternativas ficam escritos para quem vier depois.

Multiplicar os outros

Esse é o comportamento mais difícil para quem construiu a carreira sendo quem resolve.

Consultando High Output Management, de Andy Grove, encontrei a ideia que melhor resume isso: o resultado de um gestor é o resultado do time que ele influencia. A mesma lógica vale para staff. O impacto deixa de ser medido pelo que você entrega e passa a ser medido pelo que você destrava.

O texto da Level Up cita uma ideia de Tanya Reilly que encontrei também no livro dela: uma das formas de ter impacto é apoiar as ideias dos outros. Nem tudo precisa nascer de você.

Um exemplo do meu desenho: um engenheiro do core que documenta bem o contrato de uma API e senta com a linha de cliente até ela conseguir consumir sozinha multiplicou mais do que se tivesse feito a integração com as próprias mãos. Deu mais trabalho naquela semana e economizou meses.

Influenciar além do time

Quando desenhei a estrutura, ficou claro para mim que a fronteira entre os times é também a fronteira entre os produtos. Por isso fiz questão de levar a liderança de produto para dentro do desenho, e não decidir só pela ótica da tecnologia. O mesmo vale para quem quer ser staff: não dá para influenciar a direção técnica sem entender para onde o produto quer ir.

Na prática, isso é pouco glamuroso. É explicar um risco técnico para alguém de produto sem jargão. É entender por que o atendimento está reclamando antes de propor a solução. É perceber que dois times esperam modos diferentes de trabalhar juntos, um querendo ser atendido como serviço e o outro achando que é colaboração, e conversar até alinhar.

O segundo salto: de staff para sênior staff

Se o staff cuida das fronteiras de uma área, o sênior staff começa a responder por iniciativas que atravessam todas elas. Os autores apontam três comportamentos: liderar de ponta a ponta iniciativas críticas, formar pessoas em vários times e garantir excelência operacional ao longo do tempo.

Pense em uma exigência regulatória nova que muda a jornada de pagamento. Ela mexe nas regras do core, muda telas e fluxos na linha de cliente e pede ajustes de infraestrutura e de dados nas plataformas. Nenhum time sozinho consegue entregar. Alguém precisa enxergar o caminho inteiro, quebrar o problema, combinar a interface entre as partes e acompanhar até o fim. No vocabulário do Team Topologies, é o momento em que os times saem do modo de serviço e entram em colaboração por um tempo definido. Conduzir essa colaboração, e devolvê-la ao modo de serviço quando a interface fica clara, é trabalho de sênior staff.

A excelência operacional é a parte menos visível. Para esta parte, voltei às quatro métricas de Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim: frequência de deploy, tempo até a produção, tempo de recuperação e taxa de falhas em mudanças. Um sênior staff não olha para elas em um time. Olha para a área inteira e pergunta por que uma linha publica toda hora e a outra uma vez por semana, e o que precisa mudar na plataforma para isso.

E a formação de pessoas deixa de ser no próprio time. O sênior staff ajuda a formar os próximos staff, nas três partes do desenho.

O terceiro salto: de sênior staff para principal

No nível de principal, o raio de explosão é o domínio inteiro. Os autores falam em ser dono de um domínio, em puxar inovação e em uma mentoria que se adapta a qualquer nível, incluindo gestores e diretores.

Em pagamentos, ser dono do domínio é responder por perguntas que nenhum time faz sozinho. Como o desenho de times precisa evoluir quando o negócio muda? Que dívida técnica vira risco de negócio nos próximos dois anos? Que tecnologia, ou que forma de trabalhar, abre uma possibilidade que hoje não existe? É também o nível em que a pessoa aplica de forma consciente o que Conway descreveu: se a organização molda o software, um principal pensa na organização como parte da arquitetura.

A mentoria muda de natureza. Um principal ajuda gestores a tomar decisões técnicas, participa de seleção e de calibração de níveis e influencia o que a empresa reconhece e recompensa. Lembro bem de um comitê de performance sobre o qual já escrevi aqui: ter alguém técnico desse nível na conversa muda a qualidade da decisão.

Nesse ponto, a pessoa trabalha tão perto da liderança executiva quanto da engenharia. É a ponte entre o que a tecnologia consegue fazer e o que o negócio precisa.

O que trava, em qualquer salto

O texto da Level Up lista três armadilhas, e reconheço as três nas conversas de carreira:

• Falta de visão estratégica. Projetos tecnicamente bonitos que não se conectam a nenhuma prioridade. Viram distração, por melhores que sejam.
• Não conseguir delegar. Segurar as tarefas difíceis porque "é mais rápido eu fazer". É mesmo, uma vez. Na décima, virou gargalo.
• Comunicação fraca com outras áreas. Não saber negociar dependências nem explicar um problema técnico para quem não é técnico.

Nenhuma delas é falta de capacidade. São hábitos de um sênior muito bom, que funcionaram até ali. Fui ler o livro que a série recomenda sobre isso, de Marshall Goldsmith, e o título já resume a ideia: What Got You Here Won't Get You There. O que trouxe você até aqui não leva você adiante.

O que isso muda para quem lidera

Escrever este texto me trouxe uma responsabilidade que eu não via tão claro: o desenho do time cria ou tira a oportunidade de alguém agir como staff.

Se as fronteiras são confusas, ninguém sabe onde atuar. Se um time carrega coisa demais, sobra energia só para o trabalho dentro da caixa. Se todo problema que cruza dois times sobe direto para a gestão, o engenheiro nunca tem a chance de resolvê-lo.

Então parte do meu trabalho é abrir esse espaço. Deixar claro quais problemas vivem entre os times, dar a alguém a chance de liderar um deles e reconhecer o trabalho de cola que não aparece em nenhum commit.

Por onde começar

Para quem está diante de um desses saltos, os autores sugerem três movimentos, e concordo com eles:

1. Procure modelos, não checklists. Olhe para quem já atua no nível que você quer e observe como essa pessoa lida com um conflito, uma decisão difícil, uma reunião com produto. A régua de carreira diz o que se espera. Um bom exemplo mostra como.
2. Ataque o comportamento que mais limita você. Em vez de somar habilidades novas, descubra o hábito que mais segura você hoje. Pergunte para o seu gestor e para os seus pares.
3. Entenda como funciona na sua empresa. Converse com quem foi promovido há pouco. Pergunte como é o dia a dia, quais projetos contaram e quem apoiou. Cada empresa valoriza coisas diferentes.

Fechamento

O salto de sênior para staff, e todos os que vêm depois, quase nunca são técnicos. A técnica é o ingresso, e quem chegou a sênior já pagou.

O que muda é o endereço do trabalho. Ele sai de dentro do time e vai para as linhas que ligam um time ao outro, depois para a área inteira, depois para o domínio. Foi olhando para o desenho de times que eu lidero que entendi isso de vez: as caixas mostram onde cada um trabalha, e as linhas mostram onde as próximas carreiras acontecem.

Fontes

• Breaking the Staff Engineer Ceiling pt. 1, Caleb Mellas e Thiago Ghisi, Level Up Software Engineering, 2024
• Staff Engineer Behaviors: pt. 2 Breaking the ceiling into Staff Engineering, Caleb Mellas e Thiago Ghisi, Level Up Software Engineering, 2024
• Staff Engineer: Leadership beyond the management track, Will Larson, 2021
• The Staff Engineer's Path, Tanya Reilly, O'Reilly, 2022
• Being Glue, Tanya Reilly, 2019
• Work on what matters, Will Larson, 2021
• Implementers, Solvers, and Finders, Randall Koutnik, 2016
• Getting Things Done, David Allen, Viking, 2001
• Building a Second Brain, Tiago Forte, Atria Books, 2022
• levels.fyi, comparação de níveis entre empresas
• Carta aos acionistas referente a 2015, Jeff Bezos, Amazon, publicada em 2016
• Documenting Architecture Decisions, Michael Nygard, 2011
• High Output Management, Andrew S. Grove, Random House, 1983
• AWS Well-Architected Framework: pilar de confiabilidade, Amazon Web Services
• Team Topologies: Organizing Business and Technology Teams for Fast Flow, Matthew Skelton e Manuel Pais, IT Revolution Press, 2019
• Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble e Gene Kim, IT Revolution Press, 2018
• How Do Committees Invent?, Melvin Conway, Datamation, 1968
• What Got You Here Won't Get You There, Marshall Goldsmith, Hyperion, 2007
• The Effective Hiring Manager, Mark Horstman, Wiley, 2019