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

271–280 of 732 posts

Re: Lessons from 14 years at Google

#271

Post by imperio59 »

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 sad thing is it doesn't have to be this way.

I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.

We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.

We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).

Everyone was a team working together towards the same goal of making these tools the best for our internal audience.

It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...

Re: Lessons from 14 years at Google

#272

Post by Rapzid »

martinpw wrote: post #244
avidiax wrote: post #200

Earlier quoted context omitted.

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…

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…

This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others?

There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.

Re: Lessons from 14 years at Google

#273

Post by disqard »

samiv wrote: post #74
ryandrake wrote: post #66

Earlier quoted context omitted.

While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.

That's the other side of the value added coin. Users sometimes find value even in the half assed software. Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".

> "solving the right problem wrong" vs "solving the wrong problem right".

That's a really useful framing!

Re: Lessons from 14 years at Google

#274

Post by dijit »

naijaboiler wrote: post #259
bigcloud1299 wrote: post #133

15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you i…

we are human being interacting with other human beings. what you call "kissing ass" is just learning to influence and work with other humans. It is by far the most useful skill to have in workplace. But don't worry. continue your disdain of it, includeing calling it negative names, and watch your career stagnate.

Sometimes.

Sometimes it's just bullshit.

Learn the lingo, the language, the proper way of posturing and the correct way to shirk responsibility and that's what matters in certain orgs.

I sound really bitter, but I'm not, I'm actually quite good at the game and I've proven that, I just don't really like the game because it doesn't translate into being able to take pride in what I've done. It's all about serving egos. Your own and others.

Every french multinational I've worked for is entirely built on this.

Re: Lessons from 14 years at Google

#276

Post by deepsun »

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…

> very single one of their services is a pain to use

Uhm, no? Google Cloud Platform is way more convenient to use than AWS, the IAM is way better designed, and documentation is leagues ahead of AWS.

Re: Lessons from 14 years at Google

#277

Post by dijit »

hansmayer wrote: post #256
dijit wrote: post #237

Earlier quoted context omitted.

> If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support. But even then, contemporaries outclassed Microsoft by a lot. It was culture back then to provide printed user manuals, I still have some from Sun Microsystems because it was the best resource I found to learn how storage appliances should work and the technical trade-offs of them.

Fair enough, everyone delivered software in boxes and with 500 page manuals. I still maintain MS did invest a lot in the quality of their documentation and they cared about developers - otherwise the Petzold series would have never happened (or the MS Press for that matter).

Ah yeah, fair, the Microsoft Press had some absolute bangers.

Re: Lessons from 14 years at Google

#278

Post by kenferry »

johnmwilkinson wrote: post #64

> 4. Clarity is seniority. Cleverness is overhead. Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice. I wrote a book that attempts to teach how to write clear code: https://elementsofcode.io > 11. Abstractions don’t remove complexity. They move it to the day you’re on call. This is true for bad a…

I agree with you re: abstraction - one of the author's only points where I didn't totally agree.

But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that has insufficient abstraction than inappropriate abstraction.

Re: Lessons from 14 years at Google

#279

Post by kiwijamo »

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…

I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major issues with the video quality. Teams isn't without its flaws and I do occassionally fall back to ZOom for larger group video calls but at the end of the day Teams video calling sort of just works fine. Not great but not terrible either. YMMV of course.

Re: Lessons from 14 years at Google

#280

Post by inglor »

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…

Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.
Post reply on HN