4 ms·
There is very little incentive for engineers to spend a lot of time on support at big tech. In fact it detracts time from their projects which tie to their perf
by nvarsj 3y ago
There is very little incentive for engineers to spend a lot of time on support at big tech. In fact it detracts time from their projects which tie to their performance review.
Internally big tech would need to prioritise customer satisfaction as some OKR to incentivise engineers - but this doesn’t happen for some reason. As a result you’re at the whim of whether the engineer cares enough to spend time on your case.
Note in my experience AWS has great support - so their internal incentives seem to be aligned with customers.
- Amezarak 3y agoI see comments like this on HN frequently and I wonder what is going on with BigTech. I guess I wouldn't make it. Support is fun. You're solving mysteries and (hopefully) fixing them within the constraints of the design.
- InitialLastName 3y agoLevel 2 support is fun. Level 1 support is "dealing with an onslaught of people whose days have gone wrong, and they're sure it's your fault".
- nvarsj 3y agoIt's the performance culture at these companies. An engineer gets evaluated on metrics they move the needle on. At very OKR centric companies like Google, these metrics have to tie into high level business goals like revenue growth. I imagine it is pretty difficult to match customer support metrics to these, hence it's not prioritised by engineers or the company.
- supriyo-biswas 3y agoSupport engineers are usually a completely different team and unrelated to engineering teams.
- nvarsj 3y agoSupport engineers are first or second line support, and typically limit their scope to customer errors/pebkacs. If you find a legitimate bug, it is typically escalated to the SWE team's oncall who maintain the service. For example, I found a legitimate bug in ALBs (new at the time) and was talking directly with the SWEs who built ALBs.
- HeyLaughingBoy 3y agoThis is not a difficult problem to solve, if the corporation wants it solved. We managed it by assigning someone to support on a rotating weekly basis. During that week, project hours missed due to support tasks were acceptable. If you had a critical task due and it was your support week, you could swap support with someone, or we'd reassign the task. But with Software being the "last line of defense" after Field Service and Product Technical Support, we couldn't just ignore it. There are solutions. You just have to act like you want it solved.
- PH95VuimJjqBqy 3y agoI honestly think this is the best way to do it. I know a lot of software developers don't want to do this and I understand why. But there's nothing like an engineer seeing the struggles people have for themselves and choosing to fix it so they don't have to field that damned question anymore (I'm saying this tongue-in-cheek). Plus, you know as well as I do, the more people between your customers and your engineers, the more agenda's get injected into the mix.
- HeyLaughingBoy 3y agoThe company had a voluntary program (for a while) where you got to shadow specific local customers for a day. It was unbelievable. I had been there about 2 hours before I had a long list of potential product ideas just from watching this guy struggle. Not just with our product, but mainly with the interaction between all the different machines and instruments he had to use to get his work done.