Hacker News Reader

Comment by SkyPuncher | Hacker News Reader

Further, I'm not sure what efficiency it provides overall. Is dedicating 20% of your team to support _that_ much different than the entire team spending 20% of their time on support?

We've actually found our quality goes up massively when we force our engineers to deal with the problems in the features they ship, directly with customers. We still have dedicated front line support (that rotates weekly), but they run off a playbook for common support needs then delegate everything else out.

It really sucks when you get pulled into support a feature you launched, but it really makes you want to build your next features better. Better internal documentation, better customer documentation, better UX/requirements, better edge case handling, etc, etc.

View on HN

Would putting some percentage of the team on 'support' for a week or two help with reducing task switching and help to allow deep work? Maybe everyone in the team would spend 2 weeks per quarter or something like that doing support.

I (n=1) would prefer to be answering support tickets for 2 week blocks, and know when the blocks are in my calendar, so that I can plan work around them, rather than trying to debug something while I am being pinged about unrelated stuff all day.

hand-off needs to be really carefully defined and managed efficiently. Client tickets rarely respect arbitrary calendars, and the context switching alone can be really expensive. The best I've seen is a primary/secondary setup where you move from copilot to pilot, so you're not coming into everything cold

It's pretty hard to be fully hands off of customers. That being said, we don't expect immediate replies unless (1) you're the front line support for the week (2) something is on fire. We also don't expect immediate replies. Generally, within 24 hours is acceptable.

It's a bit of a drag, but most people just deal with their occasional support needs at natural context switches. First thing in the morning, before they head out, in-between meetings, etc, etc

> Is dedicating 20% of your team to support _that_ much different than the entire team spending 20% of their time on support?

Yes, it's [much] worse. Because nobody wants to be the support crew, so you end up with the 20% most junior, least outspoken people. Then the other 80% cares less about what support requirements will come out of the code they're writing because it's not their problem.

It's the perfect scenario for the aggressive prima donna who thinks their code is golden and everyone else's is dogshit.

I feel strongly that your front-line support should be full-time (not rotating) front-line customer support. That should be their job. If I reach out to a company for support I don't want my first contact to be with someone who writes code 95% of the time and this is their one week answering Zendesk tickets. I want it to be someone whose entire job is fielding customer issues and resolving them quickly and efficiently.

That's why you rotate everyone, not just those that "volunteer"... This way, you're spreading knowledge to everyone, e.g. if I'm forced to deal with an issue on code you wrote, I'm forced to learn about it.

Of course, I might have to ping you and get you to help me with it, so it's less efficient. Then again, if you leave the company, I have some knowledge about the feature, so... There's tradeoffs for sure.

I believe you're referencing the Engineering Management principle of "share shit work evenly".

Reply on news.ycombinator.com