Você termina um projeto, sente que parou de evoluir e abre a documentação de outro framework. O impulso faz sentido: aprender uma API nova produz progresso visível, exemplos compilam e o currículo ganha mais uma linha. Só que isso não resolve um problema comum de quem já é pleno ou sênior: demonstrar, com evidências, que consegue sustentar sistemas, ampliar o trabalho de outras pessoas e comunicar decisões difíceis.
A pergunta útil deixa de ser “qual tecnologia falta?” e passa a ser: qual evidência do meu trabalho um colega cético conseguiria abrir e verificar? Se a resposta for apenas uma lista de ferramentas, o gargalo talvez não seja conhecimento. É só mais confortável instalar uma dependência do que organizar a prova. A dependência, pelo menos, não agenda uma conversa de carreira.
Saber usar não é o mesmo que sustentar
Saber usar uma tecnologia permite entregar um caminho feliz: configurar o projeto, conhecer as APIs e colocar uma funcionalidade no ar. Sustentar exige fechar o ciclo operacional:
- detectar que o usuário está recebendo erro;
- separar sintoma, gatilho e causas contribuintes;
- restaurar o serviço com uma ação segura;
- registrar o que aconteceu sem procurar um culpado;
- entregar uma mudança durável que reduza a recorrência ou o impacto.
O postmortem publicado pelo Google para o Shakespeare Search dá uma forma concreta a essa diferença. O incidente envolve aumento de erros HTTP, uma falha latente exposta por carga e ações de restauração e prevenção. O ponto importante aqui não são os números daquele ambiente, nem uma reconstituição heroica. É o formato: houve detecção, mitigação, explicação e trabalho posterior. A resposta não foi “reescrever tudo com o framework da semana”.
Para observar sua capacidade no eixo operacional, escolha um serviço que você mantém e responda: se ele alertar de madrugada, você consegue encontrar o impacto para o usuário, executar o último caminho seguro de restauração e apontar uma melhoria que ficou depois do incidente? Se não consegue, a remediação não é estudar outra API. É revisar um alerta voltado ao usuário, testar um passo do runbook e registrar o resultado em um documento ou PR que o time possa consultar.
Monitorar métricas conhecidas também não encerra o assunto. A orientação da DORA sobre monitoramento e observabilidade inclui estado percebido pelo cliente, ferramentas para depuração em produção e capacidade de investigar propriedades que não foram previstas. Ter um dashboard sem saber qual decisão ele dispara é decoração corporativa com atualização automática.
Três eixos para tornar senioridade verificável
A divisão abaixo é uma lente editorial deste texto, não um modelo oficial de carreira. Ela organiza evidências em três eixos: sistema, pessoas e comunicação. O objetivo não é produzir uma nota de senioridade, mas encontrar onde faltam artefatos verificáveis.
| Eixo | Pergunta | Evidência que um par consegue verificar | Se estiver vazio | Como observar com segurança |
|---|---|---|---|---|
| Sistema | Você observa, restaura e melhora o sistema atual? | dashboard ligado a uma decisão, runbook exercitado, postmortem ou PR de prevenção | teste um caminho de restauração e deixe uma melhoria pequena | ambiente controlado, alerta de produção existente e histórico de mudanças |
| Pessoas | Seu trabalho aumenta a capacidade de outra pessoa? | design revisado, pessoa patrocinada para trabalho visível ou entrega feita por alguém que você orientou | escolha uma entrega real, defina autonomia esperada e registre o apoio | feedback da pessoa, artefato entregue e autoria preservada |
| Comunicação | Suas decisões sobrevivem fora de uma reunião? | proposta escrita, decisão com alternativas ou relato de incidente revisável | escreva contexto, decisão, impacto e lacuna em uma página | revisão assíncrona por pares, sem dados sensíveis nem nomes desnecessários |
Essa lente evita dois atalhos. O primeiro é tratar título como prova: o guia de arquétipos da StaffEng mostra formas diferentes de atuação — Tech Lead, Architect, Solver e Right Hand —, não uma escada universal. O segundo é esconder trabalho de liderança sob o verbo “ajudar”. Desbloquear uma entrega, integrar alguém ao time e perceber trabalho abandonado são contribuições técnicas, mas precisam de resultado e artefato.
Há ainda uma diferença prática entre mentoria e patrocínio. Mentoria oferece orientação; patrocínio coloca o nome de alguém diante de uma oportunidade visível. A explicação de Lara Hogan sobre sponsorship ajuda a transformar boa intenção em ação observável. Se o eixo de pessoas estiver vazio, escolha uma pessoa por uma contribuição real, indique-a para apresentar ou liderar o próximo passo e depois verifique se ela recebeu crédito e espaço — não se você apareceu como salvador na reunião.
Como contar um incidente sem fazer um despejo de currículo
Um relato técnico forte não precisa de drama, nomes ou uma lista de vinte tickets. Ele precisa permitir que outra pessoa entenda contexto, decisão e consequência. A cultura de postmortem sem culpa do Google SRE recomenda olhar causas contribuintes e corrigir sistemas e processos, assumindo que as pessoas decidiram com a informação disponível.
Use esta estrutura curta:
- Situação: qual serviço estava envolvido, qual impacto era visível e como foi detectado;
- Ação: quais decisões você tomou — declarar o incidente, reverter, reduzir carga, ampliar capacidade ou corrigir um playbook;
- Resultado: como o serviço foi restaurado e qual ação preventiva foi realmente entregue;
- Evidência: link permitido para postmortem, PR, runbook ou painel que confirme o relato.
Diga “eu” somente para a ação que foi sua. Para o resto, descreva o time e o sistema. Remova nomes, mensagens privadas, julgamento de caráter e a tese preguiçosa de que “a cultura é quebrada”. Se o relato ainda parece uma guerra cultural, reescreva causas como condições observáveis e converta cada condição em uma ação com responsável. Peça então a um colega que leia e marque o que não consegue confirmar. Essa revisão é a observação segura; publicar detalhes internos para parecer experiente definitivamente não é.
Quando aprender outro framework resolve um problema real
Framework novo não é proibido. Ele apenas precisa responder a um problema nomeado. O texto Choose Boring Technology propõe pensar em “fichas de inovação”: cada nova tecnologia adiciona modos de falha, operação e custo cognitivo que o time ainda não conhece. Tecnologia conhecida também falha, claro, mas costuma falhar de maneiras que alguém já documentou. Um luxo subestimado.
Antes de adotar algo novo, escreva respostas para cinco perguntas:
- Qual problema de produção ou de negócio cabe em uma frase?
- Como ele seria resolvido com a stack atual?
- O que torna essa solução proibitivamente cara ou inadequada?
- Quem será responsável por alertas, documentação, restauração e migração?
- Se houver sobreposição, qual é o plano para retirar a solução anterior?
O framework ajuda quando a limitação atual é demonstrável, os modos de falha podem ser operados e há dono para a migração. Ele só adia a conversa quando o problema é “quero aprender”, ninguém consegue narrar o último incidente e o time acumula duas soluções para a mesma função.
A remediação é simples: registre as cinco respostas em uma decisão curta e teste primeiro a alternativa na stack atual. Observe custo, risco e operabilidade com dados que o time já pode coletar, não com promessas de uma página de produto. Se a nova opção vencer, adote com plano de saída para a anterior. Se não houver resposta para a terceira pergunta, mantenha a stack e use a energia no eixo que está sem evidência.
O experimento de 30 minutos
Reserve meia hora. O resultado esperado é o eixo mais vazio e um único artefato para produzir — não uma porcentagem imaginária de senioridade.
Minutos 0–5: liste no máximo três trabalhos dos últimos 90 dias.
Minutos 5–15: para cada trabalho, anote o que era, o que você fez, o impacto comparado ao objetivo e a complexidade enfrentada. Associe uma evidência: documento, PR com caminho de rollback, dashboard, postmortem ou entrega de alguém que você orientou. Sem artefato, marque NÃO VERIFICADO.
Minutos 15–25: descreva um incidente ou quase incidente com situação, impacto, sua ação, resultado e um acompanhamento entregue. Não inclua nomes nem transforme o texto em acerto de contas. Se nunca houve incidente, use uma mudança arriscada e explique como ela seria revertida.
Minutos 25–30: distribua os itens entre sistema, pessoas e comunicação. O eixo com mais espaços vazios ou NÃO VERIFICADO é o próximo investimento.
Se quiser continuar no fim de semana, produza somente um artefato: exercite um passo de runbook para sistema; registre uma entrega autônoma ou um patrocínio para pessoas; transforme a decisão em uma página revisável para comunicação. Envie o artefato a um colega e pergunte: “o que aqui você não consegue verificar?”.
Esse é o próximo passo: faça o experimento de 30 minutos antes de abrir o tutorial de outro framework. Se surgir um problema técnico que realmente exija a ferramenta nova, ótimo — agora você tem um motivo. Se não surgir, você também ganhou uma resposta, só que sem baixar mais metade da internet para obtê-la.