Sort of. I've worked with having a rota where engineers would spend a week handling support and bug reports which avoids many of the pitfalls with the entirely separate "two crews". I wrote a bit more about it in https://news.ycombinator.com/item?id=43337703#43339972 .
> Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week.
In my experience this works well. With my current and previous client each team had a "hero of the week", whose responsibility was second line support and monitoring. If nothing came up the hero would work on their tasks as usual.
If something does come up the heroes of the week would be tasked with solving it or pulling in someone who knows how to solve it. This leads to engineers both having to accept accountability for writing shoddy code, but it also exposes engineers to the wider codebase when pulling on threads. It also solves the issue where no-one or the same person always takes responsibility for handling bugs.
This just sounds like having a point developer. The challenge is too many companies expect this without giving up a feature-dev headcount. Any work the get done aside from point is a bonus and unplanned.
Maybe - though I associate being "on-call" with being expected to respond outside of normal business hours which was not the case in the teams I worked in.
