You’re not a platform team if you’re just managing infrastructure

Calling it a platform engineering team doesn’t make it one. Learn what really defines a platform team and why managed infrastructure just doesn’t scale.

Artem Lajko

Platform Engineer @ iits-consulting

•

Published on

June 11, 2025

Fig.0: The matrjoschka effect: Same job, new label

These days, it’s trendy to rename roles. Look at LinkedIn and you’ll see people changing titles like:

System Engineer → Cloud Engineer → DevOps Engineer → Platform Engineer

But frequently the actual work stays the same, only the tools change. It used to be Linux VMs, now it’s Kubernetes and containers.

In some cases, this works just fine. But when it comes to platform engineering, the impact of mistakes is much bigger. Many teams claim to offer self-service platforms, but ignore what happens after setup: the infamous Day-2 Operations.

In practice? Same role, same responsibilities - just with Kubernetes instead of Linux VMs. Because the world changes.

Yes, some automation is added. Yes, GitOps is used. But at its core, the team still provisions infrastructure and runs it themselves. The developers rely on them for every update, config change, or new database request.

This is not platform engineering. This is managed infrastructure - and it doesn’t scale (trust me, I failed, too, at this point).

A platform is easy to build, hard to run

From my own experience, building or buying a platform is the easy part. But what you get is usually just a raw skeleton. And most enterprises are not greenfield startups.

They have:

Their own data centers
Long-established internal structures
And, of course, loads of shadow IT.

Fig. 1: The illusion of simplicity: “ If you can’t see it, you’re always secure!”

So you can’t just “rip and replace” everything. Many choose to say: “From now on, all new projects go to the platform.” In theory, that’s a good starting point, but only if self-service works and Day-2 Operations are handled.

Why do I emphasize Day-2 so much? Because here’s where things break down.

So, who is responsible when it breaks?

Fig. 2: Who Is responsible? The blame game in Day-2 failures

Let’s take a simple example:

The platform team provides a Terraform-based template that deploys managed Kubernetes.
The developer team deploys their services, but configures a faulty PodDisruptionBudget(PDB).
The platform team releases Template v2.
The developer uses it to upgrade the cluster.
The upgrade fails, due to the misconfigured PodDisruptionBudget.

Now… who’s to blame? That’s the exact gray area where teams get stuck.

The platform team ends up firefighting, even though they didn’t cause the issue. And that’s exactly the problem: you’re responsible for something you don’t control. This model doesn’t scale.

What you’re actually doing: Managed infrastructure

Fig. 3: Managed Infrastructure Team — Provision, operate, repeat

This is how most so-called platform teams work in practice:

A new project comes in.
The team provisions cloud resources using Terraform modules: Kubernetes, DBs, networking, DNS.
Then, they use Helm + GitOps (Argo CD) to deploy common third-party tools: external-dns,cert-manager,ingress-nginx, etc.
They either: Provide a separate Argo CD instance, or enable multi-tenancy (e.g., repo sharding and Application pointers).

For teams who’ve worked in Kubernetes for 5+ years, this will feel familiar.

But here’s the reality:

The infra team provides, operates, and upgrades the shared platform.
The dev team deploys apps via GitOps and handles their app lifecycle.
There’s shared responsibility, but with many gray areas:
Devs shouldn’t break monitoring with bad NetworkPolicies.
Devs shouldn’t misconfigure PodDisruptionBudgets that block upgrades.

In theory, the infra team could “make misconfiguration impossible.”
In practice, that’s extremely hard, especially as tooling complexity grows.

This setup can work well for:

20–30 developers
10–15 projects
2–4 infra engineers

But with 100+ developers? The team becomes a bottleneck.

What real platform engineering looks like

Fig. 4: Real platform engineering: Turning infra into a product

Now let’s look at an actual platform engineering team.

Yes, they also:

Write Terraform modules
Maintain Helm charts
Operate clusters.

But they don’t just offer raw infra. They provide a product: an Internal Developer Platform (IDP).

That includes:

A portal or API where devs can request a full stack (Kubernetes, DBs, DNS, etc.)
Pre-integrated tools: cert-manager, logging, monitoring, etc.
A real self-service experience.

The responsibilities change fundamentally.

The platform team:

Owns the IDP and its integrated services.
Ensures the platform is testable, stable, and maintainable.
Provides self-service, but doesn’t own what devs launch.

Developers:

Use the IDP to provision infra.
Are responsible for the services they spin up.
Must update, patch, and fix things they misconfigure.

It’s like using Google Cloud Platform (GCP): If you misconfigure a service and it blocks upgrades, you fix it. GCP might help - but you own it.

Why most teams fail: The missing product mindset

Fig. 5: Platform engineering salary vs DevOps salary

When you build a real Internal Developer Platform, you’re not just writing automation.
You’re not just assembling Terraform modules, Helm charts, GitOps templates, and custom pipelines for yourself.

You are building a product - for other people to use.

That means:

Accepting feature requests
Writing documentation
Creating testable releases
Maintaining compatibility
Monitoring service health
And handling bugs.

Yes, that sounds like overkill - but let me tell you something:

When I ask most Infra or Platform teams, “What’s your test coverage? What’s your release cadence?” The answer usually is: “Well… Infrastructure is different from software.”

And they’re right - testing infra is different. But that doesn’t change the fact that if you’re building a platform, it becomes a product , and it needs to be treated like one. And that’s why they struggle , or collapse under scale. So what’s the real problem?

In my experience, most people working as platform engineers today have never been software developers.

They don’t have experience:

Managing feature requests from real users
Working with bug trackers
Planning and maintaining product releases
Or thinking in terms of user behavior, edge cases, and UX.

This creates a huge gap. If you’re building a platform just for yourself or your small team, it’s relatively easy:

You know the stack
You can control changes
You govern everything end-to-end.

But once you open a portal and allow real self-service, users will do unpredictable - and sometimes crazy - things.

As a developer, you’re used to that. But for infra people turned platform engineers, it’s new, and often overwhelming.

In the old world, the platform team owned the castle: They made the rules, controlled the playground, and ensured compliance.

Now, they just build the gate, with clear boundaries, and let others build their own playgrounds. That’s not just scary for some organizations. It’s genuinely hard to manage, govern, and define where responsibility ends.