1) SLO improvement should be a negotiation that must include management. It's a resourcing decision. What things are enabled by it, and at what cost? Though, TB

1) SLO improvement should be a negotiation that must include management. It's a resourcing decision. What things are enabled by it, and at what cost? Though, TBH it sounds like even if they were mandated to achieve a certain SLO, you couldn't trust them to achieve it or correctly measure if they're achieving it. If it did get to that point, you would want to be closely involved in defining how the SLO is measured. 1b) Where are your SLOs even coming from? If the db team offers no SLO, you have no business offering one yourself, or if you do it needs to be something that takes into account observed backend reliability, not something imposed by a pointy-haired boss. 2) I'm skeptical about the sharding solution. If the data you're using doesn't need to be shared across teams, consider just setting up your own db. 3) Aggressive caching and prefetching might improve the end user experience. 4) Graceful degradation. Build your UIs such that if one call to the DB fails, it only breaks a minimal part of the page, not everything. This sounds more like an organizational issue, though. The most value you could provide to the company sounds like it'd be breaking through those institutional barriers. More likely than not you'd try and fail (nature of these things, not a knock on you), but it's worth a shot.