←back to thread

177 points foxfired | 4 comments | | HN request time: 0.464s | 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 #
1. 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 #
2. 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.

3. p_v_doom ◴[] No.43629715[source]
Problem is that most big companies have "professional" management. And professional management is stuck in completely outdated command and control thinking even today. Whether its people taught by other people at other big companies or freshly minted MBAs none of them really seem to learn or know how to really govern, create autonomy, etc. etc. and there is very little incetive to.When you get the odd curious one they go and find agile, and the first thing they run into is SAFE, LESS and similar, which is the same old taylorism wearing the fresh skin of agile on top like a horrible costume.
4. nitwit005 ◴[] No.43638998[source]
They will learn the deployment system some principal engineer in another organization set up is terrible, and will be powerless to fix it in any way.