The author seems to be missing how disruptive interruptions can be to some developers.<p>The "on call" idea might have some merit because it allows the developer to adjust their coding schedule around the X hours they will lose every day for a given period of time with customer assistance.<p>The "all hands" idea sounds terrible. Asking a developer is asked to answer 5 customer emails daily, each one needing a variable length of time to respond to, threatens to poison the well and become a burden. My understanding is that a developer would either try to answer the emails at the very beginning or at the very end of the day to keep distractions at a minimum.<p>My biggest question is - what is the reason for the author to have this many questions after being with Buffer for over 8 months? This seems like sufficient time to learn all the ins and outs of most products. Moreover, I hope that Buffer dev new-hires are told that they'll be asked to wear many hats, including the responsibility for customer support, as part of the regular duties.
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
This post seems sincere, but insecure. I'm a bit concerned that someone in support needs to ask so many questions...<p>This is where a queue of support tickets and a knowledge base would really help out I suspect.
So basically, when somebody asks you a question, it's better to answer it truthfully and possibly do some research on the answer, rather than just make up a bad answer?