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.
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.
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.
I've seen this sort of setup work very well. It's something I've done myself (while wearing a dev hat) and found it very useful. I'd happily do it again.
Yes - being interrupted at any time would be a pain - but...
1) There are normally enough natural pauses during the day where knocking off a few customer support issues is doable. It can actually be quite a nice change of pace. It uses a separate bit of your head and you come back to that problem that just stumped you fresh after the break.
2) It's can be a mistake to worry about the productivity of individuals and neglect the productivity of the company as a whole. Slowing me down individually can make the company as a whole run faster.
3) It gets you direct contact with actual customers on a regular basis. This is pure fking gold. Lost count of the number of times this has produced insights about how the ongoing development should work. That minor annoyance that three folk mention in a row that's sounds tricky but is a 2m fix.
So, unless you're spending your whole day on one single huge feature all day, there are plenty of opportunities for short breaks.
But I agree that having interruptions at random times may be counterproductive.
The developer would be the only person that CS (and others) can come to with questions. He would not be expected to be very productive and would generally deal with small ad-hoc bug fixes when not acting as internal support (Which it really is). He'd also be responsible for various ad-hoc and maintenance tasks. The rest of the team would then be free to work uninterrupted on development tasks.
We'd have some sort of token (a teddy bear or whatever) at the designated developers desk, so everybody would know who to go to.
Of course it does cost a full developer "resource" at all times, so this probably only makes sense once your team reaches a certain size.
This is where a queue of support tickets and a knowledge base would really help out I suspect.
I do feel this post is pretty sincere and I liked the fact that she was honest with her mistake.
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.