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

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

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.

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.

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.

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.

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.

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.

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.

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?

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.

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

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.

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.

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

THIS IS A GREAT QUOTE! UPVOTE FOR REAL INSIGHT.

Thank you for sharing your experience.

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

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.

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.

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.

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.

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

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

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

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

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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

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!

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

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

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

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.

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.

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

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

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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?

jk

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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

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

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

Why do you think you need the top 40%?

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.

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

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!

L3: $192,064

L4: $268,758

L5: $358,423

L6: $502,465 (!)

https://www.levels.fyi/

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

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

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.

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

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

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.

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.

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

Thanks for the feedback.

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.

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.

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~

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.

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

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

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.

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

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.

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.

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!

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 should be some way for a manager to see what someone has accomplished by the artefacts they have left on the company systems.

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.

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.

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.

and replaced it with manager bias.

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.

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

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.

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?

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.

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

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

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

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.

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.

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

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.

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.