Ownership boundaries for shared services

Shared services are attractive on diagrams.

One team runs authentication, another runs billing, a third runs notifications. Product teams plug in as consumers.

In practice, those shared services often live in blurry territory:

• Who fixes a bug that appears only in one product’s usage?
• Who decides when to deprecate an API?
• Who gets paged when a shared service is up but misused?

We saw incidents and projects stall in those gaps.

This post describes how we clarified ownership boundaries so shared services behaved more like products and less like libraries.

Constraints

• We already had shared services in place; we weren’t starting from scratch.
• Some teams were small and could not absorb a large new on-call or roadmap burden overnight.
• We wanted changes that would survive org charts shifting.

What we changed

We focused on three questions for each shared service:

1. Who owns what?
2. How do consumers engage with that ownership?
3. How do we handle gray areas during incidents?

1. Define service ownership like product ownership

For each shared service, we wrote a short ownership document:

• what the service does (its "product description")
• its SLOs and support expectations
• who owns:
  • on-call
  • roadmap and breaking changes
  • documentation

We published these next to the service’s runbooks.

This turned "ownership" from a list of names into a description of responsibilities.

2. Define consumer responsibilities

Consumers of shared services have responsibilities too.

We wrote down expectations for them:

• follow documented usage patterns
• surface requirements early (SLOs, traffic estimates, data needs)
• participate in testing and rollout for breaking changes

We added a simple rule:

If a consumer relies on behavior outside the documented contract, that is a bug in the consumer until it’s negotiated and documented.

This avoided debates during incidents about "what was implied."

3. Make support paths explicit

We clarified how consumers get help:

• a single internal page for each shared service with:
  • links to runbooks and dashboards
  • how to page or escalate
  • how to request features or changes

We also added an internal label for issues and incidents touching shared services, so we could see patterns across products.

4. Handle gray areas in incidents

During incidents, the question "whose problem is this?" is often the wrong starting point.

We adopted a simple rule:

• the team on whose critical path the failure appears leads the incident
• the shared-service team joins as domain experts for their part of the stack

Afterward, the ownership document is where we adjust boundaries if we find repeated confusion.

Results / Measurements

After a few months of using these documents and rules, we saw:

• Fewer stalled incidents. It was clearer who should pick up an incident and who to pull in, even when multiple products were affected.
• Clearer roadmaps. Shared-service teams had better inputs on what consumers needed and could plan breaking changes with real partners.
• Better incident reviews. Instead of arguing about "who should have done what," reviews focused on whether the ownership and contracts were clear.

We also saw soft but important effects:

• teams stopped treating shared services as "that code over there" and more as internal products
• new engineers could learn the system faster by reading ownership docs

Takeaways

• Shared services need product-like ownership: clear responsibilities, SLOs, and support paths.
• Consumers also have responsibilities; reliability is shared.
• Written ownership boundaries reduce friction in both incidents and roadmaps.
• When incidents cross boundaries, lead by "who is impacted" and collaborate, then adjust the docs later.

Further reading

• Support tools are product
• No heroics as policy