Where SRE and platform engineering need an explicit handoff

A rollout stalls inside a shared deployment platform. The platform team can investigate the controller, but the application team knows whether a rollback is compatible with the data already written. In this hypothetical case, both teams have something essential to do. The customer’s recovery depends on those investigations meeting, not on finding a job title broad enough to own every detail.

A clean organization chart can still leave a messy gap in the response. Job titles tell you where people tend to focus; they do not tell the responder who will take the next check when a release stops halfway through. That takes an agreement about the service, the decision waiting to be made and what the receiving team is accepting.

Different purposes still create shared incidents

Platform engineering commonly treats internal capabilities as products for developers: deployment workflows, templates, identity integration, infrastructure access and supported defaults. Reliability engineering asks whether services meet user expectations and how to reduce the work required to keep doing so. Both can involve writing software, operating infrastructure and taking on-call shifts.

Those emphases do not remove ownership. A platform team remains responsible for its platform’s reliability, while a product team remains responsible for application behavior. SRE involvement can range from advice to substantial operational ownership depending on staffing and maturity. A small organization may combine the functions without losing their purposes, provided its actual commitments remain clear.

Google’s guidance on implementing SLOs is relevant because reliability objectives need stakeholder agreement. SRE cannot independently choose acceptable customer impact, and a common platform template cannot infer every application’s tolerance. The agreement has to reach the people carrying those consequences.

What, exactly, is the receiving team accepting?

For the stalled rollout, controller repair and application rollback compatibility are separate questions. Coordination can arrange both investigations without giving the coordinator every production permission. The application owner still has to establish whether the older workload can use data left by the newer version. The examples below show how the accountable owner follows the failed component and required decision.

An incident commander needs a way to summon the owners who can act and keep their work aligned with customer impact. That does not transfer ownership of every affected component to command. It gives each investigation a shared context without obscuring who can authorize and implement its change.

Define a handoff by the decision the receiving team accepts, the evidence accompanying it and the fallback when the needed owner is unreachable. In the rollout case, the application owner might show that execution never reached application startup and attach the platform error. The platform owner can explicitly accept investigation of that stage while the incident lead continues coordinating customer impact.

Until someone accepts the investigation, keep it moving. Changing a ticket’s queue proves that a routing action happened, not that a person has begun the next check. The gap can be easy to miss because both teams have done something reasonable: one has identified the likely platform stage and the other has a queue for platform work. The customer is still waiting between them.

Recurring incidents can change platform defaults

If several services repeatedly misconfigure timeouts, local fixes may leave the default causing the pattern untouched. Incident evidence can make a platform-backlog proposal concrete: identify the affected workflow, explain the mechanism, propose the default change and account for migration work among existing users. Reliability work then influences the shared product instead of recurring as separate repairs.

The cost can travel in the other direction too. A platform team adds a deployment guard, but each application team must supply a meaningful health check. A telemetry convention simplifies investigation, but someone pays for its storage and maintains the integration. Both can be worthwhile improvements. Involving application owners makes the new work visible before the launch, while there is still time to design and fund it.

Adoption and reliability outcomes together help expose the tradeoff. Teams may willingly use a platform that still fails too often, or avoid controls that make routine delivery difficult. In the latter case, a nominal control may push work into unsupported paths. Neither adoption alone nor a well-designed policy on paper establishes the result.

When the expected owner is unavailable

A recent case that bounced between teams is a useful rehearsal. Walk through who receives the page, who can pause deployments, who restores the platform and who verifies the user journey. Check actual permissions along with names. The exercise should expose a missing capability or unavailable owner before the same gap appears during the next rollout.

Explicit acceptance must not delay urgent mitigation; appropriate bounded actions can be authorized in advance, with emergency transfers recorded so continuity does not depend on one person. An unresolved cross-team exposure can enter the risk registry with an owner and review date, where it can influence planning rather than be rediscovered in another incident.

A reassigned ticket is not an accepted handoff

Read diagram description

Illustrative failed rollout: the sending team keeps investigation moving until the receiving team accepts it. The incident lead continues coordinating customer impact across that transfer. Diagram labels: Application owner: Identify failed stage; attach platform evidence; Platform owner: Explicitly accepts investigation of that stage; Accepted workstream: Named owner, next check and escalation route; Incident lead throughout: Coordinates customer impact and shared priorities.

The stalled rollout now has two clear lines of work. The platform owner investigates the controller; the application owner checks whether the older workload can use the current data; the incident lead keeps both connected to recovery. No title had to expand to cover everything. The next decision simply stopped falling into the space between teams.