Review: The Principal Engineer Handbook, ou como pensar como Principal sendo Staff

1. Introdução

Chega um momento na carreira em que ser o melhor engenheiro da sala já não resolve. Foi com essa sensação que li o "The Principal Engineer Handbook", do JJ Tavernier, que a Packt Publishing disponibilizou para eu fazer o review. Fica aqui o meu agradecimento a eles pela oportunidade.

O autor passou dez anos na Amazon, onde chegou a Principal SDE, e depois foi Senior Principal Engineer e Director na Capital Group. Ou seja, escreve de dentro de grandes empresas.

A ideia central do livro é simples: o que define um Principal é o tamanho e a ambiguidade dos problemas que ele pega, e não o quanto ele sabe de tecnologia. Saber muito continua importando, mas não basta. Para mim, que hoje estou como Staff, a leitura foi menos um guia de promoção e mais um espelho.

2. Por que isso importa para um Staff hoje

O começo do livro lista problemas que qualquer Staff reconhece de longe: times tocando iniciativas que não movem o negócio, tecnologia escolhida só porque é legal, sistemas difíceis de evoluir, código e dados duplicados entre áreas e boas ideias que ninguém compra. O autor trata tudo isso como o material de trabalho de um Principal.

Um ponto me chamou atenção por ser bem atual. Com agentes de código escrevendo boa parte do software, esses problemas tendem a piorar. Hoje uma empresa consegue criar sistemas duplicados e designs incoerentes mais rápido do que nunca. Escrever código deixou de ser a parte difícil. O difícil é decidir o que construir, manter tudo coerente e segurar a barra de qualidade. Quem consegue pensar nesse nível, o da organização, ganha muita alavancagem. E é isso que, na prática, separa o Staff que entrega bem do Staff que já age como Principal.

3. O que levo do livro

Energia vezes alavancagem. É o modelo mental que mais usei desde que li. O valor que um engenheiro gera depende do esforço que ele aplica e de onde aplica. Dois engenheiros igualmente bons e dedicados podem gerar resultados bem diferentes. Reescrever um serviço estável que já atende tem pouca alavancagem. Construir algo que dois times acabariam duplicando tem muita. Pensar como Principal começa por escolher bem para onde vai o esforço, o seu e o do time.

Dar nome aos gargalos. O autor cataloga padrões que se repetem: fragmentação, duplicação de lógica, data sprawl, data siloing, ownership centralizado e monolitos. Parece detalhe, mas muda a conversa. Em vez de "esse sistema é ruim", você diz "temos lógica duplicada e um serviço agregador resolve". Ele comenta que o data sprawl é comum no setor financeiro, onde cada aplicação acaba montando o próprio pipeline. Quem trabalha em banco conhece bem. No mundo Angular, vejo a mesma coisa em experiências de usuário fragmentadas e em componentes que cada squad reimplementa.

Escrever para pensar. O capítulo de escrita parte de uma ideia que eu já sentia na pele: escrever é pensar. Um design document bem feito te obriga a enfrentar as ambiguidades antes que elas apareçam no meio do projeto. O livro também recomenda o PR/FAQ, que parte do cliente e vai para trás, mas deixa claro que o formato importa menos que o exercício. Para um Staff, escrever é a forma mais escalável de influenciar.

Reduzir o risco antes de construir. O livro separa os riscos em problem framing, pesquisa, engenharia, execução e product-market fit, e sugere uma ferramenta para cada um: PR/FAQ, experimentos, spikes, mapa de dependências, pilotos. Tem um benefício político também. Com evidência na mão, fica bem mais fácil questionar um prazo ou um mandato irreal sem parecer que é opinião sua.

Recuperar o próprio tempo. O Staff costuma virar o gargalo de todo mundo. O exercício do livro é listar o que você faz e perguntar três coisas: isso é necessário? Só eu posso fazer? Me dá energia? O que não passa vira delegação, office hours, FAQ ou automação. Gostei também do método socrático para as perguntas que o time consegue responder sozinho.

Uma cultura que funciona sem você na sala. Padrões escritos, reuniões com propósito claro (decidir, aprender, criar vínculo ou fazer) e contratar gente com autonomia. A meta é que a qualidade não dependa de você estar presente.

4. Como isso aparece no meu dia a dia

Durante muitos anos, o banco tentou criar uma conta internacional. Em vez de insistir em construir do zero, tomou uma decisão ousada: comprar a plataforma tecnológica de uma startup em fase de sunset. Foi nesse projeto que vivi, na prática, quase tudo o que o livro descreve.

Primeiro, fui o responsável pela avaliação técnica da plataforma, que embasaria a decisão de comprar ou não. O livro cita esse tipo de tarefa entre as de um Principal: avaliar uma empresa ou um sistema e dizer se ele atende à necessidade ou se vale como aquisição. Não é algo que aparece para quem só entrega features. A sua análise pode custar ou economizar muito dinheiro, e a resposta honesta às vezes é "não compre". Dessa vez a conclusão foi positiva e o banco comprou.

Aí começou o trabalho de verdade. A plataforma funcionava, mas tinha nascido num mundo de startup. Precisávamos adequar o front-end e, principalmente, o back-end aos padrões de arquitetura e segurança de um banco. Isso não se resolve só com código. Foram muitas conversas com Arquitetura, Cyber e DevOps, cada área com as suas exigências e o seu ritmo. Boa parte do meu papel foi fazer a ponte, transformando as restrições do banco em decisões técnicas possíveis, e não em bloqueios.

O time também juntava dois mundos: 7 pessoas vindas da startup e 3 do banco, um grupo internacional, com gente de países e culturas diferentes. Misturar duas culturas de engenharia, fusos distintos e jeitos diferentes de trabalhar é o que o livro chama de cultura: os valores e as práticas que decidem se a visão vai sair bem, devagar ou nunca. Num time assim, acordo implícito não funciona.

Colocamos o app no ar em seis meses, numa época em que ainda não havia agentes de código. Isso conversa com aquele ponto do livro sobre escrever código ter deixado de ser o difícil. Olhando para trás, concordo. O que fez diferença não foi a velocidade de digitação, e sim a qualidade das decisões e o alinhamento entre as pessoas.

Se eu pudesse voltar, escreveria mais ADRs. Tomamos muitas decisões de arquitetura ao longo do projeto, e boa parte dos combinados com as áreas correlatas, como Arquitetura, Cyber e DevOps, ficou em conversas e reuniões. O livro defende que um documento escrito permite comunicar uma vez só e receber feedback de vários públicos. Registrar cada decisão, com o contexto, as alternativas e o acordo com cada área, teria evitado retrabalho, ajudado quem entrou depois e poupado o time daquela pergunta clássica: "por que a gente decidiu isso mesmo?". Num time internacional e distribuído, teria valido ainda mais.

No fim, o que fica para mim é que a passagem de Staff para Principal não chega com um título. Ela acontece quando você começa a tratar o problema como problema da organização, que envolve avaliar uma compra, negociar padrões com várias áreas e montar um time de origens diferentes, e não só desenhar a arquitetura de um software.

5. Veredito

Tenho algumas ressalvas, e o próprio autor admite várias delas. O livro é muito marcado pela cultura de Big Tech e de grandes corporações, e os números de remuneração e de tempo de carreira refletem o mercado americano. Vale adaptar para a sua realidade.

Mesmo assim, o que mais ficou comigo foi o capítulo final. O autor conta que, quando passou a tratar a promoção como objetivo principal, acabou desmotivado e perto de um burnout. A conclusão dele é que o foco deve estar em fazer um trabalho excelente, com impacto em algo maior que você, e o título vem como consequência.

Recomendo o livro para Staff Engineers que querem ampliar o escopo do que fazem. Ele traz modelos mentais concretos e técnicas que dá para aplicar já na segunda-feira. Para saber mais e comprar o seu exemplar, o livro está na Amazon.

Obrigado, Packt Publishing, por disponibilizar o livro para este review.