Como eu comecei a pensar em platform engineering antes de saber que tinha esse nome
Antes de conhecer o termo, já estava fazendo o trabalho: reduzindo o atrito para outros devs, construindo ferramentas internas, abstraindo complexidade. Só faltava o nome.
Em 2022, comecei a notar um padrão no meu trabalho: as tarefas que mais me engajavam não eram features para o usuário final. Eram ferramentas para os outros devs do time.
Automatizar o processo de setup de ambiente local. Criar um template de serviço que novos projetos podiam usar como ponto de partida. Documentar como fazer deploy de forma que qualquer pessoa do time conseguisse fazer sem me perguntar. Configurar alertas para que problemas em produção fossem visíveis para todo mundo, não só para quem tinha acesso ao servidor.
Eu não tinha nome para isso. Chamava de "devops" quando precisava explicar, mas sabia que não era exatamente o que DevOps queria dizer.
Alguns meses depois, li sobre platform engineering pela primeira vez. A definição que ficou comigo: plataforma interna é um produto cujos usuários são os outros desenvolvedores da empresa.
Isso clarificou muito. Quando você constrói uma feature para um usuário externo, você entende o problema do usuário, constrói uma solução, coleta feedback, itera. Quando você constrói infraestrutura e ferramentas internas, o raciocínio é o mesmo — exceto que seus usuários são seus colegas de time.
Developer Experience é User Experience para desenvolvedores.
O que mudou na minha forma de trabalhar quando entendi isso:
Antes, quando alguém do time me pedia ajuda para fazer deploy, eu ajudava. Depois que incorporei o mindset de plataforma, comecei a me perguntar: por que essa pessoa está me pedindo ajuda? O que está faltando para que ela faça sozinha? Como eu posso construir algo que elimine a necessidade de me pedir ajuda?
A diferença é entre resolver um problema e resolver a classe de problemas.
Um engenheiro de plataforma resolve a classe de problemas. Cria o runbook, automatiza o processo, reduz o número de decisões que um dev precisa tomar para completar uma tarefa comum.
O lado difícil: plataforma interna não tem usuários gritando por features. Seus colegas raramente vêm até você com requirements claros para a developer experience. Eles simplesmente sofrem em silêncio com processos ruins e encontram workarounds.
Aprendi a identificar os sinais: o que as pessoas perguntam repetidamente? Qual processo tem documentação desatualizada? Onde as pessoas passam tempo fazendo a mesma coisa manualmente que poderia ser automatizada?
Esses são seus backlogs de plataforma.
Não é glamoroso. Nenhum usuário final vai agradecer pelo novo template de serviço que você criou. Nenhuma feature visivelmente nova vai no changelog. O valor aparece de forma difusa — menos tempo de onboarding para novos devs, menos incidentes causados por configuração errada, menos perguntas repetitivas no Slack.
Mas esse é exatamente o tipo de trabalho multiplicador que define o impacto de um engenheiro sênior. Você para de fazer o trabalho e começa a construir as condições para que o trabalho seja feito melhor por todos.
Quando vi vagas de Platform Engineer pela primeira vez, reconheci o trabalho. Era o que eu já estava fazendo de forma não-estruturada. A diferença era que empresas maiores tinham times inteiros para isso — e estavam pagando bem por engenheiros que entendiam tanto de infra quanto de developer experience.
Isso me deu um vocabulário para o que eu queria construir na minha carreira. E vocabulário importa: quando você sabe nomear o que faz, consegue encontrar os outros que fazem o mesmo, aprender com eles, e navegar para oportunidades onde esse trabalho é valorizado.
Essa semana: pensa no time em que você está. Qual tarefa repetitiva consome mais tempo de outros devs? O que você poderia construir, documentar, ou automatizar que eliminaria essa fricção? Esse é o seu primeiro projeto de platform engineering — independente do seu título.