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 é:

1. 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.
2. Ficar 1–2 anos montando o Lego da plataforma “definitiva”.
3. Entregar algo que exige semanas de ramp-up para fazer o básico.
4. 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:

1. Que problemas concretos a plataforma vai resolver nos próximos 6–12 meses?
2. Para quais times/personas isso é mais crítico?
3. Qual é a definição de sucesso (em termos de tempo, qualidade, custo)?
4. 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