The author seems to be missing how disruptive interruptions can be to some developers.
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.
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.
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.
Re (1): I am a developer. I do several different things a day. It's an ideal moment, do do 1 short thing in between 2 different long tasks. It's a nice distraction, a time to empty your head.
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.
I've had good experience with a rotating on-duty developer in at least two different companies I've been at.
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.
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.