[burnout1540]

Our approach may not be scalable (and may not fit into your worldview) but having our developers do API support for us serves two important purposes:

1. Giving our clients the best possible technical support

2. Making our developers feel the pain (and joy!) of clients using what they built. I can't think of a better way to motivate developers to fix what's sub-optimal, share in the success of a job well done, and come up with new ideas to help our customers.

We're not alone in this strategy:

http://www.helpscout.net/blog/customer-pain/

https://gettingreal.37signals.com/ch14_Feel_The_Pain.php

[mak4athp]

I think your intuition is correct when you suggest that this approach isn't scalable. It runs counter to the concept of "flow", articulated in Peopleware[1] 30 years ago and confirmed many times since then.

Sharing the pain has benefits, but you're almost certainly paying more in lost productivity on both bugs and features than you're gaining in insight and sensitivity. As a small and stable company, you can probably afford the loss as you learn more about your market and as you prepare for more organizational complexity, but it will eventually inhibit your growth and burn out many of your developers.

[burnout1540]

That's a fair point. The one constant in a startup is change. It may be that in the future we'll have developers only doing front-line support for beta features of our API.

Regarding flow, we don't have all of the developers doing support all of the time. We have one developer doing support at a time and rotate each week. This protects the rest of the team from having their flow I interrupted.

[mreiland]

More than that, the links he gave talked about the entire company doing support, not just the developers. In other words, he misunderstood the point being made.

Putting the responsibility for tech support on your development team is how you increase your turnover rate.

Personally, I don't believe he's really doing that, I think it's just marketing.