GitOps.dk

Why Most Platform Teams Fail

The hidden organizational problems behind Kubernetes initiatives.

GitOps.dk

In our experience, failed platform initiatives usually have healthy clusters. The pods were running, the dashboards were green, the pipeline passed. The failure was rarely in the technology; it was in the organisational assumptions wrapped around it.

The technology is rarely the problem

Kubernetes itself is rarely the hardest platform problem any more. Installing, upgrading and hardening it is demanding work, but it is known work, with mature tooling and a large body of practice behind it. What no amount of configuration settles is this: who is the platform for, who owns it, and what happens when the people who built it move on. Teams that cannot answer those three questions are building a liability with excellent uptime.

No product owner, no product

The pattern we see most often behind a failed platform is a platform run as a project: funded once, staffed temporarily, declared done. Platforms decay the moment they stop being owned. The pattern behind the ones that last is boring by comparison — a named owner with a roadmap, users they interview, and adoption numbers they answer for.

Building for engineers who never asked

Platform teams are staffed with infrastructure specialists, so platforms grow the features infrastructure specialists find interesting: another abstraction, another operator, another layer of flexibility. Meanwhile the product teams wanted one thing — a reliable, boring way to ship. Every feature nobody asked for adds cognitive load to the people the platform was meant to relieve.

  • Adoption is voluntary — if teams route around the platform, the platform is wrong, not the teams.
  • Golden paths beat golden cages: defaults with exits, not mandates without them.
  • Measure time-to-first-deploy for a new team, not feature count.

How to recover a failing platform

  1. 1.Stop feature work. Interview five product teams about what they route around.
  2. 2.Appoint a product owner with authority over the roadmap — not a committee.
  3. 3.Pick the single worst friction point and remove it end-to-end, publicly.
  4. 4.Publish adoption metrics and let demand pull the roadmap from there.
“Platforms do not fail at runtime. They fail in the org chart, months earlier, quietly.”

Turning these ideas into a platform?

For platforms where failure has consequences.

Start an Architecture Conversation