Rotating "on call" around sprint cycles, for example, has a lot of potential IMO; as engineers we need to have not only a solid understanding of our product and technology but also of our customers - how can we build the best product for them without having some empathy with them?<p>One of the greatest joys for me in my day to day job is problem solving for customers and colleagues. The satisfaction I get from helping someone is almost second to none; there's also the added benefit of the customer feeling valued and the company coming off as one with great service. Another part of the interactions is honesty; explaining what an issue is to a customer or colleague makes them feel cared about as well, and builds a lot of trust. That relationship can really help you get through tough times; a happy, helped customer is a loyal one. I've had one or two customers at a past employer who have said that I was the only reason they didn't drop us.<p>Having said that, it can be a huge time-sink and I wouldn't recommend mixing "support" with "feature" work; inbound communication is highly disruptive to concentration, impossible to estimate and if there's a lot of it it can overwhelm a developer to the point where they don't get feature work done and will, I guarantee, start feeling crap about it.<p>I would personally advocate a "Business As Usual" team working in a Kanban style to handle piecemeal support and technical issues, with perhaps a small, non-critical feature project bubbling in the background, balanced with feature teams working in sprints, with a healthy team rotation; it will keep your engineers fresh, interested and engaged with customers and the product.<p>/my 2c