SRE, DevOps and platform teams: who gets the report to the customer?

“We submitted the job,” says the application team. “The queue is healthy,” says the platform team. The customer still cannot download the report.

Both teams may be telling the truth. Neither answer gets the file to the person waiting for it. To find the gap, someone has to follow this particular export across the handoff and know whom to reach when the next decision belongs elsewhere.

In this hypothetical Dispatch workshop, the product team owns export behavior, the platform team supplies a shared queue and an SRE group helps develop reliability targets and response practices. These are example assignments, not a prescription for your organization. The useful test is whether they lead to someone who can act.

Who can change the retry?

Put that question beside three others: who can add queue capacity, change the customer promise or accept a remaining risk? The answers may name different people. The person coordinating an incident can bring them together without being authorized to make every change.

Draw the export's route from acceptance to download. Mark where the application gives work to the queue and where it takes work back. If the shared queue breaks, its operators restore it. If a retry needs to keep the same export identity, that belongs in application behavior. Meanwhile, someone must give the waiting customer one coherent account of the delay.

The drawing is useful when it answers a question the team labels cannot: what decision comes next, and who can make it?

A shared queue is not a delivered report

The platform team can give several product teams a queue they can reuse, with a documented interface and a support route. That is a shared capability. It saves each team from having to supply the same machinery for itself.

SRE work addresses how reliably the service delivers its result: making reliability explicit, improving how the service is built and operated, and reducing repeated manual work. DevOps describes collaboration and delivery practices more usefully than it dictates a separate department. These ways of working can overlap without making the customer's report someone else's problem.

A green queue indicator tells us something about the queue. We still have to follow the export far enough to find a downloadable file.

Three messages went in. Three came out.

Suppose Dispatch times out and retries, sending the same export three times. The platform team shows that the queue delivered all three messages it received. That narrows the search: the application team needs to preserve the export's logical identity across retries. Queue operators, in turn, need to explain which delivery guarantees callers can rely on.

Now reverse the failure. Dispatch submits one valid job, but the shared queue stops delivering. The platform team leads restoration. The application owner still decides whether to accept more exports, communicates the delay and checks that the waiting reports finish after the queue returns.

Walk both cases through the ownership map. Who repairs duplicate submissions? Who restores delivery? If neither team understands what is happening at the interface, who gets them together to decide? A useful map gives the next responder a route through that uncertainty rather than another team to ask at random.

The right owner is away. What happens now?

Rehearse three complications: the queue runs out of capacity, Dispatch sends duplicates and the only engineer with release permission is unavailable. For each, name who investigates, who can change the system, who communicates and who provides backup. Point to the access role or procedure that lets them do it.

Responsibility needs a path to a funded, authorized change. If the product team must answer for reliability but cannot influence queue limits or reach someone who can, a more elaborate diagram will not help. The teams need to repair their agreement, not merely redraw the boxes.

Write down what each side can count on

For the queue, that agreement should cover supported usage, capacity signals, upgrade notice, an incident contact, evidence of customer impact and a way to resolve disagreement. Dispatch has obligations too: slowing submissions when needed, preserving retry identity and using compatible clients.

Then replay the same three complications. Is the next person easier to find? Is the next decision clearer? Giving everyone more responsibilities is not an improvement if the export can still disappear into the space between teams.

The names can change; the handoff still has to work

A small team may combine these jobs. A regulated or high-consequence service may separate approvals. Use the policies and expertise your organization actually has, keeping backup authority and the route to a decision visible. This workshop does not create access rights that were missing before it.

Follow the customer's export across the revised map one last time. At every handoff, can you reach someone who can investigate, approve a change or obtain the help needed? Several organization charts can do that job. The one worth keeping is the one that gets the work through.

Sources

How SRE relates to DevOps and the SRE engagement model provide context for adapting responsibilities. Dispatch is a hypothetical workshop, not a description of a company's organization or access permissions.