Opens in a new tab
Home/Articles/Engineering leadership
Commentary

Give the service owner a way to make the recovery happen

In brief

Use a shared-database rollback to find the evidence, authority, escalation and engineering time behind an ownership label.

By 4 min read

BeginnerAbout reading levels
Is this the right starting point?
Before you read
No formal SRE training required; familiarity with team responsibilities helps apply the hypothetical recovery example.
What you will take away
Distinguish doing, deciding, coordinating and verifying, and identify the specific access, authority or capacity gap blocking an owner.
Sources
Paper collage shows a shared database connected to three services while separate hands inspect compatibility, approve a change and reserve work time.
On this page4 sections

The service owner is on the call. The failing release has an earlier version ready to restore. But the new version changed a shared database, and nobody present can approve the data risk of going back. A name on an ownership chart has not yet produced a recovery decision.

Follow this hypothetical rollback through the people and evidence it needs. The earlier application must understand the current stored data; someone must decide the acceptable scope; an authorized operator must make the change. Each missing connection points to a different organizational repair.

Name the jobs behind the role titles

Responsibility describes work someone performs. Accountability identifies who answers for an outcome or decision. Organizations use these words differently, so describe the actual duties rather than assuming everyone reads a letter in a matrix the same way.

In this recovery, a database engineer can inspect compatibility with the current schema, the structure of the stored data. An authorized operator can perform the change. The incident commander keeps timing and concurrent work coordinated. Leadership may decide the commercial consequence of pausing delivery.

Assign these jobs according to real authority. Coordinating the call does not grant every production permission or the right to accept every consequence.

Doing, deciding and coordinating can belong to different people
Doing, deciding and coordinating can belong to different people
Role comparison, not a required organizational chart. Name who fills each role for the service and check that their access and availability match the work.
Read diagram description

Role comparison, not a required organizational chart. Name who fills each role for the service and check that their access and availability match the work. Diagram labels: Performs the work: Investigates or applies the change; Authorizes the change: Can accept its specific consequences; Coordinates the response: Maintains priorities and handoffs; Verifies recovery: Checks the affected user operation.

The SRE and platform engineering guide applies the same distinction to shared platforms. A deployment button can simplify execution while leaving the application team responsible for deciding whether its behavior is acceptable.

Follow the rollback until you find the missing connection

Ask what stops the service owner now. Missing compatibility evidence, an unreachable decision maker and no available operator are different problems. “We need the database owner to decide this compatibility risk” is an answerable request. “We need more ownership” may leave everyone where they started.

An owner need not control every dependency personally. The operating arrangement needs a usable escalation path and a reachable fallback. Greater initiative from the service owner cannot create authority the organization has not granted.

Test that path before relying on it. Give the owner the failing release, proposed earlier version and shared schema change. Follow the compatibility check and authorization request far enough to reach a real person or a documented reason to stop.

Make the lasting repair fit the plan too

Suppose the database engineer confirms compatibility and the operator performs the recovery. The follow-up repair can still lose its place in every planning cycle. Now the immediate recovery path works, but engineering time for the lasting correction is missing.

That is a capacity decision. If the organization defers the repair, record the remaining exposure, who considered the tradeoff and what brings it back for a decision. Otherwise each responder rediscovers a choice leadership already made, or never finished making.

Disagreement tests the arrangement too. If the owner wants to pause rollout while delivery wants to continue, identify who resolves it and when. Bring that person service evidence and the cost of waiting so accountability includes a practical route to influence the outcome.

Make the next commitment observable

“Improve monitoring” leaves the owner to interpret the promise. Detecting a particular failed user operation and showing that its page reaches a staffed rotation describes an outcome someone can check. Assign the delivery work and the responsibility for establishing that result.

The risk registry connects completed tasks with remaining exposure, and the follow-through guide develops verification. The forum allocating the work must also resolve conflicts among those commitments.

Explain decisions honestly by examining the information and constraints available at the time. An engineering postmortem investigates why a database choice was hard to make or reverse; personnel or misconduct concerns follow their separate process.

Return to the owner on the call. Can they obtain the compatibility evidence, reach the data-risk decision maker and get the agreed work executed and scheduled? If one link fails, repair that link. Asking the same owner to care more cannot supply missing access, authority or time.

Source context

This article does not include external reference links. Read it as the author’s perspective and evaluate the guidance against your environment.

Report an error or outdated detail

Keep reading

Where to go next