> 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.
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.
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.
Their whole management process encourages people to chase after impossible goals, and literally discourages people from getting things done.
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.
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.
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 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.
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.
> 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.
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.
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
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.
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.
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.
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
L3: $192,064
L4: $268,758
L5: $358,423
L6: $502,465 (!)
>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.
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?
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.
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"
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
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.
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.
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.
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.
"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 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".
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)
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.
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
There's a limit I guess, but sometimes having multiple people to report to can lead to checks and balances.
There's no inherent reason for management to be hierarchically superior. If you want productive relationships, you have to level the power dynamic more.
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.
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?
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.
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.
It's good to have people who understand the difference between the prisoners' dilemma and the iterated prisoners' dilemma.
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.
These are of course people, after all. Not robots.
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'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.
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.
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.
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 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").
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 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.
i don't know what the answers are to manage that shift and avoid it going into the wrong direction.
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.
Would the goal be to promote everyone? Who's going to do the work they all used to do?
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 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.
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.
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.
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.
They try again next cycle.
how do you know that's what usually happens?
"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?
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.
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.
Does anyone remember this thread?
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.
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"
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.
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.
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.
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.
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.
Is there a 'safe' space I can give feedback regarding this that doesn't damage my chances of making it through the process?
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.
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.
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.
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.
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.
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.
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?
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 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.
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.
Basically, turn it into a marathon not a sprint.
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.
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.
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.
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 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.
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.
That said, there were lots of people who obsessed over the process, looking for shortcuts or ways to game the system.
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 ...
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.
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.
1. Don't hire junior engineers.
2. All ICs have the same title: Senior ____ Engineer.
Then it's likely 3% forever.
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.
(This was 6-10 years ago; I know some things have changed, but I hear from people there it’s still crazy).
- 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.
It inspired me to quit years later and write my own version: https://suketk.com/why-i-quit-google
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
What would be problem with such a system?
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.
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.
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.
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.
"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.
Real meritocracy is a market economy (barring corruption).
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.
This used to be L5 until a few years back.
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 ?
