[xoofoog]

Former Googler here. This person has correctly identified that a key reason why google sucks is that people very often...

> choose between doing what’s best for users or what’s best for their career

But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.

Imagine if people did get promoted for fixing bugs instead of building a new product (to be abandoned)! Or if maintaining an existing system was somehow on par with building a new system (which is just a bigger more complicated version of something perfectly good). The googler would say "well those useful problems are too easy to merit a promotion. Anybody can solve easy problems - we're google, and we're too smart to work on those easy problems." Grow up.

Y'all value the wrong things. That's why your culture is broken.

[lisper]

Another former Googler here (from waaaaaaayyyy back -- I was employee #104).

The reason Google is the way it is, and many organizations are the way they are, is that they are trying to reproduce the circumstances that led to their initial success. Google initially succeeded by solving what was at the time a Really Hard Problem, and so the people at the top want to reproduce that by encouraging people to solve more Really Hard Problems. Apple has fallen into the exact same trap. Their initial success came from building a Cool New Thing, and so they are constantly trying to build the next Cool New Thing. The problem is that at some point the product has actually converged to a local design maximum and so making further changes to it in order to produce something New and Cool is not actually an improvement.

But it doesn't work because it's sn inductive fallacy. Just because solving a Really Hard Problem or making a Cool New Thing led to success once does not mean that doing these things will lead to success in general. But the memory of that initial success is really hard to get past, especially when it was as earth-shattering as the initial Google search engine, or the Mac or the iPhone.

(Apple has actually done better than most companies at reproducing their initial success. They've done it at least five times, with the Apple II, the Mac, OSX, the iPod and the iPhone. But then there is the touch bar, the butterfly keyboard, the flat look...)

[brokencode]

I think Apple has done a fantastic job of incremental improvements on their products rather than chasing the next cool thing. Can you name a company that has actually been doing this better?

For instance, they often resist new technologies like high refresh rate or OLED screens, 5G, etc., until they feel the technology is developed sufficiently and won’t impact battery life. There are other brands that compete by making a list of features rather than a coherent product.

Of the examples you named, both the Touch Bar and the butterfly keyboard are gone now, and the latest Macs are the best Macs ever. That shows a willingness to try new things, while also showing that they have good judgement in the long term and a willingness to move away from what doesn’t work.

Also, the iPad and Apple Watch haven’t been as important to Apple as the iPhone, but they are still original and category-defining products that I would call innovative. Not every new product needs to double your company’s market cap to be a big success in the category.

[lisper]

> Can you name a company that has actually been doing this better?

No. But that doesn't mean that Apple hasn't fallen prey to this phenomenon. It just means that they set the bar incredibly high to begin with.

My first Apple was an Apple II, and I have never been without an Apple product since then. I currently own three Apple phones and eight Apple laptops. But for me the overall usability and quality of Apple products has been in decline over the last decade or so. I still run Mavericks on many of my machines because it was the last version of MacOS that Just Worked.

[majormajor]

The MacBook design has only changed step-by-step in small increments since the 2003 aluminum Powerbooks. The iPhone has pretty similarly used just a couple of basic designs since 2013.

So I'd definitely say Apple is best in class at incremental changes with the exception of the touchbar/butterfly MBPs. I'd just disagree with you over the quality: my M1 MBP is a big improvement over even the pre-touchbar ones in basically every way.

[lisper]

I'll see your M1 and raise you a trash-can Mac Pro, and the fact that anything other than a Mac Pro can't be upgraded.

But it's actually more about the software than the hardware. Once upon a time Macs were the computer that Just Worked. But recent devices, including phones, tablets, and laptops, have major usability issues. It's more about the software than the hardware, but with Apple you literally cannot separate the two.

Here are some war stories.

I bought a brand new M1 MBA. I installed XCode. The install process produced a tiny little progress bar that required a microscope to see. It got very near the end and then got stuck for several hours just short of being done. There was absolutely no indication whether the process was actually hung and no apparent way to inquire. So I tried starting XCode and it worked. I assumed that all was in order and the progress bar just hadn't gotten updated.

Then I updated the OS, which required a restart. But when I tried to restart I got a modal dialog saying that I could not shut the machine down because XCode was still in the process of being installed, and shutting down now could "damage my machine". Worse, the button to dismiss this dialog was inactive. There was no way to get rid of it. I ended up having to do a hard reset.

And this is just one of many, many similar experiences. I've tried transferring data from one iPad to another, waited many hours, only to have the process fail. I've tried importing old iPhoto libraries to Photos, waited many hours, only to have the process fail. When these failures happen there is no indication of what went wrong or what I might be able to do about it. Just, "Sorry, an unexpected error occurred".

I also really despise the new UI look and feel. Once upon a time it was easy to tell what was clickable and what was editable and what was static because all of these elements had different standardized looks. Now everything looks the same. Many UI elements are hidden until you hover over them. Apple devices have become the exact opposite of the easy-to-use discoverable devices they started out as. Using an Apple device today feels more like an old-style adventure game, complete with grues that randomly jump out and kill you for no apparent reason.

But other than that, yeah, Apple devices are great.

[quadrifoliate]

Apart from the look and feel, there are severe regressions with the operating system in a lot of places – external non-Apple hardware that would just work just fine on the existing OS stops working with a new OS version, etc. The quality of their OS has gone steadily downhill over the last few years.

At this point I would never do a macOS update unless I'm forced to do so for security purposes. I can't even begin to fathom why anyone installs the beta and does free QA for Apple.

I get the impression everyone at Cupertino works with only Apple Cinema displays and a lifetime supply of insanely priced Apple hardware; and no one bothers to test out compatibility with third-party devices at all.

[mrtranscendence]

I somewhat disagree?

To be honest, the current UI look-and-feel hasn't bothered me at all. I can't recall ever being confused by it (with one exception: iPad multitasking). Perhaps I've simply internalized it to such a degree that I accept it, warts and all, without thinking about it critically. But it's difficult for me to be too upset by a UI that really has "just worked" for me.

As long as my customized keyboard shortcuts still work, I'll be happy, I guess.

I also haven't experienced the software stability issues that you point out, though I have no doubt this is because I rarely do things like transfer data from one device to another (though when I have done so it's worked well enough). YMM(and does)V.

> I'll see your M1 and raise you a trash-can Mac Pro, and the fact that anything other than a Mac Pro can't be upgraded.

The trash can Mac Pro was a mistake, though at least it's one they eventually remedied. Their recent lineup has been almost universally praised, except for cost and (as you point out) upgradeability. I'm not too bent out of shape about upgradeability because I've never tried to upgrade a laptop, but I see the annoyance.

[lumost]

I haven't worked at apple, but I suspect that this is the result of only having <20 core products (including services such as the app store). This generally implies that there are a very small number of internal employees who built those core products, and in most organizations this leads to a resistance to change.

Some companies like to spam new products, others like to perfect what they have.

[judge2020]

Apple spent ~22B in R&D in 2021, but they definitely have large-scale decision makers expecting near-perfection on anything considered for released, probably before they even push it to DVT.

[lumost]

Resistance to change has an odd correlation with R&D spending. A company that refuses to change their products may spend more on R&D than one changing products all the time, as the cost of each change is much higher.

[dekhn]

R&D spending at FAAMG includes all software development work, regardless of whether it's research.

[nickelcitymario]

I'm not sure if you're saying it's a bad thing that they have <20 core products? I've always considered that a strength and a remarkable show of discipline, especially when they're willing to kill perfectly good products in order to create imperfectly great ones.

[guelo]

> both the Touch Bar and the butterfly keyboard are gone now

Everybody was surprised by that because they've so rarely admitted that they were wrong. It took Jony Ive's departure for it to happen.

[jfk13]

I realise it's uncool to say so, but I quite like the Touch Bar on my MBPro.

[macintux]

I find it valuable on occasion; I certainly understand why they were reluctant to give it up, but they should have either pushed harder for its success or given up sooner.

[thereddaikon]

I can't really think of anyone who has done it well but I don't think Apple has either. They have released plenty of half baked products. The original apple watch is a good example, it was retroactively made the Gen0 and quickly killed. They had similar problem with the first Intel macs too and the original M1s weren't 100% either. I think sometimes they over estimate how ready a product is. The iPhone was amazing at launch but in retrospect it was missing almost everything.

[brokencode]

I wasn’t saying that every product they release is perfect right out the gate. If your bar is perfection, then prepare to be disappointed.

But Apple will stick with a product and keep on improving it generation after generation until it is excellent. It’s rare to see them go all into something then give up to chase the next shiny project like Google does.

[apozem]

That makes sense. Googlers keep dumping out technically interesting products with no go-to-market strategy because one time doing that, they made a perpetual money machine (search ads). The problem is it’s 20 years later, technology has changed and not all markets are like search.

Throwing something out there is fine when it’s a magic website that answers your questions. When it’s, say, a half-baked messaging app none of your friends use, not so much.

[loudthing]

... the Lisa, the Apple III, firewire, calling wifi "Airport" for way too long, that home speaker boombox thing, the weird round mouse that came with the iMac, ...

But seriously, I remember reading on here a comment from a previous Apple employee that all of their products are designed with the primary goal of looking good in a keynote presentation, which makes sense for their image, but results in underdeveloped products that "disappear" after a few years.

[bern4444]

I think Apple continues to innovate in new product categories.

Apple Watch

AirPods

M1 Chip

Services (Apple TV+, Apple Pay, Music, Fitness, iCloud etc).

I include iCloud for services likeHide My Email and Private Relay.

They do this all while maintaining a consistent release cycle of upgraded versions of their hardware (new iphones, macs etc).

Also, everything in the list above has been developed under Tim Cook which is also impressive. He's been able to maintain Apple's ability to expand into new products and services.

[jldugger]

You realize that's his point right? Each of those is trying to be the Cool New Thing, and part of what distracts the company while it ships butterfly keyboards, touchbars without escape keys, AntennaGate, whatever plagued HomePod so much they quietly discontinued it. Polish and Attention To Detail is outsourced to execs, who are increasingly spread thin.

[vlovich123]

AirPods in their first year shipped more bluetooth headsets than the all bluetooth headsets from all other manufacturers combined ever (or something insane like that). AirPods by itself is a Fortune 500 company. Apple Watch is a Fortune 100. AirTags is a 1B revenue business.

Their scale is so immense that "flops" means "not a breakout success that resulted in a massive instantaneous increase to their bottom line". It also means the pressure is on them to have everything right (from the HW side) from the initial launch in terms of volume, build quality, reliability, & value add or they will have a meaningful setback to an expensive proposition (no room for exploring with smaller-scale things which is where competitors should start - Oura for example).

[bern4444]

But it hasn't distracted the company. Each of those things I listed are massive successes in their own right.

Not everything Apple does is a success, but they have gotten it more right far more often than wrong. The M1 chip affects also their entire existing computer line. AirPods work beautifully across iphones, macs, and ipads. Apple watch integrates flawlessly with my iphone (answer calls, play pause etc). These are accessory products that reinforce the main ones which they continue to upgrade beautifully every year.

They are able to balance both (Cool New Thing and upgrade cycles) and through it all, keep their product list to a relatively small number of items/skus. Compared to google who offers so many additional services and applications.

[gowld]

> ships butterfly keyboards

a Cool New Thing

> touchbars without escape keys,

a Cool New Thing

> HomePod

a Cool New Thing

Cool New Thing was not distracting from these things.

> Polish and Attention To Detail

gets harped on at Apple because they are so much better than everything else (and charge $$$ for it), that customers and opponents don't tolerate mistakes. Maybe being perfect is actually, really too hard to reach?

[LegitShady]

google should work on some really hard problems they've ignored - customer service, privacy, etc.

It's why the only business I do with google now is in places where they essentially don't have competition, and only when I absolutely have to.

[nunez]

seven times if you include AirPods and the Apple Watch

[svachalek]

Yup. I left a decade ago with this exact thought. There are people there who lift mountains to create real working systems, but you're actively discouraged from doing that if you want any sort of career there. And spending two weeks a year on performance reviews just serves as a constant reminder of those values.

It's easily visible from the outside too. The constant stream of one half-baked video chat solution or social network replacing the last one, without any sense of progress or continuity, why would a company do that? Easy, no one gets promoted for fixing anything, but creating the next broken thing? That's vision.

[jrochkind1]

I work in academic libraries. At the point Google Books and Google Scholar (two things that were relevant to my work) were being developed or very new, maybe 10 years ago now, I could actually talk to Google engineers about questions on how I could/should best integrate on my end, or problems or bugs (I did find some, that the google contacts agreed were). (It's true that cooperation from libraries/academic sector was something Google needed to succeed there too, to some extent).

Two years later... forget it. There was no way to get anyone's attention or a response about anything. This includes actual bugs and problems.

It was pretty clear to me then that there was nobody driving the bus on these projects anymore. There had been excited invested smart people around for the development, but once the thing seemed stable... there didn't seem to be anyone around at all anymore? I started to notice that this was how things worked at Google generally -- after a new product was deployed, there seemed to be simply nobody around anymore with the time and interest to act on bug reports, or talk to external partners, or just care at all. Without having at that time heard anything from inside the walls, that became my theory of how things worked at Google -- everything is abandonware.

So, yeah it's visible.

[esprehn]

> why would a company do that?

Or maybe it's because the company is always looking for the runaway 10X success story (like search, ads, etc). Incremental growth doesn't make a dent in the balance sheet. So they're always shutting down the products that didn't explode into a success and starting new ones to roll the dice.

[dogleash]

I don't think you're disagreeing with the parent poster, you just re-framed it terms that gloss over the downsides.

[blobbers]

"Easy, no one gets promoted for fixing anything, but creating the next broken thing? That's vision." -- svachalek

THIS IS A GREAT QUOTE! UPVOTE FOR REAL INSIGHT.

[mochomocha]

A friend of mine didn't get a promotion at Google because he was told that though his work generated >1B of revenues for the company, it was not "hard enough". He left the company.

[SystemOut]

This was one of the primary reasons I left. I had a project that enabled more than 100M+ increased revenue globally and the sales teams it impacted loved my work. But it wasn't considered hard enough or technically challenging work by engineering leadership so I got CME. That was it for me.

[ScoobleDoodle]

What does CME stand for?

Thank you for sharing your experience.

[murderfs]

Consistently Meets Expectations, one step up from "you are probably going to get fired" (needs improvement)

[oofbey]

Another example of this is their OKR system. If you meet all your quarterly goals at Google, that's not a success. In fact, you're frowned upon for not setting your goals high enough.

Their whole management process encourages people to chase after impossible goals, and literally discourages people from getting things done.

[jedberg]

Yeah from what I've heard you ideally want to hit 70-80% of your OKRs, and people game it to make sure they fail at one or two so they don't get accused of being "too easy".

[dekhn]

One of the most hilarious things I've ever seen was the head of Google Plus loudly sharing his "1.0 OKR" regarding social adoption at TGIF. It was about that time folks got suspicious and some long-termers found out Vic was lying about adoption rates.

[native_samples]

Oof. Is that really why he got canned. I'd always assumed Gundotra just made too many enemies during the period where L&S empowered him to do whatever it takes to win in social, and when he didn't win, he had burned too many bridges to stay. Lying about adoption is something I didn't hear before.

[twayt]

I’ve seen this in many companies other than Google and shockingly even at startups.

If setting an OKR is meant to focus the team and maximize effort towards solving those problems, this approach is counterproductive because it completely fails to measure the effort exerted towards a goal.

You could have a 1.0 OKR and you could have 2 cases. 1. Set it too easy, didn’t have to do much to achieve it 2. Set a hard goal and produce a Herculean effort to achieve it

The latter case isn’t accounted for. It’s is glaringly obvious but the dull manager types don’t seem to want to acknowledge the difference or the fact that the latter behavior, if incentivized, leads to better and more predictable outcomes.

Instead, the effort is met with a blanket: “Too easy, didn’t set a hard enough goal”.

This incentivizes people to set easier goals that they can meet comfortably and slack of 20% of the time so that it doesn’t look like the goal they set was too easy.

[tuckerman]

I've never seen or even heard of anyone throwing their OKRs to avoid the appearance that they were too easy. In fact, you rarely hear about another team's grading of OKRs at all. Plenty of teams inside Google also set OKRs expecting/hoping to hit 1.0 so it wouldn't be at all surprising to see lots of 1's/near 1's on teams.

[benlivengood]

My team (under ads SRE umbrella) usually did aim for ~0.8 with a 1.0 stretch goal of some sort. It was a fairly reasonable calibration to make sure we were scoping and planning OKRs accurately.

If every OKR got 1.0 it meant we could comfortably take on more work next half, below 0.8 and we would plan to do a little less next half.

In theory it would have been fine to score OKRs above 1.0 for stretch goals for the same effect, but the software didn't work that way.

[jedberg]

Well this was told to me by xooglers who were now working for other companies, so either they were the ones doing it and that's why they left, or they made it up to make Google sound worse. So I guess take it with a grain of salt?

[vrc]

12 years ago OKRs were huge. And yes, you graded them, managers and other teams viewed them, and you aimed for 0.7. Recently, it was a lot more lax. Many teams didn’t do them, drifted away from them, or didn’t bother grading them

[ShamelessC]

Here here! We don't have to believe everything internet strangers say. The presupposition that an unvetted internet comment will somehow become "vetted" by the probing of _another_ internet stranger doesn't make any sense.

[native_samples]

That culture came straight from Larry and Sergey. When I was there they would say at TGIF explicitly that if you score 1.0 they'd get suspicious because maybe you were setting goals that were too easy. Guess what, nobody ever got 1.0

[xmprt]

Missing OKRs always seemed a little weird to me. It strikes me as a lack of vision and makes the numbers and goals chosen seem very arbitrary.

[nine_zeros]

Missing OKRs means that the team cannot set achievable goals. It is a signal that the team has terrible foresight.

I know the argument is that by being more ambitious and achieving 70%, you are setting ambitious goals. But then the goals are never met. The work doesn't finish. The projects falter. The users are unhappy. Engineers leave.

[xmprt]

In my experience, people make 10 goals during planning and then later decide on the 7 that they're going to hit. I wouldn't mind if the goals were ambitious but efforts were made to achieve 70% of them. However, in practice it seems like there's no vision during planning and instead they change course midway through the half. What's the point of planning if you can't stick to the plan.

[JJMcJ]

Had to look it up. Objectives and key results (OKR, alternatively OKRs). More at https://en.wikipedia.org/wiki/OKR.

Hmm. If you are supposed to not meet all your OKRs, then that guarantees you will have a record of unmeet OKRs, which can be used as ammunition to deny promotion or even fire someone.

So that encourages a sort of favoritism, where the people you want to promote anyway have their missed OKRs overlooked, while the rest of the pack aren't meeting their OKRs.

[ericbarrett]

Never worked at Google but I have seen exactly this happening at other OKR-based companies. Ultimately whether missing your OKRs is framed as valiant struggle or disappointing failure does absolutely depend on external perception.

[autokad]

Tech Management wants to -not- promote people, so they try to make promotion difficult which inadvertently creates promotion driven culture.

For instance, if they promoted people for working hard, then everyone would work hard and we (high level management at tech companies) cant just promote everyone. so they make it arbitrarily hard, such as at Google "only promote people who solve hard problems". I think most tech companies will have some flavor of that, like at Amazon "work on projects that have cross team company impact".

Its all about trying to -not- promote people fokes, which ironically creates this promotion driven culture. After all, we are mostly college grads, and a lot of us are from the top schools (not even the majority, just a lot).

[titzer]

> Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.

It's partly that, but Google's counter has always been this refrain of "we are a data-driven company". I guess that is better than completely subjective metrics, in some respects, but it introduces another bias, which is focusing on things that can be measured.

I saw a lot of successful promo cases that were based on pushing metrics. That just rewards quantifiable things, and disadvantages unquantifiable things. Worse, it makes people introduce bullshit measures and game them. It's pretty much impossible to measure long term impact, but nevertheless, impact[1] was one of the main three drivers.

[1] Leadership, difficulty, impact are the three main components of a succesful packet, especially at L6 and above.

[mindcrime]

It's partly that, but Google's counter has always been this refrain of "we are a data-driven company". I guess that is better than completely subjective metrics, in some respects, but it introduces another bias, which is focusing on things that can be measured.

Being "data focused" is probably a Good Thing in a very general sense, but there are real dangers that come with that. For example, there's a form of "data myopia" you can develop, which is best expressed by the old saw "data and optimization can help you get better at doing $SOMETHING, but don't tell you if you're doing the right $SOMETHING in the first place."

I saw a lot of successful promo cases that were based on pushing metrics. That just rewards quantifiable things, and disadvantages unquantifiable things. Worse, it makes people introduce bullshit measures and game them.

And of course there's Goodhart's Law[1] which leads to situations where trying to be "data driven" actually makes things worse when people start trying to "game" the metrics.

[1]: https://en.wikipedia.org/wiki/Goodhart%27s_law

[somethoughts]

At least in my own small company - I'm hoping to promote the concept of the T shaped technical leader ladder.

You're rewarded/measured on two metrics - breadth and depth

- a depth metric - leadership in your own specific project team where you add features.

- a breadth metric - you've demonstrably shown that you've gotten other teams outside your own to contribute to your project effectively. Additionally and perhaps more importantly you must show that you can act in a supporting role on multiple other projects outside your own core project. Supporting other projects outside your core project include signing up for triage support, updating documentation, improving testing, etc. without frustrating the primary maintainers.

IMHO - focusing on depth as the only way to technical career progression leads to feature creep, ball of mud codebases with high barriers to entry and silo thinking.

Would be curious if/why this is controversial.

[zeroonetwothree]

I think both are important but it’s not necessary for any one person to excel at both. Some will naturally be better at depth and others at breadth. As long as you acknowledge both types of contributions I think it will work out well.

[somethoughts]

Good point! I think you're right.

So currently there are two narrowly defined options for career progression:

* technical leadership on core project/domain

* engineering management

Perhaps instead of eliminating the depth option for the technical track and making the T shaped depth/breath mandatory, just make it an additional option to provide an additional track for people to take for career progression.

* deep technical leadership on core project/domain

* broad-based technical leadership on core project/domain and supporting role on multiple projects

* engineering management

[sytelus]

You should reward only based on customer satiesfaction and adoption.

[somethoughts]

Agree - one feature that is missed w.r.t. long term customer satisfaction and adoption is long term support for previously delivered features. This is exacerbated when product managers/SW teams are mostly measured on new feature delivery metrics.

The full feature lifecycle and reducing bus-factor across the entire existing product feature set is rarely considered as its not generally captured in OKR metrics.

[gkop]

You could count the number of customer complaints. Oh wait, we’re talking about Google..

[TuringNYC]

>> But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.

Not saying this is the best thing, but it can get much, much worse at other places. I started my career at Accenture (then, Andersen Consulting). People go promoted for either sales (SrManagers or higher) or controlling issues (Managers and below.) Note, the aim was to control issues (documenting, writing up mitigation plans, briefing clients, deploying fixes, etc.) -- THE AIM WAS NOT TO PREVENT ISSUES. So code quality didnt get you promoted.

Several years in, a group of individuals passed up for promotion realized this all-together and literally started turning a blind eye to minor bugs, which eventually passed into PROD. Then they would solve them (which is what Management wanted.) Shockingly they got kudos for controlling issues. Many got promoted.

Set the wrong incentives, get the wrong behaviors.

[samhw]

> Set the wrong incentives, get the wrong behaviors.

I don't mean this as a slight at your comment - rather at the shockingness of the reality that your comment (really) needed to be said - but isn't this blatantly implied by the meaning of the word 'incentive'?? I'm astonished that people keep not realising this. The whole culture of OKRs/KPIs at startups feels like it's tempting this problem - I don't see why any but a very small number of companies should need to optimise metrics which are non-obvious. Having an OKR/KPI which one needs to deliberately decide on feels like a very pungent 'bad smell' of an XY problem.

[summerlight]

> the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.

This is the real problem, but people typically underestimate difficulty of correctly identifying "useful" problems at scale. Fixing a bug is nice, but correctly prioritizing bugs worth fixing is harder than said because most cases relevant engineers have limited contexts on UX and PM also has limited contexts on its difficulty. I don't deny that big techs have a bias toward solving "interesting" problems, but in many cases seemingly simple bugs are not that really easy to solve while not making any dent on business.

[ZephyrBlu]

> but in many cases seemingly simple bugs are not that really easy to solve while not making any dent on business

I work at a big tech company and see this all the time. Bugs that clearly exist and are impacting users, but they're hard to solve and have no or very little business impact. It doesn't really make sense to work on them, but it's kind of sad they just get left :/.

[lliamander]

> Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.

Playing the devil's advocate here, but shouldn't one position in the technical career ladder be correlated with technical expertise? Furthermore, technical ability is something that the employee has some control over: whereas impact to the business has more external factors.

The incentive problem to align people with the needs of the users is difficult. I imagine the best way to handle that would be through bonuses/profit sharing for high impact work, whereas promotions focus on difficulty of work.

[bluGill]

> shouldn't one position in the technical career ladder be correlated with technical expertise? Furthermore, technical ability is something that the employee has some control over: whereas impact to the business has more external factors.

Partially. Your position should be your technical expertise in things important to the company. There are a lot of technical skills you can learn that are not useful and so the time to learn them would be wasted at that company.

[lliamander]

> Partially. Your position should be your technical expertise in things important to the company. There are a lot of technical skills you can learn that are not useful and so the time to learn them would be wasted at that company.

I think that's a fair point, but I'm not sure it changes things a lot for companies like Google.

The more a company relies on technical innovation to provide business value, the harder it is to predict what sort of things actually align with business value.

To put it simply - we don't know what hard problems need to be solved. Having a place where really smart people have the autonomy to work on whatever they want is the best way to find out. This is the classic argument for funding basic research in the sciences.

[cbsmith]

> To put it simply - we don't know what hard problems need to be solved. Having a place where really smart people have the autonomy to work on whatever they want is the best way to find out. This is the classic argument for funding basic research in the sciences.

This really isn't the classic argument for funding basic research.

All you're saying is that it's hard to know what will prove to be a useful tool, and that's really beside the point for figuring out what should be rewarded. Absolutely having a commanding understanding of a broad set of technical tools should be a career asset, but it should be a means to an end, not an end unto itself.

You don't need to know what hard problems need to be solved to address the original criticism here. You need to understand what problems the organization is currently focused on, and solve those problems with simplicity and efficiency, even if that doesn't allow someone to show off that they can solve the harder technical problems than anyone else. The reward systems in the company should reflect that, and if it does, I would expect that people who could solve the harder technical problems would be more likely to be rewarded than others, but their skills would be much more likely to be directed towards simplifying and improving the efficiency of the company's execution rather than having a bias towards the reverse.

Now, another important skill at more senior levels is being able to identify new problems deserve focus (i.e. figuring out what problems are useful to solve), so that should also be reflected in the company's reward systems as well, but that is still an orthogonal skill to "demonstrates they can solve the hardest problems".

Think of it like product managers: if you primarily reward your product managers for launching new features, pretty soon your company will be weighed down in operational overhead from trying to support a cornucopia of features, many of which aren't particularly well done, rather than having a streamlined operation that delivered products that excelled at delivering on the solution they most wanted.

[majormajor]

Going off the description of "bugs being too easy" vs "building new things" - is "shipping a product without bugs" a worthwhile technical ability to cultivate?

I would argue that attention to detail and polish are important technical abilities, and that focusing your technical advancement path solely on less tangible-to-the-user abilities will cause you, as a company, to make less compelling products.

[ALittleLight]

If you are a developer who just implements what the PMs tell you to (more or less) then I agree that you shouldn't get extra credit when the project is a massive success. If the product earns a billion or loses millions you didn't have anything to do with that - you just implemented the designs of other people.

If you significantly contribute to the design of a successful project - that's different. But then, you should be making the case that you solved the hard problem of improving the design, not just that you were a good developer on a successful project.

[lliamander]

> If you are a developer who just implements what the PMs tell you to (more or less) then I agree that you shouldn't get extra credit when the project is a massive success. If the product earns a billion or loses millions you didn't have anything to do with that - you just implemented the designs of other people.

Actually I think you should be rewarded, just with money rather than a title.

[ALittleLight]

Why? Should you be penalized if the project fails?

[lliamander]

No need to penalize if the project fails. It's an incentive to encourage people to work on high impact projects. Especially important where people have some freedom over which teams they are on. Doing menial work that provides clear value to the company should be recognized and rewarded.

[ALittleLight]

If you aren't responsible for the project's failure, you're not responsible for the project's success, and rewarding, or punishing, someone for what they aren't responsible for is irrational.

[onpensionsterm]

That turns the incentive away from creating shareholder value and towards hazing and navel gazing.

There's also the issue of conflating the incentive/reward schemes with the need for roles to be performed. Being good at inverting binary trees won't make you a good manager but when the manager role carries money and prestige then it's the hammer you use to reward the shape rotators.

[lliamander]

> That turns the incentive away from creating shareholder value and towards hazing and navel gazing.

It's navel gazing until it turns into the next big money maker.

> Being good at inverting binary trees won't make you a good manager but when the manager role carries money and prestige then it's the hammer you use to reward the shape rotators.

Nitpick, but I was focusing on the non-manager track.

[ZephyrBlu]

Technical skills in isolation have no business impact. There's a reason that the higher up you go, the more business-y it gets even as an IC.

> Furthermore, technical ability is something that the employee has some control over: whereas impact to the business has more external factor

Rewarding someone for their skills in isolation makes no sense. The outcome is what matters.

[scarface74]

Having technical expertise doesn’t mean much of anything if it doesn’t positively impact the bottom line.

[lliamander]

If it doesn't impact the bottom line then business folks need to do a better job of capturing the value you could provide.

[scarface74]

Unfortunately, Google is a very much technology focused and not business focused. That’s why after 20+ years almost all of its revenue still comes from advertising. All of the other major tech companies have multiple billion dollar profitable revenue streams.

It even came out during the Oracle trial that Google only made about $26 billion in profit from the inception of Android to 2016. Apple makes more from Google in mobile by being paid for it to be the default search engine ($12-$18 billion a year) than Google makes from Android.

[lliamander]

> Unfortunately, Google is a very much technology focused and not business focused. That’s why after 20+ years almost all of its revenue still comes from advertising. All of the other major tech companies have multiple billion dollar profitable revenue streams.

Is that true of other ad-tech driven companies as well? Companies like Meta and Twitter.

Companies like Amazon, Apple, and Microsoft are used to charging users directly for some good or service. It may be that they are just better positioned to establish those other revenue streams.

[scarface74]

Twitter is not exactly a shining light on the hill as far as being a good business.

Facebook is also starting to see the issue with being a one trick pony.

But as for as Google, how many failed “other bets” have they been throwing money at since they were founded?

Google was founded in 1998. About the same time that Apple was close to bankruptcy.

One year they introduced three messaging platforms. How many failed first party phone initiatives have they had including buying Motorola?

Not to mention Google Fiber that left city streets ruined with “micro trenching” (https://arstechnica.com/information-technology/2019/02/googl...)

Since then, Apple has grown the Mac business, iPhone, iPad, “wearables”, and has a growing services business.

Microsoft built Azure, Xbox and pivoted with Office365.

Amazon (disclaimer I work at AWS), built AWS.

Google has a lot of smart people. But not a good business development strategy.

[joshuamorton]

So what happens when you promote someone for maintaining the same system for years? When do you stop promoting them? There's a person on my team who is happy to maintain what he works on. He has worked on fundamentally the same project for over a decade. He's a senior level engineer, and as far as I know doesn't have aspirations beyond that, which is perfectly fine. Assuming he keeps doing that work, and no more, does he get promoted again? Once? Twice? Does he become a principal engineer, for adequately maintaining his corner of the world?

The person who is really good and really effective at fixing user issues, first of all can't scale past a certain point, but second of all, likely doesn't have the the experience to design and shepherd the data storage system that also manages permissions across nested groups efficiently (one of these is what we'd expect of a solid L4, the other is https://research.google/pubs/pub48190/).

You're asking for title inflation. Is that really what you want? What you really want is a different role, "maintenance eng" who can get paid more for doing the same work they were doing yesterday, and who needs to reinterview for SWE roles, because its very quickly obvious that a principal maintenance eng and a principal eng do very different things!

[Zhenya]

Maybe instead of promoting, which is a stand in for $ and peer respect, you give those things, and/or provide a track which values being a domain expert+maintenance e.g. professor emeritus.

Building half working shiny things is bad for the company, and erodes user trust.

[jedberg]

You wouldn't promote them. But if they picked up a new system and started maintaining that one too, then they could get a promotion for expanding their scope and for getting more efficient at maintaining the old system.

Or, if they are both adding new features and maintaining them, then that could merit a promotion too. They are still doing innovative work, and they are maintaining it and fixing it.

[dudeman13]

>You're asking for title inflation

You're asking for feature bloat. If the only way of winning is getting new stuff done, new stuff will be done regardless of the benefit or cost to the company.

That does sound like Google alright, though.

[joshuamorton]

Yes, it is in fact the case that getting new stuff done is the only way to benefit the company. But new stuff != feature bloat. There's lots of new stuff that can be totally invisible to end users, and is deeply valuable.

Treading water should not get you promoted. That doesn't make sense.

[dudeman13]

>it is in fact the case that getting new stuff done is the only way to benefit the company

I spent a few weeks just refactoring 6k lines of code into +- 300 lines on my current job.

If my company was run by you, the best course for me woould have been leaving that mess around. Which would have led to either the same refactoring under far more stressful time constraints, or even more shit code by applying a band-aid into the old code (this code makes us some serious money, and an unexpected third party change would have broken it in such a way that would be seriously hard to fix with the old code).

Also, there are loads of features that were far easier to implement after the refactoring.

Maintenance job isn't coasting around. It has a multiplicative effect on anyone who works in the system. It needs to be done, if you want the org to not slow down to a snail pace - and when someone leaves a mess, it isn't even neccessarily easier than pumping new features since you have to figure out all observable behaviours from messy stuff.

If there's no incentive to getting your hands dirty, no one will want to get their hands dirty. People will fight to not do neccessary jobs if the only way of advancing their career is avoiding those jobs.

[joshuamorton]

> Also, there are loads of features that were far easier to implement after the refactoring.

Congratulations, you have demonstrated the value and made it easier to do something. As someone who has gotten promoted 2 times (and soon to be 3) primarily off of tech debt reduction and infrastructural improvements that don't themselves do anything, but drive future productivity, of course I think this is valuable. This kind of thing is literally the only work I do.

Now yes, there's a point beyond which only doing that work won't get you promoted, but that point is L5 where you're making 350K/year, and you can continue to do some of that work and get promoted further, you just likely have to

1. Get other people to also do that work 2. Do other work that acts at a larger scale

If you're actively adding new features to a service, you aren't doing maintenance. You're launching new things, and people get promoted by launching new things all the time. And people get promoted for making it easier to launch to features all the time.

[dudeman13]

>it is in fact the case that getting new stuff done is the only way to benefit the company

>[work that will] drive future productivity, of course I think this is valuable

These 2 aren't compatible. Seems like you've walked back on the former from this last reply.

[sytelus]

If a person is locked up in one feature/one product and unwilling to learn new things for the years then I do not think that person should be promoted. You can certainly give merit increases to keep up with inflation but that's about that. Ultimately, we all responding to market value of a person. That value remains unchanged for someone not learning anything new for years after the earned experience saturates. In many professions like doctors or pilots, experience never saturates and continues to increase person's market value however in other like cashier or barista that's not the case. So this opinion is job-dependent.

[lordnacho]

But the person might have the knowledge to build on whatever the system is, without having the mandate to do so. He'd still be the best person to modify the system, but for whatever reason the business doesn't need the edits. Should you keep him happy just in case or let him find another job and take the option to upgrade with him?

[thethethethe]

> So what happens when you promote someone for maintaining the same system for years? When do you stop promoting them? There's a person on my team who is happy to maintain what he works on. He has worked on fundamentally the same project for over a decade. He's a senior level engineer, and as far as I know doesn't have aspirations beyond that, which is perfectly fine. Assuming he keeps doing that work, and no more, does he get promoted again?

I know a few of these people who have been on the same product at Google for a decade and they generally cap out at L6, which is staff engineer.

L7 engineers are typically careerist and have larger a scope, focusing on higher level cross team collaborations. Some L6s are like this but there are plenty of them that are just chilling

[Manuel_D]

At some companies, this is broadly what "SRE" vs "SWE" is meant to capture. But the issue is that roles aren't very fluid, plenty of times SWE ends up transitioning to a role more resembling an SRE after building a system and reorienting towards maintaining it.

[joshuamorton]

God I hope not, SRE isn't a maintenance engineering role!

Improving the reliability of a system (SRE's ultimate responsibility) is deeply technically challenging work of its own, and one can encounter deeply challenging problems.

[Karrot_Kream]

The problem is that people think "maintenance" is a bad word. A company like Google is seeing growth from external customers, churn from their internal systems as internal best practices change, and changing threat landscapes on the internet.

"Maintenance" often is actual hard feature work. But when your org or company has a culture of thinking of maintenance as some low-level job, you get a culture like Google's.

[joshuamorton]

I don't disagree. I don't think maintenance is a bad word. But I do think that there is a point beyond which "maintenance" cannot grow. If you're maintaining a system there is a breadth of experience you cannot get. Being a senior engineer at Google is not easy. But my point is that sre is still fully capable of supporting L7 and L8 ic swes, while "maintenance" isn't.

[BurningFrog]

And this can and will go on until the $$ Billions from search/ads stop raining from the sky.

[usrn]

It's much more boring and you don't hear much about it but it's ultimately more pleasant to run things this way.

[hintymad]

Isn't this problem shared by pretty much every large company? Why is Google particularly bad?

[fshbbdssbbgdd]

I think Google has this worse than most because it has a relatively selective hiring process, large headcount, and is a mature company. The ratio of talent per scope is high, which mean there are less real problems left to solve per engineer.

[dane-pgp]

> the problem is that Google promotes people for "solving hard problems"

So you're saying that the incentives misalignment at Google leads to engineers who aren't self-deprecating, and products which are self-deprecating?

[mathattack]

What’s more import for Senior leaders to do - solve hard problems or useful ones? If it’s the former they’re doing the right thing. If it’s the latter that explains a lot of their deprecation issues.