Cross-team ownership negotiation: make responsibility executable
Resolve unclear operational responsibility with explicit interfaces, decision rights and acceptance evidence. Practice a realistic shared-platform handoff.
TL;DR: Resolve ownership disagreements by naming the decisions and work each team will own, then testing the handoff. A team cannot accept a production responsibility without access, operating knowledge and capacity to perform it.
Replace “who owns this?” with a specific operation
Two teams can both claim to own a service while expecting the other to handle certificate renewal. They may also both deny ownership of a failing integration because each component works in isolation. A single label hides several responsibilities: changing configuration, responding to alerts, approving risk and fixing a defect can belong to different people.
Start with the disputed operation. In a hypothetical company, a platform team runs a shared message broker and an application team produces billing events. Broker latency rises whenever the application deploys. The platform team calls it a client problem; the application team expects the platform to make delivery reliable. The useful negotiation concerns producer behavior, broker capacity and the evidence needed to distinguish them.
Google's communication and collaboration chapter treats collaboration as engineering work. Apply that idea by bringing a concrete failure and an operating proposal to the discussion, rather than asking an executive to assign a vague noun to a team.
Agree on the interface before assigning the pager
Write a small responsibility table using verbs. Each row should identify an action someone can perform and the authority required to do it.
| Situation | Primary action owner in this example | Required contribution from the other team |
|---|---|---|
| Broker storage approaches capacity | Platform expands or restricts capacity | Application forecasts retained event volume |
| Producer retries create a traffic spike | Application changes retry behavior | Platform supplies broker saturation evidence |
| Consumer schema change breaks processing | Application coordinates compatibility | Platform preserves agreed retention during recovery |
| Failure source remains unknown | Named incident lead coordinates investigation | Both teams supply responders until routing is justified |
These assignments are a proposal for this scenario, not universal platform doctrine. A managed service team might own more of the client library; another organization may delegate broker operations to product teams. What matters is that the operating model matches the actual tools, staffing and decision rights.
Specify the shared measurements. For billing events, identify accepted publication, durable storage and successful consumption separately. “The broker is up” does not settle whether an invoice event was processed. Include the identifiers and timestamps needed to trace a sample through the boundary without exposing customer data.
Unknown cause should not leave the incident without an owner. Assign coordination immediately, then revise technical responsibility as evidence improves.
Negotiate capacity and acceptance explicitly
Suppose the application team agrees to take the producer alerts but lacks permission to inspect the broker's rejected-request metrics. Transferring the pager that afternoon would create a predictable escalation loop. Grant the required read access, document the query and exercise the diagnosis before the transfer becomes effective.
A practical handoff can include a shadow period with a named end condition. The receiving team demonstrates that it can identify a failed publication, find the responsible release and execute the agreed mitigation. The previous owner remains a backup during that period. A date alone is a weak acceptance criterion when the runbook has never been used.
The SRE engagement model provides useful context for readiness and shared responsibility. For this scenario, negotiate what happens to unfinished work: perhaps the platform team retains a capacity alert until it exposes the missing telemetry, while the application team accepts producer retry alerts immediately.
Document who can accept the remaining risk. If both teams lack staffing for a required response, escalate the capacity decision with alternatives and consequences. Do not describe an unresolved staffing gap as “shared ownership” and hope somebody notices the next page.
Tell the interview story without inventing agreement
Use a real example from your work. State what each team was worried about, the evidence you introduced and the responsibility that changed. Explain your own contribution precisely: drafting a table, running a failure exercise and negotiating access are different from personally implementing the entire integration.
If the agreement remained partial, say what remained unresolved and how it was escalated. Evidence might be a tested runbook or a completed access change. Only quote reduced escalation counts if you actually measured them over a stated period.
Self-check: both managers approve a responsibility table, but the new owner cannot perform the documented mitigation. Is the handoff complete?
No. Manager agreement establishes intent. Operational acceptance requires the receiving team to perform the work, or an explicit exception with a functioning backup and a named risk owner. Reflect the current state in the service catalog so responders do not discover the gap during an outage.