We do daily shifts with a follow the sun rotation, makes it easier to handle persistent commitments and ensures a bad week doesn't all land on the same person.
This! Whenever someone talk about on-call this aspect of that rotation gets swept under the carpet. Whenever I interview I always ask whether they have on-call system (they must if there are servers and apps involved) and if they do whether they have follow the sun.
Most don’t even like the question. For them such questions are red flags or the candidate is not “motivated enough”. Rarely some even have follow the sun policy. They might have one in their HQ, true for a lot of US/EU firms, but their offices in a developing country like India - it’s always something on the lines of “oh, engineers here take full ownership; they are the owners”.
Also, I have seen — 2-3 days rotation with follow the sun is best, week long or longer being worst.
Then there are companies where it could be forever on-call with no follow the sun - e.g. Amazon, Uber (in India at least). That’s another world altogether.
I mean it sounds clever, but how do you have engineers with no expertise in a system handling calls for it? I've been at places that follow the sun, and you frequently have no idea what to do during an incident, because the person who owns the system is offline. But at least you can sit one a useless incident call during work hours instead of completing your own tickets I suppose.
The point is that the "ownership" used to rhetorically justify the labor of such engineers is not "ownership" at all: it's missing the literal most important aspect, that is the ability to profit proportionally as a project brings in revenue. Literally everything else is included -- the intensity of work, the singular focus, the care and devotion, the expected level of initiative -- but not the part that would most benefit the engineer.
There should be SOPs in place for each "expected" issue so people know what to do.
Its not like you (should) start debugging and deploying stuff in the middle of your on-call shift anyway.
Its not 100% for sure but in the normal case this should be fine.
Not only that but if you have a multiple continental team then no one needs to be waken by an emergency meow. (My PagerDuty is set to a meow sound. So we practice meow driven development: I don't want to hear my phone meowing piteously.) Say, you have someone on the US west coast they can do 10am-10pm while someone else in continental Europe being nine hours ahead can do 7am-7pm.
In some cases it might help. Because then it becomes “natural” - on-call thing. It’s not something someone dreads as in “god, that week is coming”. Also, it spreads the fuck-ups and peaceful times better.
Increasing hand-offs by 7x is sub-optimal and interferes with folks wanting to take continuous vacation time. Again, I can see for ops teams that could be true, but very much disagree that on-call should be a "natural" thing for dev teams in the first place. It can be a necessary evil that should be minimized (the personality of people who like firefighting and quiet development are quite distinct and there are people who actually like the former.) On the latter point, I think that benefit is very much a mirage. If there's a flaw in the system causing a "bad week," it actually might be easier for the first person who gets the hang of it to deal with it than to try handing off and teaching the next one in the rotation.
