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

331–340 of 732 posts

Re: Lessons from 14 years at Google

#331

Post by addaon »

websiteapi wrote: post #147
addaon wrote: post #136

Earlier quoted context omitted.

Omni Group. Wolfram. Parts of Apple. Rhino3D. Parts of Breville. Prusa (on device, not on desktop). Speed Queen (dial-based). Just from applications I currently have open and devices I can see from where I'm sitting.

I mean something that has a clear Google analog/equivalent that way can compare on. I personally think Wolfram Alpha (assuming that's what you're talking about) isn't any better than Google.

Never really used Alpha, was talking about Mathematica.

I don’t the the web is compatible with good UX, but that doesn’t mean good UX isn’t possible — it just means that the companies that are successful at UX build native applications, or physical objects, or both.

Re: Lessons from 14 years at Google

#332

Post by Rapzid »

majormajor wrote: post #285
Rapzid wrote: post #272

Earlier quoted context omitted.

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.

There's not enough hours in the day for everyone to do everything. > 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. Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And…

Poor leaders gonna lead poorly.

Re: Lessons from 14 years at Google

#333

Post by d0gbread »

sans_souse wrote: post #229
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…

To me; point #3 is the big one and it is in conflict with point #1

How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat.

Re: Lessons from 14 years at Google

#334

Post by asim »

This is good. I worked at google and lasted less than 2 years. Many other things happening in that time - came in via acquisition, worked on backend for that, dad died, transitioned teams, etc. But I was 27-28 and couldn't really navigate that world after my first job at a startup. In some ways, I wish I'd found a way, but in other ways, I know it wasn't meant to be. It's a good list, if you want to do 10 years at Google or elsewhere, internalise that list and it's lessons.

Re: Lessons from 14 years at Google

#335

Post by jordwest »

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…

> Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer.

Chiming in to say I’ve experienced the same.

A coworker who became a good friend ended up on a PIP and subsequently fired for “not performing” soon after he helped build a non technical team a small tool that really helped them do their job quicker. He wasn’t doing exactly as he was told and I guess that’s considered not performing.

Coincidentally the person who pushed for him to be fired was an ex-Google middle manager.

I’ve also seen so commonly this weird stigma around engineers as if we’re considered a bit unintelligent when it comes to what users want.

Maybe there is something to higher ups having some more knowledge of the business processes and the bigger picture, but I’m not convinced that it isn’t also largely because of insecurity and power issues.

If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.

Re: Lessons from 14 years at Google

#336

Post by globalnode »

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…

Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.

Re: Lessons from 14 years at Google

#337

Post by soorya3 »

This first 3 hit me very hard,

1. The best engineers are obsessed with solving user problems.

I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user.

2. Being right is cheap. Getting to right together is the real work.

- Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis.

3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.

- Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.

Re: Lessons from 14 years at Google

#339

Post by ngokevin »

j3s wrote: post #96

feels LLM assisted, at the very least. > The skill isn’t being right. It’s entering discussions to align on the problem > clarity isn’t a style preference - it’s operational risk reduction > The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate > This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone > The problem isn’t that engineers…

I've repeatedly told ChatGPT to stop talking like this (it isn't X, it's Y) every other sentence

Re: Lessons from 14 years at Google

#340

Post by bitexploder »

hansmayer wrote: post #286
bitexploder wrote: post #265

Earlier quoted context omitted.

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.

I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not?

Oh, I have no doubt they are at Google. I was just trying to say that the author was not really making a commentary on UX directly. The author was trying to make the point that understanding what sort of products and problems users have is a valid long term strategy for solving meaningful problems and attaching yourself to projects, within Google, that are more likely to yield good results. And if you, yourself, are doing this within Google it benefits you directly. A lot of arguments win and die on data, so if you can make a data driven argument about how users are using a system, or what the ground reality of usage in a particular system is and can pair that with anecdotal user feedback it can take you a long way to steering your own, and your orgs work, towards things that align well with internal goals and or help reset and re-prioritize internal goals.
Post reply on HN