“DevOps is not a team. DevOps is not a tool. DevOps is a cultural and professional movement.” — Gene Kim, author of The Phoenix Project, The Unicorn Project, and The DevOps Handbook
In 2020, the biggest DevOps challenge was convincing enterprises to adopt CI/CD at all. In 2026, the challenge has inverted. Every serious software organization has a CI/CD pipeline. The problem is that CI/CD alone is no longer enough — and many enterprises have discovered this the hard way.
The symptom is always the same: your deployment frequency has plateaued. You ship to production 3-4 times per week but cannot break through to true continuous deployment. Your developers spend 30% of their time on infrastructure configuration, environment management, and “DevOps toil” instead of building product features. And your three DevOps engineers — who you hired at €110K each because the market is insane — are permanent bottlenecks because every team needs them for everything.
“The problem isn’t that we need more DevOps engineers. The problem is that we’ve made DevOps a dependency instead of a capability.” — Charity Majors, CTO of Honeycomb and co-author of Observability Engineering
The DevOps Maturity Model: Where Is Your Organization?
Level 1: Manual Operations (The Basement)
Deployments are manual SSH sessions. Infrastructure changes require tickets to an ops team. Environment provisioning takes days. Rollbacks involve praying.
Prevalence in 2026: Roughly 15% of enterprises — mostly legacy manufacturing, government, and healthcare organizations.
Level 2: CI/CD Implemented (Table Stakes)
Automated build, test, and deployment pipelines exist. Infrastructure is partially codified. Developers can trigger deployments through merge requests. Basic monitoring is in place.
Prevalence in 2026: ~50% of enterprises sit here. They have adopted the tools but have not changed the organizational model.
Level 3: Platform Engineering (The Next Frontier)
An Internal Developer Platform (IDP) abstracts away infrastructure complexity. Developers provision environments, deploy services, and manage configurations through a self-service portal — without needing to understand Kubernetes, Terraform, or cloud provider specifics.
Prevalence in 2026: ~25% of enterprises have reached genuine platform maturity as defined here, though a broader 55% report having started building platform engineering capabilities in some form (Puppet’s 2025 State of DevOps Report). That gap between “started” and “matured” is where the velocity difference between top-performing and average engineering organizations becomes a chasm.
“Platform engineering is what DevOps was supposed to be all along: infrastructure that serves developers instead of the other way around.” — Gregor Hohpe, author of The Software Architect Elevator and Enterprise Integration Patterns
Level 4: Developer Experience as Product (Elite)
The platform team operates like a product team. They conduct developer satisfaction surveys, track “time from idea to production” as their North Star metric, and iterate on the IDP based on developer feedback. Cognitive load on development teams is systematically measured and reduced.
Prevalence in 2026: ~10% of enterprises. These are the organizations shipping 50-100x more frequently than their Level 2 competitors.
The Internal Developer Platform: What It Actually Looks Like
An IDP is not a single product you buy. It is an integrated experience layer built on top of your existing infrastructure:
The key metric: When a developer joins your company, how long does it take them from “first day” to “first production deployment”? At Level 2 organizations, this takes 2-4 weeks. At Level 4, it takes 1-3 days.
The ROI of Platform Engineering
Puppet’s 2025 State of DevOps Report provides hard numbers:
“Elite performers in DevOps deploy 973 times more frequently than low performers, with 6,570 times faster time to recover from an incident. The difference is not talent — it is tooling and organizational design.” — Dr. Nicole Forsgren, co-author of Accelerate and creator of the DORA metrics
The Team Topologies Framework: Where a Platform Team Actually Fits
Most enterprises that fail at platform engineering do not fail on tooling. They fail on org design — they build an Internal Developer Platform and then bolt it onto an organizational chart that was never designed to support it. The most widely adopted framework for getting this right comes from Matthew Skelton and Manuel Pais’s book Team Topologies, which defines four fundamental team types and the interaction modes between them.
Skelton and Pais define three interaction modes that determine whether a platform succeeds or becomes another bottleneck: collaboration (teams work closely together, typically early in a platform capability’s life), X-as-a-Service (the platform team provides something stream-aligned teams consume with minimal friction — the target state for a mature IDP), and facilitating (one team helps another learn or unblock, typically the enabling team’s mode).
The mistake most enterprises make: they keep the platform team in permanent collaboration mode — fielding Slack requests, manually provisioning environments, joining every sprint planning session — instead of investing in the self-service tooling that lets the relationship graduate to X-as-a-Service. A platform team stuck in collaboration mode with more than 3-4 stream-aligned teams becomes the exact bottleneck platform engineering was supposed to eliminate. The fix is not more platform engineers; it is treating “graduate this capability to self-service” as a first-class backlog item, not an afterthought once the collaborative version already works.
Building Your Platform Team
A platform team is not the same as a DevOps team renamed. It is a product team whose customers are your developers.
Staffing model for a 50-200 person engineering organization:
Critical mistake to avoid: Do not staff your platform team entirely with infrastructure engineers. The best IDPs are built by engineers who understand product thinking — because the developer experience IS the product.
Why Manifera Builds DevOps Into Every Engagement
At Manifera, we do not treat DevOps as an add-on service. Every application we build ships with:
- Terraform-based infrastructure — reproducible, version-controlled, provider-portable
- GitHub Actions CI/CD pipelines — automated testing, security scanning, and deployment on every merge
- ArgoCD-based GitOps — declarative deployment with automatic rollback on failure
- Grafana + Prometheus monitoring — out-of-the-box observability from Day 1
- Environment parity — development, staging, and production environments that behave identically
Our Amsterdam architects design the DevOps architecture. Our Vietnam and Singapore teams implement it. The client receives not just working software, but a working engineering platform.
FAQs
How much does it cost to build an Internal Developer Platform? (Scenario: CTO Building Business Case for Board)
For a 50-200 person engineering organization, expect an initial investment of €200,000-€400,000 over 6-12 months to build the core IDP (service catalog, environment management, deployment orchestration, observability). Annual maintenance runs €100,000-€200,000 including platform team salaries. The ROI calculation is straightforward: if your 100 developers each spend 30% of their time on infrastructure toil at an average fully-loaded cost of €120,000/year, that toil costs €3.6M/year. Reducing it to 10% saves €2.4M annually — a payback period of 2-3 months on the initial investment.
What is the difference between DevOps Engineers and Platform Engineers? (Scenario: VP Engineering Restructuring Teams)
DevOps Engineers typically operate as shared resources who handle infrastructure requests from development teams — provisioning environments, debugging deployment failures, managing Kubernetes clusters. Platform Engineers build self-service tools and abstractions that eliminate the need for those requests entirely. The analogy: a DevOps Engineer is a taxi driver who takes you where you need to go. A Platform Engineer builds the subway system so you never need a taxi. The organizational shift is from DevOps-as-a-service-desk to DevOps-as-a-product-team.
Should we buy a platform (Humanitec, Port) or build our own IDP? (Scenario: Platform Team Lead Evaluating Options)
Start with open-source Backstage (maintained by Spotify, adopted by 3,000+ companies) as your developer portal foundation. Layer managed services on top for specific capabilities — Humanitec for infrastructure abstraction, ArgoCD for deployment, Grafana Cloud for observability. Building a fully custom IDP from scratch is only justified if you have 500+ engineers and genuinely unique infrastructure requirements. For 50-200 engineer organizations, a curated combination of open-source and managed tools delivers 90% of the value at 20% of the cost of a custom build.
How do we measure DevOps performance? (Scenario: Engineering Manager Reporting to C-Suite)
Use the four DORA metrics, created by Dr. Nicole Forsgren and validated across 36,000+ organizations: Deployment Frequency (how often you deploy to production), Lead Time for Changes (time from code commit to production), Change Failure Rate (percentage of deployments causing incidents), and Mean Time to Recovery (time to restore service after an incident). Track these monthly and benchmark against Puppet’s annual State of DevOps Report. Additionally, track Developer Satisfaction (quarterly survey, target 75+/100) and Time Spent on Toil (target below 15% of engineering hours).
Can Manifera help transition our existing DevOps to a Platform Engineering model? (Scenario: Enterprise CTO With Legacy CI/CD)
Yes. We approach this as a phased transformation. Phase 1 (Weeks 1-4): Audit your current CI/CD pipelines, infrastructure tooling, and developer workflows to identify the highest-friction bottlenecks. Phase 2 (Weeks 5-12): Implement quick wins — typically environment self-service, standardized service templates, and unified observability — that demonstrate immediate developer velocity improvement. Phase 3 (Weeks 13-24): Build the full IDP layer with service catalog, infrastructure abstraction, and automated compliance checks. Our Amsterdam architects design the platform strategy and our Vietnam teams implement the tooling, giving you Level 3 Platform Engineering capability at 40-60% below the cost of building an in-house platform team in the Netherlands.
How does Team Topologies help us decide who owns the platform? (Scenario: VP Engineering Redesigning Org Chart Around a New IDP)
Team Topologies (Matthew Skelton and Manuel Pais) gives you a vocabulary for the decision instead of an ad-hoc org chart reshuffle. Your product-delivery squads should be stream-aligned teams — they own a business outcome end-to-end and consume the platform, they do not build it. The platform team’s sole customer is those stream-aligned teams, and its success metric is developer self-service adoption, not ticket-resolution speed. If a specialist domain (fraud detection, a media pipeline) has knowledge too deep for a stream-aligned team to hold, it becomes a complicated-subsystem team that also consumes the platform rather than being folded into it. The single most common org-design mistake: leaving the platform team permanently in “collaboration” mode — fielding one-off requests via Slack — instead of funding the self-service tooling that lets the relationship graduate to “X-as-a-Service,” which is what actually removes the platform team as a bottleneck.
Suggested Posts
How useful was this post?
Share it with your friends
Get our latest articles here!
Thank you for subscribing to our blog!
Do you have any questions?
Help us improve the content of this Insightful blog by asking us questions. Manifera's team of experts will help you answer these questions as soon as possible.
