Cross-Team SLO Alignment

Team SLOs aggregate to org SLO.

Hierarchy

Once an organization has more than a few teams, SLO management requires alignment across teams. Without alignment, each team's SLO is in isolation; the company-wide reliability story does not add up; customers experience the worst-team's reliability rather than the average. Cross-team SLO alignment is the discipline that produces a coherent reliability story across the org.

What hierarchical SLO alignment looks like:

• Team SLOs roll up to product SLOs.: Each team has SLOs for their services. The services compose into products (the checkout product, the search product, the messaging product). The product-level SLO is computed from the underlying team SLOs using the dependency math. The composition makes the rollup explicit.
• Product SLOs roll up to organization SLO.: The organization has a few headline SLOs that get reported to leadership and customers. These are computed from the product SLOs. The math is hierarchical; each level is grounded in the level below.
• Consistent math throughout.: The same SLI definitions, the same time windows, the same exclusions apply across the hierarchy. A team that defines availability one way and another team that defines it differently produce numbers that cannot be composed. The consistency is what makes the hierarchy meaningful.
• Visible at every level.: Engineers see their team's SLO. Engineering managers see their product's. Engineering leadership sees the organization's. Each level has its own dashboard; each rolls up coherently.
• Tied to the organizational structure.: The SLO hierarchy mirrors the org chart. Teams own their SLOs; product engineering managers own product SLOs; engineering leadership owns organizational SLOs. The accountability structure matches the metric structure.

The hierarchy is what scales SLO management beyond a single team. Without it, each team is isolated; with it, the organization has a coherent reliability story.

Dependencies

Teams do not own their SLOs alone. Almost every team's reliability depends on other teams' services. Cross-team alignment includes recognizing these dependencies and coordinating reliability decisions across the boundaries.

• Team A's SLO depends on Team B's.: The customer-facing API team depends on the data plane team's reliability. The recommendation team depends on the user-profile team's. Each dependency is a constraint on the depending team's achievable SLO.
• Coordination required.: When Team A wants to commit to 99.95% but Team B operates at 99.9%, the math does not work. Either Team B has to invest in tighter reliability, or Team A has to relax their commitment, or the architecture has to reduce A's dependence on B. Each option requires coordination.
• Cross-team SLO contracts.: Mature organizations document the SLO contracts between teams. "The data plane commits to 99.95% availability for the API team, with the following caveats and the following maintenance windows." The contract is reviewed quarterly; it is the basis for the API team's own SLO commitment.
• Bidirectional accountability.: Team B knows what reliability they owe to Team A. Team A knows what reliability they can rely on from Team B. The relationship is explicit; it is not "we hope our dependency is reliable"; it is "we have a contract for what we expect."
• Reliability investment trade-offs surface.: When the chain of dependencies has a weak link, the cost of fixing it can be quantified. "Team B needs an additional engineer to hit 99.95%; that lets Team A commit to 99.9% to customers; Team A's customers will pay 30% more for that commitment." The conversation gets specific.

The dependency layer is where SLO alignment turns into actual coordination. Teams talking to teams about reliability commitments produces the architecture that delivers them.

Review

The third practice is the cross-team review when alignment breaks down. Team A's SLO is at risk because of Team B's degradation. Team B's SLO is at risk because of architectural decisions made by Team C. The review is the forum where these tensions get resolved.

• Cross-team review when SLOs conflict.: A regular meeting (monthly or quarterly) where the teams whose SLOs depend on each other review the dependency state. Are the contracts being met? Are any teams about to breach their dependents? What investments are needed?
• Resolve specific conflicts.: The review is action-oriented. Each conflict produces a specific resolution: investment by one team, contract change, architectural shift, escalation to leadership. Conflicts that cannot be resolved in the meeting get owners and deadlines for follow-up.
• Engineering leadership engaged.: The review includes leadership at the level that can allocate resources across teams. If the resolution requires shifting headcount or budget, the people who can make those decisions are in the room.
• Documented outcomes.: The review produces meeting notes with decisions and owners. Future reviews follow up on the previous decisions. The continuity is what produces multi-quarter improvement rather than the same conflicts recurring.
• Avoid finger-pointing.: The review is a problem-solving forum, not a blame forum. Teams that have caused issues for their dependents are working with the dependents on resolution, not defending themselves. The culture of the review determines whether it produces solutions or escalations.

Cross-team SLO alignment is the discipline that scales reliability practice from single-team to organization-wide. Nova AI Ops models the SLO hierarchy and dependency graph across teams, surfaces the cases where dependency breaches cascade up the hierarchy, and produces the artifacts the cross-team review needs to resolve specific conflicts efficiently.