←back to thread

177 points foxfired | 1 comments | | HN request time: 0s | source
Show context
star-glider ◴[] No.43625781[source]
This isn't effective at a large org, but if you're running a small company/startup, just have an engineer "help out" with support every so often. We'd ask devs to run the support desk when the person was on vacation and also had a general rotation through.

It's good for building customer empathy but also for helping the people who build the product understand how it's used. The intuition you build up from those experiences is very powerful.

Also, about two hours into handling support tickets for the same issue, 99% of devs will just fix the problem. So you create a very elegant incentive structure for bugfixing that circumvents a lot of the traditional structural issues.

Of course you can't do this in a big company, which is one of the structural disadvantages that come with size.

replies(2): >>43626590 #>>43626938 #
kristianp ◴[] No.43626938[source]
Why can't you do this at a big company? If it had the support of management, you could.
replies(3): >>43627085 #>>43629715 #>>43638998 #
1. xyzzy123 ◴[] No.43627085[source]
"Support" is usually a different org, may be outsourced, may be centered in a different country.

The userbase is different, in a small saas company you will probably get fairly "high signal" complaints, this is not true for mass market products.

Fixing bugs is different, sometimes you need to cross 3 teams in different timezones and have a bunch of meetings to fix a bug. Often the real problem is that a business process or a legacy system is messed up and an individual dev is not going to have the political "swing" to be able to do anything about it.

Big companies are typically structured to limit the agency of ICs.