> team decided to have a shared on-call rotation. They would cross-train. Each team makes a procedure book that covers any first-on-the-scene tasks for most ale

> team decided to have a shared on-call rotation. They would cross-train. Each team makes a procedure book that covers any first-on-the-scene tasks for most alerts and issues. Shared on-call is a section I strongly disagree with. Shared on-call erodes the very same boundaries that provided value in the first place. You could say it's a lesser and necessary evil, but you should at least be open about it. Procedure book is a naive "sounds good, doesn't work" solution. Why don't you "solve" the on-call problem completely by outsourcing it to a $15/hour worker if you have these amazing playbooks? This approach naturally leads to bloated playbooks. It's very similar to trying to solve all of the architectural issues by "writing good documentation". Never works. On-call is typically a company-wide policy, and those are at odds with smaller independent teams. The right answer is giving those teams more independence: they figure out how to solve their on-call themselves. Maybe playbooks is the answer for them. Or they have people who are still online after work hours and they don't mind being semi-oncall. Or maybe all their issues are not critical and 24/7 on-call is not necessary. Smaller teams benefit from independence, don't ruin it via company-wide policies.