The Google incentive mismatch: Problems with promotion-oriented cultures | Hacker News Reader

The Google incentive mismatch: Problems with promotion-oriented cultures

warp.dev

634 pointszachlloyd591 comments

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.

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.

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.

What does CME stand for?

Thank you for sharing your experience.

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

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.

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.

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.

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.

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".

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.

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.

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.

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?

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.

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

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.

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

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.

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.

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.

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.

> 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.

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

"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.

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.

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.

You should reward only based on customer satiesfaction and adoption.

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.

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

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.

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

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...)

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.

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.

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.

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.

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.

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

> 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.

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.

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.

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.

I think this is a topic about which people can reasonably disagree :-)

I'll just add that my complaint about inability to upgrade does not just apply to laptops. It's the whole product line (other than the Pro) including the Mini and the iMac. If I have an iMac and I need more RAM, I have to throw out a perfectly good SSD, processor, and display. There is just no excuse for that. I have a NUC that is essentially a hardware equivalent of a (pre-M1) Mini. The NUC is both smaller than a Mini and upgradable so I know it's possible.

You are correct to say there is no excuse for the lack of upgradability, but not for the reasons you believe.

There is no excuse because “excuses” are not germane to making trade offs. Apple chose to not make devices easily upgradable because it enabled them to be amazing in other dimensions (sturdiness, manufacturing efficiency, design, aesthetics, plus most users don’t give a flying fuck about upgrading)

Why would you need an excuse for defining your own products your way?

But this is exactly my point. Apple is optimizing the wrong things (for me) because it's trying to build Cool New Things rather than things that are actually useful. My NUC looks perfectly fine, and it sits under my desk so no one ever sees it anyway. It is superior to a Mac Mini in every conceivable way. It's smaller and it costs less for the same tech specs. The only thing that a NUC doesn't do that a Mini does is run MacOS legally.

> It is superior to a Mac Mini in every conceivable way

Based on the dimensions you feel are important and are visible to you. That is only one perspective on the elephant.

If you built that machine, and you made decisions that were not necessary tradeoffs AND these decisions went against your values, you would need an excuse. Apple is not you, and they do not need any excuses - they have a different set of values and built to those values.

Those values are what the market, aka other people, care about.

But you don’t have to throw those things away. Just sell it, for a decent percent of what you bought it for - because they have good resale value - and buy one with more RAM.

Then I have to transfer all my data. That's time consuming even when it goes well, and not once has that process ever gone flawlessly for me. Something always gets lost. Passwords. License keys. Settings. It has been a colossal PITA every single time.

> I can't recall ever being confused by it (with one exception: iPad multitasking).

Oh god, don’t get me started. Not a single thing in any field of technology puts me straight into confused-grandma-mode as quickly and thoroughly as accidentally going into multitasking mode on the iPad. Oh god how do I close the floating safari window I accidentally opened? Why does swiping it off the screen do nothing? Oh god now there’s a weird paddle thing on the right side, and now it’s… gone? Is that window just there running forever now? Or I drag it to the left and now… oh god now it’s in split view. How do I go back? I move the vertical bar all the way to the side and now I have two safari windows, but I can only see them for a brief period when I cmd-tab… somebody please help me oh god.

Granted, it’s a little better each release, and used to be so much worse, but it’s still ungodly awful and impossible for me to figure out. I wish I could just disable it outright.

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.

> 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.

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

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.

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.

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.

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.

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.

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.

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).

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.

> 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?

... 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.

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.

seven times if you include AirPods and the Apple Watch

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.

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!

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.

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?

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.

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.

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.

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.

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.

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.

>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.

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.

>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.

> 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.

>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.

No, they're perfectly compatible, you're just choosing to take an extreme interpretation of the first.

Like there is always groundwork that has to be done as part of the new thing, and doing that work is part of getting new stuff done. If getting new stuff done is the end goal, "getting new stuff done 5% faster" will obviously get new stuff done (and benefit the company).

> 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

> 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.

> 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 :/.

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

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.

> 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.

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.

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.

> 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.

Why? Should you be penalized if the project fails?

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.

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.

> 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.

> 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.

> 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.

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

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

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.

> 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.

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.

> In Louisville, Google Fiber reportedly was burying cables in "nano-trenches" that were just two inches deep.

> "When you're walking around the neighborhood, [the lines are] popping up out of the road all over the place," resident Larry Coomes said at the time. "People are tripping over it."

This is the most obviously Google thing I've read ever. Half-ass a job and then saying "screw it" and leaving because it's too difficult? Name another company that would do this. Not even Spectrum is this incompetent. They have the attention span of a stoned teenager. Their Toronto Sidewalk Labs also comes to mind. Probably for the best they pulled the plug early on that one. Imagine parts of your city just stop functioning because some private company got bored one day and left.

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.

> 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.

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.

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).

> 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.

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."

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

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

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

>> 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.

> 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.

> 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?

I spent over 9 years at Google. Got promoted 3 times. Was a manager.

Google is absolutely bonkers when it comes to promotions. At every opportunity to provide feedback towards upper management, I had one consistent refrain:

Everyone needs to chill the f### out.

The stakes (seem) too high. The amount of time invested is too high. The amount of discussion, rehashing, tinkering, rejiggering, and calibration is just too high. It's off the charts how obsessed seemingly everyone is about it. It's off the charts how much company time was blown on it and psychological stress people were subjected to. IMHO, the process at Google doesn't need to be readjusted or tinkered with, but somehow de-escalated; like it needs to not be such a huge f'ing deal.

One positive development ~5 years ago is that promotion to levels L5 and below were mostly moved out of the IC's hands and into their manager's. Despite being a manager at the time (and creating more work for me), I thought this was great. It reduced the bias in the system from ICs writing up their own packets, which disadvantaged poor writers and poor self-promoters less. It got employees thinking less about promotion, since there was less they could control or do. There were other biases that crept up, but it helps the psychology of day-to-day life to not be stressing over the frantic ladder climb.

Inevitable with bureaucracy unless we solve the oracle problem in a tragedy of the commons resistant way.

Can't speak to Google, but I can say that having ICs write their own packets has been hugely enabling for me at other companies. It means their success isn't reliant solely on implicit visibility of their work by me (which in turn meant I either had to maintain visibility on everything to the nth degree, get everyone to give constant feedback on each other, or fail to recognize their successes). I still come in and help consolidate and tweak it (I ask for a brag sheet from them that fits the packet format), with a 1-on-1 or three to ensure any questions I have get answered, and that we're aligned on the message, but taking it off my plate was -huge-.

As stated in TFA and throughout this thread, moving the burden to the ICs means they will be incentivized to focus on Promo Packet instead of real work.

No offense intended, but in your comment it comes off a bit selfish and bears the hallmarks of a classic archetype of terrible manager. I'd never willingly work for you. Being in management isn't for everyone, it's a people-focused domain. The whole job is about supporting the team and setting things up for successful outcomes.

There is nothing wrong with being an individual contributor. If your organization limits how far ICs can go, take this as a sign of toxicity and consider finding a higher quality organization to join.

Hey, agree to disagree on basically every point you make.

But, just to provide some context you're missing, I had someone promoted the last promo cycle without any mention of features or new products in her packet. It was entirely support work, tackling tech debt, etc, all of which was stuff she personally was passionate about, and which had led to her being passed over for promotion -for years- prior to my managing the team.

The incentive I'm working to create is "document your successes so we can ensure they're visible", not "focus on work that is by its nature highly visible", and, yes, definitely not "ignore the visibility of your work and rely entirely on your manager instead". It's no different than "maintain a brag sheet", except that I want them to be aware how that brag sheet feeds into the actual promo packet, and provides a common place for us to connect and discuss. If that means you'd never work for me...okay.

There is no single correct take, and I appreciate you filling in more of your perspective on the matter.

I'd be curious to understand what exactly you feel my points were, and why you think differently. I can't help but feel like I must be missing something or misunderstanding your comment.

Fortunately we're unlikely to ever collide in real life :). Again, I mean no disrespect. Genuinely would like to understand your point and see how it maps to higher overall team health and better output.

Sure -

>> moving the burden to the ICs means they will be incentivized to focus on Promo Packet instead of real work

Such has not been the case. In fact, I've had to repeatedly remind people to add things to their promo packet. The point is that documenting successes as they happen means they get to own their own visibility; I've walked into multiple teams where people chafed at being passed over, because their past managers didn't have suitable visibility on their successes, and so while the IC was like "I have achieved all these amazing things!", the manager was like "I can't make a strong enough case for them", and the net result was no promotion and poor morale. To fix that, I could either insert myself into everything to know who is doing what (slowing everything down, taking away their feelings of autonomy, and taking up all my time in doing so), and still risk missing things, or I can ask individuals to maintain a brag sheet that I can then rework into something to submit at promo time. Every task has value on a promo packet now, not just those leadership cares about/remembers, and in practice it has meant people take work that grows and challenges them, rather than just work that has innately high visibility.

>> your comment you come off a bit selfish and bear the hallmarks of a classic archetype of terrible manager

I mean, you're entitled to your own read on it, but in my book a terrible manager is someone who insists on inserting themselves into every little thing rather than trusting their team, giving them autonomy, and instead spending their time looking for ways for the team to function better, while clearing out people/organization/process obstacles. I've had multiple people say I'm the best manager they've ever had, as well as one person memorably fighting back tears when I told them I'd gotten them promoted (with a packet they filled out, then I reworked, as mentioned above) after years of being passed over for doing work that wasn't high visibility. You mean no disrespect/no offense you say, but that's a hell of a follow up, that I 'come off as selfish and bear the hallmarks of a class archetype of a terrible manager'. I'm not sure how to say this politely, but if you want people to engage with you, you really need to learn how to not come across as offensive; just saying you don't mean to be doesn't really cut it.

>> The whole job is about supporting the team and setting things up for successful outcomes. There is nothing wrong with being an individual contributor. If your organization limits how far ICs can go, take this as a sign of toxicity and consider finding a higher quality organization to join.

All of this feels very much a non-sequitor; I have no idea what I said that you think this runs counter to (since I agree with every word of it), and so I disagree with the implication that this is a relevant argument.

Wow, what a classy af response. You hiring?

This has been my experience too, and is a frustration for managers that, in my experience, ICs don't understand: we _want_ to help you. But we've got a lot of shit to do. So we need evidence to draw from to rep you to the Powers That Be, both formally and informally. I always tried to have good ambient awareness of what my people were doing and how they were contributing, but that gets stretched thin. I am not omniscient, and cannot, and do not want to, micromanage your every action.

The best solution I found is the one you described: get people in the habit of incrementally building a case for how they contribute. Some people bought into this strategy and they benefited bc I became way more effective in advocating for them, not just at set times, but always. Some didn't, and they were constantly dis-satisfied with the company, and with me. I never was able to solve the issue for them before I resigned.

Totally agree with this. I'm also an advocate for giving people substantial pay rises every year. It sounds profligate, but the alternative is that people leave for the so-notorious-as-not-to-merit-explaining pay bump one gets from switching company, and all your institutional knowledge ends up churning practically continually. It's probably the biggest thing I learned from my (former) time doing eng management.

(Also, fwiw, it's a non sequitur - I sat in Latin classes for 8 years and I still can't remember the conjugations well enough to explain why, but, long story short, it's a verb and so it doesn't obey the familiar rules of (even Latinate) English noun endings.)

((Also, that was a very classy and magnanimous response to a – speaking of the comment as distinct from its author – very classless and pusillanimous comment. Chapeau to you. I can't say I'd have managed the same myself.))

lostcolony: thanks for following up and clarifying. Your response makes it clear you probably aren't a googler or xoogler, but that's a plus imho.

You've persuaded me. You don't sound bad at all, and I'm confident I'd actually like working with you, and I apologize for jumping to conclusions prematurely.

Note to self: Ask better questions first.

Best wishes~

Hey, no worries. I'm not a googler or xoogler. It definitely seems like maybe what I said, the way I said it, viewed through a lens different than my own, may have come across quite differently than I intended it.

I can't speak to how particular patterns have played out at Google, I just wanted originally to respond that the advice being given runs counter to my own lived experience at other places. Not to undermine the original post, just to say it may not apply universally.

It's hard to believe that someone can write these sentences based solely on the OP's statement. You have no idea who this person is.

Some people think that if they look down hard enough at someone else, they can lift themselves up. Especially if that 'someone else' is someone clearly high-status by an agreed standard (which 'senior software engineer at Google' undoubtedly is, on this forum, no matter what we tell ourselves).

So the GP comes on here, sharing a perfectly nice and candid opinion, and our friend sees the chance of a lifetime ("terrible manager", "would never work under you", "management isn't for everyone", "find a higher-quality organisation", etc). Simples.

Can you please make your substantive points without crossing into personal attack?

https://news.ycombinator.com/newsguidelines.html

I did try to word it in a neutral way, but I'll try harder in the future.

Thanks for the feedback.

In a manager driven promo process, do you want gp in charge of whether you're promoted or not?

Thats a benefit to having ICs run their promo process.

Generally, I think freedom to have anyone drive an ICs promo process is better than forcing it to be one group or another. The IC might be best for it, or the manager might.

Regardless of who it is, the IC can work at gaming the system, that's just the nature of systems and abuse

I did my own promo packet at a large tech company and it was the most depressing, demoralizing experience I ever had. The packet had 10's of things mentioned in it to provide evidence for and I felt I have done 2-3 big projects and I'm mentioning same thing for every line item but that was because we don't produce one line item worth of evidence in one project. Eng promotions at large tech companies are the most de-humanizing, de-moralizing things ever. I got promoted but I felt my morale took a huge dip after starting promo process as compared to before.

It would be great if promo wasnt such a big deal. But when I look at the comp for an L3 software engineer, and the comp for an L5 software engineer, I have a hard time seeing how you could make people pay less attention to promo.

I guess you could switch the process to "promo after N years of not being fired at your current level" but that seems even worse.

Why exactly does it seem worse? Last year I switched from a FAANG to a Series B startup that does experience-based levels, and in my observation it's just better in every way.

Here's a blog post explaining their approach:

https://www.daily.co/blog/rethinking-levels-promotions-and-s...

Maybe it's not possible to switch from a cutthroat promotion-oriented environment to this, but it's worth thinking about for anyone building up a software engineering workplace.

“ We have around 50 people on staff, and for the past couple of years, we have leveled new employees based on years of relevant experience. We had three levels, each with a single, non-negotiable salary that was the same across locations, and everybody was assigned to one of those levels. We've always been completely remote”

I guess the main question that comes to mind is “why would a strong-performing, early-in-career engineer want to join?”

In other words, aren’t you capping junior hires to come from the bottom ~60%?

Normalizing pay to years experience is a bad move in general, IMO.

You are going to have a distribution of high and low performers at all levels of experience. If you pay all the senior people the same, you have less money to pay your high performers. And maybe they go get that pay from elsewhere.

There's a difference between having 20 years of experience and one year of experience 20 times.

If your manages appropriately manage the employees, it'd require letting go poor performance.

Even if you let go the poor performers, there's still a wide range of ability in the rest. It also means people will do just enough work to not get layed off (or appear to do that much work), because there's no benefit to doing better.

While I see your point, I'd argue with "there's no benefit to doing better."

People are motivated by more than money. Mastery, autonomy, and purpose come to mind.

I would expect the majority of people are more motivated by having some skin in the game than they are by the rewards of doing the work itself. I get great joy out of making my clients happy and solving hard problems (I enjoy rabbit holes), but even I get frustrated when there's no real advancement (financial or otherwise) for doing a better job.

The root of the promo and hiring problems is this focus on individual performance. The appropriate unit of analysis for most human efforts is the group level. Just have some livable base salaries, and then give everyone a big chunk of the profits each year.

I don't know if it's always true for people, but my performance goes up and down quite a lot depending on how much I believe in the group mission and the group dynamic. I'll occasionally stay late working for some abstract metric that might impact 10% of my pay, but I'll stay up 48 hours working fanatically to make something work for my friends and co-workers and the dream of success in changing the world that the group is striving for together.

And if that filters out the people that only do software for a princely salary, leaving the people motivated to transform the world for the better, so much the better. Greedy people are a bit demotivating to work with.

> The root of the promo and hiring problems is this focus on individual performance. The appropriate unit of analysis for most human efforts is the group level.

This is an awful idea.

Rewarding individuals based on the group outcome is a great way to drive rockstars away from the team. Why would any high performer want to anchor themselves to lower performing team members? That is a surefire way to get a lower bonus. Why would I volunteer to take on a crummy or particularly hard task when I can just hope someone else does it and I reap the rewards?

> I don't know if it's always true for people, but my performance goes up and down quite a lot depending on how much I believe in the group mission and the group dynamic. I'll occasionally stay late working for some abstract metric that might impact 10% of my pay, but I'll stay up 48 hours working fanatically to make something work for my friends and co-workers and the dream of success in changing the world that the group is striving for together.

Peoples' performance changes for every reason under the sun from "I decided to stay out late and drink on a Wednesday" to "my boss is an asshole" to "I just don't feel like working today". Personally, I want control over my own destiny and my own bonus. I don't want to feel obligated to push myself harder for someone else's bonus. And just the same, I don't want someone else's shortcomings to tank my bonus.

The actual answer here is to make sure that your review process accounts for how individuals impact the group dynamic.

> And if that filters out the people that only do software for a princely salary, leaving the people motivated to transform the world for the better, so much the better. Greedy people are a bit demotivating to work with.

This is a super ignorant take.

Any person who has a family and works to support them wants to provide the best they can for their family. That's not greed. Kids are fucking expensive by themselves, let alone trying to send them to college.

The best way for someone who wants to be a rockstar to win is by anchoring themselves to a low-performing team. If pay is based on relative performance, then you should find the lowest performing coworkers you can.

I wouldn't inherently mind explicitly tieing individual performance to (small) team level performance. In practice this often happens when management looks at performance holistically anyway.

>Why would I volunteer to take on a crummy or particularly hard task when I can just hope someone else does it and I reap the rewards?

When you are on a team that is committed to the success of a project or a real thing in the world, rather than hoping for a bonus, you help everyone on the team at each step of the process. If you enjoy the work you are doing, you'll enjoy the hard tasks; even the tedious tasks take on a certain type of satisfaction in a good job.

A team where people are sitting around for others to take action is not a good team or a good job. I encourage you to raise your standards.

>Rewarding individuals based on the group outcome is a great way to drive rockstars away from the team.

I don't care how many rockstars are on a team, I care if the team is transforming the world into a better place, is helping the company and humanity make the transition to "everything is software and networked" a thrilling transition. If someone is slower mentally but has a vision of a better world that the team is making happen, then they will probably move the team towards delivering on that vision than some smart but Blind obsessed person that wants the "FIRE" crap. Also, valuing money over all means your team will fall into traps like accounting irregularities more easily - lacking a sense of values outside of economic gain means the team will fall into things like the Enron mess or https://www.washingtonpost.com/archive/business/2005/03/22/t... or the various shady ad selling schemes or privacy selling schemes so common these days.

I've worked with teams where most people love the work and love the outcome of the work on the world, and I've worked where people are beset with visions of becoming some sort of rich software engineering lord, and it's a lot more fun in the former case.

People that want families and is supporting them are not doing software only for a princely salary. The thing that's awesome about a software career and families is that the demand for engineers means you can afford to insist on the flexibility and time-off needed by the family, and still get a livable salary.

I think it is primarily people who find a strong sense of identity in work and careers that think this way. For many, their passions lie outside of work and they do indeed want to maximize their value and time so that they can focus on things they care about.

So to say filtering out "greedy people" is quite demeaning IMO.

I don't mean the "slackers" that want to go home at a reasonable time and hike the Appalachian trail or rescue lost mountain climbers or whatever, I mean the ambitious types that worry if they are getting 185K USD instead of 205K USD rather than on making the digital transformation a really cool thing for humanity, and making products that they are proud to try to explain to their families.

As I feel the "digital transformation" is mostly handwaving BS, indeed it takes that increment of compensation (as much as possible!) not to perseverate on the worthlessness of that buzzword. I'm in the midst of changing jobs right now because I'd rather devote my efforts to the honorable (IMHO) concrete instead of being the DT advocate (one of the parts of my current job).

For one thing, Daily (intentionally) doesn't have a lot of junior engineers, so I don't really know firsthand how they feel about the system. It may well be that this appeals more to mid-career people with families and other life to worry about.

But consider that Daily is fully remote, hires globally paying SV-level salaries, doesn't do whiteboard torture interviews, and has an interesting product space where you can make a visible impact. I'd imagine this combination would be appealing to early-career people, especially if they don't live in a FAANG hiring market or aren't set on acquiring that kind of résumé.

> In other words, aren’t you capping junior hires to come from the bottom ~60%?

Why do you think you need the top 40%?

They mention this potential downside explicitly in the blog post. It sounds like they actually believe this is a good thing as it signals to junior employees that would need alot of support that they cannot provide it:

> The way we’ve set up our levels, people in the early stages of their careers can get bigger titles and raises more quickly at other orgs than they can at Daily. This will likely be a deterrent to some early-stage candidates, but we are ok with that for now. While we are excited to bring in early-career people once we have the structure to support them, we aren’t there yet, and probably won’t be for a while. We don’t want to make the mistake of hiring high-potential people we then under-serve, especially if they’re from groups typically excluded from tech.

Japan traditionally has that “getting promoted after X years” approach.

At scale it encourages coasting and not doing much until your manager moves on for whatever reason and you have a window into moving up. It also means the Peter principle is in competition with getting promoted while not being very competent.

I think there are specific fields and job where it’s a decent approach, but not at scale and not with salaries tied to promotions.

> I guess you could switch the process to "promo after N years of not being fired at your current level" but that seems even worse.

Ex googler here, and when I was there 4 years ago this was true of L3 and L4. My entire team was L3's and L4's. We spent literally all of our time on projects with no meaningful impact on the company, but that made for promo packets.

6 engineers focused on rewriting the form to input credit cards on YouTube for 3 years. Completely insane.

Sometimes I don't think I could make it at a FAANG, and then I read stuff like this and I don't think I could make it at a FAANG, but for different reasons.

It seems like a soul sucking marathon run by relentless ladder climbers fueled on concentrated avarice and amphetamines.

It’s not much different at large corporations, just far less money.

Large corporations?

Pick any company on the Fortune 500 and you’ll see the same behavior to climb the “ladder”. A small corporation could be less than 1000 or so people and might not have that culture as much.

I worked at a Fortune 500 and the ladder was floating in a mist of opaque fog, with inexplicably shifting rungs.

Upside was that many of us just said screw it and focused on the work. Downside was that many said screw it and went to other companies where they could at least grok the ladder.

Google only has a couple 100k employees at most. Other organizations dwarf that.

> soul sucking marathon run by relentless ladder climbers

The saddest part about the ladder is that it's not even fun. In academia, our ladder has fun names, and on each level you get to dress up in a different outfit that gets more elaborate the higher you climb on the ladder, which is basically the driving concept behind every MMO ever made, so that's cool. The whole promotion culminates in a parade and a blessing from the church elders, I mean University leadership.

At Google, they creatively dubbed the levels "L1-L10", and there's no outfit or parades. I assume they throw you a party or something at least? With cake?

Sure, the art faculties have the best costumes, but where I come from there was making vows in LATIN how cool is that (you needn't have to understand latin, just recite the vows is all fine)

If you need to ask, promo parties were suspended with the lockdown, but I guess they are gonna come back in style

> it seems like a soul sucking marathon run by relentless ladder climbers fueled on concentrated avarice and amphetamines.

That’s very inaccurate. Some of us use Ritalin instead.

Infinite marathon

> 6 engineers focused on rewriting the form to input credit cards on YouTube for 3 years.

Can you explain how this gets them promos? I feel like a promo-focused culture would result in 6 engineers creating a new server-side rendering framework so that they can improve credit card input rendering speed - possibly equally useless, but much more work.

Those rendering frameworks are being written as well, for no other reason than promo

>creating a new server-side rendering framework so that they can improve credit card input rendering speed - possibly equally useless

at the scale of Google I'm not sure I would consider that useless. But it would definitely feel useless.

> result in 6 engineers creating a new server-side rendering framework so that they can improve credit card input rendering speed - possibly equally useless, but much more work.

We didn't create our own, but we did migrate our codebase to a new server-side rendering framework twice in my time there.

Also, nobody on our team ever got promoted.

Yes, and it doesn't stop there:

L3: $192,064

L4: $268,758

L5: $358,423

L6: $502,465 (!)

https://www.levels.fyi/

Why dont people work for themselves, you can earn alot lot more, like over 20x more!?!

Please tell me how I can make $10M per year (20 x $502k) And I’ll quit my job right now.

Found startup, get acquihired in a year for $10M. There's risk involved, but there are certainly people who have managed to do this.

There's a number of other ways of varying risk/time/shadiness tradeoffs. Start VC fund, have $1B exit, cash out $70M carry in 7 years. Start hedge fund, raise $300M, earn 12% returns for 7 years, cash out $70M carry on $360M profits. Find a DeFi exploit, hack Ethereum, earn $300M in a 10 seconds, hope the Feds don't catch you. Lever up on real estate, put 3.5% down on 100 $300K properties, turn $1M into $20M as they've gone up to $500K over the past year.

The worst case when you fail to get promoted is still making salary at the current levels.

The worst case when you fail at a start up is years of lost time, money and health. And starting way behind others, should you(now that you are out of money, wouldn't you?) start a a job again.

The term mediocre is loosely used there, pretty much every one who starts a company fails, and thereby ends up being mediocre compared to a person working a job.

Salaried jobs have a better path to financial success than a start up, for nearly all the people.

I wrote a program which did months of coding in hours.

Is this juvenile? https://www.reddit.com/r/ProgrammerHumor/comments/ud3vhp/pro...

A bit of this helps. https://www.youtube.com/watch?v=d3hAnAnJwyU

Better than $500K/year plus best-in-class benefits and access to a large number of very bright people? How, exactly, did you manage this?

You might be forgetting self-employment tax there?

He's talking about making 10 million a year and you think the issue is he forgot the 8k or so of self employment FICA taxes?

Well he also added one too many zeroes, but that's just a surface level problem.

I've worked in UK tax havens.

At the end of 2008 I had to add 3 more zero's so a trader could be paid their bonus.

Have you seen how wide the bands can be (especially when factoring in appreciation)?

Some L4s can make more than L6s.

What is bonkers is that you can care about levels so much - but pay is wildly disconnected.

What's the point behind putting all this effort into it when at the end of the day it means almost nothing?

>What's the point behind putting all this effort into it when at the end of the day it means almost nothing?

At a company like Facebook, the difference between L4 and L6 is over $100k in salary, and $80k in stock (difference in 4 year refresh grant of $325k). $180k a year difference isn't almost nothing.

Not if the L4 started 3-4 years before the L6. Their original RSU grant might have been substantially more than they are handing out due to price appreciation, and thus their TC is much higher. This happened to hilarious effect at Amazon, where I had some coworkers that were receiving insane comp and were Sr, but not PE level. Originally they got a grant that was worth 500-600k that went up 5x.

price hasnt appreciated at meta lol

That's not L4 vs L6, that's start in 2015 vs 2108 or whatever.

IIUC, there's a >$100k range in TC (grants, bonus, salary) - WITHOUT appreciation for L4s. It's >$150k range in TC for L6s.

If there's a ~$180k difference between the average L6 and the average L4, and the bands are that wide - you have a lot of L4s making more than L6s.

If an L4 is "Exceeding Expectations" enough to get huge grants and bonuses, and an L4 is "Needing Improvement" enough to get terrible grants and bonuses... Why is the L4 an L4 and the L6 an L6?

Additionally, everyone has different (with big swings) of how much of their compensation comes from stock vs salary & bonus. When appreciation comes into play - this has large implications.

Additionally, people working between 2-4 years often make substantially more money than anyone else at the company in their current level.

Because you get less of an annual raise at the high end of the bands. This means if you stay at the same level you drift to the center of the band. It's better to be a the lower end of a band so the model causes you to drift up.

This is why promo culture is impossible to remove at bigger companies. Perks of promotion (higher salary, title, status) far outweighs just trying to do right by customers.

Whereas at early-stage startups, the only way to really make a lot of money is to grow the pie, which usually involves serving customers better.

Now that there are so many well-funded startups (https://topstartups.io/) there are more paths to escape the promo BS and still make a great living

Any promo process with any randomness (especially a promo process that changes over time as upper management changes) is effectively a stochastic version of "promo after N years after not being fired." I don't worry much about promos, but still randomly get promos because the stuff I found important for a few years was also nicely slotted into the promo standards at the time. And the obsession on titles and such book-cover-like triva does seem to get worse the more they try to systematize the process. When it's clearly equivalent to rolling dice, people worry less about it. The more rigorous they make the process and the more they have panels and packets and so on, the more people start introducing each other with their title. My first ten years in software, no one cared about titles at all unless you met with a non-engineering org and met dumb people with an exalted titles (in which case you felt bad; titles only serve to harm morale, they never improve it). The last ten years, people act like becoming Senior Principal Staff Engineer is like becoming a different sort of human. It does correlate with more pay, so it's hard to say it's completely trivial, but honestly, once you can afford a house or whatever, it's less important to happiness than fulfilling work, good co-workers, flexibility to meet your family or parenting obligations, autonomy over your work, and so on. One imagines one gets more autonomy by having a grander title, but really you get autonomy by just exercising the autonomy you have by being in control of the scarce and valuable resource of being able to create and improve software systems. If what you find important is valued by the organization you work in, then it will work out that people trust you, no matter the levels.

> but honestly, once you can afford a house or whatever

That's probably where Bay Area housing inflation has an effect - houses that used to be affordable to "normal" engineers are now only affordable to staff engineers. Tech companies are hiring more and more people scrambling for a fixed supply of housing. Of course it's dystopian!

I'm a staff engineer at one of FAANG and I cannot afford a house in bay area in 2022 (only considering prices and not the recent rate hikes). It's Sr Staff+ in bay area now for affording a decently sized house in a decent neighborhood that isn't too far from work centers like MV, SV and SF.

You are right. Till the time you have promotions tied with significant pay bump, you will have people working their a* off for promos and trying to do all it takes to satisfy criteria.

>I guess you could switch the process to "promo after N years of not being fired at your current level" but that seems even worse.

Though, If you do this you will have a culture where people are scared all the time and don't feel any job security.

> It reduced the bias in the system from ICs writing up their own packets, which disadvantaged poor writers and poor self-promoters less. It got employees thinking less about promotion, since there was less they could control or do.

I agree that this seems positive, but you lose some things with this sort of change as well. ICs often have knowledge of their own performance that their managers don't, even when you're having highly effective 1-on-1s. You definitely don't want engineers spending huge amounts of time and energy selling themselves, but you probably do want them to at least a little bit!

I have been using git logs and cvs logs to see who does what, across hundreds of developers, since 1997. I don't understand how people, managers, claim to not be able to figure it out.

And if people are doing work in an engineering organization that isn't backed by commits to some durable and versioned system, that is a huge red flag. They should probably not get promotions till they automate and make their work flow use version control. Even in the 90s this was true (the "install the OS on the new hardware" team would have things more automated than many "application dev" teams). Now in 2020s, the whole AZ should be in git and the change implementation procedure should be a variation on a big button that does "push master to n% of live; wait for monitor/validate scripts roll back or push more; repeat"

There is so much more to engineering than slinging code into the repo. Using commit logs as anything other than a superficial note of trivia is absolutely terrible for anything but the most junior engineers.

There is more to software engineering than just version control logs, but those artefacts should be accessible in the system somewhere, be they documents, diagrams, meeting notes, system logs (for software releases), etc.

There should be some way for a manager to see what someone has accomplished by the artefacts they have left on the company systems.

> It reduced the bias in the system from ICs writing up their own packets, which disadvantaged poor writers and poor self-promoters less.

It could be a blessing and a curse. Sometimes managers are rotated right before the next round of appraisals, and the new manager knows nothing about you or your contributions.

Even after the shift, both managers I had requested very firmly that I write the initial draft of the packet. I left Google in September and my last day was a week after packet due date. I straight up refused to waste my time on a packet when I should be documenting any and everything that people might need after I left. My manager put tons of pressure on me and threatened me saying I was burning bridges and that word gets around.

Definitely much more to this story, but they basically wanted you to do a part of their job for them. It's common and mostly understandable, as they might not remember everything that you did. They'll have to re-word everything anyhow.

I'd understand if we were asked to pick what we felt was worth highlighting and provide some supporting data, but we effectively were doing the same amount of work on our own packets as before the shift. Just with a due date a couple weeks sooner so our manager could have time to edit.

What is a packet?

A promo packet is a document explaining why you should be promoted. Includes link to the evidence, your design docs, your check-ins, and anything else you think might help.

It's a precis of what an IC has achieved over the last performance cycle. Can't speak for Google, but where I am it's focussed on the impact you've achieved in various axes.

At Google you do a "self-assessment" for your annual review, and you pick some number of peer reviewers who you want to also provide feedback. Your manager can add or subtract from this list. Your manager then provides that perspective and a rating that is normalized across the organization through managerial "calibration meetings".

This turns into your annual (sometimes 6 monthly) review packet.

In engineering, you and/or your manager can decide to put you up for promotion.

In this case, your review turns into a "promo packet", and it is sent to a promotion committee who decides whether you are clearly operating at the next level.

A critical point is that your peer reviewers can see a 'P' next to your feedback request, so they know if you are up for promotion. In theory, promo feedback should match normal review feedback, but in practice promo feedback follows game theory dynamics.

> it reduced the bias in the system from ICs writing up their own packets,

and replaced it with manager bias.

Google hires a ton of really competent and motivated people with low experience at a low level. Many times undeservedly so.

I’ve seen some phds with 3-4 years of experience being hired at L4 (starting phd level), some masters with 3-4 years of experience, sometimes even leading teams at previous companies at L3 and some experienced managers with 10 years of experience at L4.

Why do these people accept offers? Because although their level is lower, their comp is adjusted to the appropriate (higher end) of the level.

What you notice at Google is that projects and work are scoped to your level so that you can justify your promotion easily. So a PhD with 4 years of experience who’s completely capable of leading a project has to act as an individual contributor fulfilling others’ plans until they get promoted.

There are some exceptions but most people and teams in Google operate as though someone’s level defines their scope of work. Managers/TLs will often talk about how many LXs they have on the project and who is responsible for what kind of work.

So you have a ton of highly competent people hoping that their promotion will finally allow them to play at their true level and contribute in a way that will be rewarded.

A ton of such deserving candidates are passed over during promotion and this is very demoralizing. They still get paid handsomely so they don’t leave and continue to coast while looking for a better alternative (which is hard to come by).

Promos at Google are primarily about self-actualization. The comp is what prevents them from quitting and joining a startup.

This ^ Exactly this.

I worked at Google for a while. I started there at 50% more than my previous compensation, but two steps down in terms of responsibility. After a couple of years of my manager saying that I'd be ready to apply for promo when the current project finished and watching projects fly by, I started shopping my resume around.

Experience is not equal to ability.

That cuts both ways, ability to excel and take on responsibility within Google isn't equal to ability to succeed at Google. That's an argument against making outside hires start at a lower level.

Sorry, I meant "ability to excel and take on responsibility within Google isn't equal to experience at Google"

Your last sentence sums it all up for me. Having come into Google through acquisition (and product then killed off) maybe biased me, but still. That's how I see it.

I worked at Google for 10 years and didn't have more than a few minutes of job satisfaction and jumped from team to team hoping to eventually find a place where I could fit in and maybe get promotion. But I never went for promotion ever. The whole process looked meant to demoralize. I was clearly not a "culture fit" -- as they call it -- but somehow I soldiered on and nobody cared.

Until eventually, after 10 years of L4, it became clear me I had wasted 10 years of potential career progression because the money was (at least) twice as good as what I would have gotten in a smaller local company where I would have more impact and creative input. The rest of the industry was off doing other stuff, and my friends moving into lead and management jobs, while I putzed around moving protobufs (with just the right comments, indentation and stylistic flourishes) around Google's walled garden. Any interesting work was snatched up by others faster than you could get it.

Promotion level at Google is only loosely corelated with programming or engineering talent. It's a measure of political skill and motivation, and your ability or desire to thrive in a large organization.

Don't get me wrong, the money was excellent and my priority was feeding my family. But it wasn't "retire early" money, not without a lot of severe financial discipline and restraint anyways.

Google got lucky 15 years ago and managed to turn on an absolutely massive firehose of money in ads. Now Google hoovers up as much talent as they can in hopes that they'll strike it lucky and turn on a second or third revenue faucet. But spoiler alert: they never will. So they have to settle for attempting to starve potential competition of talent.

Occasionally I've landed a boring job with good pay. Yes, I'd keep an eye out, but while waiting I worked on floss projects. Not sure if that would've worked for you.

The problem with this approach is the FLOSS stuff being more interesting ends up impacting the success of $work, or the $work distracts you enough that you can never focus long enough on the FLOSS. Plus the guilt.

Plus, at Google in particular, you have to make them aware of your OSS work and go through the motions of getting the licensing set up so either they own it or you get permission.

Even if you "get permission" that's only for copyright. They still claim ownership of other IP (patents, trademarks, trade secrets), ... on _everything_ in your private life. I doubt it gets enforced often, but the employment contracts are draconian.

I'd say work on an existing project they can't wrestle control over. I am not your lawyer however.

This experience fits mine at Google too. If I had only pushed to start at level 6 my life would have been different. Instead I was level 5. My group was full of people at level 5 who wanted to be level 6. No one ever got promoted. I eventually left Google and have been principal and architect at other companies, like I was before Google. G did pay a lot.

How is 10 years of L4 ($270k now) not retire early money? That's double what the median earner will earn in their entire 40 years of work.

lifestyle creep. living in the bay area, kid or two in private school, driving a tesla... $270k doesn't go that far.

“living in the Bay Area, kid or two in private school, driving a Tesla“ is, itself, very far.

Yeah, I guess. I try to avoid that as much as I can, such that my rent is currently around 10% of net pay, but I constantly feel an urge to upgrade things (and do, eventually). But it certainly is retire early money if you can fight that urge even moderately. I make less than that and am on pace to retire at 35 with a comfortable middle class lifestyle.

> PhD with 4 years of experience

Google and other FAANGs pay very well, so it's not surprising they can hire PhDs but I sometimes wonder about the negative effects of vacuuming up so many research level people and having them do very mundane work.

It's an arms race. Promotion reviewers expect some portion of candidates for promotion won't pass promotion - otherwise the bar isn't being set high enough. The answer to this is that managers refine the promotion packets to ensure their employee's promotions are in the upper bracket - which in turn forces reviewers to recalibrate.

Eventually you are left with an over the top expectation of what a promotion case looks like. As an engineer at a FAANG I recently moved out of a team where I had built a range of services and was close to PE, because I found that I was closing in on a point in my career where I was spending ~80% of my time on promotion oriented activity... which in turn means politics.

How does the important, money-making stuff at Google get done?

It’s easy to demonstrate impact with the money-making stuff as you can put a dollar figure in your perf. The stuff that doesn’t get done as much is where your impact isn’t as easily demonstrated (e.g small incremental improvements that add up to a lot in term of overall quality)

Automatically.

Everyone else is eating the results of all that money-making in the many many cafes.

Actually, this is only true for SWEs. The money making at Google really runs on the insane hard work of its SREs and its data centre staff.

I often have the feeling that if almost everyone at Google just took a 1 year vacation, the thing would run itself. It's a money printer (search + ad auctions) surrounded by all this other busy work. Just leave the Borg to its business and take a break already.

It gets worse than promo-driven development.

Recently we had a chat with a lead from another team. Their product has a lot of similarities with ours so we sync up every now and then to bounce ideas off each other. They recently release a big change that we thought didn't provide much value, so we asked him about it.

His candid answer was "you know how it works, we have a service running in production, so we need to make changes". This sounds simple, but the implications are deep. Unlike individual engineers, moving entire teams around is difficult. If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.

I think this is one of the key frustrations I have with modern software development, change for the sake of change. I feel as though many products degrade over time and as a user I’m generally quite hesitant to upgrade anything if I don’t have to.

They have to show on investor calls the line went up.

We’re propping up the wealth of a generation that has no idea how anything works, but they got there first so of course they are now the de facto deciders of our agency.

True, it’s difficult to know how things work when they become needlessly complicated and one is unable to move on from a project that is essentially complete.

It’s presumed needlessly complicated is necessary to make the line go up; behind the scenes, they say, mathmagical forces exist that only the chosen few truly understand. You see everything is really a graph of infinite brand names, and the flow of value is determined by the taxonomy of brand ownership.

Many a study have been attempted to quantify what character qualities or technologies boost productivity. Their model becomes so nebulous no reasonable conclusions can be made.

But now of course computers learning helps us untangle that web and low and behold the same economic winners emerged! Wow!

It's a whole "growth" thing.

Like, it's not good enough to have a quality product that generates a sustainable revenue stream year after year. You have to "grow" because companies don't really do dividends anymore, they want a constant increase in stock prices, product be damned.

Arguably one of the causes of this is high salaries and only hiring (supposedly, I have no personal experience) Very Smart Developers. You're going to pay Google salaries for someone just to keep the lights on?

It would be a smart business decision. A Google mid-tier employee or two just isn't a large cost to keep a project running. It's not cheap, sure, but to have a product running at scale?

The rationale for developing Go is that Googlers are fresh out of school and only barely smart enough to program Java, so I think they’ve eased off on the notion they only hire super-geniuses.

I think it's more that they're smart as hell but know very little or have poorly developed taste. So you have to give them a short leash otherwise they'll hang themselves with it through over-engineering and accidental complexity.

The literal quote from Rob Pike is "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.".

The problem is a bit more insidious than that

As an engineer, you want to be working on cool new features too! Very few folks will be content sitting on their laurels just fixing the occasional bug or adding a touch more polish to a product that's already "done"

If you setup a team to work that way, very soon you'll find that most of your engineers have left. Heck, the manager might get bored and leave too.

"Okay, that's fine," you might think "The product is still doing alright even without an owner. Higher level leadership should be fine with that"

Until the day comes when the service crashes unexpectedly, and you realize that no one left on the engineering team has enough context to debug the issue properly

Hello two week long outage

Examples: Heroku - https://twitter.com/GergelyOrosz/status/1520770263977271296 Atlassian - https://twitter.com/GergelyOrosz/status/1513605414029516806

Isn't the 20% time to work on whatever cool shit you want enough ? (like how googlers created that garbage angular1 because they were border, have no clue about GUIs and had some fun scewing around ) ? I know people that are fine with getting paid to maintain shit so maybe the problem is Google only hires cool developers and the cool developers only want to work on cool stuff and in 2 years the newest cool stuff of-course.

It's a lie.

There is that too, but you could solve that by having engineers/teams working in new, cool, and useful products. I feel my company doesn't have a good mechanism to maintain services that aren't actively developed.

We experience it first hand when one of our services got deprecated and we moved to a new org. The solution was literally to hire a new team in a low CoL country and hand over the service to them. Needless to say it was difficult to hire for those positions.

Experienced something similar, but it was not an outage. Had several knowledgeable people leave the company, and they all happened to be experts in a particular service. Positions weren’t backfilled even though the people gave advance notice. About two months later we ended up getting out butts kicked when nobody knew the details of the service implementation and the service was expected to be updated to support some new features.. couldn’t get it updated for about 3-4 weeks because we couldn’t afford an outage.

> couldn’t get it updated for about 3-4 weeks

That doesn't sound like a large issue (but the details can completely change it). Maybe it was the right decision.

Arguably those folks who left didn't do quite as good a job as they perhaps should have when they were still there. A high quality developer leaving a service behind should have already written sufficient documentation so that another high quality developer (especially one at the same company) can ramp up more quickly than 3-4 weeks. I think this is just another symptom of many tech companies throwing up their hands and pretending like "legacy" services are inescapable technical debt, when really they just never bothered to emphasize to their employees that services should be built in a maintainable way from the outset.

This is true but only so long as they have been given time to do it. I've left a company, with notice, and they had me working on building stuff almost to my last day. Sure I did have a few "hand over" sessions in my schedule where I was expected to walk other devs through some stuff I was the owner for in a broad sense, but they never gave me time to produce solid docs for anything even knowing I was headed out the door

It can get worse: me and my teammate trained a new dev for half a year with the explicit intention for him to take over should one of us leave. When the day came, said new dev was moved to another team, the product was given to an outsourcer and I was told to train them how to develop in two 2h sessions before I left. (The product was a legacy mess we were in the (multi year) process of refactoring into something maintainable. Documenting the intentions midway or even the status before was beyond the time budget we were allotted. All of this while doing feature development, without having proper requirements or user stories or access to customers who understand their use case, of course.)

That sounds rough. It's very painful not having time to do things properly, and it's also painful when you don't have proper requirements so you can't even be totally sure what properly even is. I semi-recently left a job (the one I was talking about originally) after more than once being told "we just want a toy, proof of concept version and any time you spend on things like performance is a waste of time and we will scold you for it, even if there isn't any other work for you to do" before they decided to ship my "toy proof of concept" to a client requiring an ungodly rework of it while it was running in a production environment.

I honestly think people denigrate having at least some actual design work and requirements done upfront as being "too waterfall" and think doing it is a bad idea so we as an industry end up with not even the intentions of how a piece of code should work written down and no idea how stuff works once the original author moves on

That's exactly my point. If companies aren't expecting their developers to document their services - while the developers are still employed and building those services in the first place - that's a failure in my books. It's exactly the sort of corporate culture that props up this mindset of "promotion-driven development".

Ah my apologies, I thought you meant it was a failing of the developers themselves - which it definitely could be in some circumstances - and I felt the need to point out that a corporate culture can lead to docs not existing.

Kind of experienced that when interviewing for one of the well-known music steaming companies years ago.

They had one critical service in Erlang and the developer who coded it had left years ago and nobody knew the language so they wanted to rewrite it.

I was starting using Elixir back then and said I could maybe took that code over but they chose the other candidate ;)

Part of this is due to companies shooting themselves in the foot over and over, recruiting developers looking for challenges rather than grunt developers okay doing largely maintenance for a solid income. If they advocate themselves as providing the challenges for the former and filter out the latter, yes, obviously your employees are going to leave after they have to move that one div by 5 pixels for the umpteenth time and get no mental stimulation for months.

Does anyone recruit grunt devs like that? That honestly sounds like what I'd prefer. I just want to come in, keep the lights on, and have enough mental energy for other stuff after work.

I could see a market for that guy, and he takes 10 jobs like that Reddit thread.

All across corporate America, there are devs who make 80-120k a year and keep it 9-5 (but really like 11-2). Especially with the recent turmoil in the market, you can find a very easy yet well paying (for normal people) job. Now if only HR would advertise the jobs this way...

I don't know too much about Google, but I can talk about other companies. Everyone recruits grunt devs like that. That's what every job in Silicon Valley is. It's just that some companies and teams want you to spin it like you're some amazing lone wolf 100x genius while you're scraping dogshit off the bottom of the company's shoes.

A big part of it is that the executives decide what's making money for the company, and they'll focus on that. If you're scraping turds on the "rockstar" team in the "rockstar" org, you'll get showered with bonus money and RSUs. If you're scraping turds on a product that none of the VPs care about, you'll probably get screwed over. Some of the people in the non-"ninja"/"wizard"/"rockstar" orgs will do OK because they look like indispensable geniuses, and I think that's what a lot of this sentiment comes from.

> That's what every job in Silicon Valley is

I am curious - is this informed by your experience of having sampled every job in SV? Or perhaps a representative sample? Is it possible other people might be different than you and have a different perspective.

What a fucking joke of a comment.

Well, you have to maintain things after they're made. New things are usually made out of multiple old things. Figuring out how stuff works, then fixing and reusing, supporting, or replacing it is the bulk of every programming job I've done or heard of.

I can't even conceive of what programming job wouldn't be describable as "grunt work" from the point of view of some hypothetical super-genius. Writing "new" code that just does the same thing as something you're tossing out, but with a different set of mistakes? Cutting-edge science work is mostly glue code between hardware and spreadsheets or databases. Cell phone firmware is mostly repurposing and updating the old firmware. Anything involving a GUI is going to be a massive time-sink getting the GUI to work the way the non-technical people using it want it to work.

How much time do you spend in any given year figuring out how to operate debuggers, find the right log files, narrow down some crash, etc?

As you said, those are required components of shipping software. I don’t consider them grunt work, any more than I would consider being a janitor as a grunt.

Grunt implies a heirarchy and a job that anyone can do. It’s pejorative. There is work that I don’t enjoy doing but needs to be done well (cleaning a toilet). I appreciate those jobs even more than what I do!

My point is that you should try to shift to language of “work I don’t enjoy” rather than “work that is beneath such an exalted 10x programmer such as myself”. Because that’s how I interpreted your original comment.

I think you nailed the crux of the problem.

The challenge for engineering management is how to provide metrics to measure your bus factor reduction efforts and the strength of your insurance prior to the emergency.

It is highly possible though that the new support team members are actually coasting up until the disaster so you didn't really have the insurance you thought you were paying for.

You can find maintenance experts too. When someone tells me that they have this important, dangerous, buggy system wthat has trouble handling its ever growing load, and they need someone to come in and fix it, I cannot be any happier. But I know the system has to be really important, and that the fire has to be so bad that upper management is willing to spend the money to let some specialists come in, few questions asked, knowing that they will be rewarded as if they were building a new shiny, high visibility doodad. What is difficult is to have management that will keep that level of attention, instead of realizing that the reason that nobody has heard a bad thing from the system in months, if not years, is because there's a lot of work being done trying to make the system invisible.

What usually happens is that after a year or two they forget, and the maintenance programmer jumps to a different fire, typically in a different company, because there is far less reward to keep improving the system than to stop it from being a raging fire.

Yeah and this problem is exacerbated at Google by the relatively easy process of moving between teams. Other companies I was at made this hard. Google encourages it.

When friends complain to me about Google killing projects, they act as if it's upper management making a decision to kill. And that is sometimes the case. But often it's just: nobody wanted to work on it anymore. And Google isn't the kind of "command and control" culture where you crack the whip and tell all your engineers that they're doing X and assign them. At Google they'll just leave your org and move to some other team, and you won't have the power to stop them.

Not saying that's a bad thing, but it has some bad outcomes occasionally.

There are plenty of people who like fixing the occasional bug and adding a touch more polish. The problem is that this is actively disincentivized on every level. On top of that, a lot of people have internalized this.

If the world weren't so obsessed with differentiating pay, you would have people who are enthusiastic about a wider variety of things.

This sounds like Eric Weinstein's Embedded Growth Obligation (EGO) concept. Notably also occurs in academia and economics.

> If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.

This. It generates the Bullshit Jobs that David Graeber talked about. As a middle manager or tech lead (Taskmaster) you hire people (Flunkies) to make yourself seem more important as well as for roles (Box Ticker) that you might not need but that any "important" project will retain. In the end, this generates duplicate effort and needless work that requires fixing (Duct-Tapers). The only one of the five Graeber categories not represented is the Goon, and that's because those get moved to MTV and fast tracked to the executive suite.

> and that's because those get moved to MTV and fast tracked to the executive suite.

"The Goon" is the analyst from an investment firm who tells your directors and CEO how many of you are going to be fired to make him happy.

The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.

The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion. Everybody becomes "fake friend".

Were strict hierarchies really that bad?

It seems that just about anything else devolves into an ontological mess of Byzantine proportions. At one stage in my career I was reporting to 4 different bosses in this weird interleaved hypercube topology. I spent most of my time giving status updates

I do think more democratic, less hierarchical systems can work well if they're implemented in the right way. I saw a shift from that, where it was functioning well, to something more hierarchical and everything play out as this blog post is criticizing. It became really clear very quickly how aims shifted from more institutional mission-statement-type goals to promotion criteria and personal power agendas.

There's a limit I guess, but sometimes having multiple people to report to can lead to checks and balances.

I once had a similar situation and seriously contemplated building an application to manage my status updates so I could enter the raw data once and have all N people who needed to be updated sent the right information in the right way at the right time....

This is a great idea!

I think someone already built it… and called it Jira.

Seems like if your boss is a receptacle for status updates, the company is doing management wrong. Sure, it works less bad with one, but that doesn't mean it's good.

At least for performance reviews it's so much easier. If your boss hates you for some reason, that sucks, but you can just move on. It's a lot simpler than trying to please a dozen different people simultaneously though.

I have a scrum master, a product owner, a tech lead, and a team manager. All four of those are management relationships, but only 1.5 are hierarchal (the manager and sort of the tech lead). The most effective and efficient relationships we have, IMO, are with the scrum master and product owner, who aren't above us in a hierarchy.

There's no inherent reason for management to be hierarchically superior. If you want productive relationships, you have to level the power dynamic more.

Phwewww... this blog post and all these comments ring so true to me way outside of contexts resembling software development or business that it seems to me it's getting at something very fundamental.

A corollary to this in my opinion is that if promotion is expected at some point, I think the business/organization/institution has a responsibility to try to facilitate people moving toward that through mentoring or at least clear expectations. If nothing else, it makes the expectations clear, which clarifies how those might be at odds with other goals such as what the blog poster is articulating.

The "nobody dares giving bad feedback" thing isn't about retaliation (though I suppose that could happen). It's because perf is actually the worst place to provide "honest" feedback to a person about their performance.

It's complaining to managers/directors instead of talking to the person themselves (the recipient wont get to read your feedback for a couple months after). Even if you want to talk to a manager about some performance concerns, you should do that directly, instead of putting it in a record that sticks around for a persons whole employment

It's a bureaucracy game, and people who give bad feedback don't know how to play.

(I'm not endorsing the system at all, just rejecting the idea of it being retaliation-based. Anybody giving bad feedback doesn't understand what is going on)

Oh. I think I understand my work culture now. Thank you.

I worked at a place that did perf reviews every 6 months. 360 degree style, where you got manager feedback and a bunch of peers that you nominated. None of the feedback I received was ever actionable or useful. None of the feedback I gave was ever really useful, either! People rated you on a bunch of silly, vaguely described sliding scales from 1 to 5, then answered a couple of equally vague questions. It probably distracted people for 3 or 4 days, every 6 months.

All I ever got was stuff like "Joe writes excellent design documents! His code is always well tested. I always want Joe on my projects!" I'd write stuff like "Amy is extremely effective at solving problems with <blah> API's, and is a great communicator. She should do a brown bag session about her experience with <blah>." The reviews were all fluff. Some people wouldn't put in any effort at all, and write one liners. Seriously, one of my reviews was "Just keep on being Joe!" Thanks, but why bother?

The review process at most companies is a big waste of time and money.

I gave a coworker honest feedback during our 360 review period and now I feel bad.

It really depends on the corporate culture. The last review heavy place would put an overly positive spin on everything. In one review I wrote, I could've said "Jack's project has been taking an excessively long time to complete. He needs to work on delivering changes incrementally", instead I spin it as "I'm really looking forward to the delivery of Jack's work on X! He's been working on <initiative> since the last review cycle. It will be exciting when it is finally completed."

Leave it up to the manager to interpret and read between the lines. At the end of the day, the better managers know it's all bullshit anyway.

This is Amazon 100%.

It was actually a much smaller tech company! I hesitate to call it a startup, since it was well over 10 years old.

This sort of BS review process is pervasive in the industry.

I’d say this goes with letters of recommendation, too.

> The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.

Raising up and increasing the productivity of your peers sounds like a good thing. I think I'm missing how this is a bad outcome due to a perverse incentive. Are you saying the value extracted from peers is not real value or that the focus on your raising your peers detracts from more important business goals?

Your peers are rewarded for accomplishing their goals. In the best-case scenario, the incentive is to find ways to synergize your goals so you are all benefitting.

In the common-case scenario, you figure out how to bribe / cajole / coerce them into putting time in on your project and don't really care about how things are going on their project, because we're all responsible engineers who can time-manage ourselves, right? So you get your promotion and they get screwed because the work they did to deliver on something valuable to the company isn't reflected in their OKRs.

It degenerates what should be a collective goal of accomplishing the company's objectives the best way possible into a slotting game of making sure you're always listed on paper as being on the right project, because your work won't have value if you applied it outside your bullpen.

No good deed goes unpunished. No decent coworker goes unexploited.

> the focus on your raising your peers detracts from more important business goals?

It's this. Actually doing work is seen as simple and unworthy of a higher-level engineer.

Good engineers focused on problems (fixing complex bugs in distributed systems, adding fallbacks and failovers, improving the UI or performance of internal tools, etc) can add significant value to the company...but they won't be rewarded for it, because the perf process considers those to be simple, the domain of lower-level employees.

What the process _does_ reward is whitepapers, tech talks, daily updates, and delegation. It sometimes felt like the goal was to make every little change as noisy as possible: if you just fix something yourself, you get no points. If you plan it out, generate whitepapers, announce it, convince other people to work on it, send daily updates to every possible stakeholder and then a triumphant announcement, and then do a round of tech talks on every piece of it, you're a shoo-in for promo--whether on not the 'it' was actually important or valuable to the company.

Of course, people with those planning and communication skills are really valuable to a company. But somebody also has to do the work. Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet. And a lot of effective engineers getting frustrated and quitting because they don't want to spend their days working on slide shows.

It feels to me like the people in charge of the perf process just tend to overemphasize their own strengths and skills. Kinda by definition, the people designing the system are going to be senior people who are interested in communication and process, so that's what they look for in others. If they were the kinds of people who were interested in identifying and solving particularly devious or consequential issues on their own (or as part of one of their peer's projects), they wouldn't be working on the promo process in the first place.

It’s basically cargo cult engineering. There’s the appearance of engineering and sophistication but the actual substance is hollow.

Yep. The truth is, most of the work we do isn't that important, interesting, or useful, so the pomp and circumstance is necessary to raise its "visibility." Truly sad.

You described many of reasons I left a previous company. As one of the higher level engineers, I was constantly writing "tech specs", reviewing tech specs, doing code reviews (one week I had 12), and forced to present slide decks full of fluff against my will. Usually I'd push the slide shows off for a few weeks, but eventually I'd run out of excuses. Occasionally, I'd get to do some real work, but it mostly involved refactoring an almost decade old smoldering dumpster fire, so I left.

> What the process _does_ reward is whitepapers, tech talks, daily updates, and delegation. It sometimes felt like the goal was to make every little change as noisy as possible: if you just fix something yourself, you get no points. If you plan it out, generate whitepapers, announce it, convince other people to work on it, send daily updates to every possible stakeholder and then a triumphant announcement, and then do a round of tech talks on every piece of it, you're a shoo-in for promo--whether on not the 'it' was actually important or valuable to the company.

This is absolutely my experience at Google. If you want to move up quickly you have to write docs to convince people to work on your ideas.

> Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet.

This doesn't really align with my experience. Most people I interact with at Google do not try to do this. They are happy being ICs at L4 or L5 doing their own thing. There is plenty of room to be an L5 or even L6 IC without constantly self promoting, it will just take you much longer to get there and you will never move past L6.

> This doesn't really align with my experience.

Well TBF, I was an SRE while at Google, so I worked with a whole bunch of other teams. And tech talks were considered a good way for SREs to familiarize themselves with partner teams' various systems. So my calendar had several weekly meetings for tech talks and other presentations...and they were usually pretty yawn-inducing. And at the same time, I felt a fair bit of pressure to prepare talks about my various projects and present them: it would help to spread my knowledge and (ahem) raise my visibility. But they weren't interesting projects, and I was not interested in making presentations about them (or in general).

The whole point of a tech company is to pay engineers $X and find a way for them to create some over-unity multiple of $X in value.

If the problem is “this incentivizes engineers to make each other deliver more value”, that sounds like not a problem (and opens everyone up for increasing $X).

It’s a problem when you start to see your fellow employees as the competition instead of your actual competitors being the competition.

It's a problem for people who value working on things that actually get used for more than a few years and aren't duplicate efforts to make some line on some graph go up somewhere.

These are of course people, after all. Not robots.

> The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.

It's good to have people who understand the difference between the prisoners' dilemma and the iterated prisoners' dilemma.

The author did a really good job of pointing out problem of promo culture, but the solutions suggested are more inspirational than actionable.

All founders/execs/early employees are easily aligned on compabt success. But how do you align incentive of later hires?

In order to reduce time spent on perf, you'd have to rely on a few people who knows an employee's work instead of a larger peer group and committee. The person entrusted with this decision (typically the manager) now wields tremendous amount of power over others. This leads to a different set of problems, like "B player hires C player", yes-man culture, ICs spending effort brown nosing instead of creating value, etc.

Building a culture is all about incentives, it's easy to identify and reward user/company impact when the team is small. But as number grows, it becomes harder to do that, and the declared core values gets ignored as the reward system departs from that.

i remember reading in some startup oriented text that founder driven values works up to about 50 people. once your company grows beyond that a culture shift is inevitable.

i don't know what the answers are to manage that shift and avoid it going into the wrong direction.

Should avoid hiring people from big companies that are used to promotions every year.

No big company I know of, certainly no FAANG, anyone expecting to be promoted every year. Even every two years would be considered quite fast.

Doesn't Microsoft bump levels ~yearly?

Maybe just don't go above that. Whatsapp was at that level when acquired fwiw.

This echoes my read of this article as well. Any system for promotion has tradeoffs. You can't just say "this system's tradeoffs suck, we should have a new system with no tradeoffs."

I'll admit, I don't really have a good solution. My strategy has been to just stick to early-stage startups where everyone is aligned on company success. Would love to hear some more meaningful discussion of alternative systems for managing career ladders.

Experience points. Every you complete a task, you gain experience points. Gain enough, you go up a level. Flavor them for different job tracks, tweak the rewards to incentivize the behaviors you want and not the ones you don't. If someone isn't gaining experience at a good rate, take a closer look to see whether they are doing things that should be worth XP, or whether you need to have a different conversation.

Give people some choices on leveling up -- maybe most people just want a bump to salary, maybe other people would like to gain more vacation, stock, half days Friday, a private office, a good parking spot, etc etc.

The deeper issue you are pointing out is that only early employees get to capture the majority of the value while late employees only get the bread-crumbs. So everyone wants to be "early employee" of new products. In a way, this is inherent problem with capitalism where the idea is that if you have the capital, you pay the workers generating your capital only through return on capital as opposed to part of the capital. This way you can grow your networth exponentially in capitalistic system as long as you can begin with sufficient initial capital somehow. Anyone without such capital must live on month-to-month or year-to-year wages generated by the return-on-capital.

> The person entrusted with this decision (typically the manager) now wields tremendous amount of power over others.

This happens anyway in Google's "objective" promo system. Your manager assigns your projects, gives you your non-promo performance ratings, sets direction for your team, they sit in the room with the promo committee, and their feedback is critical to the promo committee's decision. You need their help and support to get promoted. If they didn't have significant impact on your work, they're not a manager.

Ostensibly you can go try for promo even if your manager disagrees. I never had any evidence this worked for anyone and I have no idea how it would work. Sometimes borderline promo cases would go up for promo when their manager thought it was unlikely, and it would succeed. But if your manager doesn't think you should get promoted, they're going to tell the committee that, and I don't know what the promo committee would see that would cause them to overrule the manager.

I worked at companies where managers are little tsars of their turf, and Google.

The difference with Google is that: 1) you can give feedback to your manager, both anonymously and explicitly, and they'll affect their perf; and 2) your success, in terms of impact and promo are part of your managers success; 3) perf committee will challenge and can override your manager if the rating given seems too low/high given the evidence.

These forces while do not take power away from manager completely, they provide some checks and incentivize managers to respect and support their reports.

Of course, all these nice things come at a cost, that is perf becoming a somewhat transparent and heavy process that eats everyone's time and mental energy.

I've been on promotion committees where it was clear that the manager didn't support it, but we promoted the candidate. I feel like most of the memorable discussions in those committees were figuring out how to give the manager feedback on how bad of a job they were doing.

I agree that you're basically screwed, especially L3->L4, if your manager isn't actively counselling you on how to grow your career. You obviously don't have enough experience to do it on your own at that point, so you are at their whim. Even when you do have the experience, if you don't have a good working relationship with your manager, you're in trouble anywhere. It is ultimately going to be them or you, and you are easier to get rid of ("he took another offer" versus "everyone thinks your manager is a jerk, so we fired him, oh by the way in the meantime your career is on hold while we figure out what the fuck to do please keep showing up").

Yeah, I agree with you totally. The promo culture is certainly broken, but the solution they propose seems....like startup worship at best, exploitation at worst (work harder without a payout and be happy).

I don't know what the solution is. I've been at amazon, and the number of abandoned promo projects are insane. Microsoft has like 7 billion levels, maybe they have it right, you can promo someone without it meaning a whole lot, but it still gives them greater pay and a sense of progression.

> The author did a really good job of pointing out problem of promo culture, but the solutions suggested are more inspirational than actionable.

Totally agreed.

One thing that killed my motivation in mega-corp(tm) is that your peers are, in reality, your competitors, despite the constant barrage of HR propaganda indoctrinating the opposite. Either directly or indirectly, you are incentivized to take high visibility projects for yourself, take credit for other people's work, and reinforce a narrative about yourself where you are better precisely than those around you.

I used to manage engineers at another large tech company and this was a big problem. There was nowhere near enough big projects to get everyone the evidence they needed for promotions.

As a result we ended up doing two things a lot:

1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)

2) de-prioritizing important things that were small in order to ensure everyone had a big project every quarter.

We ended up having to hire contractors to work on the small stuff because it was piling up and causing problems.

> 1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)

Ideally this gets people fired, not promoted. Google explicitly calls out "solutions to hard problems are easy to maintain" on its ladder, for example. People can fail to identify these cases, but the intention is to promote based on hard problems rather than complex solutions.

I think there just aren’t enough reasonably solvable hard problems. All the low hanging fruit is taken, and the result is artificially complex solutions as a way for engineers to demonstrate craftsmanship.

Do they consider fixing easy bugs are hard problem? Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?

I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.

No, this wouldn't get someone promoted, because it doesn't actually solve the problem. The problem here is that the triage process is a mess. Fixing that, so that bugs don't bounce around for months, would probably get someone promoted, or at least be a significant factor.

What if the solution to that hard problem is improving the incentive structure and paying/promoting people for fixing bugs? That's something only ELT or SVPs can do and they aren't getting promoted for that.

If you think the problem can only be solved by management attention, and you cannot demonstrate to your management that the problem is impactful enough that it deserves their attention, either you are incapable of making a clear enough argument to focus on the right problem, or the problem isn't actually as dire as you think it is (or management is bad and wrong, or at the very least mismatches your values).

Two of these are a signal that perhaps you shouldn't be promoted. The third is a signal that you should leave.

In a less generic sense, I think that there are almost always ways to improve incentive structures and encourage people to focus on specific problems that don't directly involve SVPs. Your manager has some control over your rating. If you can argue that "customer happiness" should be a priority and as part of that, end to end bug triage time will impact ratings, you have successfully created an incentive structure that will reward that, without involving anyone who can modify compensation structure.

Many outsiders have noted that googles incentive structure is not around customer happiness in general. Thus articles and discussions like this one.

You're mixing two problems.

Is the issue that Google, as a company, is not addressing user happiness enough? Or is the issue that some organization is letting bugs languish? The first is a much harder problem than the second. You don't need to solve the first to fix the second. I stand by my claim that it is feasible to address the first as an L5, that could reasonably get someone promo'd to 6, and you wouldn't need to involve anyone above a director to do it. Of course, doing so would involve writing very little code, because so much of this is procedural and political, so the engineer who just wants to be rewarded for fixing bugs wouldn't take the initiative to solve this problem. But alas.

Sorry but shouldn't you have just taken the initiative and fixed the bug yourself? This is the sort of thing I would hope a company would reward - not passing the buck.

If that's "below your pay grade" _and_ you're still capable of doing it, well that's kind of the problem then, isn't it.

> Sorry but shouldn't you have just taken the initiative and fixed the bug yourself

Why should I spend a week learning a different domain when someone with experience in that code can possibly fix the bug in an hour? Passing the buck to the right person is the correct answer when you are not an expert and someone else is. Passing the buck too many times happens very rarely, most of the time it is the correct answer, so long as you pass it to the right person.

I can go into anyone's code and fix a misspelling. However if the problem is less obvious someone with experience can take a few days off my time just because they don't have to figure out how the code is supposed to work before figuring out why it doesn't do that.

> Do they consider fixing easy bugs are hard problem?

No.

> Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?

No. Grungy work has to get done, but it also won't build a promo case. If a leader isn't finding ways to make sure that the grungy stuff is being completed then they are a failing leader.

It's all about how you twist it. If you say "I built 2 new services that could have just been a feature in an existing service" then you'll probably get a bad review.

However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.

> There was nowhere near enough big projects to get everyone the evidence they needed for promotions.

Would the goal be to promote everyone? Who's going to do the work they all used to do?

It's a retention issue. If people don't level up fast enough and get raises they'll leave for another company.

This is underlying problem with promotion culture, I am in a big financial firm, my whole team wants to get promoted every 1-1.5 year. I feel people are not really learning how to write and manage software systems properly due to this.

At Google at least, if you stay low level for too long, you get fired. If your team is full of low level people maintaining a project that's stable, you need to invent work to justify your existence.

You only need one promotion, L3 (entry level) to L4 (mid level), to not get fired at Google. And the company is quite generous with how long it gives you to get there. L3 to L4 is basically about writing good code on your own, and isn't really affected by promo culture -- doesn't really need shiny work.

Several years back, you had to also eventually get to L5. This was more affected by promo culture, but was also largely unenforced, which is why they get rid of the formal requirement to get to L5.

It was worse than "largely unenforced", it was unevenly enforced, depending on your management chain.

> L3 to L4 is basically about writing good code on your own, and isn't really affected by promo culture

I'm unsarcastically glad that you had a different experience at Google than me. This was not my experience, nor the experience of anyone else on my immediate team.

It sounds you had bottleneck in product management pipeline. Product managers should generate enough creative and significant features to justify stream of large projects.

Meanwhile at Apple, there aren't product managers and the business doesn't create an expanding stream of new products.

Sorry, can't comment on this, never owned anything from Apple :)

YES!

I worked at a start-up that was later acquired by a mega corp. When it was a start-up, it felt like we were focused on growing the pie. Once we were acquired, everyone just wanted a bigger slice for themselves.

I also felt like we had a ton of terrible presentations, and it felt like a braggy culture whereby you had to promote the work you did and make it seem more important. The reality was we all knew who the good engineers were and who the bad ones were. It was just annoying to have to listen to people talk about a widget they'd built that tbh nobody really cared about.

I worked with people to make their talks less about promotion and more about education; that at least made the presentations bearable and engineers felt like they might have learned something from them. Eventually though I realized I didn't want to be in that sort of culture and joined a smaller company.

Yes. I worked at a big fintech company and all people cared about was marketting what they were doing and never solving the actual problem. Everyone knew who the bad developers and bad leaders were. No one did anything about it. At the end, my friends and I left because we were fed up

My experience has been that some companies pressure engineers to want to advance. If you come into a performance review and say "actually I'm happy where I am" it's seen as a lack of motivation and will count as a mark against you. I had a boss say to me "I always want to move to the next level and I expect the same of my reports". Whatever, I guess I'm a poor employee because I like my job.

I’ve openly stated that I want my retirement job to be an SWE3-ish role somewhere. High enough to have interesting, somewhat challenging work, but with negative desire to climb the ranks any further.

Problem with that is due to inflation, you're making less and less compensation every year. Standard "you're doing a good job" raises often do not meet inflation, and certainly are not right now where inflation is higher than the recent historical mean. This is not a problem for some people, maybe including you, but I think most people have a general vague career expectation of making more when they're 60 than they make when they're 50, than they make when they're 40, and so on--even if they don't plan to be an overachieving "ladder climber".

I may have been unclear. By retirement job, I meant a job that I took during (read: after) retirement, not the one I’d walk away from at the moment of retiring.

At that point, financial arrangements are presumably already all set.

You can always move to the same level in a different company to readjust your pay.

I agree, but this isn't as bad as you might think once you're a senior engineer at a top-end company. A lot of your compensation is in the form of stocks that will appreciate in value with inflation, so assuming you're in good graces with your director and VP, it's possible you'll fall behind the market rate very slowly

If you had a paid off house, and no kids to take care of, you should be able to live off a junior engineer’s salary no problem.

That reminds me of the guy getting a burger flipper job in the film American Beauty.

i want to retire as an engineer. If I went management I'd be much more likely to get to this high paying jobs in the executive suite. What I don't want is to be doing the same thing again and again with no recognition of how useful I am. If I'm not useful, then I need to get into a different position.

Can confirm, it’s a great choice. Step one, convince a FAANG/MAGMA to let you work remote at the same salary level you already have. Step two, move to an extremely cheap cost-of-living area. Step three, avoid promotion at all costs, and just fix bugs.

Provide value, but _never_ get promoted. Every year come review season, talk about how your goals for the next year are to improve latency/perf/whatever. It doesn’t have to be specific, just something that’s important enough to be useful, but don’t be ambitious. Just keep your head down and make enough improvements that people consider you to be a good “grunt” worker.

Yeah yeah, inflation sucks and technically I’m making less because my RSU’s have mostly vested and my yearly grants haven’t made up for it, but I don’t care. I’ve saved up enough that I could retire now if I really wanted to.

Every day for me, I work 9-5, fix a few bugs, provide some value, then work’s over and I get to play with my son and completely forget about my job. Then once he’s in bed I smoke some weed, watch shows with the wife, talk about the good old days. It’s heaven.

(By the way, I say all this, but I kinda failed at it because I got promoted last year anyway. I got hella worried because I thought they’d start expecting more out of me, so I actually slowed down my pace even more. I just got a mid-cycle bonus last month. Maybe I’m not so great at keeping my head down after all…)

The demand for “reliably and undramatically accomplishes needed tasks” far exceeds the supply.

I hope I can down level myself after I go over 65 or 70 (depending on my health of course, hopefully I have that option). I think it is an option at some companies (older talent getting ready to retire but still have a lot to contribute).

Some (many?) companies have an 'up or out' requirement where each position has a time limit to get promoted, unless it's a 'terminal position' which is ok to stay at.

When I was at Facebook, this was administered by using the next level review guidelines after you had a position for N months (depends on the position), and if you don't meet those expectations, putting you into the firing pipeline (PIP, etc). One of many reasons I was happier when I stopped having people reporting to me.

Only true for E3/4. After that you can stay forever. I know someone that’s been E5 for 12 years

I just want to say that I can't believe some of the smartest people in the world are willing to put up with all of this off-putting corporate bullshit. No disrespect.

I'd argue they are far from some of the smartest people in the world. Smart? Sure, some (many?) but I've known quite a few idiots in software. But I'd hardly compare the regular software engineer at a FAANG to some of the geniuses in the world.

But they put up with it because it's a career and not a job. Many of them couldn't handle a minimum wage or working class job. No breaks, short lunches, no wriggle room for life, permanent fast-tracks to firing.

I dunno, I would say on my whole in my 10 years at Google I really did meet some of the most talented (in terms of raw knowledge or focus or some other skill) people ever in my career.

But they were mostly being paid handsomely to apply those amazing skills to really humdrum tasks -- but painting them up to be really profound -- and that's the saddest thing.

I would say that a high affinity for playing the games invented by others for the rewards invented by others is orthogonal to raw intelligence. In fact, smart people usually have a lifetime of being rewarded for exercising their intelligence on command. Where are they supposed to learn a healthy disrespect for authority when they have always been the darlings of authority?

And now you know why Google, etc. have a strong bias for hiring out of academia and out of the higher levels of education. (Not just because the founders never worked industry, just academia, when they started Google, but I digress...).

The interview process is highly highly biased towards recent grads (algorithm/data-structure courses) and the kind of people who do super well in university show-and-tell.

I've experienced managers pressuring me to either go for promo or find a different team.

I have worked in three FAANG's and that was not true in any of those once you reach a certain level. This is somewhere between 4/5. The reason is that at that point the employee is considered mostly independent and can be expected to solve their task without too much intervention.

You are being pressured to get higher salary for the same level of work you are currently doing and this is a problem? Strange.

What often happens when an employee doesnt get promoted? they leave and usually are able to get that next level role in another company. Why is that?? Why does the current company require employees to show a track record and data points to be promoted, while they hire externally for the same position and often only look at resumes, interview and maybe an assessment. Why isnt it the same bar for internal vs external.

I think promotions to the next level should just be considered a new job (in the same company), and you don't 'win it' or get promoted - instead you apply for it and go through an interview process. If you study/train and get through the interview, then you get the job and all it's benefits. This way, employees can focus on doing the right things for the company and if they feel they're ready for the next level, apply for it.

If they don't get it, its based on merit - they can go back, get more experience/study etc. and reapply later. Their ego isn't destroyed, they're not pushed to to do the wrong things simply to get promoted, and I bet most people will remain at the company.

I think promotions to the next level should just be considered a new job (in the same company), and you don't 'win it' or get promoted - instead you apply for it and go through an interview process.

That sounds like a recipe for an incredibly toxic environment. Not only are you hired for a specific pigeonhole, you are expressly forbidden from progressing through it: at least in some sane companies promotion is preceded by already having done the new role for a time and the title jump merely formalises the situation.

In fact, I thought the pigeonhole hiring in traditional finance was bad enough. You just managed to outdo decades of dysfunction in one try.

The last thing we need in tech is a codified caste system.

The other posts in this thread make it sound like internal promotion has higher barriers than an external apply/interview/offer process. Bizarre when you think about it, but it does seem to be the norm. The person you're replying to is suggesting that employees should be encouraged to apply to other positions within their current company as if they were an external hire.

I've worked at a company that did both (internal promotion and internal re-hire) and IME people that actively applied to new positions had faster "career progression".

It’s far easier to get a boomerang promotion at Amazon than it is to work through the process.

codified caste system? Have no idea what you mean.

You're hired for a position, when you feel you're ready for the next level you apply, if not, just continue where you are. This doesnt mean you dont get paid more the better you perform. Why do you need someone above you to say you're ready for the next level?

When professors apply for promotion from associate to full in academia, and they don't get it, do you think they apply again? Clearly you would have to jump to a different company in your case if you are denied the first time unless there has been a total management turnover.

That just gives you a huge incentive to apply externally, which most employers don’t want.

not at all - i think it's the opposite. Why apply externally, when you know the ins and outs of the current company and have to go through an interview process anyway

That’s the problem the GP is describing though: it’s easier to get a promotion externally than internally. Their proposed solution wouldn’t really improve things but companies have got themselves into a really weird position when boomeranging is an efficient promotion path.

> they leave and usually are able to get that next level role in another company.

how do you know that's what usually happens?

I worked at a company with a process like that when I was an "Engineer" looking for a promotion to "Senior Engineer", at least for me it felt insulting that I had 3 years of performances reviews "exceeding expectations" and "already performing at the level of Senior Engineer" to then be told, ok now you have to do an interview and a presentation to say why you deserve to be promoted to Senior. I declined to go through the process and then left a few months later to become a Senior Engineer at a different company.

> What often happens when an employee doesnt get promoted?

They try again next cycle.

This all sounds nice but it's missing the concrete details and that's the most important part.

"Build into core values wanting to create a culture where the end-user is the priority, not individual advancement up the ladder"

Is there any non-exploitative way to interpret this? The only thing worse than wasting my time on features for promo rather than users is working overtime to make more money for those with significant equity/ownership in ways that will never seriously affect my comp. Without promo or "promo by a different name" i.e. money, how do you incentivize people? How do you decide who to allocate your finite equity and money to?

Why combine two problems working overtime without compensation and promotion focused culture?

A culture where I'm supposed to be working for "the user" rather than for my own benefit is inherently exploitative. Employment is a contract. If I stop delivering value, the company will fire me.

As they say, the reward for being good at your job is more work. Expecting me to put in top effort for "the users" without compensating me doesn't work.

The idea that you can fix this with culture is wrong. It's been tried many times at many companies and it doesn't work for anyone but the owners. Unless you own a significant (let's say >5%) piece of the company, those late nights you work for "the user" will never be worth it to you.

> As they say, the reward for being good at your job is more work. Expecting me to put in top effort for "the users" without compensating me doesn't work.

You do not work for free. You are being paid. 'Top effort' needs not to translate to working overtime, more hours, etc.

That's not a popular school of thought in American business schools.

It reads a bit unintentionally exploitive as well. You're essentially asking employees to put the companies growth ahead of their compensation.

This passage specifically:

> For as long as possible, make the success of the company the primary motivator, rather than promo

How do you simply make the success of the company the primary motivator? IMO, you either try real hard to pay/promote them based on the success of the company, which feeds into the promo culture problem, or you find people to work towards the company's success without explicit promises of rewards, maybe by alluding to potential rewards you may/may-not give them (aka maybe exploiting them).

One alternative is you can find people who are satisfied with their place in life, and willing to just crank out work regularly without promises of increased rewards. IME, people like that AND skilled enough are very rare. It would be very hard to build a company of solely those people.

> Is there any non-exploitative way to interpret this? The only thing worse than wasting my time on features for promo rather than users is working overtime to make more money for those with significant equity/ownership in ways that will never seriously affect my comp. Without promo or "promo by a different name" i.e. money, how do you incentivize people? How do you decide who to allocate your finite equity and money to?

Easy, there is no promo, you just pay everyone 450k like Netflix and raise everyone's pay each year to stay at the top of the market.

This is only sort-of related, but a while back there was a beautiful Twitter thread, I think about Google product managers or engineering leaders, who come into a product, revamp a bunch of features and come up with metrics to show that they were successful with it in the short term, and then use that as the case for their promotion and time it just right so they can disengage and bail over to the next product, just before all of the short-term decisions they made blew up and hurt the original product. The punchline of the tweet thread was that they move on to the next product - and the final tweet in the thread looped back to the first tweet in the thread.

Does anyone remember this thread?

That is hilarious. It's a real life example of catastrophic forgetting.

A co-worker of mine described this as 'surfing ahead of the wave of responsibility'

This is great. I am going to borrow it.

Reminds me of the parable of three envelopes

For anyone else who didn’t know that one:

https://kevinkruse.com/the-ceo-and-the-three-envelopes/

is it this one? https://twitter.com/shreyas/status/1440138354390016003

Seriously, why do people care about being promoted beyond senior/staff? Even at a smaller company you're making 200k/year, you probably have a good handle on your job, why not just coast? There's a big discontinuity in comp if you can make it to the director level, but being a manager or senior staff seems like a ton of work for no benefit.

I work like 20 hours a week at my job, I almost quit because it's extremely boring and dysfunctional, but then I realized I can just disengage and enjoy my extra free time instead of pushing to exceed expectations. And I still get paid the same.

Try having a family as a sole earner on 200k in the bay area. Or new york.

Is this a joke? What is median household income for families in both of these cities? Fairly sure it's below 100k.

But you need a house with a backyard, two teslas, a wine cellar and a college fund or you aren't really living /s

In San Francisco, the median household income was $120k. That’s 2 years ago mind you, and a lot of inflation has occurred since then.

https://www.census.gov/quickfacts/sanfranciscocitycalifornia

Doesn’t account for the fact that many are under rent control, own houses from decades ago, etc.

It’s better to look at the average incomes of people who are buying houses in SF.

Do their budgets balance or do they take on credit card and other debt to manage the deficit ? I am not claiming its one way or the other as I do not know the answer.

The median household only has 2 people so presumably the median income for a family is higher.

> What is median household income for families in both of these cities?

What is the median credit card debt for them in these cities?

What is the median annual savings for them in these cities?

I'm going to guess that software developers, especially ones at FAANG, aren't aiming for a median household lifestyle. 200k post tax is easily ~140k a year. A san francisco mortgage is easily 4-5k a month for 30 years. And if their kids don't get lucky on the school lottery, they're going to be sending them to private school. And then there's college savings to account for.

At Google specifically, even being promoted to staff is a huge undertaking. And until recently, there was an expectation of forward career trajectory built into the lower ranks, i.e. every engineer was functionally multi-year probationary. If you found something valuable to do but you weren't progressing your career (because, say, the work was necessary but boring, like micro-optimizations, feature polish on a mature product, or documentation / example creation), you'd start to have talks with your manager about your future at the company.

I believe they relaxed that process when someone at the top took a look at their org-chart and realized they've become a big company where they need a critical mass of not-actually-interested-in-progressing engineers to keep the lights on and if they actually followed their policy, they risked churning those reliable workhorses out of the company because they couldn't actually afford to find a slot to promote them all.

I don't know because the change was decided way above my pay grade, but I always assumed that the reason was HR legal.

It is hard to look at people who are objectively doing as well as each other, and rate some lower only because they have been at that job grade "too long".

The fig leaf was always that the ladders encourages keeping up with technology and the company, which meant people couldn't tread water at the lower grades.

But if the "new technology" isn't necessary for the job duties, labor lawyers can have a field day.

Off the top of my head:

1. More money means less time till I hit FU money and can choose work without any consideration of pay

2. 200k/yr is not as much as it seems if you're in the bay area and have kids

3. Bigger title -> more input on core design decisions. Hate some idea coming from the higher ups? You're in a position to do something about it.

4. Bigger title -> more control in picking interesting problems to work on. People trust you to say "this should be a priority"

In general I agree. It's just that I don't know if salaried job lead to FU money. The only person I had or will be able to say FU is to myself sitting alone in living room.

You'd be able to reach FIRE money as a SWE. Possibly FU money if you get to vp level at a FAANG and then work for 10 years.

Depends on who you are and what your growth potential is. I know SWEs getting offers in the 7-8 figure range. That's not in any way typical but if you're smart enough, hardworking, and get the right breaks hitting a 7 figure income isn't something I'd consider weird and is definitely FU money.

Do you worry about being hit by a bus before you have FU money? Personally I'd rather work half time for twice as many years than try to race to retire.

A lot of responses seem to be focused on high cost-of-living areas, which is kind of a chicken-and-egg problem. If you want to be a moderately checked out person, living in a smaller city and stretching your giant bay area salary is the way to go. If you want to be aggressively careerist, you have to be face-to-face in the bay networking.

More input and more interesting problems both feel like more responsibility for the same comp, imo, which might be appealing for some people but is anathema to me. The people higher up got there by being more argumentative, or backstabbing, or ingratiating themselves, and instead of going along with them now you get to fight them. No thanks.

I’d rather work twice as many hours per year for half as many years. It’s not that one choice is obviously dominant over the other across all people.

Yes, given "getting hit by a bus" is a probabilistic event that is independent of my working hours, I would rather make 2x for half as many years, all other things being equal. I'd also rather make 3x for a third as many years, and so on, if it were possible. Given time value of money and compounding interest, it's always better to front load your working time and make Nx for 1/N as much calendar time worked.

And for the controversial part: The above is why I think it's insane to, for example, take 1-2 years of not working, early in your 20s, to go see the world and "find yourself." Those 1-2 years, if spent earning, could mean retiring an extra 3-6 years earlier.

I agree with your conclusion, but I think there’s a fair argument to say that an extra week of leisure in your 20s is worth more than an extra week of leisure in your 50s or 60s. That is even more true if you’re working 48 weeks/year in your 20s and zero weeks in your 60s.

I think it's insane to, for example, work at an office early in your 20s, to put a couple grand in your 401(k). Those 1-2 years, if spent exploring, could mean finding a happier and more thoughtful way to progress through the latter 70% of your life.

I think this points out a difference in viewing everything in life as an efficiency problem focused on retirement age and overall wealth. Makes sense for a forum of engineers to see it this way I suppose.

Early on the money is probably the least important part. Momentum seems like a lot more important.

If you finish uni and take 1-2yrs off, that puts you wayyy behind someone who goes straight into a job. If you take 1-2yrs off your knowledge won't be fresh and you'll not really be a new grad anymore.

"getting hit for a bus" is a hyperbolic example meant to stand in for a catastrophic event. It really means you (or a family member like a parent, partner or child) has a major health event, for instance. Some things are random, some things tend to become more likely with age. Even just chronic pain or other health issues might make retirement less fun than travelling in your 20s (speaking as someone with chronic pain from surgical implants).

Besides health there's a lot of reasons why being certain about doing something now might be preferable to putting it off for 10+ years.

My todo list will keep me busy until I'm 3000 years old. I might not be hit by a bus, but I have no reason to think I will ever get to the end of that list. Money can buy things required for the list that are not on the list, but I have to work to get them. In many cases I spend less time working then I would just doing it. I could make a canoe from scrap wood and row to New Zealand, but in a week at work I get enough money to pay for a plane ticket, while paddling across the ocean would take months (people have taking canoes across the ocean so I know it is possible - though I'm not sure how risky it is)

> Do you worry about being hit by a bus before you have FU money?

No. I don't work that hard, and my work is generally enjoyable, I've made a lot of good friends, and get to live in the area I grew up in near my family.

> A lot of responses seem to be focused on high cost-of-living areas

Well, my response was to a poster asking "why do you care about making more if you make 200k?" and the answer for some people making that amount of money is that they are only able to find work paying 200k+ in a high COL area.

> More input and more interesting problems both feel like more responsibility for the same comp

The thing driving more interesting problems and more input is a title bump, which in my neck of the woods means a 50% or greater pay bump, so I would say that's not for the same comp. Whether it's more responsibility is variable, but I know engineers two levels above senior who more or less have the same responsibilities as a senior engineer except their project is "harder" and more important to the company (this does not mean the more senior engineer is actually working more hours though).

Perhaps a meta point here is also useful. Once you're senior, most engineering work available is not interesting and does not help you grow as an engineer. Engineering work that helps you grow as an engineer often makes you more valuable. Companies usually give interesting work to their best engineers. If you can quickly climb the ladder to where your job feeds you interesting work you can enter into a "winners-win-more" sort of feedback loop. This is a strong incentive to front-load your career growth by working really hard for your first decade in industry (or at least years 5-10).

> 4. Bigger title -> more control in picking interesting problems to work on. People trust you to say "this should be a priority"

This is probably one of the most dominant non-financial factor for engineers. Because if you want to make a visible, critical design decisions for billion-user products you usually want to be at least L6~L7, the level where you're now an owner of a non-trivial product/system spanning across teams.

My main motivation for work at this point is to provide for my children and buy my retirement. More money via promotion helps me achieve those goals.

You are counting on that job to always be there for one thing.

In the boom time there's an unending appetite for mediocre engineers to inflate headcount, making managers look good (more reports) and companies look good (to investors). In the bust time, I don't think even the smartest people will be safe, and the top of the ladder may well be pruned more aggressively because they're expensive. Having positive reviews may protect you, but being high in the org won't.

Depends on how high. You don't want to be in the "off in the corner" research group which is usually comprised of very high level engineers (senior or staff level or higher). You definitely don't want to be high up in the middle tier either. What you want is to be known to your Vice Presidents and above. That's when you reached "high enough" to avoid the great cull.

I witnessed this more times than I can count.

Otherwise its all balance sheet calculations and maybe your manager can pull a punch or two if the product area is critical enough.

Performance reviews in corporate culture often have a "what have you done for me lately?" mindset.

If you're senior or staff and haven't launched anything exciting lately, middle management might become less interested in whether the service is running well and more interested in having "career" conversations about how your role description says you're supposed to be launching cross-functional projects more frequently.

If you aspire to be a homeowner, 200k in the Bay Area will be difficult.

As of 2022, it's now difficult anywhere in most US metropolitan areas.

"Most of the US" != the five places you'd be willing to live. Outside of the HN bubble, a $200k salary _easily_ affords a home in most markets.

https://cdn.nar.realtor/sites/default/files/documents/metro-...

Okay, but the important part is "the five places you'd be willing to live". There are significant reasons most of us aren't moving to the middle of nowhere to be able to afford a home.

I meant to say 'major metropolitan' - Thanks for the clarification

A promotion (pre-director in CA/NYC) can easily be an increase of 50k (~25%) in comp so it's pretty meaningful.

I understand the perspective of people who view their profession as solely a job, checking out after their 9-5 and doing other things with their life. This isn't me. I enjoy the work. Idealistically, I think I can make a large impact on people with my knowledge and experience. Shave off a seconds on a workflow in Google Docs end-to-end, that's a net good to humanity. It's not all about compensation. At some point it's almost only about impact, and impact often requires higher titles and putting in hours due to systems that govern these large companies.

To be clear, your question is why do people want to grow? Or why do they want to make more money? Or why do they want more status/power/recognition?

Because coasting costs me mentally. I want more than that. I coasted for a year and it was disastrous to me, mentally.

I've been at Google for 12 years, and this has not been my experience. While it is a popular narrative, it is by no means dominant, and is fairly specific to individual teams. I got my second promotion leading the Google Maps Desktop Latency team. We demonstrated impact solely by reducing load latency and increasing performance while advocating for latency consciousness across the product space and implementing latency regression tests and monitoring. Google has some of the most complex infrastructure in existence, and there are thousands of engineers that are getting promoted and finding gratification in maintaining and improving this infrastructure.

My experience at Google has been characterized by collaborating with the smartest and most driven people I've ever worked with. And I worked at several companies before Google. I think a side-effect of this personality type is that the engineers themselves want to make a difference, whether through maintaining Google's complex infrastructure or launching new products. And while it may be easier to show impact by launching a new product, it is by no means a problem unique to Google. Startups find it much easier to show impact by launching and buying users, rather than measuring how useful the product actually is.

I have come to believe that, lean-startup style, a good engineer should be able to demonstrate how the work they are doing is important to a company, a product or a product's users. With a little bit of thought around how to show that the work you are doing actually is valuable to your organization's OKRs, you can get promoted doing whatever work appeals to you the most.

I'm going through the Google interview process right now, second round. My interviewer has rescheduled three times in the past week, each with less than 24hrs notice and without a reason given.

Is there a 'safe' space I can give feedback regarding this that doesn't damage my chances of making it through the process?

During my interview process, my recruiter was very much my advocate. Have you talked to them honestly about this? It should not hurt you. I'm sorry you're going through this.

Don't. It isn't going to help you or them.

Just roll with it. It's all upside from the interviews. It's largely a good place to work and worth the headaches during interviews. Smile and carry on.

You need to talk to your recruiter and let them know this is an issue. They are incentivized to hire you and are there to help you and give you a good impression of Google. The recruiter isn’t going to tank your chances of making it through unless you say something that is egregious and a red flag.

Just be straightforward and ask if there’s another interviewer available

Reducing latency is mostly easy to measure, has directly understandable implications, is likely (and understood to be likely) quite difficult to pull off on a product like maps. It's basically a perfect promo packet project.

The example given by the author - fixing lots of tiny features in sheets - is the opposite. Difficult to measure, lots of little and difficult to explain implications, sounds kinda easy - many individual items probably are just work.

I disagree. Add a couple of these features, put them behind an experiment flag, and inspect metrics that matter. What usage are they getting? Do users in the experiment use the product more frequently? And for longer periods? If not, perhaps feature parity with Excel is not the highest impact project, despite the feature requests. If you are finding it hard to come up with measures that show impact towards your orgs' OKRs, this is also a signal that your pet project may not be the best thing for you to spend time on in the eyes of your bosses.

At a high level, promo is an incentive that directors and VPs use to keep an org working towards strategic goals. You may disagree with those goals, but that doesn't necessarily mean promo is broken.

Inspect the metrics over what time horizon?

Think about how companies choose between office and google workspace, especially excel v sheets, and the buying process. And think about the industry/function where it matters most - finance. You aren't going to see sheets usage tick up next qtr because you added 5 features that ibankers use. Usage of those feature will slowly go up, and when mixed with 20 other things you'll slowly see more finance users. Hopefully. Maybe Goldman will switch, and others will follow. Whoever is running Sheets is in a long term game. Much of enterprise software is like this. It isn't Facebook where you often get instant feedback.

I guess this works for explicit features, but might not work for omissions, especially the tiny features and bugs.

Small annoyances might add up, and the GP's point is that this incentive system doesn't reward those who try to fix them. Unless... somebody's deranged enough to keep known and fixed bugs in a customer facing product behind an experiment flag to see how a small percentage of unlucky users would react...

> With a little bit of thought around how to show that the work you are doing actually is valuable to your organization's OKRs, you can get promoted doing whatever work appeals to you the most.

If you put yourself in the shoes of an L3 or L4, you know this is not exactly true. Who your manager is and what their priorities are, and how they view the promo process can greatly affect your ability to get a promo. I mean, before you can apply you need to get "strongly exceeds expectations" for two consecutive halves. If you do great work that you think benefits Google, but your manager doesn't think you've sufficiently demonstrated things on the rubric (e.g. "google-quality delivery" or "autonomy") you won't get a promo. Managers also have their own agenda and list of things they need to deliver, so you end up having to work on things they want you to work on, even if they don't help you tick the boxes in the rubric. If you're lucky and get a good manager who helps you play the game, these things aren't problems. If you're well-informed, you know how to bail when you encounter such folks. If you get unlucky or don't wise up to how it works, you can be set back many years in career progress.

I don't see how any of this is specific to Google. Everything you've said here is how companies function. If you want to work on things that are not important to your manager, why should you expect anything? And bad managers exist everywhere.

My point here is that my managers thought the latency of Google Maps was important, doing good work on it got me promoted, it was not a product launch, and things like this are happening all the time across the organization.

Sure. I was just pushing back on the idea that "you can get promoted doing whatever work appeals to you the most." The "dot dot dot" that is required in order to make that work is a lot of luck, because your manager and their incentives factor so heavily into that. You got lucky -- plenty of folks do similar work and don't find as much support.

Promo-culture cannot be ignored because with each level, your total compensation often increases by 50-100% at many big tech. You can absolutely expect people to alter their actions to whatever promo-culture demands. As the article says, one answer is to simply align the incentives which is to make promos based on customer satiesfaction and adoption. The issue is this: when you release new product, your adoption/satiesfaction/revenue increases infinitely because denominator is zero. Often media blitz follows which raises the profiles of small team and increasing their market value than usual bug fixer. The new learning experiences of new-product teams and ability to do aggresive hustle on impossible schedules also adds into their market value relative to Joe, the minor feature developer. These people become important because one of the growth criteria for big tech is ability to diversity, aka, release new products and excite the hopeful investors. So companies are forced to associate product releases with promos. Current promo-culture at big tech is not a bug but a feature. I think very few understand this dynamics.

There is one extremely bad aspect of promo-culture not discussed in the article: Many promos in higher level have requirement that the person must become the people manager. The idea is that at certain pay level you must be able to "scale" you impact by directing others as opposed to doing things by yourself. In tech, this is extraordinarily flawed idea. Scale can be achieved by being manager but also by being individual contributor. People like Jeff Dean has contributed far more as IC than probably most VPs at Google. I don't know how many brilliant technical ICs have killed themselves by trying to be people manager to get that alluring promo.

When I was younger I was aware of the idea of perverse and misaligned incentives, but I never would have expected the extent to which they pervade practically every human institution.

There would need to be something big to override individual interest.

Historically this was achieved via religion. Small-to-medium size startups can sometimes pull it off with the concept of a "mission", although that's probably less effective these days since everyone wants to "change the world". I think someone would have to be pretty naive to have a similar level of belief in the mission of a multinational corporation. Or they're high enough in the org chart that they don't have to worry about anything else.

It is very instructive to read Deming and Weber.

Max Weber pretty much defined the modern conceit of bureaucracy. [1]

W.E Deming wrote extensively on the "American Disease". [2]

In a few words management and measurement are both inescapable beyond a certain organisational size, and they are the problem, because in almost all scenarios they will expand to displace/strangle the actual work.

It is a recognised general structural problem in systems.

Of course there is much more to it than the above simplification which may sound like an extreme philosophy - but I have yet to encounter good refutations or counterexamples to this tendency.

The answer, perhaps, is that small and many is beautiful.

[1] https://en.wikipedia.org/wiki/Max_Weber

[2] https://en.wikipedia.org/wiki/W._Edwards_Deming

Thanks for the recommendation. I am a big fan of Weber, not familiar with Deming but his work sounds very relevant. In general I tend to agree that beyond a certain size organization these problems seem unavoidable. I've read Systemantics/The Systems Bible and it seems to come to a similar conclusion.

I'm Poor Charlie's Almanac, Charlie Munger explains that cheating is a huge problem, and that if you create a game where people can cheat to get ahead, they almost inevitably will.

At Google you could cheat the promotion system. Just spend more time optimizing for promo than for improving products for your customers, and you would be handsomely rewarded. You end up with the cheaters becoming the leaders and the good engineers leaving in frustration when they need to take orders from cheaters.

> The main problem with promotion-oriented culture is that it’s very hard to align promotion-criteria with business objectives, and so engineers end up doing a lot of work that doesn’t necessarily most benefit the product, users, or business – or even potentially their own growth.

Welcome to Amazon! Just about everything in this article rings true at Amazon. In fact, I’d say Amazon is even worse.

I think L4 to L5 and L5 to L6 promotions have certainly gotten easier over the years, and promotions have actively been used as a retention tool, given all the other (dis)incentives that would convince talent to leave.

What I saw in Amazon retail and Alexa was a culture of:

1) refusing to work on valuable projects unless you could actively claim to be the lead

2) taking credit for others’ contributions, or deliberately throwing a teammate under the bus and saying X didn’t work because of some thing specific they proposed (even if you agreed with it at the time)

3) general culture of back stabbing and not helping your own teammates, especially out of concern that your teammate would reap the promo benefit over you

And at a higher level, L7 managers will attribute a failed project, mismanaged project, or other issues to a partner team. “Our team is blocked on this other team Y” - never mind the fact that all the contracts have been agreed upon and this L7s team never wrote a line of code.

By the time I left, Amazon had gotten horrendous with organizations trying to invent “frameworks” so A or B can be done in 1 click, and this became the way for Sr SDEs and Principals to get their promotion. They create complexity and deliver some half baked, constrained way of solving problem X. This lets you show “impact” across an entire organization, even if this new abstraction has made engineers’ lives a living hell.

This was a major reason I left Amazon. The company was running out of ideas, and instead of focusing on products and customers, the engineering culture was heavily focused on inventing complexity for the sake of promotion. 9 times out of 10, the son of a bitch creating this complexity would take his or her promo and then move to another org, a new greenfield project. Never sticking around to deal with the pain they’ve caused.

There's just a lack of ability to own a product as an engineer. Those things are delegated to managers and product owners; lead engineers are really just there to align work - not really to make broad vision beyond suggestions.

If engineering firms wanted to improve they'd ensure that everyone who has decision making power over a product, whether from a business or technical perspective, is at the same level and has the same input. That way refactor is weighed the same as a new feature or service.

In my experience most of the perf-review is a show.

Promos typically have a "pecking order", determined by how long you have been asking for one (or performing at the next level if you have some meritocracy), the amount of budget available for promos this time, your age (easier to promote "mature" people), D&I status, proximity of ethnicity to your managers biases (could be implicit, doesn't matter for the outcome), height (tall people promoted easier), introversion vs. extroversion, and just if your manager likes you.

Also they ask you to give vague, subjective snippets that will be weaponized against your colleagues in form of "feedback" for the next 6-18 months.

So it's better to not partake in this type of time wasting activity.

This is a fascinating, complex topic. Why are a group of very clever, smart people spending ANY energy on giving each other high-school level report cards? Why does one of our best ever tech companies become focused on everything but the customer ? I'd like to think they are dumb but c'mon, they are not dumb people.

It doesn't mean I can't feel sad and deeply upset at this is what it takes to 'succeed' at a company I have honest admiration for.

BUT; I've been researching this 'problem'; which boils down to "is a hierarchical management structure needed" for a group of 'activists' to achieve great things? So far I have found no alternatives, why do we have to keep track of our 'success' and relative worth so intensely so share the pie around?

as the top responses says; everyone needs to chill out and I'd add "try to be nice and do no harm".

The only point I have to add is that as someone who wants to not participate and does not care what "level" they rank; f### off?

You would turn down an extra few hundred K a year to avoid some paperwork? Lol

I've begun developing a philosophy under the idea that I have less interest in touting my accomplishments and successes in the aim of getting a promotion and instead expect my lead/manager to notice and actively reward that either through promos, raise, new equity grant etc.

If a company, or speaking more locally, my manager doesn't do that, I'd rather just leave and try somewhere else. Some may view this as childish, picking up and leaving just cause I don't get what I want. I view it as exercising my market power and refusing to be pigeon holed into a system that exists just because that's the way it's always been.

This philosophy certainly benefits from the current job market and this makes me feel more empowered knowing I can just pick up and leave and get a better raise, promotion, new equity round etc.

A good signal for identifying these types of companies where this approach can work IMO is

- Smaller companies

- Ask and look into engineers seeing if there are lots of internal promotions

- Learn what the promotion process is at a company before joining.

I think the problem with the promotion culture is that you can't demote someone after they've been promoted. If you just focus on showing impact and cross team projects, your engineers will naturally build more complex projects than needed to hit those targets. The key is to track the long term maintainability and quality of the systems built. E.g. time to land diffs, incidents, performance metrics, etc. If a system starts to quickly fail these things or don't last then it is a pretty good sign that the project wasn't actually built well. Things aren't always under a single person's control but a lot of people will work on a big complex (seemingly good) project and then bounce after they've gotten their promo.

I do think there is a balance though because at a lot of startups the incentive is to just crank out a lot of product code but not really think about multiplier type work.

Half of me wishes we just got rid of titles and just adjusted pay based on the value perceived/demonstrated to the company YoY. People would probably be more inclined to work harder and on more challenging stuff if their comp was more outcome driven like a sales type role.

Incentives make people do the weirdest stuff. It becomes pure politics at a certain point and largely a cool kids club of who you know to sponsor you and being generally well-liked. I'm not going to kiss ass for a title. I'm going to demonstrate I earned it the hard way. While most companies don't recognize that path as much anymore, it's not very hard to get the title at another company.

The people who bring the most value to each team are often the unsung heroes who don't get promoted fast either. Good leaders will take notice however.

The book "Staff Engineer" by Will Larson has some good bits on this topic.

Some ideas: hire fewer people, well remunerated, but make normal pay increments guaranteed and promotions less frequent. Then there isn't such a glut of new engineers constantly creating an "up or out" culture, and people aren't laser-focused on promotion to win big. And lower the early 3 years' RSU allocations.

Basically, turn it into a marathon not a sprint.

Most promotions I've seen are when someone has a huge amount of tribal knowledge about some system and the company cannot afford to have them leave. So they get promoted. This is even within FAANG, where this narrative about impact or 10x developers is common. Not saying promotions dont happen for those reasons, just that huge systems that few people understand lead to promotions for those who do understand them

Not really? Promos incentive "up and out" culture, where people switch teams after getting promoted. Machiavellian managers respond by not promoting their best people, instead forever dangling the carrot of "deliver this and get promoted next cycle!".

100%, have worked at two FAANGs and this is what I have seen. Complex business knowledge leads to promotions

“You got a really high CME this cycle” is the meme du jour I’ve heard

This is very common! What's worse is these engineers likely created or at least contributed to a situation where tribal knowledge is valuable, rather than developing simple decoupled systems that can be picked up by new engineers.

Yeah it’s your usual “hire a bunch of underpaid and under skilled-for-the-job” “engineers” at the beginning of your startup that write piles of crap code that then become knowledge pullers of the business. When if you paid good money in the first place you wouldn’t need that knowledge in the first place.

A problem I've noticed working at larger companies is complexity simply for the sake of demonstrating complexity. In order to demonstrate technical prowess or importance, engineers will push a project in terms of headcount, solution, etc.

Good engineering can look simple. The best engineers I've worked with will make things look easy. This can be at odds with promo driven culture.

An interesting way of looking at this is that it's the Iron Law of Bureaucracy at work.

The Iron Law of Bureaucracy:

In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals that the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely."

https://en.wikipedia.org/wiki/Jerry_Pournelle

Also called the tragedy of the commons.

It's obvious why these mid-century SF authors like Pournelle and Heinlein wrote all these cool-sounding aphorisms - that's their job - but it's not clear why anyone listens to what a grumpy old conservative SF author thinks.

Based on my Google manger time and prior experience, the problem isn't necessarily the promo orientation - it was the emphasis on tech heroics to justify the promotion.

Rumor I heard was that pre-IPO the only was to get a stock option/grant boost was to be prompted. I believe the first actual annual refresh was in '06. For several years after that it was 100% managed at the SVP level, so you needed to be known at the top of your management chain to get a refresh beyond the algorithmic minimum.

Also there was top level compression because Google didn't have L8, 9, or 10s for a long time - if Jeff Dean is a L8, a new hire previous "Director level" engineer lands at 7 if they are lucky.

Given that Google frequently hired at one or two job grades below typical Si Valley, promo was a MAJOR motivator, and you needed to seem as though you fit in at the next level up. Google's approach to the Peter Principle was that if you got promoted and then didn't meet expectations, they would manage you out.

The question was always "Is that project really L6, L7, L8, L9 work?" I saw someone who changed the way a longstanding internet protocol was seen and replaced it based on their research stuck in the "only L6 level work" category.

And of course the promo committees were filled with people who got promoted under these regimes.

Corporate culture gets set and maintained in strange and interesting ways.

When I was at Google this was a huge problem.

I worked on features/products that could be built and supported by small teams. Once those projects were ‘done’, those same teams inevitably turned to unnecessary rewrites, expansions and redesigns. And they all got promoted for it. For turning a 5-person project into a 25 person project that did the same thing, but with more moving pieces.

Because you can’t usually reach L6 by maintaining a project, no matter how impactful.

My take on these BigCos is that there is so much middle management and hierarchy that the frontline workers are blocked from the actual performance of the company.

My proposed fix is entire product groups and their members should be held accountable and directly take profit of what they earn. If the product does well that quarter, engineers should be rewarded. Something to keep them working on a great product rather than catastrophically forgetting.

That works in sales, where one salesperson runs the whole engagement and can clearly claim responsibility for the revenue and thus be directly compensated with a proportion of it.

But in engineering you need people to be thinking big picture, thinking collaboratively, taking risks, doing long term development, cleaning up technical debt. If you overly tie compensation to product revenue, you risk incentivizing your entire engineering staff toward short-term bolt-on-the-feature thinking.

What about infrastructure teams? Not all work is product work.

At my previous employer, every quarter we were supposed to update an elaborate spreadsheet describing how we measured up against the numerous criteria for the next level on the career ladder. I hated it.

That said, there were lots of people who obsessed over the process, looking for shortcuts or ways to game the system.

In my experience, most engineers won't even get the chance to work on something so impactful and cross team/org to land a promotion.

Not their fault. Sometime, as everything in life, you are in the right place at the right time. You get to work on a good project and bingo. But most of the time you will end up fixing bugs in some half baked, broken PoC that someone launched in production just to get that promotion, and now you got to make it to work, while the person who got promoted get to move on and draft another broken PoC, launch it etc ...

It depends if you are the one fixing shit and make things work (you rarely will get a promotion) or you are the lucky one who get to write spaghetti code on the next thing, cash out and move on onto the next thing ...

Life is not fair I know ...

> and even if you care deeply about other things (your product, your users, etc), you can’t really avoid caring about promotion as well.

I can honestly say I didn't care about promotion while I was on the Windows accessibility team at Microsoft (as a Software Engineer II). The quoted assertion makes me wonder if I was being naive or lazy. I truly believed that I didn't need to care about promotion because the work I was doing was worthwhile for its own sake, i.e. I cared about the product and the users. In retrospect, maybe I didn't make the most of the opportunity I had there; I suppose I could have had more impact if I had leveled up. But I wasn't thinking that way at the time.

The way I looked at it was: if I'm being paid enough, I care about being happy more than being paid more. Jumping through hoops to get promoted is going to get me more money and also make me do more stuff I don't want to do. I was happiest when I had a clear, important job to do, that everyone knew wasn't enough work for one person, and then the expectation that I'd spend the rest of the time fixing stuff that was nobody's job and freedom to set priorities for the most part (after all, if it was important, it should be somebody's job). Of course, at the last place, I think they have four engineers now doing my important job that left me mostly idle. Not sure how four people can work on it, but not my circus.

I briefly had one person reporting to me (well two people, in sequence), and navigating performance reviews on behalf of someone else is not for me.

The Netflix model is worth considering as an antidote. In short:

1. Don't hire junior engineers.

2. All ICs have the same title: Senior ____ Engineer.

Even Netflix is moving to have levels, however. At great cost to morale it seems, with people who were formerly all at the same title being grouped into potentially different levels.

Could be worse. You could be on a small team where there's no room for promotion and then get a 3% yearly raise based on your production despite the fact that you were rated "excellent" across the board because company policy dictates that 4/5 and 5/5 ratings are specifically for people they intend to promote, and alas your team isn't large enough for there to be promotions.... so you have to deal with your manager saying "I wanted to give you a 5, but I was only allowed to give you a 3 due to company policy."

Then there are ultra-micro companies where there can never be a promotion, only a raise, because the team is one or two people.

Then it's likely 3% forever.

I clicked the link ready to read and then feel critical about a criticism of meritocracy, but found the exact opposite. This makes me realize that promotion in the current state of tech and likely other types of businesses is pretty far removed from merit. Great article, and it's sad that business has made it necessary to point out that doing a good job and being awesome are the most important parts of promoting employees. There's a lot of fat to be trimmed in organizational structures, I would hypothesize.

Can we now, finally, stop thinking that everything Google does is smart? In the 90s, everyone wanted to copy Microsoft culture. Maybe we just always need to have one company that’s worshipped.

I was talking last week with a friend working for Google and worked at Facebook before. The overhead to show that you are worthy for promotion is ridiculous. But he was giving for granted that was part of the "game."

I was never interested in climbing the corporate ladder and prefer to impact the users but I found that unfortunately trying to avoid wasting time in this overhead is eventually working again the users because who prefer spending time improving the product does not get promoted.

Ex-googler here. I hated the promotion process with a passion. 20 pages of "evidence" which is usually just links to green/blue docs, CLs, and just flowery puff language to argue your case. My org skipped the promo committee process at the start of the pandemic when I was up for it. When we had teammate that changed teams join us for a virtual meet up to tell us _he_ got promo in his org. I quit the next week.

Couldn’t agree more. I took a level cut when I went to Google from Microsoft after being assured by the recruiter that, as a tech lead, getting promoted would be easy. Unfortunately due to two teams using the same code names I was put in Ads, last place I wanted to be, and took a non-lead role in another team instead. It quickly became apparent that the game at Google was very dysfunctional, and the “manager-bias” problem they were trying to avoid, while sometimes a real problem, was still a much better system that Google had cooked up. I lost interest in trying to get promoted and tried to focus on interesting work for the next four years. Meanwhile, I saw crappy engineers around me get promoted (and sometimes immediately use their new level to jump to Facebook) while hard-working engineers who cared about glue work, quality and meeting customer needs get overlooked (and sometimes leave too in frustration). Combined with having line managers with 16-25 reports (rendering them effectively useless), it was a pretty broken culture.

(This was 6-10 years ago; I know some things have changed, but I hear from people there it’s still crazy).

It seam that the fix should be the promotion criteria and process.

- use continuous promotion screening instead of well defined annual periods

- use indirect measurement instead of candidate self selling (involve manager's and colleague's feedback, but not only because introverted people merit promotions too)

- measure things to be aligned with the success of the project and the company objectives

- increase impression of progress and success by increasing the number of promotions (gamification)

- reduce frustration and demoralizing effect by reducing the gains of promotions

- make the criteria clear and objective to reduce frustration and demoralization (clear goals, clear push directions)

It seam that a system based on points (or karma) might be interesting to explore. People would earn these points by different actions or indirect objective evaluations.

People may loose points if efficiency or contribution quality degrades, but smooth out to absorb "life accidents" (e.g. transient health or personal social issues), to give a second chance, etc.

That's what I would explore. It's not easy to align this promotion system with the benefits of the company. Not every company earn billions like google.

I feel such a disconnect from all the comments. Seems most engineers/manager in the comments are pulling by my estimates, $400,000~$1,000,000+ a year arguing over culture. I don't get it because it's not an issue outside of FANG. Seen far more ugly stuff in companies that pay 90% of that in Canada. It explains why there's a big brain drain here.

I don't understand this comment. Are you saying people should take their money and stop complaining?

Seems you understood it just fine.

A fantastic blog post that dives into the same problem: https://mtlynch.io/why-i-quit-google

It inspired me to quit years later and write my own version: https://suketk.com/why-i-quit-google

So, if you have a company that depends on uptime, then pay the people doing the maintenance programming / sysadmin twice as much as the normal developers since they don't get to play with the new thing, they are much more likely to have to deal with things at odd hours, and need to be promoted based on keeping the business running.

> Alternatives to promo-cultures

What would a co-op look like?

aka Worker Self-Directed Enterprise. https://www.democracyatwork.info/democratizing_the_workplace

Could a co-op technology startup raise capital? I have zero clue about such things. My guess is that VCs want to control the board and exec roles, so wouldn't fund an efforts where they can't replace the leaders.

What about the co-ops and FOSS? I've been casually poking around, trying to see how misc projects are organized, governed. eg ZeroMQ, SQLite, Zig.

What about the maturity of an industry? Sure, emerging markets and hyper growth are probably hostile to co-ops. BDFL vs democracy. But search is now mature. Take away the advertising biz model and it's just a bog standard IT project. Surely something like DDG could be a co-op.

In other words, "hire people who want to work hard for the founders at the expense of their self-promotion".

If job posts were honest, they would say "our ideal candidate is a martyr."

Or incentivize them with a form of profit-sharing that isn't tied to "promotion" per se?

One thing that could make this less problematic - make levels hidden.

Another more radical approach - get rid of levels completely. Increase pay significantly, similar to a promo if someone is doing good consistently, don't if they're just okay, fire them if they suck, but make levels implicit.

I've seen one case at Google where a Manager was going for promotion, in part based on some metrics claiming the product usage increased a lot. Someone found that the metric was broken and was overcounting, but the report chain was explicitly told NOT to fix the bug until the manager gets promoted. This was kept broken for months. He did get promoted to L7 (senior staff), since the metrics were very positive, even though it was not deserved and the product was worsened in the process.

Make a huge incentive of promotion, behind well defined rules, and smart competitive engineers will tlgame the system. Even if it's an actual negative value for the product and company. You can always change teams after promo and start fresh with your increased total compensation.

Eh I saw worse than that. The last team I was on at Google before I left had metrics that for years genuinely got better, and these were real metrics users cared about, they weren't gamed or irrelevant (related to spam detection). Each quarter our manager would go to his managers and present the team's latest success. He'd show the metrics and say how they'd improved from last time. Praise would come down from on high. As time went by this little ritual become almost formalized, because said manager kept re-using the same presentation slides each time, just adjusting the numbers. And the praise was always the same. Morale was good.

One day, the metrics stopped going up. In fact they went down a bit.

What happened? The manager went to his manager and gave the exact same presentation, in which somehow the metrics were still great news and the team was still executing really well. And his managers didn't notice. The praise came back, just the same as it always did.

At that point me and one or two others on the team became very cynical and lost motivation, because we realized that nobody who influenced our careers seemed to have noticed what was really happening. Celebrating an endless series of utopian success stories, regardless of truth, was more important than tackling reality.

The first thing that comes to mind reading this is that 'corporate ladder' is the wrong visual concept. Corporate hierarchies are trees with root at the top. The problem is then comparable to the academic world, where each PI will have a series of PhD students who themselves want to become PIs, but the PI replacement rate is too low to accomodate this. Unless the global academic world is expanding, inevitably the majority of PhDs will not become PIs.

One general solution is to flatten the hierarchy, which ultimately would reduce the spread in compensation and rewards from the bottom layer to the top layer. This would make promotion somewhat less attractive particularly if it came with heavier administrative responsibilities (generally less fun and more hassle).

> you’re likely focused on one career question: when am I going to make it to the next level?

This premise does not apply to everyone, there are many people who are perfectly happy with their current income and their current set of responsibilities. It's indeed likely that most people do their work for the money, and promotions do contribute directly to that incentive. But there is a sizable population who are not in it for the money, and they contribute to the company culture as well.

Related, this article reminds me of comments on an earlier article:

"Do Not Change Your Job": https://news.ycombinator.com/item?id=30437733

Thoughts on the following idea? I think Google's incentives have a problem similar to the incentives of any other company: It's open-ended, and possible to game everything. Whether promotions are based on the "hard problems" solved by your work, or the revenue it generates for the company -- or hell, even the software quality/performance -- this will always cause drama, people will get mad and leave. Any choice will lead to some positives and negatives for the whole company.

You might hate Google's choice, maybe enough to leave, but you might end up joining Microsoft/MANA and hate their incentives too. Basically, you're back to square one.

I propose changing the promotion criteria every year so they can't be predicted.

I work at Google and the who promotion culture is very toxic. People are incentivized to "Launch" things just in time to get promo and only to abandon it or switch teams in search of the next promo. It also gets hypercompetitive and harms teamwork sometimes. The promotions are usually B.S. anyway, they add stress and usually remove a good functioning engineer from doing good work into more "non technical leadership" work.

The Truth is, people really want promos for the extra money and more stock. I say, just give them the extra money and stock privately, and only promote people when there's a job to be filled for that position.

The dual-ladder system exists to fix something that is broken but ends up breaking it more.

In essence, there's the E9/O1 problem. An elite engineer with 25 years of experience simply knows more than an entry-level manager. Organizations try to solve this by dual-laddering and saying that there are "Director-equivalent" engineers (e.g. Staff or Principal) and so on, to rectify the obvious injustice of a scenario where a fresh MBA is seen to outrank the best engineers because he manages a team and they don't. The problem is that this dual-laddering makes it worse, because it's so much harder to move up the engineering ladder. If you're a Software Manager I at Google, you have to shit five or six different beds not to make Director within ~6 years and VP within ~12. On the other hand, making Principal+ Engineer is quite difficult, especially if you're not in MTV. So it perpetuates a false equivalency in which the managerial and product folk are gods (because of their swift, easy promotions) while most of the engineers are leftovers.

How can every single manager become a director ? That seems impossible.

It can happen for a while with large year-over-year headcount growth + manager attrition. But eventually, the music stops.

In the military the E9/O1 issue is at least understood. Not so much in corporate life.

The parity between the two ladders is something of a myth. At most companies, you can see that clearly if you count heads.

A director might oversee 150 to 250 people. There will likely be five second level managers reporting to the director, and maybe twenty first level managers reporting to those second level managers. So 30 manager level people.

And there will be maybe four or five Staff and one Principal engineer in the same organization. Sometimes even fewer.

So the parity really isn't there.

Parity is not identity (nor equivalent to it, lol). The two jobs are importantly equal in their difficulty and (more directly) their value, and not - among the many other differences - the number of people they manage. This thinking is why valuable individual contributors move to companies where progression isn't defined in terms of the number of reports you have (respectfully).

Late reply.

My point is not number of reports, but number of people.

A directorate might have 25 managers, and maybe 200 developers. Of those developers 4 or 5 might be staff/principal, and it might be as small as 1 or 2, or even zero.

So far fewer people move up the technical ladder than up the management ladder.

"If you have other ideas on how to avoid the slip into promo-culture, I’d love to hear your thoughts"

Proper bonuses (proper = multiple of base salary). If promotion is the only way to get comp then obviously it matters a great deal. However, if you can get good comp based on your performance (and not your rank), then promotion matter much less. At most investment banks/hedge funds the highest paid employee is NOT the CEO; it is somebody that made the the firm $248m last year and that got to keep a fraction of it as a bonus.

I wonder if any company has successfully eliminated promo-culture. One possible option (in tech context) is to have same base for everyone (like Amazon used to have) with a $0 to $1billion stock range for everyone. Then you select actual stock amount in proportion to increased customer satisfaction, product impact and adoption. No promos ever. All the mess of titles "Staff", "Principal" etc are gone too. No one talks down to anyone exercising their titles.

What would be problem with such a system?

A lot of work is hard to evaluate in terms of those metrics. Especially comparing people across different areas of the stack.

Also it encourages a cutthroat competitive culture of stealing credit. At least with levels higher level people don’t need to steal credit from lower level people and aren’t directly evaluated against them.

Some HR rules are put in place to make the workplace appear more "equal" but it often ends up making advance people that are good a paper-pushing and BSing.

After enough years are passed with this system in place, the company is full with people that rarely care much about the users and care a lot about their status and paycheck. In these kind of cultures what tend to flourish is ego-boosting shining objects that rarely impact the users for good.

I wonder how much newer trends of transparent career ladders are at play here.

The old way wasn't perfect either, but generally high performance was rewarded with broader scope. I assumed hard, high quality work was the way to get promoted.

Now with many public career ladders, employees realize they should take on broader scope (larger, complex projects) to look the part of a more senior engineer, even if that doesn't match their team's immediate needs.

> Post-hoc design documents written specifically to explain work to a promo-committee after the feature has been built

I actually wish these would get written all the time. Not because of a promo-committee, but because post-hoc documentation explaining how the system works after it's already been built (as opposed to a design doc from the planning stages that may or may not reflect the actual state of the built system) is really valuable.

My dad used to go aboard a ship, take measurements, and draw what they call an as-built blueprint for this reason. He’d find crazy stuff like “they must have moved this wall a little because the equipment wouldn’t have fit in the space on the plan.”

Another issue is that "promotion" can mean any number of things which someone may desire or not care about. This "promotion" may mean a private office, more flexibility with your time, more money, respect, control over what you work on, meetings with higher-ups, direct reports, and so forth. Not everyone wants all of these things in a single bundle.

There sure is a thriving subculture of telling people how to not repeat the "mistakes" of an 1800-billion-dollar organization.

Those who stayed later Fridays and logged in to work on the weekends, those who rattled some cages and when yelled, yelled back, where promoted. The rest of us who enjoy our evenings with our families and married feasibility with sustainability got burned out and left for greener pastures. Good article.

It is an eternal quandary - make money and promotions not the central theme of your life. Move jobs, when it becomes a soul-sucking promotion oriented culture. I chose this path - am probably poorer than FAANG folk, but I did not trade my soul and find joy in the work that I do.

So what this man is saying is:

"We at Google are promoting the wrong things. We have necessary work that our code monkeys do but nobody wants to do because those jobs are not promoted"

As a manager of a company promoting the right things is your job.

Of course people want to earn half a million dollars if they can.

The main problem is that promo-culture is fake meritocracy.

Real meritocracy is a market economy (barring corruption).

FYI - Google completely revamped their promotion and rating system just today.

Is Google an up or out company?

That is, if you don't get a promotion in a certain number of years, you will be encouraged to leave?

That would encourage making projects more complex than they need to be, to get that promotion.

For software engineers, the expectation is to get to L4 eventually (new grads get hired at L3). I've not seen any concrete guidance on what "eventually" means in this context.

This used to be L5 until a few years back.

So if they make one promotion, they are OK indefinitely?

They have to continue meeting the requirements of their level (in this case L4) but there's no expectation of growth beyond that level.

Even the old system, where there was a formal expectation for every SWE to grow to L5, wasn't uniformly enforced. One person I know joined as an L4 SWE twelve or so years ago; they're still an L4 SWE.

Can it be that the aim of this system is limiting the number of potential promotees, similar to how leetcoding limits number of candidates for hiring?

serious question here - how does Apple deal with this problem ?

Apple also survives on big bang releases - the next iphone, macbook pro, etc etc. But also is famous for not abandoning old phones. iphone 6 was still receiving updates in Dec 2021.

so how does Apple manage this dichotomy ? or is the company level yearly release completely wipe out the need for individual "hard problem" solving ?

Does Apple even promote on solving "hard" problems?

Traditionally they made it ungameable by making it completely opaque to the point where you have no input on promotions and they may not even tell you there is something called promotions.

The fact that this comment thread is so long itself tells how big a problem this is.

never gonna join the mice race

:eyes:

google knows how to overengineer thing.

Reply on news.ycombinator.com