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

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? 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. 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. 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. /my 2c