Por que tanta Engenharia de Plataforma falha (e o que ninguém conta pra você)

Muita empresa hoje tem “engenharia de plataforma”, IDP, portal interno lindo, YAML pra todo lado… E, ao mesmo tempo, mais incidentes, mais custos e um exército de devs tentando fugir da tal plataforma.

Se isso está acontecendo, não é falta de talento técnico. É porque a plataforma virou mais um problema — não a solução.

Quero compartilhar o que tenho visto na prática, ao longo de mais de 25 anos liderando times de engenharia, infraestrutura, plataforma, arquitetura e operações em empresas de software e grandes organizações, para que seu time não repita os mesmos erros.

1. Engenharia de Plataforma não é projeto — é produto

Um dos maiores venenos da engenharia de plataforma é tratar a iniciativa como projeto com começo, meio e fim:

“Vamos construir a plataforma em 12 meses. Depois ela se paga sozinha.”

Na prática, isso gera:

Roadmap que morre junto com o projeto.
Time que é desmontado ou realocado quando o “projeto acaba”.
Plataforma que envelhece rápido e vira legado em 1 ou 2 anos.

Plataforma saudável se comporta como produto:

Tem problem statement claro:
Tem dono (PM de Plataforma / Tech Lead com mentalidade de produto).
Tem roadmap vivo, revisado com base em feedback e métricas.
Tem budget recorrente, não verba de “projeto especial”.

Se no seu contexto:

não há dono claro,
não há backlog priorizado,
e tudo termina no “go-live”,

então você não tem Engenharia de Plataforma. Tem um projeto de automação caro condenado a virar legado.

2. Construir para o time de plataforma, não para os devs

Outro erro recorrente: plataforma desenhada a partir do que o time de plataforma acha que os devs precisam.

Padrão que vejo o tempo todo:

Reuniões internas, debates arquiteturais profundos…
Muito pouco tempo gasto ouvindo squads de produto e times consumidores.
Releases cheios de “capabilities” e termos bonitos – com pouca aderência à dor real.

Resultado previsível:

A plataforma vira “infra com marca” e um portal bonito em cima.
O dev olha e pensa: “Legal, mas ainda preciso abrir chamado pra tudo ou entender 12 conceitos novos só pra subir uma API.”
Time de plataforma reclama de “baixa adoção” e começa a empurrar uso via decreto.

Plataforma que funciona nasce de conversas desconfortáveis, porém simples, com perguntas como:

Qual é hoje o maior atrito pra você subir uma nova feature em produção?
Onde você mais perde tempo no dia a dia?
Se eu pudesse automatizar uma coisa na sua jornada, qual seria?
O que hoje só o time de infraestrutura consegue fazer e que você gostaria de resolver sozinho?

É a partir dessas respostas que surgem golden paths que as pessoas querem seguir, não trilhos que elas são obrigadas a usar.

3. Obsessão por ferramenta e overengineering

Vamos ser honestos: nós, de engenharia, adoramos brinquedo novo. Kubernetes, service mesh, GitOps, policy engine, AI no pipeline, portal, scorecards, tudo ao mesmo tempo.

O problema não é a tecnologia. O problema é esquecer o porquê:

“Por que estamos construindo essa plataforma agora?”
“Qual problema concreto ela resolve no próximo trimestre?”
“Quem é o primeiro time que vai de fato ganhar tempo e dormir melhor por causa dela?”

O anti-padrão clássico de falha é:

Adotar uma arquitetura nível hyperscaler em uma organização que não tem nem volume de serviços, nem maturidade, nem equipe suficiente para isso.
Ficar 1–2 anos montando o Lego da plataforma “definitiva”.
Entregar algo que exige semanas de ramp-up para fazer o básico.
Descobrir que os times de produto seguiram a vida por fora, com seus próprios scripts e jeitos de fazer.

Alguns sinais de que você está caindo nessa armadilha:

Seu backlog tem mais itens de plumbing técnico (clusters, CRDs, integrações, operadores) do que melhorias na jornada do dev.
Para um dev subir um serviço simples, ele precisa entender Kubernetes, YAML, políticas internas, naming conventions, secrets, IAM, e mais 5 siglas.
A maior parte da capacidade do time de plataforma está em manter a própria plataforma de pé, não em melhorar o fluxo de entrega de produto.

Às vezes, o que o seu contexto precisa não é de um IDP completo, mas:

alguns templates de pipeline bem feitos,
um conjunto de ações reutilizáveis de CI/CD,
um bom padrão de observabilidade pronto,
e um provisionamento simples de ambientes.

Comece pequeno, resolvendo um ponto de dor real, e só então evolua.

4. Subestimar cultura, modelo de time e gestão de mudança

Engenharia de Plataforma é vendida como disciplina altamente técnica. Mas, no dia a dia, o que derruba ou sustenta a iniciativa é gente, política, cultura e medo.

Três fontes de sabotagem silenciosa:

4.1. Medo de “caixa preta”

Desenvolvedores experientes olham pra plataforma e pensam:

“Se eu não entender o que está por baixo, sou eu que vou pagar o preço quando algo quebrar.”

Se a sua plataforma comunica pouco, compartilha pouco e trata tudo como abstrato demais, a sensação é de perda de controle e aumento de risco.

Como isso aparece:

Times evitando usar o caminho padrão porque “não sabem debugar”.
Rejeição a padrões de segurança porque parecem “restrições arbitrárias”.
Gente boa demais migra para times que não dependem da plataforma, por não confiar nela.

4.2. Plataforma como “balde de tudo”

Outro erro é transformar a plataforma em depósito de problemas que ninguém quer assumir:

Tudo que é ferramenta, DevOps, CI, cloud, acesso, observabilidade… “joga na plataforma”.
Times de produto não sabem se a plataforma é parceira ou porteira.
O backlog vira lista infinita de demandas operacionais e tickets reativos.

Isso mata qualquer chance de estratégia de produto. O time vive em “modo bombeiro”, apagando incêndio de curto prazo.

4.3. Gestão de mudança fraca (ou inexistente)

Um erro gravíssimo: subestimar a mudança de comportamento exigida.

Exemplos muito comuns:

Novas formas de criar serviços, monitorar, fazer rollback, abrir incidentes.
Mudança no modelo de responsabilidade: “time é dono do serviço em produção”.
Novas métricas, novos rituais, novos acordos entre times.

Se isso não vem acompanhado de:

comunicação clara,
treinamento,
acompanhamento próximo,
e espaço para feedback,

a plataforma vira símbolo de mais burocracia – e não de fluidez.

5. Não medir (nem contar) o valor criado

Plataforma compete por orçamento com produto, segurança, dados, marketing, expansão comercial. Se você não consegue provar valor, cedo ou tarde o budget some.

Dois erros se repetem:

5.1. Métricas de vaidade

Métricas típicas que não convencem ninguém no C-level:

“Número de serviços cadastrados na plataforma.”
“Quantidade de logins no portal.”
“Quantos repositórios estão usando nosso template X.”

São indicadores de uso, não de impacto.

5.2. Ausência de narrativa de negócio

A pergunta que importa para o board é simples:

“O que essa plataforma mudou no nosso negócio?”

Você deveria ser capaz de responder com frases como:

“Reduzimos o tempo médio para subir um novo serviço de 3 semanas para 3 dias.”
“Caímos de X incidentes de produção por mês para Y, em sistemas que usam o caminho padrão.”
“Cortamos Z% do custo de infraestrutura em workloads padronizados.”
“Diminuímos o retrabalho em pipelines, reduzindo falhas em deploy em N%.”

Para isso, a engenharia de plataforma precisa:

Fazer baseline antes de começar (como era antes?).
Definir hipóteses claras (“Implementando esse fluxo, esperamos reduzir o tempo X em Y%”).
Monitorar a jornada do dev, não apenas a saúde da infra.

Quem não mede vira “centro de custo técnico” e, em tempos de corte, vira linha de Excel a ser reduzida.

6. Bônus: migrações e adoção “na marra”

Mesmo com uma boa plataforma, muita iniciativa morre em migrações mal conduzidas:

Prazos arbitrários (“até fim do trimestre todo mundo tem que migrar”).
Comunicação genérica (“todo mundo que usa Produto X vY precisa migrar”) sem clareza de impacto.
Nova jornada pouco testada, que quebra quando pega tráfego real.
“Fiscal da migração” correndo atrás de squad pra squad com checklists.

Esse combo queima a boa vontade dos times, gera trauma organizacional e fixa a percepção:

“Plataforma = iniciativa que complica minha vida.”

Migração bem-sucedida é tratada como produto em si:

Escopo claro de quem entra na primeira onda.
Incentivos alinhados (ex.: simplificar suporte, reduzir on-call do time que migra).
Acompanhamento próximo, ajuste fino rápido e humildade pra reconhecer o que não funciona.

7. O que você pode fazer amanhã: um mini playbook

Algumas ações práticas que líderes de engenharia e plataforma podem começar já:

7.1. Clarifique o “porquê” em 1 página

Responda, por escrito:

Que problemas concretos a plataforma vai resolver nos próximos 6–12 meses?
Para quais times/personas isso é mais crítico?
Qual é a definição de sucesso (em termos de tempo, qualidade, custo)?
O que fica fora de escopo por enquanto?

Se você não consegue responder isso de forma simples, não comece novo trabalho de plataforma. Pause e volte pra estratégia.

7.2. Escolha um “lighthouse team” e um fluxo crítico

Em vez de tentar atender todos os squads de uma vez:

Escolha 1–2 times com alto impacto e disposição para parceria.
Mapeiem juntos a jornada completa (da ideia ao deploy em produção).
Identifiquem os pontos de maior atrito e resolvam primeiro esses pontos.

Isso cria casos reais de sucesso para mostrar internamente e aprender rápido.

7.3. Trate a plataforma como produto

Nomeie um dono (PM / Tech Lead com visão de produto).
Tenha roadmap público, com temas, problemas e não apenas “entregas técnicas”.
Estruture rituais com usuários: demos, sessões de feedback, office hours.

7.4. Equilibre padrão e autonomia

Defina claramente:

O que é obrigatório (segurança, observabilidade, governança).
O que é recomendado, mas opt-out com responsabilidade.
O que é livre, onde os times podem experimentar.

Comunicação clara sobre esses níveis reduz medo e resistência.

7.5. Meça impacto, não só atividade

Crie um painel simples com poucos indicadores:

Lead time para subir um novo serviço.
Tempo para provisionar um ambiente.
Taxa de falha em deploy entre quem usa o caminho padrão x quem não usa.
Satisfação do dev com a plataforma (NPS ou algo simples).

E conte a história regularmente para o C-level e para os próprios times.

Conclusão: Engenharia de Plataforma é escolha estratégica, não hype

Engenharia de Plataforma não é sobre ter o portal mais bonito, o cluster mais avançado ou o stack mais moderno. É sobre tirar peso das costas dos times, reduzir complexidade acidental e acelerar o que importa pro negócio.

Quando falha, quase nunca é por falta de gente boa. É por falta de clareza, estratégia de produto, gestão de mudança e foco obstinado no problema certo.

Se você se viu em alguns desses cenários, isso não é sinal de fracasso pessoal. É um convite para ajustar a rota antes que a plataforma vire mais um legado caro.

Vamos aprofundar essa conversa?

👉 E você? Onde já viu (ou viveu) Engenharia de Plataforma falhar? Quais desses erros são mais comuns na sua realidade — e quais eu não mencionei aqui?

Comenta a sua experiência, discorda, complementa, traz casos reais. Essa troca é o que faz a comunidade de engenharia ficar mais madura e menos refém de modas.

Se esse conteúdo fez sentido pra você, 🔔 me siga aqui lá LinkedIn para mais insights sobre Engenharia de Plataforma, SRE, DevOps, Cloud e Liderança de Times de Engenharia.

🧩 Postei no Linkedin também. Nos primeiros comentários deste artigo lá, deixei um framework com 10 perguntas para você avaliar a saúde da sua iniciativa de plataforma com o seu time.

#EngenhariaDePlataforma #PlatformEngineering #DevOps #SRE #DeveloperExperience #LiderançaDeEngenharia