Why your platform team shipped nothing this quarter

I watched a platform team demo last week. Fourteen months of work. Three engineers. A Series C company with 80 engineers waiting for the golden path.

The demo was impressive. Backstage, fully configured. Service catalog. Docs integration. CI/CD templates. The works.

Then I asked: “How many teams are using it?”

Silence.

“Two,” the tech lead finally said. “Sort of. They still deploy the old way when it breaks.”

They built a platform. Nobody used it.

The golden path that nobody walks

I asked to see what deploying a service actually looked like. They pulled up their “simplified” Helm chart template.

# "Golden path" template - simplified for developer experience
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.service.name }}
  namespace: {{ .Values.namespace | default "default" }}
  labels:
    app.kubernetes.io/name: {{ .Values.service.name }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/version: {{ .Values.image.tag | default .Chart.AppVersion }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
    platform.company.io/team: {{ .Values.team | required "team is required" }}
    platform.company.io/tier: {{ .Values.tier | default "standard" }}
spec:
  replicas: {{ .Values.replicas | default 2 }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Values.service.name }}
  template:
    metadata:
      annotations:
        prometheus.io/scrape: {{ .Values.metrics.enabled | default true | quote }}
        prometheus.io/port: {{ .Values.metrics.port | default 9090 | quote }}
        vault.hashicorp.com/agent-inject: {{ .Values.vault.enabled | default false | quote }}
        # ... 40 more lines of annotations
    spec:
      serviceAccountName: {{ .Values.serviceAccount.name | default "default" }}
      containers:
      - name: {{ .Values.service.name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port | default 8080 }}
        env:
        {{- range $key, $value := .Values.env }}
        - name: {{ $key }}
          value: {{ $value | quote }}
        {{- end }}
        # ... another 80 lines of resource limits, probes, sidecars

This was the simplified version. The “advanced” template was 400 lines.

I looked at the engineers who were supposed to use this. Their faces said everything.

How it got here

The platform team didn’t start with 400 lines of YAML. They started with a clean abstraction.

Then the payments team needed Vault integration. The ML team needed GPU scheduling. The legacy team needed ECS support because they couldn’t migrate yet. Someone asked for canary deployments. Someone else needed custom sidecars.

Every request was reasonable. Every addition made sense in isolation.

Nobody noticed they’d built a monster.

The politics

I’ve never seen a platform fail for technical reasons. It’s always politics.

The platform team built what they thought engineers needed. They never asked. When they did ask, they asked the team leads, not the people writing code every day.

Team leads said “we need flexibility.” They meant “I don’t want to be blocked.” What the ICs actually needed was “just deploy my service, I don’t care how.”

The platform team optimized for the 20% of weird edge cases. Meanwhile, 60 engineers were still writing raw Kubernetes manifests by hand because the golden path was too complicated to learn.

The abstraction problem

Here’s what nobody admits.

Your developers don’t want to understand Kubernetes. They want to ship features. Every hour they spend debugging Helm template syntax is an hour they’re not building product.

The platform team was supposed to hide this complexity. Instead, they added another layer on top. Now engineers need to understand Kubernetes AND the platform’s opinions about Kubernetes.

That’s not abstraction. That’s accretion.

What actually works

The platform teams I’ve seen succeed do something different. They ship something small that works. They watch engineers use it. They fix the friction. Then they add the next thing.

They don’t build for the edge cases. They tell the edge cases to wait.

They’re not afraid to say no. “We don’t support that yet” is a complete sentence. It’s better than supporting everything badly.

And they treat adoption like a product metric. If engineers aren’t using the platform, that’s the platform’s fault. Not the engineers’.

The uncomfortable truth

Your platform team isn’t failing because they’re bad at their jobs. They were set up to fail.

Spotify has hundreds of engineers working on Backstage. You have three. That’s not a fair fight.

Stop pretending it is.

---

If you’re dealing with platform complexity, I wrote about related observability traps in my OTel pitfalls guide. The instrumentation patterns apply whether you build or buy.

— Youn