The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.
The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion. Everybody becomes "fake friend".
It seems that just about anything else devolves into an ontological mess of Byzantine proportions. At one stage in my career I was reporting to 4 different bosses in this weird interleaved hypercube topology. I spent most of my time giving status updates
I do think more democratic, less hierarchical systems can work well if they're implemented in the right way. I saw a shift from that, where it was functioning well, to something more hierarchical and everything play out as this blog post is criticizing. It became really clear very quickly how aims shifted from more institutional mission-statement-type goals to promotion criteria and personal power agendas.
There's a limit I guess, but sometimes having multiple people to report to can lead to checks and balances.
I once had a similar situation and seriously contemplated building an application to manage my status updates so I could enter the raw data once and have all N people who needed to be updated sent the right information in the right way at the right time....
Seems like if your boss is a receptacle for status updates, the company is doing management wrong. Sure, it works less bad with one, but that doesn't mean it's good.
At least for performance reviews it's so much easier. If your boss hates you for some reason, that sucks, but you can just move on. It's a lot simpler than trying to please a dozen different people simultaneously though.
I have a scrum master, a product owner, a tech lead, and a team manager. All four of those are management relationships, but only 1.5 are hierarchal (the manager and sort of the tech lead). The most effective and efficient relationships we have, IMO, are with the scrum master and product owner, who aren't above us in a hierarchy.
There's no inherent reason for management to be hierarchically superior. If you want productive relationships, you have to level the power dynamic more.
Phwewww... this blog post and all these comments ring so true to me way outside of contexts resembling software development or business that it seems to me it's getting at something very fundamental.
A corollary to this in my opinion is that if promotion is expected at some point, I think the business/organization/institution has a responsibility to try to facilitate people moving toward that through mentoring or at least clear expectations. If nothing else, it makes the expectations clear, which clarifies how those might be at odds with other goals such as what the blog poster is articulating.
The "nobody dares giving bad feedback" thing isn't about retaliation (though I suppose that could happen). It's because perf is actually the worst place to provide "honest" feedback to a person about their performance.
It's complaining to managers/directors instead of talking to the person themselves (the recipient wont get to read your feedback for a couple months after). Even if you want to talk to a manager about some performance concerns, you should do that directly, instead of putting it in a record that sticks around for a persons whole employment
It's a bureaucracy game, and people who give bad feedback don't know how to play.
(I'm not endorsing the system at all, just rejecting the idea of it being retaliation-based. Anybody giving bad feedback doesn't understand what is going on)
I worked at a place that did perf reviews every 6 months. 360 degree style, where you got manager feedback and a bunch of peers that you nominated. None of the feedback I received was ever actionable or useful. None of the feedback I gave was ever really useful, either! People rated you on a bunch of silly, vaguely described sliding scales from 1 to 5, then answered a couple of equally vague questions. It probably distracted people for 3 or 4 days, every 6 months.
All I ever got was stuff like "Joe writes excellent design documents! His code is always well tested. I always want Joe on my projects!" I'd write stuff like "Amy is extremely effective at solving problems with <blah> API's, and is a great communicator. She should do a brown bag session about her experience with <blah>." The reviews were all fluff. Some people wouldn't put in any effort at all, and write one liners. Seriously, one of my reviews was "Just keep on being Joe!" Thanks, but why bother?
The review process at most companies is a big waste of time and money.
It really depends on the corporate culture. The last review heavy place would put an overly positive spin on everything. In one review I wrote, I could've said "Jack's project has been taking an excessively long time to complete. He needs to work on delivering changes incrementally", instead I spin it as "I'm really looking forward to the delivery of Jack's work on X! He's been working on <initiative> since the last review cycle. It will be exciting when it is finally completed."
Leave it up to the manager to interpret and read between the lines. At the end of the day, the better managers know it's all bullshit anyway.
> The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC.
Raising up and increasing the productivity of your peers sounds like a good thing. I think I'm missing how this is a bad outcome due to a perverse incentive. Are you saying the value extracted from peers is not real value or that the focus on your raising your peers detracts from more important business goals?
Your peers are rewarded for accomplishing their goals. In the best-case scenario, the incentive is to find ways to synergize your goals so you are all benefitting.
In the common-case scenario, you figure out how to bribe / cajole / coerce them into putting time in on your project and don't really care about how things are going on their project, because we're all responsible engineers who can time-manage ourselves, right? So you get your promotion and they get screwed because the work they did to deliver on something valuable to the company isn't reflected in their OKRs.
It degenerates what should be a collective goal of accomplishing the company's objectives the best way possible into a slotting game of making sure you're always listed on paper as being on the right project, because your work won't have value if you applied it outside your bullpen.
> 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.
Yep. The truth is, most of the work we do isn't that important, interesting, or useful, so the pomp and circumstance is necessary to raise its "visibility." Truly sad.
You described many of reasons I left a previous company. As one of the higher level engineers, I was constantly writing "tech specs", reviewing tech specs, doing code reviews (one week I had 12), and forced to present slide decks full of fluff against my will. Usually I'd push the slide shows off for a few weeks, but eventually I'd run out of excuses. Occasionally, I'd get to do some real work, but it mostly involved refactoring an almost decade old smoldering dumpster fire, so I left.
> What the process _does_ reward is whitepapers, tech talks, daily updates, and delegation. It sometimes felt like the goal was to make every little change as noisy as possible: if you just fix something yourself, you get no points. If you plan it out, generate whitepapers, announce it, convince other people to work on it, send daily updates to every possible stakeholder and then a triumphant announcement, and then do a round of tech talks on every piece of it, you're a shoo-in for promo--whether on not the 'it' was actually important or valuable to the company.
This is absolutely my experience at Google. If you want to move up quickly you have to write docs to convince people to work on your ideas.
> Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet.
This doesn't really align with my experience. Most people I interact with at Google do not try to do this. They are happy being ICs at L4 or L5 doing their own thing. There is plenty of room to be an L5 or even L6 IC without constantly self promoting, it will just take you much longer to get there and you will never move past L6.
Well TBF, I was an SRE while at Google, so I worked with a whole bunch of other teams. And tech talks were considered a good way for SREs to familiarize themselves with partner teams' various systems. So my calendar had several weekly meetings for tech talks and other presentations...and they were usually pretty yawn-inducing. And at the same time, I felt a fair bit of pressure to prepare talks about my various projects and present them: it would help to spread my knowledge and (ahem) raise my visibility. But they weren't interesting projects, and I was not interested in making presentations about them (or in general).
The whole point of a tech company is to pay engineers $X and find a way for them to create some over-unity multiple of $X in value.
If the problem is “this incentivizes engineers to make each other deliver more value”, that sounds like not a problem (and opens everyone up for increasing $X).
It’s a problem when you start to see your fellow employees as the competition instead of your actual competitors being the competition.
It's a problem for people who value working on things that actually get used for more than a few years and aren't duplicate efforts to make some line on some graph go up somewhere.
These are of course people, after all. Not robots.
> The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.
It's good to have people who understand the difference between the prisoners' dilemma and the iterated prisoners' dilemma.
When I was younger I was aware of the idea of perverse and misaligned incentives, but I never would have expected the extent to which they pervade practically every human institution.
Historically this was achieved via religion. Small-to-medium size startups can sometimes pull it off with the concept of a "mission", although that's probably less effective these days since everyone wants to "change the world". I think someone would have to be pretty naive to have a similar level of belief in the mission of a multinational corporation. Or they're high enough in the org chart that they don't have to worry about anything else.
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.
Thanks for the recommendation. I am a big fan of Weber, not familiar with Deming but his work sounds very relevant. In general I tend to agree that beyond a certain size organization these problems seem unavoidable. I've read Systemantics/The Systems Bible and it seems to come to a similar conclusion.
I'm Poor Charlie's Almanac, Charlie Munger explains that cheating is a huge problem, and that if you create a game where people can cheat to get ahead, they almost inevitably will.
At Google you could cheat the promotion system. Just spend more time optimizing for promo than for improving products for your customers, and you would be handsomely rewarded. You end up with the cheaters becoming the leaders and the good engineers leaving in frustration when they need to take orders from cheaters.
Most promotions I've seen are when someone has a huge amount of tribal knowledge about some system and the company cannot afford to have them leave. So they get promoted. This is even within FAANG, where this narrative about impact or 10x developers is common. Not saying promotions dont happen for those reasons, just that huge systems that few people understand lead to promotions for those who do understand them
Not really? Promos incentive "up and out" culture, where people switch teams after getting promoted. Machiavellian managers respond by not promoting their best people, instead forever dangling the carrot of "deliver this and get promoted next cycle!".
This is very common! What's worse is these engineers likely created or at least contributed to a situation where tribal knowledge is valuable, rather than developing simple decoupled systems that can be picked up by new engineers.
Yeah it’s your usual “hire a bunch of underpaid and under skilled-for-the-job” “engineers” at the beginning of your startup that write piles of crap code that then become knowledge pullers of the business. When if you paid good money in the first place you wouldn’t need that knowledge in the first place.
I used to manage engineers at another large tech company and this was a big problem. There was nowhere near enough big projects to get everyone the evidence they needed for promotions.
As a result we ended up doing two things a lot:
1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)
2) de-prioritizing important things that were small in order to ensure everyone had a big project every quarter.
We ended up having to hire contractors to work on the small stuff because it was piling up and causing problems.
> 1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)
Ideally this gets people fired, not promoted. Google explicitly calls out "solutions to hard problems are easy to maintain" on its ladder, for example. People can fail to identify these cases, but the intention is to promote based on hard problems rather than complex solutions.
I think there just aren’t enough reasonably solvable hard problems. All the low hanging fruit is taken, and the result is artificially complex solutions as a way for engineers to demonstrate craftsmanship.
Do they consider fixing easy bugs are hard problem? Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?
I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.
No, this wouldn't get someone promoted, because it doesn't actually solve the problem. The problem here is that the triage process is a mess. Fixing that, so that bugs don't bounce around for months, would probably get someone promoted, or at least be a significant factor.
What if the solution to that hard problem is improving the incentive structure and paying/promoting people for fixing bugs? That's something only ELT or SVPs can do and they aren't getting promoted for that.
If you think the problem can only be solved by management attention, and you cannot demonstrate to your management that the problem is impactful enough that it deserves their attention, either you are incapable of making a clear enough argument to focus on the right problem, or the problem isn't actually as dire as you think it is (or management is bad and wrong, or at the very least mismatches your values).
Two of these are a signal that perhaps you shouldn't be promoted. The third is a signal that you should leave.
In a less generic sense, I think that there are almost always ways to improve incentive structures and encourage people to focus on specific problems that don't directly involve SVPs. Your manager has some control over your rating. If you can argue that "customer happiness" should be a priority and as part of that, end to end bug triage time will impact ratings, you have successfully created an incentive structure that will reward that, without involving anyone who can modify compensation structure.
Is the issue that Google, as a company, is not addressing user happiness enough? Or is the issue that some organization is letting bugs languish? The first is a much harder problem than the second. You don't need to solve the first to fix the second. I stand by my claim that it is feasible to address the first as an L5, that could reasonably get someone promo'd to 6, and you wouldn't need to involve anyone above a director to do it. Of course, doing so would involve writing very little code, because so much of this is procedural and political, so the engineer who just wants to be rewarded for fixing bugs wouldn't take the initiative to solve this problem. But alas.
Sorry but shouldn't you have just taken the initiative and fixed the bug yourself? This is the sort of thing I would hope a company would reward - not passing the buck.
If that's "below your pay grade" _and_ you're still capable of doing it, well that's kind of the problem then, isn't it.
> Sorry but shouldn't you have just taken the initiative and fixed the bug yourself
Why should I spend a week learning a different domain when someone with experience in that code can possibly fix the bug in an hour? Passing the buck to the right person is the correct answer when you are not an expert and someone else is. Passing the buck too many times happens very rarely, most of the time it is the correct answer, so long as you pass it to the right person.
I can go into anyone's code and fix a misspelling. However if the problem is less obvious someone with experience can take a few days off my time just because they don't have to figure out how the code is supposed to work before figuring out why it doesn't do that.
> Do they consider fixing easy bugs are hard problem?
No.
> Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?
No. Grungy work has to get done, but it also won't build a promo case. If a leader isn't finding ways to make sure that the grungy stuff is being completed then they are a failing leader.
It's all about how you twist it. If you say "I built 2 new services that could have just been a feature in an existing service" then you'll probably get a bad review.
However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.
This is underlying problem with promotion culture, I am in a big financial firm, my whole team wants to get promoted every 1-1.5 year. I feel people are not really learning how to write and manage software systems properly due to this.
At Google at least, if you stay low level for too long, you get fired. If your team is full of low level people maintaining a project that's stable, you need to invent work to justify your existence.
You only need one promotion, L3 (entry level) to L4 (mid level), to not get fired at Google. And the company is quite generous with how long it gives you to get there. L3 to L4 is basically about writing good code on your own, and isn't really affected by promo culture -- doesn't really need shiny work.
Several years back, you had to also eventually get to L5. This was more affected by promo culture, but was also largely unenforced, which is why they get rid of the formal requirement to get to L5.
> L3 to L4 is basically about writing good code on your own, and isn't really affected by promo culture
I'm unsarcastically glad that you had a different experience at Google than me. This was not my experience, nor the experience of anyone else on my immediate team.
It sounds you had bottleneck in product management pipeline. Product managers should generate enough creative and significant features to justify stream of large projects.
This all sounds nice but it's missing the concrete details and that's the most important part.
"Build into core values wanting to create a culture where the end-user is the priority, not individual advancement up the ladder"
Is there any non-exploitative way to interpret this? The only thing worse than wasting my time on features for promo rather than users is working overtime to make more money for those with significant equity/ownership in ways that will never seriously affect my comp. Without promo or "promo by a different name" i.e. money, how do you incentivize people? How do you decide who to allocate your finite equity and money to?
A culture where I'm supposed to be working for "the user" rather than for my own benefit is inherently exploitative. Employment is a contract. If I stop delivering value, the company will fire me.
As they say, the reward for being good at your job is more work. Expecting me to put in top effort for "the users" without compensating me doesn't work.
The idea that you can fix this with culture is wrong. It's been tried many times at many companies and it doesn't work for anyone but the owners. Unless you own a significant (let's say >5%) piece of the company, those late nights you work for "the user" will never be worth it to you.
> As they say, the reward for being good at your job is more work. Expecting me to put in top effort for "the users" without compensating me doesn't work.
You do not work for free. You are being paid. 'Top effort' needs not to translate to working overtime, more hours, etc.
It reads a bit unintentionally exploitive as well. You're essentially asking employees to put the companies growth ahead of their compensation.
This passage specifically:
> For as long as possible, make the success of the company the primary motivator, rather than promo
How do you simply make the success of the company the primary motivator? IMO, you either try real hard to pay/promote them based on the success of the company, which feeds into the promo culture problem, or you find people to work towards the company's success without explicit promises of rewards, maybe by alluding to potential rewards you may/may-not give them (aka maybe exploiting them).
One alternative is you can find people who are satisfied with their place in life, and willing to just crank out work regularly without promises of increased rewards. IME, people like that AND skilled enough are very rare. It would be very hard to build a company of solely those people.
> Is there any non-exploitative way to interpret this? The only thing worse than wasting my time on features for promo rather than users is working overtime to make more money for those with significant equity/ownership in ways that will never seriously affect my comp. Without promo or "promo by a different name" i.e. money, how do you incentivize people? How do you decide who to allocate your finite equity and money to?
Easy, there is no promo, you just pay everyone 450k like Netflix and raise everyone's pay each year to stay at the top of the market.
Some ideas: hire fewer people, well remunerated, but make normal pay increments guaranteed and promotions less frequent. Then there isn't such a glut of new engineers constantly creating an "up or out" culture, and people aren't laser-focused on promotion to win big. And lower the early 3 years' RSU allocations.
Recently we had a chat with a lead from another team. Their product has a lot of similarities with ours so we sync up every now and then to bounce ideas off each other. They recently release a big change that we thought didn't provide much value, so we asked him about it.
His candid answer was "you know how it works, we have a service running in production, so we need to make changes". This sounds simple, but the implications are deep. Unlike individual engineers, moving entire teams around is difficult. If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.
I think this is one of the key frustrations I have with modern software development, change for the sake of change. I feel as though many products degrade over time and as a user I’m generally quite hesitant to upgrade anything if I don’t have to.
They have to show on investor calls the line went up.
We’re propping up the wealth of a generation that has no idea how anything works, but they got there first so of course they are now the de facto deciders of our agency.
True, it’s difficult to know how things work when they become needlessly complicated and one is unable to move on from a project that is essentially complete.
It’s presumed needlessly complicated is necessary to make the line go up; behind the scenes, they say, mathmagical forces exist that only the chosen few truly understand. You see everything is really a graph of infinite brand names, and the flow of value is determined by the taxonomy of brand ownership.
Many a study have been attempted to quantify what character qualities or technologies boost productivity. Their model becomes so nebulous no reasonable conclusions can be made.
But now of course computers learning helps us untangle that web and low and behold the same economic winners emerged! Wow!
Like, it's not good enough to have a quality product that generates a sustainable revenue stream year after year. You have to "grow" because companies don't really do dividends anymore, they want a constant increase in stock prices, product be damned.
Arguably one of the causes of this is high salaries and only hiring (supposedly, I have no personal experience) Very Smart Developers. You're going to pay Google salaries for someone just to keep the lights on?
It would be a smart business decision. A Google mid-tier employee or two just isn't a large cost to keep a project running. It's not cheap, sure, but to have a product running at scale?
The rationale for developing Go is that Googlers are fresh out of school and only barely smart enough to program Java, so I think they’ve eased off on the notion they only hire super-geniuses.
I think it's more that they're smart as hell but know very little or have poorly developed taste. So you have to give them a short leash otherwise they'll hang themselves with it through over-engineering and accidental complexity.
The literal quote from Rob Pike is "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.".
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
Isn't the 20% time to work on whatever cool shit you want enough ? (like how googlers created that garbage angular1 because they were border, have no clue about GUIs and had some fun scewing around ) ? I know people that are fine with getting paid to maintain shit so maybe the problem is Google only hires cool developers and the cool developers only want to work on cool stuff and in 2 years the newest cool stuff of-course.
There is that too, but you could solve that by having engineers/teams working in new, cool, and useful products. I feel my company doesn't have a good mechanism to maintain services that aren't actively developed.
We experience it first hand when one of our services got deprecated and we moved to a new org. The solution was literally to hire a new team in a low CoL country and hand over the service to them. Needless to say it was difficult to hire for those positions.
Experienced something similar, but it was not an outage. Had several knowledgeable people leave the company, and they all happened to be experts in a particular service. Positions weren’t backfilled even though the people gave advance notice. About two months later we ended up getting out butts kicked when nobody knew the details of the service implementation and the service was expected to be updated to support some new features.. couldn’t get it updated for about 3-4 weeks because we couldn’t afford an outage.
Arguably those folks who left didn't do quite as good a job as they perhaps should have when they were still there. A high quality developer leaving a service behind should have already written sufficient documentation so that another high quality developer (especially one at the same company) can ramp up more quickly than 3-4 weeks. I think this is just another symptom of many tech companies throwing up their hands and pretending like "legacy" services are inescapable technical debt, when really they just never bothered to emphasize to their employees that services should be built in a maintainable way from the outset.
This is true but only so long as they have been given time to do it. I've left a company, with notice, and they had me working on building stuff almost to my last day. Sure I did have a few "hand over" sessions in my schedule where I was expected to walk other devs through some stuff I was the owner for in a broad sense, but they never gave me time to produce solid docs for anything even knowing I was headed out the door
It can get worse: me and my teammate trained a new dev for half a year with the explicit intention for him to take over should one of us leave. When the day came, said new dev was moved to another team, the product was given to an outsourcer and I was told to train them how to develop in two 2h sessions before I left. (The product was a legacy mess we were in the (multi year) process of refactoring into something maintainable. Documenting the intentions midway or even the status before was beyond the time budget we were allotted. All of this while doing feature development, without having proper requirements or user stories or access to customers who understand their use case, of course.)
That sounds rough. It's very painful not having time to do things properly, and it's also painful when you don't have proper requirements so you can't even be totally sure what properly even is. I semi-recently left a job (the one I was talking about originally) after more than once being told "we just want a toy, proof of concept version and any time you spend on things like performance is a waste of time and we will scold you for it, even if there isn't any other work for you to do" before they decided to ship my "toy proof of concept" to a client requiring an ungodly rework of it while it was running in a production environment.
I honestly think people denigrate having at least some actual design work and requirements done upfront as being "too waterfall" and think doing it is a bad idea so we as an industry end up with not even the intentions of how a piece of code should work written down and no idea how stuff works once the original author moves on
That's exactly my point. If companies aren't expecting their developers to document their services - while the developers are still employed and building those services in the first place - that's a failure in my books. It's exactly the sort of corporate culture that props up this mindset of "promotion-driven development".
Ah my apologies, I thought you meant it was a failing of the developers themselves - which it definitely could be in some circumstances - and I felt the need to point out that a corporate culture can lead to docs not existing.
Part of this is due to companies shooting themselves in the foot over and over, recruiting developers looking for challenges rather than grunt developers okay doing largely maintenance for a solid income. If they advocate themselves as providing the challenges for the former and filter out the latter, yes, obviously your employees are going to leave after they have to move that one div by 5 pixels for the umpteenth time and get no mental stimulation for months.
Does anyone recruit grunt devs like that? That honestly sounds like what I'd prefer. I just want to come in, keep the lights on, and have enough mental energy for other stuff after work.
All across corporate America, there are devs who make 80-120k a year and keep it 9-5 (but really like 11-2). Especially with the recent turmoil in the market, you can find a very easy yet well paying (for normal people) job. Now if only HR would advertise the jobs this way...
I don't know too much about Google, but I can talk about other companies.
Everyone recruits grunt devs like that. That's what every job in Silicon Valley is. It's just that some companies and teams want you to spin it like you're some amazing lone wolf 100x genius while you're scraping dogshit off the bottom of the company's shoes.
A big part of it is that the executives decide what's making money for the company, and they'll focus on that. If you're scraping turds on the "rockstar" team in the "rockstar" org, you'll get showered with bonus money and RSUs. If you're scraping turds on a product that none of the VPs care about, you'll probably get screwed over. Some of the people in the non-"ninja"/"wizard"/"rockstar" orgs will do OK because they look like indispensable geniuses, and I think that's what a lot of this sentiment comes from.
I am curious - is this informed by your experience of having sampled every job in SV? Or perhaps a representative sample? Is it possible other people might be different than you and have a different perspective.
Well, you have to maintain things after they're made. New things are usually made out of multiple old things. Figuring out how stuff works, then fixing and reusing, supporting, or replacing it is the bulk of every programming job I've done or heard of.
I can't even conceive of what programming job wouldn't be describable as "grunt work" from the point of view of some hypothetical super-genius. Writing "new" code that just does the same thing as something you're tossing out, but with a different set of mistakes? Cutting-edge science work is mostly glue code between hardware and spreadsheets or databases. Cell phone firmware is mostly repurposing and updating the old firmware. Anything involving a GUI is going to be a massive time-sink getting the GUI to work the way the non-technical people using it want it to work.
How much time do you spend in any given year figuring out how to operate debuggers, find the right log files, narrow down some crash, etc?
As you said, those are required components of shipping software. I don’t consider them grunt work, any more than I would consider being a janitor as a grunt.
Grunt implies a heirarchy and a job that anyone can do. It’s pejorative. There is work that I don’t enjoy doing but needs to be done well (cleaning a toilet). I appreciate those jobs even more than what I do!
My point is that you should try to shift to language of “work I don’t enjoy” rather than “work that is beneath such an exalted 10x programmer such as myself”. Because that’s how I interpreted your original comment.
The challenge for engineering management is how to provide metrics to measure your bus factor reduction efforts and the strength of your insurance prior to the emergency.
It is highly possible though that the new support team members are actually coasting up until the disaster so you didn't really have the insurance you thought you were paying for.
You can find maintenance experts too. When someone tells me that they have this important, dangerous, buggy system wthat has trouble handling its ever growing load, and they need someone to come in and fix it, I cannot be any happier. But I know the system has to be really important, and that the fire has to be so bad that upper management is willing to spend the money to let some specialists come in, few questions asked, knowing that they will be rewarded as if they were building a new shiny, high visibility doodad. What is difficult is to have management that will keep that level of attention, instead of realizing that the reason that nobody has heard a bad thing from the system in months, if not years, is because there's a lot of work being done trying to make the system invisible.
What usually happens is that after a year or two they forget, and the maintenance programmer jumps to a different fire, typically in a different company, because there is far less reward to keep improving the system than to stop it from being a raging fire.
Yeah and this problem is exacerbated at Google by the relatively easy process of moving between teams. Other companies I was at made this hard. Google encourages it.
When friends complain to me about Google killing projects, they act as if it's upper management making a decision to kill. And that is sometimes the case. But often it's just: nobody wanted to work on it anymore. And Google isn't the kind of "command and control" culture where you crack the whip and tell all your engineers that they're doing X and assign them. At Google they'll just leave your org and move to some other team, and you won't have the power to stop them.
Not saying that's a bad thing, but it has some bad outcomes occasionally.
There are plenty of people who like fixing the occasional bug and adding a touch more polish. The problem is that this is actively disincentivized on every level. On top of that, a lot of people have internalized this.
If the world weren't so obsessed with differentiating pay, you would have people who are enthusiastic about a wider variety of things.
> If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.
This. It generates the Bullshit Jobs that David Graeber talked about. As a middle manager or tech lead (Taskmaster) you hire people (Flunkies) to make yourself seem more important as well as for roles (Box Ticker) that you might not need but that any "important" project will retain. In the end, this generates duplicate effort and needless work that requires fixing (Duct-Tapers). The only one of the five Graeber categories not represented is the Goon, and that's because those get moved to MTV and fast tracked to the executive suite.
The author did a really good job of pointing out problem of promo culture, but the solutions suggested are more inspirational than actionable.
All founders/execs/early employees are easily aligned on compabt success. But how do you align incentive of later hires?
In order to reduce time spent on perf, you'd have to rely on a few people who knows an employee's work instead of a larger peer group and committee. The person entrusted with this decision (typically the manager) now wields tremendous amount of power over others. This leads to a different set of problems, like "B player hires C player", yes-man culture, ICs spending effort brown nosing instead of creating value, etc.
Building a culture is all about incentives, it's easy to identify and reward user/company impact when the team is small. But as number grows, it becomes harder to do that, and the declared core values gets ignored as the reward system departs from that.
i remember reading in some startup oriented text that founder driven values works up to about 50 people. once your company grows beyond that a culture shift is inevitable.
i don't know what the answers are to manage that shift and avoid it going into the wrong direction.
This echoes my read of this article as well. Any system for promotion has tradeoffs. You can't just say "this system's tradeoffs suck, we should have a new system with no tradeoffs."
I'll admit, I don't really have a good solution. My strategy has been to just stick to early-stage startups where everyone is aligned on company success. Would love to hear some more meaningful discussion of alternative systems for managing career ladders.
Experience points. Every you complete a task, you gain experience points. Gain enough, you go up a level. Flavor them for different job tracks, tweak the rewards to incentivize the behaviors you want and not the ones you don't. If someone isn't gaining experience at a good rate, take a closer look to see whether they are doing things that should be worth XP, or whether you need to have a different conversation.
Give people some choices on leveling up -- maybe most people just want a bump to salary, maybe other people would like to gain more vacation, stock, half days Friday, a private office, a good parking spot, etc etc.
The deeper issue you are pointing out is that only early employees get to capture the majority of the value while late employees only get the bread-crumbs. So everyone wants to be "early employee" of new products. In a way, this is inherent problem with capitalism where the idea is that if you have the capital, you pay the workers generating your capital only through return on capital as opposed to part of the capital. This way you can grow your networth exponentially in capitalistic system as long as you can begin with sufficient initial capital somehow. Anyone without such capital must live on month-to-month or year-to-year wages generated by the return-on-capital.
> The person entrusted with this decision (typically the manager) now wields tremendous amount of power over others.
This happens anyway in Google's "objective" promo system. Your manager assigns your projects, gives you your non-promo performance ratings, sets direction for your team, they sit in the room with the promo committee, and their feedback is critical to the promo committee's decision. You need their help and support to get promoted. If they didn't have significant impact on your work, they're not a manager.
Ostensibly you can go try for promo even if your manager disagrees. I never had any evidence this worked for anyone and I have no idea how it would work. Sometimes borderline promo cases would go up for promo when their manager thought it was unlikely, and it would succeed. But if your manager doesn't think you should get promoted, they're going to tell the committee that, and I don't know what the promo committee would see that would cause them to overrule the manager.
I worked at companies where managers are little tsars of their turf, and Google.
The difference with Google is that: 1) you can give feedback to your manager, both anonymously and explicitly, and they'll affect their perf; and 2) your success, in terms of impact and promo are part of your managers success; 3) perf committee will challenge and can override your manager if the rating given seems too low/high given the evidence.
These forces while do not take power away from manager completely, they provide some checks and incentivize managers to respect and support their reports.
Of course, all these nice things come at a cost, that is perf becoming a somewhat transparent and heavy process that eats everyone's time and mental energy.
I've been on promotion committees where it was clear that the manager didn't support it, but we promoted the candidate. I feel like most of the memorable discussions in those committees were figuring out how to give the manager feedback on how bad of a job they were doing.
I agree that you're basically screwed, especially L3->L4, if your manager isn't actively counselling you on how to grow your career. You obviously don't have enough experience to do it on your own at that point, so you are at their whim. Even when you do have the experience, if you don't have a good working relationship with your manager, you're in trouble anywhere. It is ultimately going to be them or you, and you are easier to get rid of ("he took another offer" versus "everyone thinks your manager is a jerk, so we fired him, oh by the way in the meantime your career is on hold while we figure out what the fuck to do please keep showing up").
Yeah, I agree with you totally. The promo culture is certainly broken, but the solution they propose seems....like startup worship at best, exploitation at worst (work harder without a payout and be happy).
I don't know what the solution is. I've been at amazon, and the number of abandoned promo projects are insane. Microsoft has like 7 billion levels, maybe they have it right, you can promo someone without it meaning a whole lot, but it still gives them greater pay and a sense of progression.
> The author did a really good job of pointing out problem of promo culture, but the solutions suggested are more inspirational than actionable.
Totally agreed.
One thing that killed my motivation in mega-corp(tm) is that your peers are, in reality, your competitors, despite the constant barrage of HR propaganda indoctrinating the opposite. Either directly or indirectly, you are incentivized to take high visibility projects for yourself, take credit for other people's work, and reinforce a narrative about yourself where you are better precisely than those around you.
Seriously, why do people care about being promoted beyond senior/staff? Even at a smaller company you're making 200k/year, you probably have a good handle on your job, why not just coast? There's a big discontinuity in comp if you can make it to the director level, but being a manager or senior staff seems like a ton of work for no benefit.
I work like 20 hours a week at my job, I almost quit because it's extremely boring and dysfunctional, but then I realized I can just disengage and enjoy my extra free time instead of pushing to exceed expectations. And I still get paid the same.
Do their budgets balance or do they take on credit card and other debt to manage the deficit ? I am not claiming its one way or the other as I do not know the answer.
I'm going to guess that software developers, especially ones at FAANG, aren't aiming for a median household lifestyle. 200k post tax is easily ~140k a year. A san francisco mortgage is easily 4-5k a month for 30 years. And if their kids don't get lucky on the school lottery, they're going to be sending them to private school. And then there's college savings to account for.
At Google specifically, even being promoted to staff is a huge undertaking. And until recently, there was an expectation of forward career trajectory built into the lower ranks, i.e. every engineer was functionally multi-year probationary. If you found something valuable to do but you weren't progressing your career (because, say, the work was necessary but boring, like micro-optimizations, feature polish on a mature product, or documentation / example creation), you'd start to have talks with your manager about your future at the company.
I believe they relaxed that process when someone at the top took a look at their org-chart and realized they've become a big company where they need a critical mass of not-actually-interested-in-progressing engineers to keep the lights on and if they actually followed their policy, they risked churning those reliable workhorses out of the company because they couldn't actually afford to find a slot to promote them all.
I don't know because the change was decided way above my pay grade, but I always assumed that the reason was HR legal.
It is hard to look at people who are objectively doing as well as each other, and rate some lower only because they have been at that job grade "too long".
The fig leaf was always that the ladders encourages keeping up with technology and the company, which meant people couldn't tread water at the lower grades.
But if the "new technology" isn't necessary for the job duties, labor lawyers can have a field day.
In general I agree. It's just that I don't know if salaried job lead to FU money. The only person I had or will be able to say FU is to myself sitting alone in living room.
Depends on who you are and what your growth potential is. I know SWEs getting offers in the 7-8 figure range. That's not in any way typical but if you're smart enough, hardworking, and get the right breaks hitting a 7 figure income isn't something I'd consider weird and is definitely FU money.
Do you worry about being hit by a bus before you have FU money? Personally I'd rather work half time for twice as many years than try to race to retire.
A lot of responses seem to be focused on high cost-of-living areas, which is kind of a chicken-and-egg problem. If you want to be a moderately checked out person, living in a smaller city and stretching your giant bay area salary is the way to go. If you want to be aggressively careerist, you have to be face-to-face in the bay networking.
More input and more interesting problems both feel like more responsibility for the same comp, imo, which might be appealing for some people but is anathema to me. The people higher up got there by being more argumentative, or backstabbing, or ingratiating themselves, and instead of going along with them now you get to fight them. No thanks.
Yes, given "getting hit by a bus" is a probabilistic event that is independent of my working hours, I would rather make 2x for half as many years, all other things being equal. I'd also rather make 3x for a third as many years, and so on, if it were possible. Given time value of money and compounding interest, it's always better to front load your working time and make Nx for 1/N as much calendar time worked.
And for the controversial part: The above is why I think it's insane to, for example, take 1-2 years of not working, early in your 20s, to go see the world and "find yourself." Those 1-2 years, if spent earning, could mean retiring an extra 3-6 years earlier.
I agree with your conclusion, but I think there’s a fair argument to say that an extra week of leisure in your 20s is worth more than an extra week of leisure in your 50s or 60s. That is even more true if you’re working 48 weeks/year in your 20s and zero weeks in your 60s.
I think it's insane to, for example, work at an office early in your 20s, to put a couple grand in your 401(k). Those 1-2 years, if spent exploring, could mean finding a happier and more thoughtful way to progress through the latter 70% of your life.
I think this points out a difference in viewing everything in life as an efficiency problem focused on retirement age and overall wealth. Makes sense for a forum of engineers to see it this way I suppose.
Early on the money is probably the least important part. Momentum seems like a lot more important.
If you finish uni and take 1-2yrs off, that puts you wayyy behind someone who goes straight into a job. If you take 1-2yrs off your knowledge won't be fresh and you'll not really be a new grad anymore.
"getting hit for a bus" is a hyperbolic example meant to stand in for a catastrophic event. It really means you (or a family member like a parent, partner or child) has a major health event, for instance. Some things are random, some things tend to become more likely with age. Even just chronic pain or other health issues might make retirement less fun than travelling in your 20s (speaking as someone with chronic pain from surgical implants).
Besides health there's a lot of reasons why being certain about doing something now might be preferable to putting it off for 10+ years.
My todo list will keep me busy until I'm 3000 years old. I might not be hit by a bus, but I have no reason to think I will ever get to the end of that list. Money can buy things required for the list that are not on the list, but I have to work to get them. In many cases I spend less time working then I would just doing it. I could make a canoe from scrap wood and row to New Zealand, but in a week at work I get enough money to pay for a plane ticket, while paddling across the ocean would take months (people have taking canoes across the ocean so I know it is possible - though I'm not sure how risky it is)
> Do you worry about being hit by a bus before you have FU money?
No. I don't work that hard, and my work is generally enjoyable, I've made a lot of good friends, and get to live in the area I grew up in near my family.
> A lot of responses seem to be focused on high cost-of-living areas
Well, my response was to a poster asking "why do you care about making more if you make 200k?" and the answer for some people making that amount of money is that they are only able to find work paying 200k+ in a high COL area.
> More input and more interesting problems both feel like more responsibility for the same comp
The thing driving more interesting problems and more input is a title bump, which in my neck of the woods means a 50% or greater pay bump, so I would say that's not for the same comp. Whether it's more responsibility is variable, but I know engineers two levels above senior who more or less have the same responsibilities as a senior engineer except their project is "harder" and more important to the company (this does not mean the more senior engineer is actually working more hours though).
Perhaps a meta point here is also useful. Once you're senior, most engineering work available is not interesting and does not help you grow as an engineer. Engineering work that helps you grow as an engineer often makes you more valuable. Companies usually give interesting work to their best engineers. If you can quickly climb the ladder to where your job feeds you interesting work you can enter into a "winners-win-more" sort of feedback loop. This is a strong incentive to front-load your career growth by working really hard for your first decade in industry (or at least years 5-10).
> 4. Bigger title -> more control in picking interesting problems to work on. People trust you to say "this should be a priority"
This is probably one of the most dominant non-financial factor for engineers. Because if you want to make a visible, critical design decisions for billion-user products you usually want to be at least L6~L7, the level where you're now an owner of a non-trivial product/system spanning across teams.
In the boom time there's an unending appetite for mediocre engineers to inflate headcount, making managers look good (more reports) and companies look good (to investors). In the bust time, I don't think even the smartest people will be safe, and the top of the ladder may well be pruned more aggressively because they're expensive. Having positive reviews may protect you, but being high in the org won't.
Depends on how high. You don't want to be in the "off in the corner" research group which is usually comprised of very high level engineers (senior or staff level or higher). You definitely don't want to be high up in the middle tier either. What you want is to be known to your Vice Presidents and above. That's when you reached "high enough" to avoid the great cull.
I witnessed this more times than I can count.
Otherwise its all balance sheet calculations and maybe your manager can pull a punch or two if the product area is critical enough.
Performance reviews in corporate culture often have a "what have you done for me lately?" mindset.
If you're senior or staff and haven't launched anything exciting lately, middle management might become less interested in whether the service is running well and more interested in having "career" conversations about how your role description says you're supposed to be launching cross-functional projects more frequently.
Okay, but the important part is "the five places you'd be willing to live". There are significant reasons most of us aren't moving to the middle of nowhere to be able to afford a home.
I understand the perspective of people who view their profession as solely a job, checking out after their 9-5 and doing other things with their life. This isn't me. I enjoy the work. Idealistically, I think I can make a large impact on people with my knowledge and experience. Shave off a seconds on a workflow in Google Docs end-to-end, that's a net good to humanity. It's not all about compensation. At some point it's almost only about impact, and impact often requires higher titles and putting in hours due to systems that govern these large companies.
There's just a lack of ability to own a product as an engineer. Those things are delegated to managers and product owners; lead engineers are really just there to align work - not really to make broad vision beyond suggestions.
If engineering firms wanted to improve they'd ensure that everyone who has decision making power over a product, whether from a business or technical perspective, is at the same level and has the same input. That way refactor is weighed the same as a new feature or service.
At my previous employer, every quarter we were supposed to update an elaborate spreadsheet describing how we measured up against the numerous criteria for the next level on the career ladder. I hated it.
That said, there were lots of people who obsessed over the process, looking for shortcuts or ways to game the system.
I think the problem with the promotion culture is that you can't demote someone after they've been promoted. If you just focus on showing impact and cross team projects, your engineers will naturally build more complex projects than needed to hit those targets. The key is to track the long term maintainability and quality of the systems built. E.g. time to land diffs, incidents, performance metrics, etc. If a system starts to quickly fail these things or don't last then it is a pretty good sign that the project wasn't actually built well. Things aren't always under a single person's control but a lot of people will work on a big complex (seemingly good) project and then bounce after they've gotten their promo.
I do think there is a balance though because at a lot of startups the incentive is to just crank out a lot of product code but not really think about multiplier type work.
My experience has been that some companies pressure engineers to want to advance. If you come into a performance review and say "actually I'm happy where I am" it's seen as a lack of motivation and will count as a mark against you. I had a boss say to me "I always want to move to the next level and I expect the same of my reports". Whatever, I guess I'm a poor employee because I like my job.
I’ve openly stated that I want my retirement job to be an SWE3-ish role somewhere. High enough to have interesting, somewhat challenging work, but with negative desire to climb the ranks any further.
Problem with that is due to inflation, you're making less and less compensation every year. Standard "you're doing a good job" raises often do not meet inflation, and certainly are not right now where inflation is higher than the recent historical mean. This is not a problem for some people, maybe including you, but I think most people have a general vague career expectation of making more when they're 60 than they make when they're 50, than they make when they're 40, and so on--even if they don't plan to be an overachieving "ladder climber".
I may have been unclear. By retirement job, I meant a job that I took during (read: after) retirement, not the one I’d walk away from at the moment of retiring.
At that point, financial arrangements are presumably already all set.
I agree, but this isn't as bad as you might think once you're a senior engineer at a top-end company. A lot of your compensation is in the form of stocks that will appreciate in value with inflation, so assuming you're in good graces with your director and VP, it's possible you'll fall behind the market rate very slowly
i want to retire as an engineer. If I went management I'd be much more likely to get to this high paying jobs in the executive suite. What I don't want is to be doing the same thing again and again with no recognition of how useful I am. If I'm not useful, then I need to get into a different position.
Can confirm, it’s a great choice. Step one, convince a FAANG/MAGMA to let you work remote at the same salary level you already have. Step two, move to an extremely cheap cost-of-living area. Step three, avoid promotion at all costs, and just fix bugs.
Provide value, but _never_ get promoted. Every year come review season, talk about how your goals for the next year are to improve latency/perf/whatever. It doesn’t have to be specific, just something that’s important enough to be useful, but don’t be ambitious. Just keep your head down and make enough improvements that people consider you to be a good “grunt” worker.
Yeah yeah, inflation sucks and technically I’m making less because my RSU’s have mostly vested and my yearly grants haven’t made up for it, but I don’t care. I’ve saved up enough that I could retire now if I really wanted to.
Every day for me, I work 9-5, fix a few bugs, provide some value, then work’s over and I get to play with my son and completely forget about my job. Then once he’s in bed I smoke some weed, watch shows with the wife, talk about the good old days. It’s heaven.
(By the way, I say all this, but I kinda failed at it because I got promoted last year anyway. I got hella worried because I thought they’d start expecting more out of me, so I actually slowed down my pace even more. I just got a mid-cycle bonus last month. Maybe I’m not so great at keeping my head down after all…)
I hope I can down level myself after I go over 65 or 70 (depending on my health of course, hopefully I have that option). I think it is an option at some companies (older talent getting ready to retire but still have a lot to contribute).
Some (many?) companies have an 'up or out' requirement where each position has a time limit to get promoted, unless it's a 'terminal position' which is ok to stay at.
When I was at Facebook, this was administered by using the next level review guidelines after you had a position for N months (depends on the position), and if you don't meet those expectations, putting you into the firing pipeline (PIP, etc). One of many reasons I was happier when I stopped having people reporting to me.
I just want to say that I can't believe some of the smartest people in the world are willing to put up with all of this off-putting corporate bullshit. No disrespect.
I'd argue they are far from some of the smartest people in the world. Smart? Sure, some (many?) but I've known quite a few idiots in software. But I'd hardly compare the regular software engineer at a FAANG to some of the geniuses in the world.
But they put up with it because it's a career and not a job. Many of them couldn't handle a minimum wage or working class job. No breaks, short lunches, no wriggle room for life, permanent fast-tracks to firing.
I dunno, I would say on my whole in my 10 years at Google I really did meet some of the most talented (in terms of raw knowledge or focus or some other skill) people ever in my career.
But they were mostly being paid handsomely to apply those amazing skills to really humdrum tasks -- but painting them up to be really profound -- and that's the saddest thing.
I would say that a high affinity for playing the games invented by others for the rewards invented by others is orthogonal to raw intelligence. In fact, smart people usually have a lifetime of being rewarded for exercising their intelligence on command. Where are they supposed to learn a healthy disrespect for authority when they have always been the darlings of authority?
And now you know why Google, etc. have a strong bias for hiring out of academia and out of the higher levels of education. (Not just because the founders never worked industry, just academia, when they started Google, but I digress...).
The interview process is highly highly biased towards recent grads (algorithm/data-structure courses) and the kind of people who do super well in university show-and-tell.
I have worked in three FAANG's and that was not true in any of those once you reach a certain level. This is somewhere between 4/5. The reason is that at that point the employee is considered mostly independent and can be expected to solve their task without too much intervention.
> and even if you care deeply about other things (your product, your users, etc), you can’t really avoid caring about promotion as well.
I can honestly say I didn't care about promotion while I was on the Windows accessibility team at Microsoft (as a Software Engineer II). The quoted assertion makes me wonder if I was being naive or lazy. I truly believed that I didn't need to care about promotion because the work I was doing was worthwhile for its own sake, i.e. I cared about the product and the users. In retrospect, maybe I didn't make the most of the opportunity I had there; I suppose I could have had more impact if I had leveled up. But I wasn't thinking that way at the time.
The way I looked at it was: if I'm being paid enough, I care about being happy more than being paid more. Jumping through hoops to get promoted is going to get me more money and also make me do more stuff I don't want to do. I was happiest when I had a clear, important job to do, that everyone knew wasn't enough work for one person, and then the expectation that I'd spend the rest of the time fixing stuff that was nobody's job and freedom to set priorities for the most part (after all, if it was important, it should be somebody's job). Of course, at the last place, I think they have four engineers now doing my important job that left me mostly idle. Not sure how four people can work on it, but not my circus.
I briefly had one person reporting to me (well two people, in sequence), and navigating performance reviews on behalf of someone else is not for me.
This is only sort-of related, but a while back there was a beautiful Twitter thread, I think about Google product managers or engineering leaders, who come into a product, revamp a bunch of features and come up with metrics to show that they were successful with it in the short term, and then use that as the case for their promotion and time it just right so they can disengage and bail over to the next product, just before all of the short-term decisions they made blew up and hurt the original product. The punchline of the tweet thread was that they move on to the next product - and the final tweet in the thread looped back to the first tweet in the thread.
Former Googler here. This person has correctly identified that a key reason why google sucks is that people very often...
> choose between doing what’s best for users or what’s best for their career
But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.
Imagine if people did get promoted for fixing bugs instead of building a new product (to be abandoned)! Or if maintaining an existing system was somehow on par with building a new system (which is just a bigger more complicated version of something perfectly good). The googler would say "well those useful problems are too easy to merit a promotion. Anybody can solve easy problems - we're google, and we're too smart to work on those easy problems." Grow up.
Y'all value the wrong things. That's why your culture is broken.
A friend of mine didn't get a promotion at Google because he was told that though his work generated >1B of revenues for the company, it was not "hard enough". He left the company.
This was one of the primary reasons I left. I had a project that enabled more than 100M+ increased revenue globally and the sales teams it impacted loved my work. But it wasn't considered hard enough or technically challenging work by engineering leadership so I got CME. That was it for me.
Another example of this is their OKR system. If you meet all your quarterly goals at Google, that's not a success. In fact, you're frowned upon for not setting your goals high enough.
Their whole management process encourages people to chase after impossible goals, and literally discourages people from getting things done.
Missing OKRs means that the team cannot set achievable goals. It is a signal that the team has terrible foresight.
I know the argument is that by being more ambitious and achieving 70%, you are setting ambitious goals. But then the goals are never met. The work doesn't finish. The projects falter. The users are unhappy. Engineers leave.
In my experience, people make 10 goals during planning and then later decide on the 7 that they're going to hit. I wouldn't mind if the goals were ambitious but efforts were made to achieve 70% of them. However, in practice it seems like there's no vision during planning and instead they change course midway through the half. What's the point of planning if you can't stick to the plan.
Yeah from what I've heard you ideally want to hit 70-80% of your OKRs, and people game it to make sure they fail at one or two so they don't get accused of being "too easy".
One of the most hilarious things I've ever seen was the head of Google Plus loudly sharing his "1.0 OKR" regarding social adoption at TGIF. It was about that time folks got suspicious and some long-termers found out Vic was lying about adoption rates.
Oof. Is that really why he got canned. I'd always assumed Gundotra just made too many enemies during the period where L&S empowered him to do whatever it takes to win in social, and when he didn't win, he had burned too many bridges to stay. Lying about adoption is something I didn't hear before.
I've never seen or even heard of anyone throwing their OKRs to avoid the appearance that they were too easy. In fact, you rarely hear about another team's grading of OKRs at all. Plenty of teams inside Google also set OKRs expecting/hoping to hit 1.0 so it wouldn't be at all surprising to see lots of 1's/near 1's on teams.
Well this was told to me by xooglers who were now working for other companies, so either they were the ones doing it and that's why they left, or they made it up to make Google sound worse. So I guess take it with a grain of salt?
Here here! We don't have to believe everything internet strangers say. The presupposition that an unvetted internet comment will somehow become "vetted" by the probing of _another_ internet stranger doesn't make any sense.
12 years ago OKRs were huge. And yes, you graded them, managers and other teams viewed them, and you aimed for 0.7. Recently, it was a lot more lax. Many teams didn’t do them, drifted away from them, or didn’t bother grading them
My team (under ads SRE umbrella) usually did aim for ~0.8 with a 1.0 stretch goal of some sort. It was a fairly reasonable calibration to make sure we were scoping and planning OKRs accurately.
If every OKR got 1.0 it meant we could comfortably take on more work next half, below 0.8 and we would plan to do a little less next half.
In theory it would have been fine to score OKRs above 1.0 for stretch goals for the same effect, but the software didn't work that way.
That culture came straight from Larry and Sergey. When I was there they would say at TGIF explicitly that if you score 1.0 they'd get suspicious because maybe you were setting goals that were too easy. Guess what, nobody ever got 1.0
I’ve seen this in many companies other than Google and shockingly even at startups.
If setting an OKR is meant to focus the team and maximize effort towards solving those problems, this approach is counterproductive because it completely fails to measure the effort exerted towards a goal.
You could have a 1.0 OKR and you could have 2 cases.
1. Set it too easy, didn’t have to do much to achieve it
2. Set a hard goal and produce a Herculean effort to achieve it
The latter case isn’t accounted for. It’s is glaringly obvious but the dull manager types don’t seem to want to acknowledge the difference or the fact that the latter behavior, if incentivized, leads to better and more predictable outcomes.
Instead, the effort is met with a blanket: “Too easy, didn’t set a hard enough goal”.
This incentivizes people to set easier goals that they can meet comfortably and slack of 20% of the time so that it doesn’t look like the goal they set was too easy.
Hmm. If you are supposed to not meet all your OKRs, then that guarantees you will have a record of unmeet OKRs, which can be used as ammunition to deny promotion or even fire someone.
So that encourages a sort of favoritism, where the people you want to promote anyway have their missed OKRs overlooked, while the rest of the pack aren't meeting their OKRs.
Never worked at Google but I have seen exactly this happening at other OKR-based companies. Ultimately whether missing your OKRs is framed as valiant struggle or disappointing failure does absolutely depend on external perception.
Yup. I left a decade ago with this exact thought. There are people there who lift mountains to create real working systems, but you're actively discouraged from doing that if you want any sort of career there. And spending two weeks a year on performance reviews just serves as a constant reminder of those values.
It's easily visible from the outside too. The constant stream of one half-baked video chat solution or social network replacing the last one, without any sense of progress or continuity, why would a company do that? Easy, no one gets promoted for fixing anything, but creating the next broken thing? That's vision.
Or maybe it's because the company is always looking for the runaway 10X success story (like search, ads, etc). Incremental growth doesn't make a dent in the balance sheet. So they're always shutting down the products that didn't explode into a success and starting new ones to roll the dice.
I work in academic libraries. At the point Google Books and Google Scholar (two things that were relevant to my work) were being developed or very new, maybe 10 years ago now, I could actually talk to Google engineers about questions on how I could/should best integrate on my end, or problems or bugs (I did find some, that the google contacts agreed were). (It's true that cooperation from libraries/academic sector was something Google needed to succeed there too, to some extent).
Two years later... forget it. There was no way to get anyone's attention or a response about anything. This includes actual bugs and problems.
It was pretty clear to me then that there was nobody driving the bus on these projects anymore. There had been excited invested smart people around for the development, but once the thing seemed stable... there didn't seem to be anyone around at all anymore? I started to notice that this was how things worked at Google generally -- after a new product was deployed, there seemed to be simply nobody around anymore with the time and interest to act on bug reports, or talk to external partners, or just care at all. Without having at that time heard anything from inside the walls, that became my theory of how things worked at Google -- everything is abandonware.
At least in my own small company - I'm hoping to promote the concept of the T shaped technical leader ladder.
You're rewarded/measured on two metrics - breadth and depth
- a depth metric - leadership in your own specific project team where you add features.
- a breadth metric - you've demonstrably shown that you've gotten other teams outside your own to contribute to your project effectively. Additionally and perhaps more importantly you must show that you can act in a supporting role on multiple other projects outside your own core project. Supporting other projects outside your core project include signing up for triage support, updating documentation, improving testing, etc. without frustrating the primary maintainers.
IMHO - focusing on depth as the only way to technical career progression leads to feature creep, ball of mud codebases with high barriers to entry and silo thinking.
Agree - one feature that is missed w.r.t. long term customer satisfaction and adoption is long term support for previously delivered features. This is exacerbated when product managers/SW teams are mostly measured on new feature delivery metrics.
The full feature lifecycle and reducing bus-factor across the entire existing product feature set is rarely considered as its not generally captured in OKR metrics.
I think both are important but it’s not necessary for any one person to excel at both. Some will naturally be better at depth and others at breadth. As long as you acknowledge both types of contributions I think it will work out well.
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
Another former Googler here (from waaaaaaayyyy back -- I was employee #104).
The reason Google is the way it is, and many organizations are the way they are, is that they are trying to reproduce the circumstances that led to their initial success. Google initially succeeded by solving what was at the time a Really Hard Problem, and so the people at the top want to reproduce that by encouraging people to solve more Really Hard Problems. Apple has fallen into the exact same trap. Their initial success came from building a Cool New Thing, and so they are constantly trying to build the next Cool New Thing. The problem is that at some point the product has actually converged to a local design maximum and so making further changes to it in order to produce something New and Cool is not actually an improvement.
But it doesn't work because it's sn inductive fallacy. Just because solving a Really Hard Problem or making a Cool New Thing led to success once does not mean that doing these things will lead to success in general. But the memory of that initial success is really hard to get past, especially when it was as earth-shattering as the initial Google search engine, or the Mac or the iPhone.
(Apple has actually done better than most companies at reproducing their initial success. They've done it at least five times, with the Apple II, the Mac, OSX, the iPod and the iPhone. But then there is the touch bar, the butterfly keyboard, the flat look...)
I think Apple has done a fantastic job of incremental improvements on their products rather than chasing the next cool thing. Can you name a company that has actually been doing this better?
For instance, they often resist new technologies like high refresh rate or OLED screens, 5G, etc., until they feel the technology is developed sufficiently and won’t impact battery life. There are other brands that compete by making a list of features rather than a coherent product.
Of the examples you named, both the Touch Bar and the butterfly keyboard are gone now, and the latest Macs are the best Macs ever. That shows a willingness to try new things, while also showing that they have good judgement in the long term and a willingness to move away from what doesn’t work.
Also, the iPad and Apple Watch haven’t been as important to Apple as the iPhone, but they are still original and category-defining products that I would call innovative. Not every new product needs to double your company’s market cap to be a big success in the category.
I haven't worked at apple, but I suspect that this is the result of only having <20 core products (including services such as the app store). This generally implies that there are a very small number of internal employees who built those core products, and in most organizations this leads to a resistance to change.
Some companies like to spam new products, others like to perfect what they have.
I'm not sure if you're saying it's a bad thing that they have <20 core products? I've always considered that a strength and a remarkable show of discipline, especially when they're willing to kill perfectly good products in order to create imperfectly great ones.
Apple spent ~22B in R&D in 2021, but they definitely have large-scale decision makers expecting near-perfection on anything considered for released, probably before they even push it to DVT.
Resistance to change has an odd correlation with R&D spending. A company that refuses to change their products may spend more on R&D than one changing products all the time, as the cost of each change is much higher.
> Can you name a company that has actually been doing this better?
No. But that doesn't mean that Apple hasn't fallen prey to this phenomenon. It just means that they set the bar incredibly high to begin with.
My first Apple was an Apple II, and I have never been without an Apple product since then. I currently own three Apple phones and eight Apple laptops. But for me the overall usability and quality of Apple products has been in decline over the last decade or so. I still run Mavericks on many of my machines because it was the last version of MacOS that Just Worked.
The MacBook design has only changed step-by-step in small increments since the 2003 aluminum Powerbooks. The iPhone has pretty similarly used just a couple of basic designs since 2013.
So I'd definitely say Apple is best in class at incremental changes with the exception of the touchbar/butterfly MBPs. I'd just disagree with you over the quality: my M1 MBP is a big improvement over even the pre-touchbar ones in basically every way.
I'll see your M1 and raise you a trash-can Mac Pro, and the fact that anything other than a Mac Pro can't be upgraded.
But it's actually more about the software than the hardware. Once upon a time Macs were the computer that Just Worked. But recent devices, including phones, tablets, and laptops, have major usability issues. It's more about the software than the hardware, but with Apple you literally cannot separate the two.
Here are some war stories.
I bought a brand new M1 MBA. I installed XCode. The install process produced a tiny little progress bar that required a microscope to see. It got very near the end and then got stuck for several hours just short of being done. There was absolutely no indication whether the process was actually hung and no apparent way to inquire. So I tried starting XCode and it worked. I assumed that all was in order and the progress bar just hadn't gotten updated.
Then I updated the OS, which required a restart. But when I tried to restart I got a modal dialog saying that I could not shut the machine down because XCode was still in the process of being installed, and shutting down now could "damage my machine". Worse, the button to dismiss this dialog was inactive. There was no way to get rid of it. I ended up having to do a hard reset.
And this is just one of many, many similar experiences. I've tried transferring data from one iPad to another, waited many hours, only to have the process fail. I've tried importing old iPhoto libraries to Photos, waited many hours, only to have the process fail. When these failures happen there is no indication of what went wrong or what I might be able to do about it. Just, "Sorry, an unexpected error occurred".
I also really despise the new UI look and feel. Once upon a time it was easy to tell what was clickable and what was editable and what was static because all of these elements had different standardized looks. Now everything looks the same. Many UI elements are hidden until you hover over them. Apple devices have become the exact opposite of the easy-to-use discoverable devices they started out as. Using an Apple device today feels more like an old-style adventure game, complete with grues that randomly jump out and kill you for no apparent reason.
But other than that, yeah, Apple devices are great.
To be honest, the current UI look-and-feel hasn't bothered me at all. I can't recall ever being confused by it (with one exception: iPad multitasking). Perhaps I've simply internalized it to such a degree that I accept it, warts and all, without thinking about it critically. But it's difficult for me to be too upset by a UI that really has "just worked" for me.
As long as my customized keyboard shortcuts still work, I'll be happy, I guess.
I also haven't experienced the software stability issues that you point out, though I have no doubt this is because I rarely do things like transfer data from one device to another (though when I have done so it's worked well enough). YMM(and does)V.
> I'll see your M1 and raise you a trash-can Mac Pro, and the fact that anything other than a Mac Pro can't be upgraded.
The trash can Mac Pro was a mistake, though at least it's one they eventually remedied. Their recent lineup has been almost universally praised, except for cost and (as you point out) upgradeability. I'm not too bent out of shape about upgradeability because I've never tried to upgrade a laptop, but I see the annoyance.
I think this is a topic about which people can reasonably disagree :-)
I'll just add that my complaint about inability to upgrade does not just apply to laptops. It's the whole product line (other than the Pro) including the Mini and the iMac. If I have an iMac and I need more RAM, I have to throw out a perfectly good SSD, processor, and display. There is just no excuse for that. I have a NUC that is essentially a hardware equivalent of a (pre-M1) Mini. The NUC is both smaller than a Mini and upgradable so I know it's possible.
You are correct to say there is no excuse for the lack of upgradability, but not for the reasons you believe.
There is no excuse because “excuses” are not germane to making trade offs. Apple chose to not make devices easily upgradable because it enabled them to be amazing in other dimensions (sturdiness, manufacturing efficiency, design, aesthetics, plus most users don’t give a flying fuck about upgrading)
Why would you need an excuse for defining your own products your way?
But this is exactly my point. Apple is optimizing the wrong things (for me) because it's trying to build Cool New Things rather than things that are actually useful. My NUC looks perfectly fine, and it sits under my desk so no one ever sees it anyway. It is superior to a Mac Mini in every conceivable way. It's smaller and it costs less for the same tech specs. The only thing that a NUC doesn't do that a Mini does is run MacOS legally.
> It is superior to a Mac Mini in every conceivable way
Based on the dimensions you feel are important and are visible to you. That is only one perspective on the elephant.
If you built that machine, and you made decisions that were not necessary tradeoffs AND these decisions went against your values, you would need an excuse. Apple is not you, and they do not need any excuses - they have a different set of values and built to those values.
Those values are what the market, aka other people, care about.
But you don’t have to throw those things away. Just sell it, for a decent percent of what you bought it for - because they have good resale value - and buy one with more RAM.
Then I have to transfer all my data. That's time consuming even when it goes well, and not once has that process ever gone flawlessly for me. Something always gets lost. Passwords. License keys. Settings. It has been a colossal PITA every single time.
> I can't recall ever being confused by it (with one exception: iPad multitasking).
Oh god, don’t get me started. Not a single thing in any field of technology puts me straight into confused-grandma-mode as quickly and thoroughly as accidentally going into multitasking mode on the iPad. Oh god how do I close the floating safari window I accidentally opened? Why does swiping it off the screen do nothing? Oh god now there’s a weird paddle thing on the right side, and now it’s… gone? Is that window just there running forever now? Or I drag it to the left and now… oh god now it’s in split view. How do I go back? I move the vertical bar all the way to the side and now I have two safari windows, but I can only see them for a brief period when I cmd-tab… somebody please help me oh god.
Granted, it’s a little better each release, and used to be so much worse, but it’s still ungodly awful and impossible for me to figure out. I wish I could just disable it outright.
Apart from the look and feel, there are severe regressions with the operating system in a lot of places – external non-Apple hardware that would just work just fine on the existing OS stops working with a new OS version, etc. The quality of their OS has gone steadily downhill over the last few years.
At this point I would never do a macOS update unless I'm forced to do so for security purposes. I can't even begin to fathom why anyone installs the beta and does free QA for Apple.
I get the impression everyone at Cupertino works with only Apple Cinema displays and a lifetime supply of insanely priced Apple hardware; and no one bothers to test out compatibility with third-party devices at all.
I find it valuable on occasion; I certainly understand why they were reluctant to give it up, but they should have either pushed harder for its success or given up sooner.
I can't really think of anyone who has done it well but I don't think Apple has either. They have released plenty of half baked products. The original apple watch is a good example, it was retroactively made the Gen0 and quickly killed. They had similar problem with the first Intel macs too and the original M1s weren't 100% either. I think sometimes they over estimate how ready a product is. The iPhone was amazing at launch but in retrospect it was missing almost everything.
I wasn’t saying that every product they release is perfect right out the gate. If your bar is perfection, then prepare to be disappointed.
But Apple will stick with a product and keep on improving it generation after generation until it is excellent. It’s rare to see them go all into something then give up to chase the next shiny project like Google does.
That makes sense. Googlers keep dumping out technically interesting products with no go-to-market strategy because one time doing that, they made a perpetual money machine (search ads). The problem is it’s 20 years later, technology has changed and not all markets are like search.
Throwing something out there is fine when it’s a magic website that answers your questions. When it’s, say, a half-baked messaging app none of your friends use, not so much.
I think Apple continues to innovate in new product categories.
Apple Watch
AirPods
M1 Chip
Services (Apple TV+, Apple Pay, Music, Fitness, iCloud etc).
I include iCloud for services likeHide My Email and Private Relay.
They do this all while maintaining a consistent release cycle of upgraded versions of their hardware (new iphones, macs etc).
Also, everything in the list above has been developed under Tim Cook which is also impressive. He's been able to maintain Apple's ability to expand into new products and services.
You realize that's his point right? Each of those is trying to be the Cool New Thing, and part of what distracts the company while it ships butterfly keyboards, touchbars without escape keys, AntennaGate, whatever plagued HomePod so much they quietly discontinued it. Polish and Attention To Detail is outsourced to execs, who are increasingly spread thin.
AirPods in their first year shipped more bluetooth headsets than the all bluetooth headsets from all other manufacturers combined ever (or something insane like that). AirPods by itself is a Fortune 500 company. Apple Watch is a Fortune 100. AirTags is a 1B revenue business.
Their scale is so immense that "flops" means "not a breakout success that resulted in a massive instantaneous increase to their bottom line". It also means the pressure is on them to have everything right (from the HW side) from the initial launch in terms of volume, build quality, reliability, & value add or they will have a meaningful setback to an expensive proposition (no room for exploring with smaller-scale things which is where competitors should start - Oura for example).
But it hasn't distracted the company. Each of those things I listed are massive successes in their own right.
Not everything Apple does is a success, but they have gotten it more right far more often than wrong. The M1 chip affects also their entire existing computer line. AirPods work beautifully across iphones, macs, and ipads. Apple watch integrates flawlessly with my iphone (answer calls, play pause etc). These are accessory products that reinforce the main ones which they continue to upgrade beautifully every year.
They are able to balance both (Cool New Thing and upgrade cycles) and through it all, keep their product list to a relatively small number of items/skus. Compared to google who offers so many additional services and applications.
Cool New Thing was not distracting from these things.
> Polish and Attention To Detail
gets harped on at Apple because they are so much better than everything else (and charge $$$ for it), that customers and opponents don't tolerate mistakes. Maybe being perfect is actually, really too hard to reach?
... the Lisa, the Apple III, firewire, calling wifi "Airport" for way too long, that home speaker boombox thing, the weird round mouse that came with the iMac, ...
But seriously, I remember reading on here a comment from a previous Apple employee that all of their products are designed with the primary goal of looking good in a keynote presentation, which makes sense for their image, but results in underdeveloped products that "disappear" after a few years.
What’s more import for Senior leaders to do - solve hard problems or useful ones? If it’s the former they’re doing the right thing. If it’s the latter that explains a lot of their deprecation issues.
So what happens when you promote someone for maintaining the same system for years? When do you stop promoting them? There's a person on my team who is happy to maintain what he works on. He has worked on fundamentally the same project for over a decade. He's a senior level engineer, and as far as I know doesn't have aspirations beyond that, which is perfectly fine. Assuming he keeps doing that work, and no more, does he get promoted again? Once? Twice? Does he become a principal engineer, for adequately maintaining his corner of the world?
The person who is really good and really effective at fixing user issues, first of all can't scale past a certain point, but second of all, likely doesn't have the the experience to design and shepherd the data storage system that also manages permissions across nested groups efficiently (one of these is what we'd expect of a solid L4, the other is https://research.google/pubs/pub48190/).
You're asking for title inflation. Is that really what you want? What you really want is a different role, "maintenance eng" who can get paid more for doing the same work they were doing yesterday, and who needs to reinterview for SWE roles, because its very quickly obvious that a principal maintenance eng and a principal eng do very different things!
If a person is locked up in one feature/one product and unwilling to learn new things for the years then I do not think that person should be promoted. You can certainly give merit increases to keep up with inflation but that's about that. Ultimately, we all responding to market value of a person. That value remains unchanged for someone not learning anything new for years after the earned experience saturates. In many professions like doctors or pilots, experience never saturates and continues to increase person's market value however in other like cashier or barista that's not the case. So this opinion is job-dependent.
But the person might have the knowledge to build on whatever the system is, without having the mandate to do so. He'd still be the best person to modify the system, but for whatever reason the business doesn't need the edits. Should you keep him happy just in case or let him find another job and take the option to upgrade with him?
Maybe instead of promoting, which is a stand in for $ and peer respect, you give those things, and/or provide a track which values being a domain expert+maintenance e.g. professor emeritus.
Building half working shiny things is bad for the company, and erodes user trust.
At some companies, this is broadly what "SRE" vs "SWE" is meant to capture. But the issue is that roles aren't very fluid, plenty of times SWE ends up transitioning to a role more resembling an SRE after building a system and reorienting towards maintaining it.
God I hope not, SRE isn't a maintenance engineering role!
Improving the reliability of a system (SRE's ultimate responsibility) is deeply technically challenging work of its own, and one can encounter deeply challenging problems.
The problem is that people think "maintenance" is a bad word. A company like Google is seeing growth from external customers, churn from their internal systems as internal best practices change, and changing threat landscapes on the internet.
"Maintenance" often is actual hard feature work. But when your org or company has a culture of thinking of maintenance as some low-level job, you get a culture like Google's.
I don't disagree. I don't think maintenance is a bad word. But I do think that there is a point beyond which "maintenance" cannot grow. If you're maintaining a system there is a breadth of experience you cannot get. Being a senior engineer at Google is not easy. But my point is that sre is still fully capable of supporting L7 and L8 ic swes, while "maintenance" isn't.
You wouldn't promote them. But if they picked up a new system and started maintaining that one too, then they could get a promotion for expanding their scope and for getting more efficient at maintaining the old system.
Or, if they are both adding new features and maintaining them, then that could merit a promotion too. They are still doing innovative work, and they are maintaining it and fixing it.
You're asking for 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.
Yes, it is in fact the case that getting new stuff done is the only way to benefit the company. But new stuff != feature bloat. There's lots of new stuff that can be totally invisible to end users, and is deeply valuable.
Treading water should not get you promoted. That doesn't make sense.
>it is in fact the case that getting new stuff done is the only way to benefit the company
I spent a few weeks just refactoring 6k lines of code into +- 300 lines on my current job.
If my company was run by you, the best course for me woould have been leaving that mess around. Which would have led to either the same refactoring under far more stressful time constraints, or even more shit code by applying a band-aid into the old code (this code makes us some serious money, and an unexpected third party change would have broken it in such a way that would be seriously hard to fix with the old code).
Also, there are loads of features that were far easier to implement after the refactoring.
Maintenance job isn't coasting around. It has a multiplicative effect on anyone who works in the system. It needs to be done, if you want the org to not slow down to a snail pace - and when someone leaves a mess, it isn't even neccessarily easier than pumping new features since you have to figure out all observable behaviours from messy stuff.
If there's no incentive to getting your hands dirty, no one will want to get their hands dirty. People will fight to not do neccessary jobs if the only way of advancing their career is avoiding those jobs.
> Also, there are loads of features that were far easier to implement after the refactoring.
Congratulations, you have demonstrated the value and made it easier to do something. As someone who has gotten promoted 2 times (and soon to be 3) primarily off of tech debt reduction and infrastructural improvements that don't themselves do anything, but drive future productivity, of course I think this is valuable. This kind of thing is literally the only work I do.
Now yes, there's a point beyond which only doing that work won't get you promoted, but that point is L5 where you're making 350K/year, and you can continue to do some of that work and get promoted further, you just likely have to
1. Get other people to also do that work
2. Do other work that acts at a larger scale
If you're actively adding new features to a service, you aren't doing maintenance. You're launching new things, and people get promoted by launching new things all the time. And people get promoted for making it easier to launch to features all the time.
No, they're perfectly compatible, you're just choosing to take an extreme interpretation of the first.
Like there is always groundwork that has to be done as part of the new thing, and doing that work is part of getting new stuff done. If getting new stuff done is the end goal, "getting new stuff done 5% faster" will obviously get new stuff done (and benefit the company).
> So what happens when you promote someone for maintaining the same system for years? When do you stop promoting them? There's a person on my team who is happy to maintain what he works on. He has worked on fundamentally the same project for over a decade. He's a senior level engineer, and as far as I know doesn't have aspirations beyond that, which is perfectly fine. Assuming he keeps doing that work, and no more, does he get promoted again?
I know a few of these people who have been on the same product at Google for a decade and they generally cap out at L6, which is staff engineer.
L7 engineers are typically careerist and have larger a scope, focusing on higher level cross team collaborations. Some L6s are like this but there are plenty of them that are just chilling
> the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.
This is the real problem, but people typically underestimate difficulty of correctly identifying "useful" problems at scale. Fixing a bug is nice, but correctly prioritizing bugs worth fixing is harder than said because most cases relevant engineers have limited contexts on UX and PM also has limited contexts on its difficulty. I don't deny that big techs have a bias toward solving "interesting" problems, but in many cases seemingly simple bugs are not that really easy to solve while not making any dent on business.
> but in many cases seemingly simple bugs are not that really easy to solve while not making any dent on business
I work at a big tech company and see this all the time. Bugs that clearly exist and are impacting users, but they're hard to solve and have no or very little business impact. It doesn't really make sense to work on them, but it's kind of sad they just get left :/.
I think Google has this worse than most because it has a relatively selective hiring process, large headcount, and is a mature company. The ratio of talent per scope is high, which mean there are less real problems left to solve per engineer.
> Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.
Playing the devil's advocate here, but shouldn't one position in the technical career ladder be correlated with technical expertise? Furthermore, technical ability is something that the employee has some control over: whereas impact to the business has more external factors.
The incentive problem to align people with the needs of the users is difficult. I imagine the best way to handle that would be through bonuses/profit sharing for high impact work, whereas promotions focus on difficulty of work.
Going off the description of "bugs being too easy" vs "building new things" - is "shipping a product without bugs" a worthwhile technical ability to cultivate?
I would argue that attention to detail and polish are important technical abilities, and that focusing your technical advancement path solely on less tangible-to-the-user abilities will cause you, as a company, to make less compelling products.
If you are a developer who just implements what the PMs tell you to (more or less) then I agree that you shouldn't get extra credit when the project is a massive success. If the product earns a billion or loses millions you didn't have anything to do with that - you just implemented the designs of other people.
If you significantly contribute to the design of a successful project - that's different. But then, you should be making the case that you solved the hard problem of improving the design, not just that you were a good developer on a successful project.
> If you are a developer who just implements what the PMs tell you to (more or less) then I agree that you shouldn't get extra credit when the project is a massive success. If the product earns a billion or loses millions you didn't have anything to do with that - you just implemented the designs of other people.
Actually I think you should be rewarded, just with money rather than a title.
No need to penalize if the project fails. It's an incentive to encourage people to work on high impact projects. Especially important where people have some freedom over which teams they are on. Doing menial work that provides clear value to the company should be recognized and rewarded.
If you aren't responsible for the project's failure, you're not responsible for the project's success, and rewarding, or punishing, someone for what they aren't responsible for is irrational.
> shouldn't one position in the technical career ladder be correlated with technical expertise? Furthermore, technical ability is something that the employee has some control over: whereas impact to the business has more external factors.
Partially. Your position should be your technical expertise in things important to the company. There are a lot of technical skills you can learn that are not useful and so the time to learn them would be wasted at that company.
> Partially. Your position should be your technical expertise in things important to the company. There are a lot of technical skills you can learn that are not useful and so the time to learn them would be wasted at that company.
I think that's a fair point, but I'm not sure it changes things a lot for companies like Google.
The more a company relies on technical innovation to provide business value, the harder it is to predict what sort of things actually align with business value.
To put it simply - we don't know what hard problems need to be solved. Having a place where really smart people have the autonomy to work on whatever they want is the best way to find out. This is the classic argument for funding basic research in the sciences.
> To put it simply - we don't know what hard problems need to be solved. Having a place where really smart people have the autonomy to work on whatever they want is the best way to find out. This is the classic argument for funding basic research in the sciences.
This really isn't the classic argument for funding basic research.
All you're saying is that it's hard to know what will prove to be a useful tool, and that's really beside the point for figuring out what should be rewarded. Absolutely having a commanding understanding of a broad set of technical tools should be a career asset, but it should be a means to an end, not an end unto itself.
You don't need to know what hard problems need to be solved to address the original criticism here. You need to understand what problems the organization is currently focused on, and solve those problems with simplicity and efficiency, even if that doesn't allow someone to show off that they can solve the harder technical problems than anyone else. The reward systems in the company should reflect that, and if it does, I would expect that people who could solve the harder technical problems would be more likely to be rewarded than others, but their skills would be much more likely to be directed towards simplifying and improving the efficiency of the company's execution rather than having a bias towards the reverse.
Now, another important skill at more senior levels is being able to identify new problems deserve focus (i.e. figuring out what problems are useful to solve), so that should also be reflected in the company's reward systems as well, but that is still an orthogonal skill to "demonstrates they can solve the hardest problems".
Think of it like product managers: if you primarily reward your product managers for launching new features, pretty soon your company will be weighed down in operational overhead from trying to support a cornucopia of features, many of which aren't particularly well done, rather than having a streamlined operation that delivered products that excelled at delivering on the solution they most wanted.
Unfortunately, Google is a very much technology focused and not business focused. That’s why after 20+ years almost all of its revenue still comes from advertising. All of the other major tech companies have multiple billion dollar profitable revenue streams.
It even came out during the Oracle trial that Google only made about $26 billion in profit from the inception of Android to 2016. Apple makes more from Google in mobile by being paid for it to be the default search engine ($12-$18 billion a year) than Google makes from Android.
> Unfortunately, Google is a very much technology focused and not business focused. That’s why after 20+ years almost all of its revenue still comes from advertising. All of the other major tech companies have multiple billion dollar profitable revenue streams.
Is that true of other ad-tech driven companies as well? Companies like Meta and Twitter.
Companies like Amazon, Apple, and Microsoft are used to charging users directly for some good or service. It may be that they are just better positioned to establish those other revenue streams.
> In Louisville, Google Fiber reportedly was burying cables in "nano-trenches" that were just two inches deep.
> "When you're walking around the neighborhood, [the lines are] popping up out of the road all over the place," resident Larry Coomes said at the time. "People are tripping over it."
This is the most obviously Google thing I've read ever. Half-ass a job and then saying "screw it" and leaving because it's too difficult? Name another company that would do this. Not even Spectrum is this incompetent. They have the attention span of a stoned teenager. Their Toronto Sidewalk Labs also comes to mind. Probably for the best they pulled the plug early on that one. Imagine parts of your city just stop functioning because some private company got bored one day and left.
That turns the incentive away from creating shareholder value and towards hazing and navel gazing.
There's also the issue of conflating the incentive/reward schemes with the need for roles to be performed. Being good at inverting binary trees won't make you a good manager but when the manager role carries money and prestige then it's the hammer you use to reward the shape rotators.
> That turns the incentive away from creating shareholder value and towards hazing and navel gazing.
It's navel gazing until it turns into the next big money maker.
> Being good at inverting binary trees won't make you a good manager but when the manager role carries money and prestige then it's the hammer you use to reward the shape rotators.
Nitpick, but I was focusing on the non-manager track.
Tech Management wants to -not- promote people, so they try to make promotion difficult which inadvertently creates promotion driven culture.
For instance, if they promoted people for working hard, then everyone would work hard and we (high level management at tech companies) cant just promote everyone. so they make it arbitrarily hard, such as at Google "only promote people who solve hard problems". I think most tech companies will have some flavor of that, like at Amazon "work on projects that have cross team company impact".
Its all about trying to -not- promote people fokes, which ironically creates this promotion driven culture. After all, we are mostly college grads, and a lot of us are from the top schools (not even the majority, just a lot).
> Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.
It's partly that, but Google's counter has always been this refrain of "we are a data-driven company". I guess that is better than completely subjective metrics, in some respects, but it introduces another bias, which is focusing on things that can be measured.
I saw a lot of successful promo cases that were based on pushing metrics. That just rewards quantifiable things, and disadvantages unquantifiable things. Worse, it makes people introduce bullshit measures and game them. It's pretty much impossible to measure long term impact, but nevertheless, impact[1] was one of the main three drivers.
[1] Leadership, difficulty, impact are the three main components of a succesful packet, especially at L6 and above.
It's partly that, but Google's counter has always been this refrain of "we are a data-driven company". I guess that is better than completely subjective metrics, in some respects, but it introduces another bias, which is focusing on things that can be measured.
Being "data focused" is probably a Good Thing in a very general sense, but there are real dangers that come with that. For example, there's a form of "data myopia" you can develop, which is best expressed by the old saw "data and optimization can help you get better at doing $SOMETHING, but don't tell you if you're doing the right $SOMETHING in the first place."
I saw a lot of successful promo cases that were based on pushing metrics. That just rewards quantifiable things, and disadvantages unquantifiable things. Worse, it makes people introduce bullshit measures and game them.
And of course there's Goodhart's Law[1] which leads to situations where trying to be "data driven" actually makes things worse when people start trying to "game" the metrics.
>> But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving USEFUL problems.
Not saying this is the best thing, but it can get much, much worse at other places. I started my career at Accenture (then, Andersen Consulting). People go promoted for either sales (SrManagers or higher) or controlling issues (Managers and below.) Note, the aim was to control issues (documenting, writing up mitigation plans, briefing clients, deploying fixes, etc.) -- THE AIM WAS NOT TO PREVENT ISSUES. So code quality didnt get you promoted.
Several years in, a group of individuals passed up for promotion realized this all-together and literally started turning a blind eye to minor bugs, which eventually passed into PROD. Then they would solve them (which is what Management wanted.) Shockingly they got kudos for controlling issues. Many got promoted.
Set the wrong incentives, get the wrong behaviors.
> Set the wrong incentives, get the wrong behaviors.
I don't mean this as a slight at your comment - rather at the shockingness of the reality that your comment (really) needed to be said - but isn't this blatantly implied by the meaning of the word 'incentive'?? I'm astonished that people keep not realising this. The whole culture of OKRs/KPIs at startups feels like it's tempting this problem - I don't see why any but a very small number of companies should need to optimise metrics which are non-obvious. Having an OKR/KPI which one needs to deliberately decide on feels like a very pungent 'bad smell' of an XY problem.
My take on these BigCos is that there is so much middle management and hierarchy that the frontline workers are
blocked from the actual performance of the company.
My proposed fix is entire product groups and their members should be held accountable and directly take profit of what they earn. If the product does well that quarter, engineers should be rewarded. Something to keep them working on a great product rather than catastrophically forgetting.
That works in sales, where one salesperson runs the whole engagement and can clearly claim responsibility for the revenue and thus be directly compensated with a proportion of it.
But in engineering you need people to be thinking big picture, thinking collaboratively, taking risks, doing long term development, cleaning up technical debt. If you overly tie compensation to product revenue, you risk incentivizing your entire engineering staff toward short-term bolt-on-the-feature thinking.
So, if you have a company that depends on uptime, then pay the people doing the maintenance programming / sysadmin twice as much as the normal developers since they don't get to play with the new thing, they are much more likely to have to deal with things at odd hours, and need to be promoted based on keeping the business running.
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.
The first thing that comes to mind reading this is that 'corporate ladder' is the wrong visual concept. Corporate hierarchies are trees with root at the top. The problem is then comparable to the academic world, where each PI will have a series of PhD students who themselves want to become PIs, but the PI replacement rate is too low to accomodate this. Unless the global academic world is expanding, inevitably the majority of PhDs will not become PIs.
One general solution is to flatten the hierarchy, which ultimately would reduce the spread in compensation and rewards from the bottom layer to the top layer. This would make promotion somewhat less attractive particularly if it came with heavier administrative responsibilities (generally less fun and more hassle).
serious question here - how does Apple deal with this problem ?
Apple also survives on big bang releases - the next iphone, macbook pro, etc etc. But also is famous for not abandoning old phones. iphone 6 was still receiving updates in Dec 2021.
so how does Apple manage this dichotomy ? or is the company level yearly release completely wipe out the need for individual "hard problem" solving ?
Traditionally they made it ungameable by making it completely opaque to the point where you have no input on promotions and they may not even tell you there is something called promotions.
Toxic masculinity accurately represents what the OP describes and is clear here. There's nothing to be offended about. It's revealing the angst that sprang up from this community of mostly men.
Classic Bulverism on display. Don't defend your position, just assume you're right and offer an armchair pyscho-analysis for why people who disagree with you are wrong.
Here's some more Bulverism: What's there to defend? Colloquially toxic masculinity means exactly what the OP was going for. It's to jockey for power, position, and status at the expense of others (and often detrimental to their own goals). Hey! Women sometimes also display these toxic masculine traits commonly found in male primates! You should be more inclusive and call it toxic humanity! has to be one of the least useful things you can bring to the overall discussion.
I suspect, though I cannot prove, than than many of those comments are made at least somewhat ironically.
We've been perpetually informed than men and women are the same from the neck up for decades, and a Google employee (James Damore) was even fired for pointing out that men and women differ in their preferences, attitudes, and social behaviors.
That it is now OK to acknowledge those differences when it makes men look bad is quite the standard to set.
I mean, which is it? Are men and women the same or are they different (on average)?
Also, that is not what toxic masculinity means. If you have an all-woman organization that has a culture dominated by counter-productive competition, you don't call that "toxic masculinity". That just wouldn't make sense.
At best, the competition is a symptom of the real (alleged) problem of toxic masculinity: too many men. Specifically an environment where men are systematically favored over women for sexist reasons.
That Google is suffering under such a system is a claim which needs defending.
The sexist part is not the "hard problems" but the competitiveness. I don't think sexism is intrinsic to solving hard problems - certainly gender-inclusive companies work on hard problems successfully. But in my experience those companies tend to be more collaborative.
Google needs to celebrate heroes. Like Jeff Dean. Or Sanjay Ghemawat. Those are Great Men. They are "Living Gods" because they solved Really Hard Problems. Getting into that class of people requires being a "lead" which necessarily means other people around you aren't leading. So you need to prove why you're worthy of being the "lead" which means proving the others around you aren't. This is toxic masculinity. Not solving hard problems.
It seems that you missed their point: the toxicity is non-gendered. (I say you missed their point but they also kinda did a poor job of making it, FWIW.) There might be a point that Google's culture in practice is male-dominant but I think it's mistaken thinking that puts the toxicity on the male-dominance.
Consider your words as if they were being said about a woman:
> Proving you're smart by solving hard problems is a gorilla-chest-thumping exercise.
Proving that you can lead does not neccesarily mean that you must prove others cannot lead. This is the fundamental problem in your thinking when you make such generic and universal claims. If people are doing this (and I do believe it happens a lot), then it is certainly very toxic culture but calling it "toxic masculinity" is forcing the issues into your own sexist ideologies. Also, competitiveness is not by default "masculine". You are doing massive disservice to many brilliant competative and successful women by making such blanket claims. When resources are finite, competition are natural regardless of sex. For example, we all need to demonstrate good grades out of school to get in to programs with very limited seats. Being able to compete is neither exclusive or inherent male characteristic.
Whether or not it's "toxic masculinity", the internal lingo around performance reviews at Google is lulzy.
It's called "perfing" (as in, if you do something bad, you might get "perfed hard" next cycle) and managers frequently threaten to take people "into the Perf Room" although it's just an expression (there isn't actually a dedicated "Perf Room"). Anyone who gets below 3.0 (Meets Expectation) during the calibration process is called a "PB" It used to be "pillow biter" but you can't make that joke anymore so it's just "PB", as in "How many PBs does Exec want us to have this cycle?"
It's offensive and backward, but it's also hilarious that grown men (and women, if they ever get let in to executive circles) are using language that sounds like it was invented by teenagers.
> It's called "perfing" (as in, if you do something bad, you might get "perfed hard" next cycle) and managers frequently threaten to take people "into the Perf Room" although it's just an expression (there isn't actually a dedicated "Perf Room"). Anyone who gets below 3.0 (Meets Expectation) during the calibration process is called a "PB" It used to be "pillow biter" but you can't make that joke anymore so it's just "PB", as in "How many PBs does Exec want us to have this cycle?"
1. You must be in an incredibly toxic enclave if managers in your org are routinely threatening people that way. It's certainly possible, it's a big company, there's been a number of shitty directors/execs that have made the news. But given points #2 and #3, I have reservations about believing generalizations about this particular claim.
2. ME is not a '3.0' (Unless you're measuring on a 12-point scale, that starts at 0.) There are three ratings above, and only one rating below ME - Needs Improvement. Which is a pretty serious wake-up call for the person and their manager.
3. Very few people get NI, you seem to be confusing Google with either old Microsoft, or Amazon, whose bell curves, as I understand, require(d) ~1/5th of the company to be on the shit list at any particular point in time.
Women demand men that are better than their peers while men only demand women who are good on their own. The evolutionary pressure produces men who are competitive in this toxic way.
This is pure evopsych fantasy land. Women do not, as a rule, demand men "better than their peers". We would see more little old ladies out there who held out for above average, never got it, and chose instead to remain single.
>We would see more little old ladies out there who held out for above average
How in the world can you come to this conclusion when society hasn't been in the situation where old ladies as a whole were in a position to be close to equal financially compared to their male peers in at least the last century? If anything, you have to wait a few more decades to come to this conclusion at minimum.
The original contention was that women held out for higher-status men, leading to selection pressure such that men evolved to be more competitive. If women are only very recently even able to be more selective, then I don’t see how all this is supposed to work.
Is there even any evidence that modern women are more “choosy” than men? You’d have an hypothesis like: among married 40-something women, the distribution of socioeconomic status matches that of women overall, whereas married 40-something men have higher SES than would be expected. Should be easy enough to test with publicly available data.
>If women are only very recently even able to be more selective, then I don’t see how all this is supposed to work.
That's not what the above implied. You can still fulfill the condition "be more selective" if the male populace as a whole was earning way more than the female populace before, which it very clearly was. This directly questions the notion of there being a bunch of old ladies who'd have held out: the majority would've found their "better off financially" peer. Things only caught up in the last few decades or so. All those younger generation women still need to age into old ladies in the first place.
>Is there even any evidence that modern women are more “choosy” than men?
Financially? Yes. While I don't fully subscribe to the idea of "equal or better than", you only have to look for a few minutes to see the hoards of anecdotes and studies pointing towards women putting vastly higher weight on a man's finances than the other way around, to the point men can use their money to compensate for deficiencies elsewhere[0]. That alone would explain why women haven't been nearly as competitive in the workplace as men: men have a far bigger incentive to do so on top of all the other incentives both experience.
> You can still fulfill the condition "be more selective" if the male populace as a whole was earning way more than the female populace before, which it very clearly was. This directly questions the notion of there being a bunch of old ladies who'd have held out: the majority would've found their "better off financially" peer.
But the original idea was that women prefer men better than their peers -- that's a direct quote from that top-level comment. You seem to be saying something distinct from that, that women prefer men who are better off financially than they are. These are very different claims.
Further, if you're right that women tended to satisfy their desire for higher-status men simply due to the fact that men used to have more money on average than women did, then where is the selection pressure supposed to come from? There's no pressure -- it wasn't hard for a woman, who had few career prospects, to find a man with a job who could bring home consistent pay.
> you only have to look for a few minutes to see the hoards of anecdotes and studies pointing towards women putting vastly higher weight on a man's finances than the other way around
Take your pick between "I don't really care about anecdotes" and "I have my own anecdotes that tell me that women don't place significantly more weight on socioeconomic status than men do". I'm curious about the studies, but I'd have to find a copy of the article you cite before I'd place too much stock in it. What I'd like to see is some proof in the data that conditioning on socioeconomic status does not significantly alter marriage rates for women but does do so for men.
The whole usage of the phrase "Toxic masculinity" to describe "Competitiveness" is some throughly pointless gendering which only serves to confuse matters.
I agree that competitiveness is masculine[1], but it's not obvious to me that this is a case where it is toxic.
It may be a more competitive or masculine environment than you would prefer, and that's fine. But what benefit do you think comes from labeling the perceived problems of Google's culture as "toxic masculinity"?
[1]Yes women are also competitive, but most of the extremely competitive people are men.
Solving hard problems isn't an inherently masculine thing, but basing a work culture's progression around being able to prove employees solved hard problems is a pretty good example of toxic masculinity. And the phrase "toxic masculinity" does not mean that all masculinity has problems, it's a separate (and pretty well-documented) concept.
Okay, Googler, how about some data to back up that assertion? Let's have a googley-argument where we're respectful in showing that we're smarter than the person we're putting down.
Here's my data. Google values consensus - fact. This "wisdom of the crowds" philosophy was core to founding google - Larry & Sergey's brilliant insight that the collective votes of hyperlinks was a stronger signal than things like H1 tags and HTML titles in picking good search results.
But consensus means, in a literal sense, that everybody needs to agree on the right thing to do. Problem is in reality people don't always agree. So what happens when the group needs to reach consensus but people disagree? Since Google doesn't have a respectful way to disagree, the holders of divergent opinions must be minimized - either pushed out of the group or proven to be not smart enough for their opinions to be valid.
God I hate myself while I'm writing this. I left for a reason.
> But consensus means, in a literal sense, that everybody needs to agree on the right thing to do.
I want to push back on this. I think there is absolutely such a thing as “rough consensus” where everyone gets to air their concerns, but the group still makes a decision where not everyone gets their way. Rough consensus processes are much harder to do over a mailing list because there’s no sense of what “the room” wants - since all the air gets taken up by the people who have the most time & are the most argumentative. It’s much easier to achieve rough consensus in person - especially amongst groups who have good working relationships with each other.
In many ways this is a product failure of mailing lists and the like. I’d love more answers in this space to allow us to make better collective decisions, remotely.
That's a little over simplified the complexity of making a decision. A decision rarely reach a fully supported level of consensus in any cases. The process is more focused on reaching an accepted level for everyone, which usually means "I don't like it but that's FINE so I won't block it". The consensus of decision is grey instead of black or white.
Also, "the holders of divergent opinions must be minimized", not really. You can even continue without a consensus as far as it doesn't hurt anyone else.
"wisdom of the crowds" means respect everyone's opinion IMO. Direct attack to your colleagues will end up with warning from managers or being fired. It doesn't have any meaning of enforcing maximium level of consensus.
The problem of "try my best to prove I'm not WRONG" is much broader than Google's company culture. It's part of our self defense process and has been well identified in psychology (Well, same emotion as what you feel in this thread when someone opposed your opinon, your are trying to prove you have better understanding of the problem or smarter than them as you described yourself). Google's culture is trying to (maybe not that successful) minimize that type of self defense since it's harmful in many cases.
I don't really blame them, and I think any group would feel the same to hear one of their personal attributes referred to as intrinsically 'toxic'. If we simply described the personality traits that we meant, we might actually get somewhere (but, from everything I've seen, getting somewhere is not the objective).
If it was about masculinity itself being irredeemable, the adjective wouldn't be there. Surely a website of programming enthusiasts can figure out parsing?
But there is a masculine (in the sense of gender roles that a person assumes for themselves) way to do it, and that is what is typically expressed in these settings. And it is typically more harmful for more people on average than the feminine expressions of same.
Tell me, what do you consider "toxic masculinity"? You're not really presenting a frame for us to discuss this in.
>And it is typically more harmful for more people on average than the feminine expressions of same.
Yeah, no. This is borderline sexist. It's one thing to argue "the workplace only allows masculinity in its toxic form". It's another entirely to go "feminine better".
I'm saying "masculine worse", yes, because it is. Any assertion to the contrary is deliberately ignoring the decades of research into aggressive tendencies and the (inverse) correlation to wellbeing globally. Anybody who speaks on this, having not informed themselves of the research, is acting in bad faith. By this point in global human connectivity, you really have to be trying in order to stay in a tiny little filter bubble that doesn't acknowledge this.
Nobody appreciates people who speak without knowing about what they speak!
Not to mention that any argument whose central point starts with "I would prefer..." cannot be taken seriously. Your opinions have no bearing on material realities, or, put another way, facts don't care about your feelings.
>typically more harmful for more people on average than the feminine expressions of same
The equivalent feminine expression of the same kind of dominance is a reputation war.
Reputation wars can destroy lives and relationships. If I have to choose one, I for one much prefer to deal with people winning at how awesome they are (and how lame I am) than a reputation war.
Civilized places have cracked down on violence, so male dominance contests almost never end up with a face punched anymore. Toning down the violence made them much safer.
Female dominance contests are still as deadly as they have always been.
On the other hand, having spent many years at IBM, the Loudest Person In The Room is rarely a woman. And, having been part of a fair number of woman-led organizations, including those that were straight up empire building, hyper-competitiveness tends not to be a problem; they have other pathologies.
Even every non physical competitive sport in the world is male dominated to an absurd degree. Chess, esports, poker, you name it. Hyper competitive environments are associated with masculinity for valid reasons.
Not google, but I was once given feedback that I wasn't promoted to a management position at a company because I was seen as being too "nice". This was despite 4 years of being a manager at past companies and being perfectly able to solve problems w/o pounding on the table and twisting arms. I left that company soon after. But I see that as an symptom of toxic competitiveness culture too.
I understand doing it accidentally or as a side-effect of hard-to-fix dysfunction, but it boggles my mind that they were fully explicit and self-aware and intentional about creating a process where you couldn't succeed without being an asshole. What a terrible place!
To give a maximally charitable interpretation, "nice" could be a euphemism for "doormat/not assertive/not raising objections when one should". Though "being perfectly able to solve problems w/o pounding on the table and twisting arms" is evidence against this. (Though conceivably those giving feedback hadn't noticed that evidence; I have no knowledge here.) Also, it would be ironic if they were "nice" enough to use a euphemism that obscured their point completely.
Since when solving "hard problems" became toxic masculinity? Are you saying Marie Curie and Ada Lovelace suffered from toxic masculinity?
PS: I am not endorsing promo-culture where impact of users/revenue don't matter but I do believe solving hard problems should be rewarded (for example, Nobel Prize or Field Model) and making it "sexist" issue is unproductive .
Seeing your comment, I'm reminded of the Far Side comic where the dog only understands her name in the owner's speech: "blah blah blah Ginger blah blah".
"Proving you're smart by solving hard problems is a gorilla-chest-thumping exercise. It's not enough to build things. You need to be better than those around you. But you have to be "googley" which means using logic and data to put down your coworkers and show why you're right and they're wrong."
Ex-Googler here. The comment above is wrong and sexist.
Googleyness was always about bringing up the people around you and elevating your team’s potential, something that both women and men can excel at.
I have a lot of complaints about Google’s perf process, but I never saw toxic masculinity, competitiveness or putting down co-workers. On the teams I was part of, if any of that happened it would have been dealt with harshly and stopped immediately.
Please keep ideological flamebait out of your comments here. The last thing we needed in this thread (ok, one of several last things we needed—but they're all tied for last place!) was yet another gender flamewar. You didn't need that to make your substantive point about competitiveness.
Can we now, finally, stop thinking that everything Google does is smart? In the 90s, everyone wanted to copy Microsoft culture. Maybe we just always need to have one company that’s worshipped.
612 comments
[ 2.8 ms ] story [ 318 ms ] threadThe 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 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.
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.
Leave it up to the manager to interpret and read between the lines. At the end of the day, the better managers know it's all bullshit anyway.
This sort of BS review process is pervasive in the industry.
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?
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 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.
This is absolutely my experience at Google. If you want to move up quickly you have to write docs to convince people to work on your ideas.
> Forcing _everybody_ to follow the one path to progress means a lot of noise. A lot of tech talks from people who have no real interest or talent for giving them, on topics that nobody is particularly interested in, just for the sake of a line on their promo packet.
This doesn't really align with my experience. Most people I interact with at Google do not try to do this. They are happy being ICs at L4 or L5 doing their own thing. There is plenty of room to be an L5 or even L6 IC without constantly self promoting, it will just take you much longer to get there and you will never move past L6.
Well TBF, I was an SRE while at Google, so I worked with a whole bunch of other teams. And tech talks were considered a good way for SREs to familiarize themselves with partner teams' various systems. So my calendar had several weekly meetings for tech talks and other presentations...and they were usually pretty yawn-inducing. And at the same time, I felt a fair bit of pressure to prepare talks about my various projects and present them: it would help to spread my knowledge and (ahem) raise my visibility. But they weren't interesting projects, and I was not interested in making presentations about them (or in general).
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.
It's good to have people who understand the difference between the prisoners' dilemma and the iterated prisoners' dilemma.
Max Weber pretty much defined the modern conceit of bureaucracy. [1]
W.E Deming wrote extensively on the "American Disease". [2]
In a few words management and measurement are both inescapable beyond a certain organisational size, and they are the problem, because in almost all scenarios they will expand to displace/strangle the actual work.
It is a recognised general structural problem in systems.
Of course there is much more to it than the above simplification which may sound like an extreme philosophy - but I have yet to encounter good refutations or counterexamples to this tendency.
The answer, perhaps, is that small and many is beautiful.
[1] https://en.wikipedia.org/wiki/Max_Weber
[2] https://en.wikipedia.org/wiki/W._Edwards_Deming
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.
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.
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've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.
Two of these are a signal that perhaps you shouldn't be promoted. The third is a signal that you should leave.
In a less generic sense, I think that there are almost always ways to improve incentive structures and encourage people to focus on specific problems that don't directly involve SVPs. Your manager has some control over your rating. If you can argue that "customer happiness" should be a priority and as part of that, end to end bug triage time will impact ratings, you have successfully created an incentive structure that will reward that, without involving anyone who can modify compensation structure.
Is the issue that Google, as a company, is not addressing user happiness enough? Or is the issue that some organization is letting bugs languish? The first is a much harder problem than the second. You don't need to solve the first to fix the second. I stand by my claim that it is feasible to address the first as an L5, that could reasonably get someone promo'd to 6, and you wouldn't need to involve anyone above a director to do it. Of course, doing so would involve writing very little code, because so much of this is procedural and political, so the engineer who just wants to be rewarded for fixing bugs wouldn't take the initiative to solve this problem. But alas.
If that's "below your pay grade" _and_ you're still capable of doing it, well that's kind of the problem then, isn't it.
Why should I spend a week learning a different domain when someone with experience in that code can possibly fix the bug in an hour? Passing the buck to the right person is the correct answer when you are not an expert and someone else is. Passing the buck too many times happens very rarely, most of the time it is the correct answer, so long as you pass it to the right person.
I can go into anyone's code and fix a misspelling. However if the problem is less obvious someone with experience can take a few days off my time just because they don't have to figure out how the code is supposed to work before figuring out why it doesn't do that.
No.
> Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?
No. Grungy work has to get done, but it also won't build a promo case. If a leader isn't finding ways to make sure that the grungy stuff is being completed then they are a failing leader.
However, if you give a reason for building the 2 new services (eg. more extensibility, enables a new flow, easier to use for other teams) then all of a sudden the complexity is justified and you'll appear to have solved a hard problem. No one is going to look super deeply and ask if those reasons are valid and if you even need the extra extensibility or if other teams will use the service.
Would the goal be to promote everyone? Who's going to do the work they all used to do?
Several years back, you had to also eventually get to L5. This was more affected by promo culture, but was also largely unenforced, which is why they get rid of the formal requirement to get to L5.
I'm unsarcastically glad that you had a different experience at Google than me. This was not my experience, nor the experience of anyone else on my immediate team.
"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?
As they say, the reward for being good at your job is more work. Expecting me to put in top effort for "the users" without compensating me doesn't work.
The idea that you can fix this with culture is wrong. It's been tried many times at many companies and it doesn't work for anyone but the owners. Unless you own a significant (let's say >5%) piece of the company, those late nights you work for "the user" will never be worth it to you.
You do not work for free. You are being paid. 'Top effort' needs not to translate to working overtime, more hours, etc.
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.
Basically, turn it into a marathon not a sprint.
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.
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.
Many a study have been attempted to quantify what character qualities or technologies boost productivity. Their model becomes so nebulous no reasonable conclusions can be made.
But now of course computers learning helps us untangle that web and low and behold the same economic winners emerged! Wow!
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.
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
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.
That doesn't sound like a large issue (but the details can completely change it). Maybe it was the right decision.
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
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 ;)
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 am curious - is this informed by your experience of having sampled every job in SV? Or perhaps a representative sample? Is it possible other people might be different than you and have a different perspective.
What a fucking joke of a comment.
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.
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.
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.
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.
If the world weren't so obsessed with differentiating pay, you would have people who are enthusiastic about a wider variety of things.
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.
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 don't know what the answers are to manage that shift and avoid it going into the wrong direction.
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").
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.
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 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.
https://www.census.gov/quickfacts/sanfranciscocitycalifornia
It’s better to look at the average incomes of people who are buying houses in SF.
What is the median credit card debt for them in these cities?
What is the median annual savings for them in these cities?
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.
It is hard to look at people who are objectively doing as well as each other, and rate some lower only because they have been at that job grade "too long".
The fig leaf was always that the ladders encourages keeping up with technology and the company, which meant people couldn't tread water at the lower grades.
But if the "new technology" isn't necessary for the job duties, labor lawyers can have a field day.
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"
A lot of responses seem to be focused on high cost-of-living areas, which is kind of a chicken-and-egg problem. If you want to be a moderately checked out person, living in a smaller city and stretching your giant bay area salary is the way to go. If you want to be aggressively careerist, you have to be face-to-face in the bay networking.
More input and more interesting problems both feel like more responsibility for the same comp, imo, which might be appealing for some people but is anathema to me. The people higher up got there by being more argumentative, or backstabbing, or ingratiating themselves, and instead of going along with them now you get to fight them. No thanks.
And for the controversial part: The above is why I think it's insane to, for example, take 1-2 years of not working, early in your 20s, to go see the world and "find yourself." Those 1-2 years, if spent earning, could mean retiring an extra 3-6 years earlier.
If you finish uni and take 1-2yrs off, that puts you wayyy behind someone who goes straight into a job. If you take 1-2yrs off your knowledge won't be fresh and you'll not really be a new grad anymore.
Besides health there's a lot of reasons why being certain about doing something now might be preferable to putting it off for 10+ years.
No. I don't work that hard, and my work is generally enjoyable, I've made a lot of good friends, and get to live in the area I grew up in near my family.
> A lot of responses seem to be focused on high cost-of-living areas
Well, my response was to a poster asking "why do you care about making more if you make 200k?" and the answer for some people making that amount of money is that they are only able to find work paying 200k+ in a high COL area.
> More input and more interesting problems both feel like more responsibility for the same comp
The thing driving more interesting problems and more input is a title bump, which in my neck of the woods means a 50% or greater pay bump, so I would say that's not for the same comp. Whether it's more responsibility is variable, but I know engineers two levels above senior who more or less have the same responsibilities as a senior engineer except their project is "harder" and more important to the company (this does not mean the more senior engineer is actually working more hours though).
Perhaps a meta point here is also useful. Once you're senior, most engineering work available is not interesting and does not help you grow as an engineer. Engineering work that helps you grow as an engineer often makes you more valuable. Companies usually give interesting work to their best engineers. If you can quickly climb the ladder to where your job feeds you interesting work you can enter into a "winners-win-more" sort of feedback loop. This is a strong incentive to front-load your career growth by working really hard for your first decade in industry (or at least years 5-10).
This is probably one of the most dominant non-financial factor for engineers. Because if you want to make a visible, critical design decisions for billion-user products you usually want to be at least L6~L7, the level where you're now an owner of a non-trivial product/system spanning across teams.
I witnessed this more times than I can count.
Otherwise its all balance sheet calculations and maybe your manager can pull a punch or two if the product area is critical enough.
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.
https://cdn.nar.realtor/sites/default/files/documents/metro-...
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.
That said, there were lots of people who obsessed over the process, looking for shortcuts or ways to game the system.
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.
At that point, financial arrangements are presumably already all set.
Provide value, but _never_ get promoted. Every year come review season, talk about how your goals for the next year are to improve latency/perf/whatever. It doesn’t have to be specific, just something that’s important enough to be useful, but don’t be ambitious. Just keep your head down and make enough improvements that people consider you to be a good “grunt” worker.
Yeah yeah, inflation sucks and technically I’m making less because my RSU’s have mostly vested and my yearly grants haven’t made up for it, but I don’t care. I’ve saved up enough that I could retire now if I really wanted to.
Every day for me, I work 9-5, fix a few bugs, provide some value, then work’s over and I get to play with my son and completely forget about my job. Then once he’s in bed I smoke some weed, watch shows with the wife, talk about the good old days. It’s heaven.
(By the way, I say all this, but I kinda failed at it because I got promoted last year anyway. I got hella worried because I thought they’d start expecting more out of me, so I actually slowed down my pace even more. I just got a mid-cycle bonus last month. Maybe I’m not so great at keeping my head down after all…)
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.
But they put up with it because it's a career and not a job. Many of them couldn't handle a minimum wage or working class job. No breaks, short lunches, no wriggle room for life, permanent fast-tracks to firing.
But they were mostly being paid handsomely to apply those amazing skills to really humdrum tasks -- but painting them up to be really profound -- and that's the saddest thing.
The interview process is highly highly biased towards recent grads (algorithm/data-structure courses) and the kind of people who do super well in university show-and-tell.
I 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.
Does anyone remember this thread?
https://kevinkruse.com/the-ceo-and-the-three-envelopes/
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Some companies like to spam new products, others like to perfect what they have.
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.
To be honest, the current UI look-and-feel hasn't bothered me at all. I can't recall ever being confused by it (with one exception: iPad multitasking). Perhaps I've simply internalized it to such a degree that I accept it, warts and all, without thinking about it critically. But it's difficult for me to be too upset by a UI that really has "just worked" for me.
As long as my customized keyboard shortcuts still work, I'll be happy, I guess.
I also haven't experienced the software stability issues that you point out, though I have no doubt this is because I rarely do things like transfer data from one device to another (though when I have done so it's worked well enough). YMM(and does)V.
> I'll see your M1 and raise you a trash-can Mac Pro, and the fact that anything other than a Mac Pro can't be upgraded.
The trash can Mac Pro was a mistake, though at least it's one they eventually remedied. Their recent lineup has been almost universally praised, except for cost and (as you point out) upgradeability. I'm not too bent out of shape about upgradeability because I've never tried to upgrade a laptop, but I see the annoyance.
I'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.
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.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
So you're saying that the incentives misalignment at Google leads to engineers who aren't self-deprecating, and products which are self-deprecating?
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.
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.
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).
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 ?
We've been perpetually informed than men and women are the same from the neck up for decades, and a Google employee (James Damore) was even fired for pointing out that men and women differ in their preferences, attitudes, and social behaviors.
That it is now OK to acknowledge those differences when it makes men look bad is quite the standard to set.
I mean, which is it? Are men and women the same or are they different (on average)?
At best, the competition is a symptom of the real (alleged) problem of toxic masculinity: too many men. Specifically an environment where men are systematically favored over women for sexist reasons.
That Google is suffering under such a system is a claim which needs defending.
Google needs to celebrate heroes. Like Jeff Dean. Or Sanjay Ghemawat. Those are Great Men. They are "Living Gods" because they solved Really Hard Problems. Getting into that class of people requires being a "lead" which necessarily means other people around you aren't leading. So you need to prove why you're worthy of being the "lead" which means proving the others around you aren't. This is toxic masculinity. Not solving hard problems.
Consider your words as if they were being said about a woman:
> Proving you're smart by solving hard problems is a gorilla-chest-thumping exercise.
Isn't it still true?
It's called "perfing" (as in, if you do something bad, you might get "perfed hard" next cycle) and managers frequently threaten to take people "into the Perf Room" although it's just an expression (there isn't actually a dedicated "Perf Room"). Anyone who gets below 3.0 (Meets Expectation) during the calibration process is called a "PB" It used to be "pillow biter" but you can't make that joke anymore so it's just "PB", as in "How many PBs does Exec want us to have this cycle?"
It's offensive and backward, but it's also hilarious that grown men (and women, if they ever get let in to executive circles) are using language that sounds like it was invented by teenagers.
1. You must be in an incredibly toxic enclave if managers in your org are routinely threatening people that way. It's certainly possible, it's a big company, there's been a number of shitty directors/execs that have made the news. But given points #2 and #3, I have reservations about believing generalizations about this particular claim.
2. ME is not a '3.0' (Unless you're measuring on a 12-point scale, that starts at 0.) There are three ratings above, and only one rating below ME - Needs Improvement. Which is a pretty serious wake-up call for the person and their manager.
3. Very few people get NI, you seem to be confusing Google with either old Microsoft, or Amazon, whose bell curves, as I understand, require(d) ~1/5th of the company to be on the shit list at any particular point in time.
How in the world can you come to this conclusion when society hasn't been in the situation where old ladies as a whole were in a position to be close to equal financially compared to their male peers in at least the last century? If anything, you have to wait a few more decades to come to this conclusion at minimum.
Is there even any evidence that modern women are more “choosy” than men? You’d have an hypothesis like: among married 40-something women, the distribution of socioeconomic status matches that of women overall, whereas married 40-something men have higher SES than would be expected. Should be easy enough to test with publicly available data.
That's not what the above implied. You can still fulfill the condition "be more selective" if the male populace as a whole was earning way more than the female populace before, which it very clearly was. This directly questions the notion of there being a bunch of old ladies who'd have held out: the majority would've found their "better off financially" peer. Things only caught up in the last few decades or so. All those younger generation women still need to age into old ladies in the first place.
>Is there even any evidence that modern women are more “choosy” than men?
Financially? Yes. While I don't fully subscribe to the idea of "equal or better than", you only have to look for a few minutes to see the hoards of anecdotes and studies pointing towards women putting vastly higher weight on a man's finances than the other way around, to the point men can use their money to compensate for deficiencies elsewhere[0]. That alone would explain why women haven't been nearly as competitive in the workplace as men: men have a far bigger incentive to do so on top of all the other incentives both experience.
[0]: https://www.sciencedirect.com/science/article/abs/pii/S10905...
But the original idea was that women prefer men better than their peers -- that's a direct quote from that top-level comment. You seem to be saying something distinct from that, that women prefer men who are better off financially than they are. These are very different claims.
Further, if you're right that women tended to satisfy their desire for higher-status men simply due to the fact that men used to have more money on average than women did, then where is the selection pressure supposed to come from? There's no pressure -- it wasn't hard for a woman, who had few career prospects, to find a man with a job who could bring home consistent pay.
> you only have to look for a few minutes to see the hoards of anecdotes and studies pointing towards women putting vastly higher weight on a man's finances than the other way around
Take your pick between "I don't really care about anecdotes" and "I have my own anecdotes that tell me that women don't place significantly more weight on socioeconomic status than men do". I'm curious about the studies, but I'd have to find a copy of the article you cite before I'd place too much stock in it. What I'd like to see is some proof in the data that conditioning on socioeconomic status does not significantly alter marriage rates for women but does do so for men.
yes; look up sexlessness among youth by sex
It may be a more competitive or masculine environment than you would prefer, and that's fine. But what benefit do you think comes from labeling the perceived problems of Google's culture as "toxic masculinity"?
[1]Yes women are also competitive, but most of the extremely competitive people are men.
https://en.wikipedia.org/wiki/Toxic_masculinity
If not, you're just sexist, full-stop. (c.f. "toxic blackness" or "toxic Jewishness")
Also, yes, "toxic femininity" is also a term (and is even linked from the other page), but for some reason I don't think you were asking in good faith. https://en.wikipedia.org/wiki/Internalized_sexism#Toxic_femi...
> such beliefs and expectations "[suggest] there is no a priori female self" apart from the needs and desires of men and boys
textbook sexism
Here's my data. Google values consensus - fact. This "wisdom of the crowds" philosophy was core to founding google - Larry & Sergey's brilliant insight that the collective votes of hyperlinks was a stronger signal than things like H1 tags and HTML titles in picking good search results.
But consensus means, in a literal sense, that everybody needs to agree on the right thing to do. Problem is in reality people don't always agree. So what happens when the group needs to reach consensus but people disagree? Since Google doesn't have a respectful way to disagree, the holders of divergent opinions must be minimized - either pushed out of the group or proven to be not smart enough for their opinions to be valid.
God I hate myself while I'm writing this. I left for a reason.
I want to push back on this. I think there is absolutely such a thing as “rough consensus” where everyone gets to air their concerns, but the group still makes a decision where not everyone gets their way. Rough consensus processes are much harder to do over a mailing list because there’s no sense of what “the room” wants - since all the air gets taken up by the people who have the most time & are the most argumentative. It’s much easier to achieve rough consensus in person - especially amongst groups who have good working relationships with each other.
In many ways this is a product failure of mailing lists and the like. I’d love more answers in this space to allow us to make better collective decisions, remotely.
Also, "the holders of divergent opinions must be minimized", not really. You can even continue without a consensus as far as it doesn't hurt anyone else.
"wisdom of the crowds" means respect everyone's opinion IMO. Direct attack to your colleagues will end up with warning from managers or being fired. It doesn't have any meaning of enforcing maximium level of consensus.
The problem of "try my best to prove I'm not WRONG" is much broader than Google's company culture. It's part of our self defense process and has been well identified in psychology (Well, same emotion as what you feel in this thread when someone opposed your opinon, your are trying to prove you have better understanding of the problem or smarter than them as you described yourself). Google's culture is trying to (maybe not that successful) minimize that type of self defense since it's harmful in many cases.
So, probably never. It’s a bit of a loaded term for lots of folks. I can understand why, even if that’s not how it’s often meant.
Hyper competitiveness. There is nothing "male" in nature about pushing people to compete in a giant free for all.
>And it is typically more harmful for more people on average than the feminine expressions of same.
Yeah, no. This is borderline sexist. It's one thing to argue "the workplace only allows masculinity in its toxic form". It's another entirely to go "feminine better".
Nobody appreciates people who speak without knowing about what they speak!
Not to mention that any argument whose central point starts with "I would prefer..." cannot be taken seriously. Your opinions have no bearing on material realities, or, put another way, facts don't care about your feelings.
The equivalent feminine expression of the same kind of dominance is a reputation war.
Reputation wars can destroy lives and relationships. If I have to choose one, I for one much prefer to deal with people winning at how awesome they are (and how lame I am) than a reputation war.
Civilized places have cracked down on violence, so male dominance contests almost never end up with a face punched anymore. Toning down the violence made them much safer.
Female dominance contests are still as deadly as they have always been.
PS: I am not endorsing promo-culture where impact of users/revenue don't matter but I do believe solving hard problems should be rewarded (for example, Nobel Prize or Field Model) and making it "sexist" issue is unproductive .
"Proving you're smart by solving hard problems is a gorilla-chest-thumping exercise. It's not enough to build things. You need to be better than those around you. But you have to be "googley" which means using logic and data to put down your coworkers and show why you're right and they're wrong."
Googleyness was always about bringing up the people around you and elevating your team’s potential, something that both women and men can excel at.
I have a lot of complaints about Google’s perf process, but I never saw toxic masculinity, competitiveness or putting down co-workers. On the teams I was part of, if any of that happened it would have been dealt with harshly and stopped immediately.
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=31262574 and marked it off topic.