The pitch is compelling. Build an Internal Developer Platform. Give developers self-service access to infrastructure. Golden paths for deployments. Service catalogs. Automated provisioning. Developers focus on code. Platform team handles the rest.
Every DevOps conference in 2025–2026 has platform engineering as a keynote. Backstage, Port, Humanitec — the tooling is mature. The pattern is established. The promise is clear.
But there’s a question that doesn’t get asked often enough during platform engineering conversations: when the self-service platform provisions infrastructure, deploys services, and configures monitoring — who owns what happens next? Who gets woken up at 3 AM when the self-service deployment causes an outage? The platform team? The developer who deployed? The on-call engineer who wasn’t involved in either?
The answer reveals a gap that platform engineering alone doesn’t close.
Two Different Problems
The clarity missing from most platform engineering conversations is the distinction between two separate problems:
Problem 1: Developer Experience (DX)
- How fast can a developer go from “I need a database” to “I have a database”?
- How standardized are deployment patterns across the organization?
- How much cognitive load does a developer carry about infrastructure?
- How many tickets does a developer file per week to get things done?
Problem 2: Operational Accountability
- When something breaks in production, who detects it?
- Who diagnoses and remediates?
- Who ensures the system is reliable, available, and improving?
- Who carries the pager?
Platform engineering solves Problem 1 brilliantly. It reduces cognitive load, standardizes patterns, and accelerates developers. But it is frequently pitched — and perceived — as solving Problem 2 as well.
Why it doesn’t: A self-service portal that lets developers deploy services doesn’t own what happens after deployment. The golden path gets the service into production. It doesn’t ensure the service stays healthy in production. The platform team builds the platform. They typically do not operate every service that runs on it.
The gap: Platform engineering creates better infrastructure interfaces. Operational accountability requires someone who owns infrastructure outcomes. These are related but different functions — and most organizations discover the distinction during their first major incident after adopting an IDP.
The Talent Assumption (Again)
If this pattern sounds familiar, it should be.
In the monitoring SaaS world, tools were architected for organizations with experienced SREs — the 5% who could extract full value. The other 95% struggled with self-service monitoring because they didn’t have the operational depth to make it useful. That’s the responsibility boundary problem applied to tooling.
Platform engineering is following the same path.
Who platform engineering works for:
- Organizations with 5+ platform engineers who can build and maintain the IDP
- Teams with established SRE practices — on-call rotations, incident response, post-mortems
- Companies where “developer self-service” means “developer responsibility” and developers accept that trade-off
Who it doesn’t work for (yet):
- Series B companies with 1–2 DevOps/platform engineers trying to build an IDP while also running operations
- Teams where developers deploy via the platform but expect someone else to handle production issues
- Organizations that adopted platform engineering to reduce operational burden but didn’t change who owns operational outcomes
The 95% problem: Most companies adopting platform engineering don’t have dedicated platform teams. They have 1–2 engineers who are simultaneously building the platform, operating existing infrastructure, managing on-call, and handling incident response. The IDP becomes another project on an already overloaded plate.
The result: the platform gets built. Half-configured. Developer adoption is partial because the golden paths don’t cover every case. And when things break, the same 1–2 people are still getting the 3 AM page — now with an additional system (the platform itself) to maintain.
This is the talent assumption repeating itself. Platform engineering assumes an organization has the operational maturity and dedicated staffing to both build the platform and operate the infrastructure that runs on it. For most companies at Series B scale, that assumption doesn’t hold.
The Complementary Model
This post is not anti-platform engineering. IDPs are genuinely valuable for developer experience. The argument is that platform engineering alone is half the solution.
What platform engineering provides:
- Self-service infrastructure provisioning
- Standardized deployment patterns (golden paths)
- Service catalogs and documentation
- Reduced cognitive load for developers
- Faster time from code to production
What platform engineering doesn’t provide:
- 24/7 production monitoring and incident response
- Alert tuning and signal-to-noise management
- Root cause analysis and remediation during outages
- Post-mortem processes and continuous improvement
- Operational accountability — someone who owns production health
The complementary model:
| Function | Provided By |
|---|---|
| Developer self-service | Platform engineering (IDP) |
| Deployment standardization | Platform engineering (golden paths) |
| Infrastructure provisioning | Platform engineering (automated) |
| Production monitoring | Operational accountability (managed) |
| Incident detection and response | Operational accountability (managed) |
| Alert quality and tuning | Operational accountability (managed) |
| Post-mortem and improvement | Operational accountability (managed) |
The key insight: Platform engineering makes infrastructure easier to use. Operational accountability makes infrastructure reliable to run. Both are needed. Conflating them leads to the “we built a platform but still get 3 AM pages” problem.
This is the same pattern from AIOps: a technology that improves one part of the operational chain gets positioned as solving the entire chain. The detection got better (AI). The developer experience got better (IDP). But someone still needs to own what happens when production is unhealthy.
The Right Sequence
For Series B companies considering platform engineering:
Option A (common, painful):
- Hire 1–2 platform engineers
- Start building IDP while also running operations
- IDP is half-finished because operational burden consumes the team
- 3 AM pages continue. Developer adoption is partial. Nobody’s happy
Option B (more effective):
- Outsource operational accountability to a managed service
- Platform engineers focus 100% on building the IDP — no operational interruptions
- IDP ships faster, with better quality, because builders aren’t fighting fires
- As the IDP matures, evaluate whether operational accountability comes in-house or stays managed
- Either way: the platform is built and operations are covered
The sequencing insight: Building a platform while simultaneously running operations is like renovating a restaurant while serving dinner. It’s possible, but everything takes longer and nothing is done well.
Option B separates the two problems. The platform team builds. The managed service operates. Neither function compromises the other. When the IDP is mature and developer adoption is strong, you can revisit whether to bring operations in-house — from a position of stability, not scramble.
Where Both Functions Fit
Platform engineering and operational accountability solve different problems. The best infrastructure organizations invest in both — and know the difference.
Vigil by IOanyT provides the operational accountability layer — production monitoring, incident response, and continuous improvement — so your platform engineers can focus on building the platform.
We handle the 3 AM pages. They build the golden paths.
