SRE sits between development, product and infrastructure, so communication is a large part of the job. This chapter covers how SRE teams organise their internal communication, how they coordinate with each other and with developers, and what has worked when several SRE teams build something together. The production meeting, a weekly review of the state of the service, is the concrete practice most teams adopt from it.

The Viceroy case study, where several teams collaborated on a shared monitoring dashboard framework, is an honest account of how cross-team projects go, including the friction.

In one minute

• SRE communication exists because SRE is multidisciplinary and spread out: teams are often multi-site, services depend on other teams' services, and incidents cross boundaries.
• The production meeting is a weekly, 30 to 60 minute meeting where an SRE team reviews its service: upcoming production changes, metrics (SLO performance), outages and their postmortems, paging events, non-paging events, and prior action items. The chair rotates. Developers are invited and the service's current state is discussed in the open.
• Agenda structure: upcoming production changes, metrics, outages, paging events, non-paging events, prior action items. Each is brief and leads to an action or a decision.
• Multi-site teams meet by video conference and the agenda is kept in a shared document so that both sites can edit.
• Roles within SRE: the tech lead sets technical direction, the manager handles people and priorities, the project manager (or technical program manager) tracks work across teams. In some teams one person holds more than one role. Each team member is expected to contribute to all three.
• Viceroy: SREs in several teams independently wanted a better dashboard framework. They combined forces, agreed on a design, and shipped a tool used company-wide. Lessons: a shared vision matters more than agreement on every detail, participation is voluntary and must be rewarded, geography and time zones add friction, and the project needs a clear owner.
• Collaboration outside SRE: involve SRE early in product design (the production readiness review), attend design reviews, and share the SRE perspective before launch rather than after. Collaboration beyond Google included open-sourcing tools and publishing this book.

Communications: production meetings

The production meeting is the team's heartbeat. It is where the state of the service becomes shared knowledge rather than something only the on-caller knows. The agenda is fixed so that it is efficient. Upcoming changes: what is being pushed, what is being turned up or down, so that the team is not surprised. Metrics: how did the service do against its SLO this week, and if badly, why. Outages: each incident gets a summary and a pointer to the postmortem. Paging events: what paged, was it actionable, should the alert change. Non-paging events: things that were noticed and handled without a page, and things that should have paged but did not. Prior action items: did we do what we said we would. The chair rotates so that everyone learns to run it, and a note-taker records decisions in a shared document.

Developer attendance is encouraged. It gives developers a direct view of what their changes cost in production and gives SREs a chance to ask about upcoming work before it lands.

Collaboration within SRE

SRE teams are typically multi-site for on-call coverage, so communication has to be deliberate: shared documents, scheduled hand-offs, and a culture of writing things down. The tech lead holds the technical vision and reviews designs. The manager handles careers, hiring and priorities, and acts as the interface to upper management. The project manager tracks cross-team deliverables and dependencies. The chapter stresses that these are roles, not ranks, and that a healthy team has every member contributing to direction, prioritisation and coordination.

Case study of collaboration in SRE: Viceroy

Several SRE teams had each built their own dashboarding, badly, on top of Borgmon. A few engineers from different teams realised they wanted the same thing and started Viceroy, a shared framework. The project had a volunteer structure: people contributed on top of their regular work. It had a design debate at the start, which was resolved by choosing an architecture and a lead and agreeing to disagree on the rest. It needed management buy-in for engineers to spend time on it. Over time it became the default dashboard tool, with a core team of maintainers.

The chapter's lessons: a cross-team project needs a clear owner and a shared vision; it needs sponsors who will protect contributors' time; it needs an easy on-ramp so that new contributors are productive quickly; and it should expect friction from time zones and from teams with different needs. The payoff is that one good tool replaced many mediocre ones.

Collaboration outside SRE

The most effective collaboration with product teams happens early. The production readiness review (chapter 32) is the formal mechanism, but informal ones matter too: an SRE attending a design review and asking how the system behaves when a dependency fails changes the design more cheaply than a postmortem later. SRE should also communicate outward: publish SLOs, publish postmortems, and make the error budget visible so that priorities are negotiated with facts.

Case study: migrating DFP to F1

The chapter closes with a cross-team migration of the DoubleClick for Publishers database to F1, which required SRE, developers and the F1 team to coordinate a long project with multiple phases. The lessons overlap with Viceroy: clear ownership, regular communication, incremental steps that can be verified, and agreement up front on how to decide whether each step succeeded.

Conclusion

SRE's effectiveness depends on communication because SRE's influence is mostly indirect: it changes how developers build, how managers prioritise and how teams respond. The production meeting, explicit roles, and early involvement in product design are the tools that make that influence routine rather than heroic.