In general, our conference calls are structured and laser focused on recovery; "what can we rollback, undo, failover or change to restore availability?" There's

In general, our conference calls are structured and laser focused on recovery; "what can we rollback, undo, failover or change to restore availability?" There's much less emphasis on figuring out the root cause, or the "why" of the issue, in that moment. That's another natural tendency - to want to understand the issue rather than fix it - that can be counterproductive. In that situation, and especially at scale, it's very useful to keep everyone on the same page about what actions are happening when, and to help folks out by showing them how to find things which may have changed (keep in mind the change may have been in a totally different system than the one that ultimately breaks). For example: it would slow things down if someone tried to flip data centers at the same time that someone else was rolling back software. If on a call it becomes clear that a team needs to make some kind of non-rollback change, like a code change, or push a new config, and thankfully that's very rare, we'll generally recommend they break off and work on it in isolation, while nominating a point person to liaise with everyone else. We do use chat too and that can be more effective as more people join. For postmortems we try hard to do in writing first, and then an in person review. It's very helpful to be able to re-assure and guide each other. I can back up the "Blame the system, not the engineer" guidance others have written about here too.