Should platform, SRE, and security merge into one function?
Back to Blog

Should platform, SRE, and security merge into one function?

Should platform, SRE, and security merge into one function?
Cristina Buenahora

Cristina Buenahora

VP, Strategic Initiatives

June 4, 2026

Platform, SRE, and security are three distinct functions in modern engineering orgs, each shaped by a different problem. SRE was the operations function's answer to scale: how to keep systems reliable when the systems get big. Platform answered a different problem: how to let developers ship without becoming infrastructure experts. Security drew the line on what could safely reach production.

That arrangement held for the better part of fifteen years. When humans wrote every line of code, three teams could draft separate guidelines, ship separate tools, and meet occasionally to negotiate the trade-offs between them. AI breaks that arrangement. A senior engineer with a coding agent now often ships in days what a team used to ship in weeks. Yet most engineering organizations report moving only about 20% faster overall. The individual speedup leaks out in coordination before it reaches production. AI-generated code removes latency, and trade-off discussions need to happen more frequently.

On a recent episode of the Braintrust podcast, Dinesh Sukhija, Director of Engineering at Okta, put the question directly:

"Maybe it's time to bring the teams together under one leadership now."

Cost shows up in the trade-offs that nobody owns

Reliability and cost are a single conversation. Every additional nine of availability has a cost. When SRE owns reliability and a separate FinOps function owns cost, the trade-off happens in a shared spreadsheet weeks after the architecture is committed.

Security and developer flow are the same. Guardrails that are too tight slow shipping; too loose, and credentials end up on GitHub. When security writes policy in isolation from the platform team that has to enforce it, the policy gets watered down, ignored, or routed around.

Observability and incident response can't really be pulled apart either. Service-level standardization makes incidents shorter: the same dashboard layout, the same SLO definitions, the same on-call runbook across every service mean less cognitive load when something breaks. When those standards live in three different orgs, no one team can hold them.

The tensions are old, but the frequency is new. A trade-off revisited every six weeks under human-paced delivery gets revisited every day when agents are committing code. At that frequency, cross-org coordination becomes friction. Each leader is doing exactly their job. The gap is that nobody owns the decisions between their jobs.

Dinesh described the same shift from the practitioner's seat:

"Complexity shifts upwards now. You're not just worried about your algorithms or your core code or the guts of the code, but you're worried about the ecosystem now."

Critical requirements for merging the functions

Closing that gap is what Dinesh is reaching for when he floats merging the teams. But the reporting lines are the surface. Whatever they look like, the response only holds if three things are true underneath.

  1. Someone owns the trade-offs between the functions. One accountability for the calls where reliability, cost, and security collide, rather than three leaders brokering across calendars.

  2. Every service has a single source of truth: ownership, dependencies, on-call, SLOs, security posture, and cost in one catalog, kept current by automation rather than manual entry. The catalog is the substrate the consolidated function operates on.

  3. One definition of production-ready covers all three focus areas. Reliability, security, and operational maturity sit in the same scorecard, evaluated continuously, with the same enforcement model. Teams know what "ready" means before they ship, not after review.

Partial versions are already observable in the field. At The New York Times, SRE and FinOps sit inside Developer Platforms because availability and cost are a single conversation. At Okta, Dinesh's mandate spans SRE, security infrastructure, and enterprise security tooling for the same reason.

A name for the missing scope

We've been calling it Engineering Operations: a single function accountable for the operating system of the engineering org, including the service catalog, the standards, the scorecards, and the trade-offs across reliability, security, cost, and delivery. A security team still draws the line. The difference is that the line gets drawn in the same room where reliability and cost are decided, instead of in a downstream review.

Every other major function got its operational counterpart years ago. Sales has Sales Ops, marketing has Marketing Ops, finance and product have theirs. Engineering, usually the largest cost center in the building, never did. The market is closing that gap now: companies like Block, WHOOP, Microsoft, and 1Password have stood up formal Engineering Operations functions and are hiring into them.

How that function maps onto the org chart comes down to size. Under five hundred engineers, one strong technical leader can credibly hold platform, SRE, and security at once. That was Dinesh's case on the pod: for smaller orgs, the mandate to move fast favors putting them under one leader. Past that, span of control breaks and each area needs its own VP.

Whether you merge the teams is a question for your org chart. Whether anyone owns the trade-offs between them is a question for your next incident, your cloud bill, and your security posture.

Listen to the full Braintrust episode with Dinesh Sukhija on how platform, SRE, and security are converging in the AI era.

Cristina Buenahora

Cristina Buenahora

VP, Strategic Initiatives

Get started with Cortex