Elastic CPO: Standing on the (platform engineering) shoulders of giants

Developers today

These rising expectations have reshaped what it means to be a developer. The role now goes well beyond writing code. It includes managing infrastructure, ensuring security addressing operational issues. But this shift isn’t about asking developers to simply “do more” per se; it’s about enabling them to take full ownership of their software’s success, from development, through to delivery and day-to-day performance.

That’s where DevOps came in.

By breaking down traditional silos between development and operations, DevOps has allowed teams to take genuine end-to-end accountability. The model leads to faster releases, tighter feedback loops and ultimately, better user experiences – all because developers are equipped to build, run continuously improve their software. It’s this accountability that leads to faster delivery and better outcomes.

The DevOps Gap

But as DevOps became popularised, a new challenge emerged: how do you ensure developers are building with best practices not just best intentions? 

With DevOps seeing a shift to developers taking on greater responsibility for ops, on top of building new features, it was assumed they would be equipped to succeed. But in reality, most engineers haven’t been trained in infrastructure, monitoring, or security. They studied computer science, not incident response.

Yet today, we ask developers to configure CI/CD pipelines, manage alerting thresholds, interpret telemetry data own runtime security – often from scratch. That’s inefficient, unsustainable not to mention risky. To help them build with confidence and consistency at scale, they need the right tools and practices. 

Don’t suffer to scale

Platform engineering provides an answer.

While it isn’t a replacement for DevOps, it’s how we can make DevOps stand taller and more successful. It fills the gap between aspiration and execution by giving developers what they need to take true ownership of their software.

At its heart is the internal developer platform (IDP), a layer of tooling, best practices reusable components built and maintained by platform engineers. IDPs provide developers with paved paths, not blank slates. They include preconfigured CI/CD pipelines, infrastructure templates, observability dashboards, integrated security, all tuned to the needs of the organisation.

This creates what I call a “pit of success” really. Developers don’t have to invent systems or learn lessons the hard way. They’re given opinionated defaults based on industry and organisational best practices, which they can adopt, adapt scale.

Instead of starting from ground zero, developers are handed the tools to operate effectively from day one. Developers may not be ops engineers per se, but they are increasingly expected to take responsibility for – and ownership of – the operational issues surrounding their software. That sense of responsibility leads to higher-quality outcomes, faster incident response tighter feedback loops.

Consistency without bureaucracy

While some may worry that adding a layer like platform engineering could mean more bureaucracy or red tape, the opposite is true. It doesn’t introduce red tape. It simply removes inconsistency and needless reinvention. Without it, every team builds their own deployment scripts, monitoring solutions security controls. That leads to fragmented approaches, duplicated effort wasted time.

With platform engineering, best practices are baked into the tooling. Developers no longer need to ask, “What metrics should I track?” or “What alerts should I configure?”. Instead, they’re given templates that reflect expert knowledge can refine them over time to fit their needs. This isn’t about micromanagement. It’s about giving developers a foundation they can trust, so they can focus on building, not tackling operational headaches without the appropriate tools or support. When you combine that with observability, security automation all built into the platform, you enable teams to deliver faster with more confidence.

Making end-to-end practical

One of the most powerful benefits of an IDP is built-in observability. From a single pane of glass, developers can monitor the health of their services, analyse logs and metrics receive actionable alerts. As teams grow, dashboards and alerts can be customised to reflect evolving needs, while still aligning with the organisation’s shared standards.

The same is true for security. While IDPs don’t typically integrate directly with SIEMs, they can support consistent log collection and formatting through common tooling – making it easier for logs to flow into existing security pipelines. That way, developers can focus on building reliable, high-quality software, while internal IT security teams have the real-time data needed to ensure the hard work of app developers isn’t constrained by security bugs. 

This shift gives rise to true end-to-end ownership, where developers own their work from design to deployment, to day-two operations. Not in isolation, but with strong support, reusable assets a culture of enablement.

Clear paths, stronger ownership 

As an engineering leader, I care deeply about setting teams up for success. The truth is, as organisations decentralise and empower developers to move quickly with DevOps, the best practices haven’t always kept pace. 

Platform engineering changes that. It operationalises DevOps. It provides common foundations. It empowers developers to ship faster, more securely with greater consistency, without having to become experts in every adjacent discipline. Internal developer platforms are built by engineers, for engineers. They enable developers to stand on the shoulders of giants – not by reinventing the wheel, but by building confidently on well-tested, proven foundations. 

The end result?

Teams that move faster, software that’s more reliable an organisation that’s ready for whatever comes next.