There was no beancounter takeover and it never was so obsessed

Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google?

> only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team This revelation is utterly shocking to me. That's like anti-abuse 101. You infiltrate their networks and then track their behavior using your own monitoring to find the holes in your observability. Even in 2010 that was anti-abuse 101. Or at least I think it was, maybe my team at eBay/PayPal was just way ahead of the curve.

> User obsession means spending time in support tickets That's really funny when Google's level of customer support is known to be non-existent unless you're popular on Twitter or HN and you can scream loudly enough to reach someone in a position to do something.

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "impactful" work that's already planned. Customer relations (or the support team, user study, whatever team actually should listen to the user directly) doesn't want you doing their job better than they can (with your intimate engineering and product knowledge). And they don't want you to undermine the "themes" or "sentiment" that they present to leadership. Legal doesn't want you admitting publicly that there could be any flaw in the product.

Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.

I love reading this insights in a corp structure. Especially the sociological aspect of it (like "• It was viewed negatively by managers and promo committees."). Thanks a lot.

It is an almost universal fact that dealing with retail customers is something that is left to the lowest paid, lowest status workers and often outsourced and now increasingly left to LLM chatbots. While you obviously can't have highly paid engineers tied up dealing with user support tickets, there is a lot to be said for at least some exposure to the coal face.

"10. In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency. The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you. This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can." ------------------------ Point 10 makes it sound like the culture at Google is to stay within your own bailiwick and not step on other people's toes. If management sets a course that is hostile to users and their interests, the "sane and effective" engineers …