Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

Post reply on HN
Print view View original

261–270 of 732 posts

Re: Lessons from 14 years at Google

#261

Post by majormajor »

avidiax wrote: post #200
mike_hearn wrote: post #139

Earlier quoted context omitted.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users,…

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 "i…

There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support.

If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback.

Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information.

The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer.

A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.

Re: Lessons from 14 years at Google

#262

Post by librasteve »

wood_spirit wrote: post #247
martinpw wrote: post #244

Earlier quoted context omitted.

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where…

It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all. I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.

this

and I speak as one of the 90%

Re: Lessons from 14 years at Google

#263

Post by javawizard »

p1esk wrote: post #168
mike_hearn wrote: post #139

Earlier quoted context omitted.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users,…

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

Xoogler here.

When you get to a company that's that big, the roles are much more finely specialized.

I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager.

So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.

Re: Lessons from 14 years at Google

#264

Post by ipdashc »

dijit wrote: post #240
hnlmorg wrote: post #221

Earlier quoted context omitted.

I hate Microsoft with the passion of a thousand burning stars, yet even I still think Google products have worse UX than their Microsoft counterparts. MS Teams is definitely terrible. But I’d take that over Google Meets. Google Docs isn’t even remotely as good as Office 365. And Azure, for all its many faults, is still less confusing than GCP. Thankfully I seldom have to touch either other these companies half-baked…

> I’d take [teams] over Google Meets What? Why? Honestly your entire comment is almost exact polar opposite to how I feel. GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them. But, honestly, the Teams one is baffling. I can…

Yeah that seriously whiplashed me too, I'm genuinely confused. Google Meets has always worked completely fine for me, good performance, works well on mobile, Firefox, etc. Nothing special but it works. Probably my favorite of all the meeting apps.

Teams meanwhile is absolutely my least favorite, takes forever to load, won't work in Firefox, nags me to download the app, confusing UI. I don't think I've ever heard anyone say they like teams.

Re: Lessons from 14 years at Google

#265

Post by bitexploder »

hansmayer wrote: post #245
bitexploder wrote: post #219

Earlier quoted context omitted.

There is a lot of nuance to their point. They are saying, in the long run, career wise, focusing on the actual user matters and makes your projects better. Google UX is decent and the author was not trying to comment on UX as a thing at Google. More that, if you follow the user what you are doing can be grounded and it makes your project way more likely to succeed. I would even argue that in many cases it bucks the t…

> Google UX is decent and the author was not trying to comment on UX as a thing at Google. Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?

Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.

Re: Lessons from 14 years at Google

#266

Post by azangru »

avidiax wrote: post #200
mike_hearn wrote: post #139

Earlier quoted context omitted.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users,…

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 "i…

> The engineer is not supposed to engage directly with the customer.

I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but.

Re: Lessons from 14 years at Google

#267

Post by wdr1 »

hansmayer wrote: post #93

Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everythi…

> I wonder why Google UX always sucked so much

It depends on how you define "suck."

When Google first launched it's homepage, its emptiness (just a logo & search box) was a stark contrast to the portal pages popular, which were loaded with content.

Some thought the Google homepage "sucked" whereas other liked it. (I was in the latter.)

Likewise, the interface for Gmail. Or the interface for Google Maps. Or the interface for Chrome.

Re: Lessons from 14 years at Google

#268

Post by sefrost »

igtztorrero wrote: post #21

Great post, Years following Addy. I wonder know how he manages his time, in addition to being a leader at Google, and writing such a valuable blog.

Unsure why this comment appears to be downvoted!

I have followed him for a long time and learned a lot too. I always wonder the same thing about the “tech influencers” and I’d love to know more about how they structure their days.

I find it difficult recently to sit down and complete a meaningful piece of work without being distracted by notifications and questions. In the last year this has been exacerbated by the wait time on LLMs completing.

I would love to know how top performers organise their time.

Re: Lessons from 14 years at Google

#270

Post by majormajor »

liveoneggs wrote: post #252
martinpw wrote: post #244

Earlier quoted context omitted.

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where…

every customer complaint is N customers lost who don't say anything "the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush

If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers.

Nothing is knowable in only the same way that plans are useless but planning is essential.

Post reply on HN