Platform Engineering: The SRE investment that pays off
Engineering teams are getting slower as they scale. More developers, more services, more incidents.
Yet deployment frequency slows down and reliability suffers.
The culprit is rarely technical debt.
It is the manual, repetitive operational work that consumes engineering capacity without producing engineering value.
Platform engineering exists to solve this problem. And the data suggests most organizations have not yet made the investment.
The software engineering bottleneck nobody talks about
Google's SRE guidelines are direct: toil should consume no more than 50% of any SRE's time. The rest should go to engineering work that reduces future toil or improves reliability.
In practice, Google's own teams average 33%, but outliers report 80% of their time consumed by manual work.
That 80% is pretty common.
Engineering teams managing cloud infrastructure without platform tooling spend an enormous amount of time on provisioning, access management, deployment pipelines, and incident triage. Every hour spent on those tasks is an hour not spent on features, reliability, or architectural improvement.
Gartner projects that platform engineering adoption will reach 80% of large engineering organizations by 2026. This shift is a response to a measurable productivity problem.
What platform engineering actually means
Platform engineering is not a rebranding of DevOps or an IT ticketing system with better branding. It is the practice of building internal developer platforms (IDPs), curated, self-service layers that give application developers everything they need to deploy, observe, and operate services without waiting on infrastructure teams.
The core concept is the golden path: an opinionated, production-ready route from code to running service. Developers who follow the golden path get automated provisioning, pre-configured security policies, integrated observability, and consistent deployment pipelines.
They do not need to understand Kubernetes internals, Terraform modules, or network policies.
The platform abstracts that complexity into decisions that were made once and maintained centrally. This matters for three reasons that everyone pays attention to:
Speed.
Self-service provisioning eliminates queues. Features that waited days for infrastructure tickets go live faster.
Reliability.
Standardized paths mean consistent configurations. Fewer snowflake environments means fewer production surprises.
Cost.
Centralizing operational tooling reduces the engineering hours spent maintaining one-off solutions across dozens of teams.
The CNCF's 2025 Platform Engineering Maturity Report reveals where organizations actually stand:
- 45.5% have dedicated platform teams that remain primarily reactive,
- only 13.1% have achieved the optimized, cross-functional ecosystem that platform engineering promises.
- 29.6% of organizations do not measure any platform success metrics at all.
Speed and reliability, together
The DORA 2024 State of DevOps Report provides the most rigorous quantification of engineering performance available. Elite engineering performers deploy 973 times more frequently than low performers, with 6,570 times faster change lead times.
With Claude Code and other tools in the picture, these numbers will increase even further.
Teams with mature internal developer platforms report 30–70% reductions in mean time to recovery (MTTR) after production incidents, because observability and runbooks are built into the platform rather than assembled during an outage.
Deployment frequency improves because developers operate within consistent environments that have already been tested and secured.
The financial case compounds over time. Each deployment bottleneck removed is engineering capacity freed for product work.
Each automated compliance check is an audit risk eliminated. Each standardized environment is a security incident prevented.
For organizations running 20 or more engineers on cloud infrastructure, the ROI calculation on a dedicated platform team becomes straightforward within 12 months.
The cloud layer matters more than you think
Internal developer platforms do not exist in isolation. They sit on top of infrastructure.
And the infrastructure layer has a significant impact on platform cost, flexibility, and lock-in.
Many organizations build their IDPs tightly coupled to managed services from a single hyperscaler: AWS EKS with IAM integration, Azure AKS with Entra ID, GCP GKE with Cloud Logging. This approach is fast to build but expensive to maintain and nearly impossible to migrate later.
The CNCF's research on Kubernetes managed services confirms that provider-specific integrations are the primary source of infrastructure lock-in in modern engineering stacks.
Cloud-neutral architecture solves this at the foundation. Platforms built on standard Kubernetes APIs, without proprietary networking, storage, or identity hooks, can run on Akamai Connected Cloud as effectively as on hyperscaler equivalents. The difference is cost and portability.
An AI analytics platform migrated to Akamai Connected Cloud with Maxima Consulting and achieved 35%+ monthly savings while maintaining identical performance benchmarks. The workload did not require hyperscaler-specific managed services. It required compute, storage, networking, and a standards-compliant Kubernetes environment. LKE provided all four, without proprietary lock-in and without egress fees.
We believe you should design your IDP against Kubernetes standards, not provider APIs. The infrastructure layer will change. The platform should not have to.
Avoiding the platform engineering trap
Organizations mid-way through platform adoption often see a temporary performance dip before results improve. Building an IDP requires engineering investment that does not immediately reduce operational load.
Teams are simultaneously maintaining existing infrastructure and building the platform intended to replace it. During this transition, toil doubles. Teams that do not plan for this window abandon the effort before the platform reaches the adoption threshold where it pays back.
There are two ways you can build an Internal Developer Platform:
- Work with someone who can do it for you. With clear deliverables, timelines, milestones and results.
- You treat your platform like a product, not a side project. This means it’s built with clear ownership and roadmap. You can’t rush things if you want to avoid burnout.
Across organizations, we see three patterns that make for a successful platform implementation:
User-centred design over completeness.
The most common failure mode is building a platform nobody wants to use. Golden paths work only if developers choose them. Start with the highest-friction workflow in your engineering org (typically environment provisioning or deployment pipeline setup) and eliminate that friction first. Expand from demonstrated value, not architectural ambition.
Metrics from day one.
The 29.6% of organizations that measure nothing cannot improve what they track. Define platform success metrics before launch: deployment frequency, MTTR, lead time for changes, developer satisfaction with self-service. Without measurement, platform investment is invisible to leadership and unjustifiable at budget cycles.
Incremental rollout over big bang.
Pilot with two to three teams who are willing to provide honest feedback. Treat those teams as design partners, not test subjects. Their friction becomes your platform backlog.
Platform engineering for engineering leaders
The platform engineering skills gap is real. A 56% shortage of engineers with combined platform, SRE, and cloud expertise is needed to build and operate mature IDPs.
Most mid-market organizations cannot hire their way out of this gap on their own timeline.
Managed SRE services offer an accelerated path. Rather than building from scratch, organizations with managed SRE partners get pre-built platform tooling, runbooks, and operational expertise from day one.
The internal team focuses on golden path design and developer experience, the highest-value work, while the managed layer handles infrastructure operations.
The business case is the same as platform engineering itself: buy back engineering time for work that compounds in value.
Operations that are predictable and repeatable belong on a managed service.
Engineering that is unique to your product belongs in-house.
