On call? I never had to do any kind of support of any of the software products that I worked on. Why would you waste eng time on something as trivial as support?
Do you work on software that gets sold to customers? Often, uptime guarantees are included in contracts. If your software breaks, somebody has to fix it.
> Why would you waste eng time on something as trivial as support?
Because eng is the only people who know how the software works if it breaks, who else can fix it?
I would also say that good support is not trivial (this is not eng specific, it's a company wide initiative) and can be a competitive differentiator
It's a "Our company has sufficiently-complex software that we sell to customers that pay us enough money to justify calling in one or more programmers outside of regular business hours to help handle problems that one or more of those customers considers Very Serious that our (IME often very, very knowledgeable) support staff can't figure out." thing.
It's a solution to the problem of "our servers crashed at 2am, the product isn't functioning, and we have no one working right now capable of fixing it"
I guess this is more about the kind of software that I write and support .. during office hours only. I wouldn't dream about picking up the work phone during non-office hours since I'm never expected to.
In my experience its more for critical time-sensitive systems that run in off-hours (i.e. if this job fails overnight it needs to get fixed before x time or we'll be bleeding massive amounts of money).
So even if there is tiered support, they'll want an SME on some aspect of the system on-call as a fallback for higher/highest level triage.
Oncall isn't user support. Amazon (and a lot of services) are supposed to work correctly even outside of office hours and someone needs to be able to fix things. That's one downside of software as a service.
Is this an American corporate thing?