[scrollaway]

Fully agreed. I'll go a bit further: Everyone, especially engineers and PMs, should once in a while actually reply to support emails. As CTO of my previous company, I still found time for large amounts of customer support, and so did one of my cofounders.

It's definitely important IMO for key people to be in contact with the userbase. Get a better look at what people are asking for, feel more directly responsible for both CS failures and successes, etc. And it overall increases the quality of support (rather than put people in CS who have no idea what's going on aside from the script they follow).

Key quote from the article:

> My experience with everyone reading support emails is, that everyone feel an increased responsibility and a sense of urgency to eliminate whatever emails hits your support inbox.

I am always sad when I see people who think doing customer support is beneath them. It's a red flag, IMO.

[chapium]

I'd like to add, shadow your customers a year after deploying your product. Engineers often blame the user, but users often end up using peculiar workflows to get around ui issues in your app, specific bugs, or other issues. Also if the user doesn't understand part of your product a year later, you probably should be improving that experience Either within the app or externally by improving documentation and providing training.

After some burn in time, is it really the user who is doing something dumb?

[kruczek]

While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that.

I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for intermediaries.

I understand the reasons for having engineers read (or maybe even sometimes answer) support emails, but still I'd be extremely wary of again working for a company that walks this path.

[anilakar]

The reason lower-tier support personnel are employed is because someone reasoned that the engineers' time is too valuable. If 90 % of incoming support requests will be escalated to developers, it makes little sense to have extra people whose main task is to create SAP tickets or press "forward" in Outlook.

Another extra perk of making devs handle the support is that they also have the chance to fix the underlying problem. Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.

[mike22]

For our on-prem enterprise software, we have two levels before a ticket reaches the dev team. Level one handles RTFM-type answers, and asks for log files (and then provide RTFM answers or engage a dev). Level two handles demos, implementation and architecture guidance, and reproducing more complex bugs. Dev handles the most complex issues that trickle down, and backup when staffing is short (mainly only around holiday weekends).

[MBCook]

> Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.

Don’t be so sure. Just because you’ve identified the issue or a good fix doesn’t mean the ticket won’t go in the backlog to die a slow death before you’re allowed to fix it.

[Aeolun]

Best way to make me improve software is to force me to use it.

[arkades]

> While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that.

I didn’t get that impression. The article mentioned reading these emails for 30m a week. Going from there to doing tech support yourself as a CTO is...

It seems to me that a CTO doing tech support either understand something I really don’t, or really fails to understand something I do. Superficially, it sounds like the sort of low-level digging around you get from engineers that got the CTO title but never got comfortable with the transition.

[scrollaway]

Obviously I wouldn't recommend people do full time support if it's not their role, and the larger a company gets the less practical it is especially in the executive roles.

But the attitude displayed in some of the replies is exactly what I'm talking about when I say some people think support is beneath them.

[edelans]

interesting ! Would you answer those support tickets as a CTO (I mean, with the title in the signature) or as a random support agent ?

question also works for PMs / devs / co-founders / ...

[scrollaway]

Never signed anything other than with a name.

[matwood]

Even if they do not reply, they should read every support email that comes in for the product/feature they worked/are working on. It is the best way to put themselves in the shoes of the user, and make better software.

I know someone will respond that they don't have time read all of the support emails, but my response would be that getting so many support emails is itself a data point.