idk, here are some ideas for on call must haves based on other talk about on call things: - normal rotation has 5-8 people - on call lasts for one week -

idk, here are some ideas for on call must haves based on other talk about on call things: - normal rotation has 5-8 people - on call lasts for one week - some institutional trigger (like an SLO) exists for changing team priorities when pages happen too often - the culture around on call is empowering, not heroic/dysfunctional - people can still carry on with normal life while on call (just keep your laptop in a backpack and don't get drunk) At least some practices could help make it suck a bit less too: - option for next day off after picking up a page (no questions asked) - frequent pages (more than a couple per quarter) trigger discussions about how to improve code quality or fix bug hot spots - during on call shift you can get a break from normal sprint work (do rewarding things that add value for the team) - there's no fear about being on call since problems are rare and everyone knows how the software systems work - if you're stuck while debugging on call there are more senior people you can page too to get help - work on app monitoring/debugging a little bit of the year to make debugging and triage easier when things do come up - ops team catches the page before your team to provide context and repro - reverting or deploying fixes isn't stressful because the deployment is stable and fully automated Do those seem reasonable? It doesn't seem like a radical idea that the team that wrote the bug has to get pulled into the call to help fix the problem. The anecdotes from this thread make it seem like a healthy on call is very much the exception not the norm though.