Why I Quit Google to Work for Myself
mtlynch.io
mtlynch.io
For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while.
The idea would be something along the lines of everyone gets a set of assist points they must distribute to people who help them the most.
While I don't love the idea of gamifying it, all the places I've ever worked have had too strong of a reverse incentive towards individual achievement, especially when it comes to promotion, and not nearly enough support for teamwork in specific and measurable ways.
Anybody have experience with teamwork metrics like this, or others that worked or didn't work?
There is a really great idea in there somewhere - create incentives for helping others - but I'm struggling to come up with a good way to implement it that doesn't just water everything down.
The closest I can think of is how repo commits can be counted/graphed per user. Works easily for code jockeying, but less so for softer talents like pair programming.
Basically it's a thought experiment in which all team members of a project (or group, etc) estimate the impact when losing various members of the team (whose work presumably is done by other team members or contracts) on the final cost.
Run some math on the data and you have a group estimation of the relative contribution of all members.
I have a theory that the reason more managers don't use this available tool is that it would probably rate management contribution on the lower end...
Sorry, you got duped into having sympathy and showing teamwork.
The better you are at convincing others we're a team and hard work is it's own reward when it's really just dog eat dog the higher up the food chain you go.
We miss the perimeter shooter who positions themselves just so to pull two defenders out of position, but give credit to the point guard who makes the now-easy pass for the "assist". It's entirely possible for the person most responsible for a play succeeding to never touch the ball. You really want something like value-above-replacement, but that's pretty hard to measure without a clear definition of what "success" is and reams of data.
I can't speak for programming but in soccer this is well-known. It's just very hard to Value just like an employer would in terms of having that person on board for morale. Fortunately the better people get it and understand that that person should be value even if they weren't directly involved in making the change but they were definitely a part of it.
This is what plagues me with most corporate companies in the United States. It should be about teamwork not about what this person did or I did, rather what the team did.
Sure you can value people individually, but teams trump individuals all day long in the long run.
Just something about knowing a person is an amazing and knowledgeable resource and he’s choosing to work here of all places is a subtle morale boost. When they decide to leave, others might start asking “well if that guy left, am I still making the right decision to stay?”
I’m sure we’ve all experienced someone important leaving our company and having a waterfall of turnover that follows it. That is very disruptive and more should have been done to keep that one employee or at least keep the rest that followed them out the door.
Moving on is a fact of life, more so now that ever. My parents both worked for the same company over 35-40 years before they retired; I don't think I can imagine that'll be even close to the norm for many in the workforce now (especially software / other tech).
That's why they have a million statistics, these days. Goals, assists, distance covered, top speed, region of the pitch most used, etc.
(a) despite the existence of better stats, a lot of people still care about goals/assists, because they're much easier to understand.
(b) the difficulty of measuring these stats in low-scoring sports (soccer, hockey) is greatly magnified in business; instead of scoring O(1) points per hour, a small software team may "score a point" every couple weeks or quarter or year. Additionally, the number of people contributing is often greater, and we see fewer "identical lineup, but with player A swapped out for player B" situations (and ~never for long enough to get meaningful stats about "points scored").
They especially undervalue actions that happen "away from the play" (the software-engineering equivalent might be something like rewarding a teammate who steps in to help you fix an critical block-ship bug, missing the person who had the foresight to write a test case two years ago that prevents a bug from occurring in the first place).
The NBA has an advanced metric for that called gravity. As you could imagine Steph Curry's gravity is through the roof.
Another related metric is +/- for when a player is on the floor. That one is more nebulous and error prone but it is meant to describe a player's impact on the floor outside of things like assists, points, rebounds, etc.
Happen to have any additional reading on that? (only if it's a handy link for you, otherwise I'll google it). I've re-started watching NBA recently after about 20 years or so, and it's the first time when I hear about this concept, one which sounds very intriguing and interesting. Maybe it was also used 20 years ago, but back then I didn't have access to Internet and as I don't live in the States the local sports newspapers (which care more about football/soccer) weren't mentioning it.
And also the guy who pressured the opponent into attempting a difficult pass so that his team mate could win the ball in the first place.
It's still not perfect: people could be spending them helping someone from another team and that would go under the radar (except the peer reviews), but it still worked a lot better.
Helping other teams succeed is a cultural thing and your organization has to encourage it with its practices and procedures.
[0] http://www.businessinsider.com/bridgewater-employees-rate-pe...
People were taking one bug, breaking it in to 3 or 4, then closing all of those.
"Add button for X" became
* "add button on form" * "add CSS for button" * "update CSS for button" * "add CSS files to build process"
Friend of mine took a bug - it was a moderately big one, touched multiple systems, but was a bear to work on. No one else touched it. He spent a few weeks making it work. Eventually closed it. Was reprimanded because his bug-closing stats were bringing down the department's numbers. He was counseled that he should have broken it down in to a few dozen issues, so that he could have closed more and "kept up" with his team mates.
No one else would touch that bug. Most people hadn't been there long enough to decipher how complex it was. But.... they got bigger bonuses because ... bug closing numbers.
We all probably have similar stories to share, and I know the "what gets measured gets gamed" mantra.
It's still frustrating to know that this mentality infects so many professional "thought workers".
What does not get measured gets ignored. It's not necessarily a bad thing to measure stuff. But it's easy to overlook a metric that later turns out to be important.
If you're measuring the wrong stuff, or measuring it in the wrong way, your metrics are again erroneous and your decisions will be based on ghosts.
Lao Tzu was truly onto something when he said "the more I learn the less I understand".
The article explains the process by which good, honest workers become corrupted into this mentality. Whether you want to do good work or not, most people don't have the confidence, security, nest egg, etc. to quit their day job, so they assimilate out of the necessity to keep their bills paid, and this becomes a cycle. The naive worker comes in determined to do a great job, soon learns that "great job" is not a straightforward evaluation and that people who have no real involvement, knowledge, or investment have control over their career trajectory, and then optimize to improve those numbers.
These people then get promoted and a) consider failure to game the system evidence of naivety, and expect this same political awakening in candidates as a "rite of passage"; and/or b) rise through the ranks without realizing that they've gradually internalized the system, and that they're inadvertently making the same loose determinations based on impersonal, macro-level metrics that are easily gamed, partially because as you get promoted, you can't possibly come to a deep intuitive or direct understanding of the work of everyone in the ranks. Rinse and repeat. The ABCs of employment are "Always Be Campaigning".
Strong, personal leadership from invested, intelligent people with conviction is the only antidote, and even when you get these people, it's a constant battle to keep their disinclination for political games from destroying things.
To take a narrower view, it sounds like that place needed to assign weights to the different bugs, so that the big scary bug was worth 20x (or whatever) of the trivial 'tweak the CSS' bugs.
I was supposed to complete an existing project. Only problem was, new bugs kept getting added by the tester, and were then assigned to me by the project manager, so the number of issues kept growing. I would fix them (or existing ones) during the week, but at the next conference call it would still look like I was not making progress, because the total number of open issues did not shrink much.
This led to weekly inquiries of "when will it be done", and pointing out that it was essentially a moving target, due to circumstances beyond my control, did not help much. Eventually I did catch up, but the damage was done. Apparently this manager now thought of me as somebody who wasn't very productive. They moved me to another, completely unfamiliar project, where I got essentially no help from others, then decided that I was not productive enough and let me go.
In retrospect, being asked continuously when the project would be done, was an indication that I was the only one being blamed for its delay. I was afraid to rock the boat though, and quietly assumed that surely this manager was taking all the factors into account (especially since I did point them out a few times). As it turned out, they were not, and I will not make this mistake again, should a similar situation come up in a future job.
This is really at the heart of why most people don't speak up (or speak up more loudly) - fear. Fear of losing the job, income, etc. There are no easy answers to this, short of having - if not FU money - a comfortable cushion to see you through a year or two between income streams.
Let's say there are 4 voters: A, B, C, D, voting on policies 1-10. Everyone gets a certain number of votes (say one per policy, so 10 total).
Voter A only really cares about policy 5 & 7. So they want to buy votes for these 2. They can give up their votes in, say, policies 1-4 to get 2 more votes for policy 5, and can also give up votes 6, 8-10 to get 2 more votes for policy 7. So they put 8 votes into the "common pool" in order to ensure that, in addition to their vote for 5 & 7, each policy also gets 2 extra votes?
FWIW, the paper describes it as a vote currency that can only be used for the vote, as opposed to cash you could spend on anything. The voice credits have to be distributed to voters.
'individuals pay for as many votes as they wish using a number of "voice credits" quadratic in the votes they buy.'
I now recall that sqrt(1) = 1. I did not recall that 2 minutes ago.
I can have my head down all week neck deep in code but because of this I'm not interacting with people around me as much and basically get punished for focusing on work.
There is a simple metric for workplace success: if most people are happier while you're around (including and especially anyone above you in the chain of command), you're winning; if not, you're not. This can probably be summarized as "popularity". A few things can overcome this, so you may want to be careful not to go 100% focused on it, but you will definitely prosper if you make it the focus of 95% of your work.
Developers who like to debate and don't take it personally when a colleague disagrees are at a distinct disadvantage here, despite simultaneously frequently being some of the best qualified coders, because they don't understand that they're rare, and that many other people take any form of non-ambiguous criticism of their ideas or work as a major offense: taking bread out of their kids' mouths, etc.
I have a theory that the more a person cares for niceties, appearances, and superficialities, the more it shows that they're incapable of operating at a level any deeper than that (that is, capacity and the presence of superficial tokens generally understood to mark capacity are inversely correlated; e.g. an expensive watch does not necessarily indicate power, wealth, or importance; compare Dunning-Kruger Effect). People who are capable of doing useful work seem to find these superficialities asinine and have difficulty hiding it, whereas people who aren't capable of useful work try as hard as possible to keep the focus on the surface level, because that's their only hope.
Since the surface level is immediately apparent and the importance of the subsurface may only become apparent after some experience, imposters can, and frequently do, find great success.
But I would say a lot of managers are trying to get their coders to be more productive with coding. When they introduce something like "assist points" which is really just a popularity game, it doesn't incentivize coding as they think it does. It incentivizes more socializing. Which frequently also means less productive with coding. Don't get me wrong I do need to work with my coworkers, but a lot of the time I need to be working alone, or just send a quick email. And I'll get punished for doing that even if that's the most productive thing to do.
On your theory--I think it depends. Sometimes it's "I'm insecure and need to compensate in some way, like expensive watches" but sometimes it's "I take pride in everything I do, including my looks." Also while in some ways I'd probably be happy to wear PJs every day, I understand that the easiest way to get more power in social situations and business is just to dress nicely.
The third category, of whom I’ve known several, is “capacity/competence, with an attention to the superficialities because they know how much those matter.”
That is, I haven’t found it to be an inverse relationship. I find it to be a 2x2, and if you happen to be someone with less capability and more ability to BS, then yes, you lean on your strength to obfuscate your weakness. But you can also be strong in both, or weak in both.
I also think there are a lot of jobs where deep mastery doesn’t generally exist (eg, mopping), and so those people just have no idea what deep competency discussions are like. It’s like flatland, only the third dimension is expertise and complexity.
A little bit of pushback on the more technical or capable people and they will start dropping the facade, whereas the less capable will just hold it up higher, because it's the only thing they know. They have no conscience accusing them of misrepresentation, no sense of guilt or concern that they may be drifting afield from an acceptable core. They only learn that they need to wear the tokens more convincingly next time.
So yes, you can have people who wear the tokens for expedience and out of a recognition that its important to fulfill the heuristics, but they're no competition for those blissfully unaware that there is anything else involved.
In my experience (I sort of enjoy fashion) most people cannot tell the minute differences between "tailored outfit & basic color coordination" and "total fashionista who keeps up with everything." I can walk around with a fake Coach bag, get compliments all day, most people just do not know.
There's exceptions of course, certain offices/fields of work. But it's not common.
How do you feel bonusly avoids this potentially awkward gamification/popularity contest? I feel like most people I know would just give 30 bonusly to a random person on the last day of the month, but maybe your colleagues are a little more disciplined :)
Managers read it, my teammates in Seattle read it. Nobody ever helped us (because you know pair programming is so much more efficient if you can have two programmers blocked when you could just have one staring out of the window and typing "help" to invisible people). If at all I would be unblocked after a few days usually the problems was some kind of unguessable piece of configuration that should have been part of the README and/or code, a problem completely unsolvable without knowing what to do. Only then I could continue doing a minor change like updating a CSS file for the next Safari or IE quirk, usually just 5 minutes of work.
Apparently helping remote teammates to get unstuck in their work just wasn't an interesting performance metric.
Until this day I still can't believe that everybody was just throwing tens of thousands of dollars of work out the window because helping stuck teammates wasn't counting towards some kind of bonus.
So if there is a micro-crunch coming up (i.e., I need to have an SOP drafted, tested, etc by this afternoon), the entire morning I tend to blow off other peoples issues. Until I can get a chance to come up for air.
But that makes me feel bad, so what I end up doing instead is I go home at the end of the day and work till past midnight just to get caught up on what I couldn't do in the daytime. For any outside-the-box work I tend to pull 20-30 hours stints over the weekend. After 25 years of this, and as I need more sleep since I'm getting older, I can be a bit snippy when someone breaks me out of my concentration because they can't figure out something, and they have a down customer that needs service "right now".
I started out as the eager mentor, even when it was among my peers in university. But somewhere in my ~25 years of R&D, I started to notice how coworkers would become dependent. They would ask for help on types of things that I knew I had figured out myself, even when I was a novice. They develop the plea for help as a first reflex to avoid any learning tangential to what they consider the task at hand.
So, I found myself swearing under my breath and refusing to be their search engine or man-page. Depending on my mood that day, I might tell them I have no time and they should google it themselves, or I might pretend I don't know the answer either. Sometimes I relished the time to sarcastically school them on the mundane deductions it would take to answer their question from the very screen full of error messages they pasted at me. But, I already knew they would miss or ignore the hint, and be back again next time they stumbled.
Sadly, I think this cultivated impatience leaked out into my attempts to mentor a very junior staff member we had a couple years ago. I could no longer really distinguish "too lazy to try" and "drowning". They found a new job after a year or so, and it was probably wise for them. I am still trying to visualize how I can do better the next time we try to onboard somebody far junior to our current team...
1st year
'Thanks for your help finding that error that was holding us up.'
2nd year
'We are all finished now. Just sent it over to you for debugging.'
3rd year
'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management
4th year
Management: 'we need to talk a about the regular delays here. We have several teams waiting on you. Also your own code checkin's are much lower than theirs. Seems like you are only making changes to what others write.'
For programmers: jump ship. A well-executed handoff process will not only maintain goodwill but remind others of your value.
Of course, by the time you have upper management yelling at you because "several teams are waiting on you", the response becomes "why have you allowed several teams to become completely dependent on one overworked person?"
The other, more drastic solution (as someone else said) is simply to move jobs. This can be the only way to fix the issue if the entire management structure is corrupted and you don't think it's fixable from within. You could even just leave, start a consultancy company, and let the second team know that you're available for hire when they need you.
- If you reach this situation, you're more competent than the rest of the group. Nobody to learn from, time to go.
- "Management" is a big machine, with its own insider culture and politics. It does not change overnight, do you want to wait 6 months minimum for things to get better?
- Changing job is good for just about everything: career, money, knowledge... as long as you don't do it too often.
- Meta-bonus: getting into a job with better peers means tighter work-friends. It's not fun to be around people overdesigning object-oriented projects when you understand functionnal programming and low-level debugging.
From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now <Peer's> inability to properly take notes or retain information. <Peer> knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally <Peer> will have better knowledge retention by synthesizing their own notes.
Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.
Management publishes a Medium article "We fired our top talent. Best decision we ever made."
> I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run.
>> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck.
This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc.
That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc.
Partly this is because I really cannot be bothered to keep such details in my head, anyway.
What has your career trajectory been like over the past 25 years?
For example, back in 89 (I was 18 - 19 then) the company I was at had a need to access multiple screens at the same time in their green-screen (serial terminal) application. So I wrote a multi-session terminal emulator. Ended up being a lot like what GNU screen is today (not sure if screen existed then, this was pre-internet days for me).
Other times I'd write up software distribution systems, monitoring systems, etc. Or work on creating things like a custom interpreted language, just because an app developer at my company needed that. Or write hand-coded postscript, because someone's app needed that.
In my current company, I'm still a Linux systems engineer / Lead, but I've been on-loan to our app development team to help with C-based libraries that they need (this code is a couple decades old, and they don't have any C hackers that can work on it). This is software that interfaces with medical testing equipment, so it feels like I'm making some difference.
Lately I've been brushing up on my web development skills, becoming buzzword-compliant, and putting together web apps both for internal use, and related to maintaining our product.
I guess I should have went into full time development years ago, but I was always worried that I'd get shoved into boring business applications instead of working on really interesting stuff. So I've stayed in the Unix/Linux ops role, found out that a lot of what I've been doing is now called DevOps, and doing open source work on the side.
As for the trajectory, I haven't changed jobs that often. I've had a couple of dud-type jobs where I lasted 1 - 3 years (they didn't want someone who could do "extra" stuff, because that "made the rest of the team look lazy" as I was told in a performance review once). But when I start at a good place I try to make a good first impression, then a better second impression, and try to work and support as many people as I can (while doing my best to make them look good, but making sure I get recognized too). Helps to have a number of people that "have my back".
Honestly, there's not much you can do if you feel like your company is not acknowledging work that you believe is a valuable use of your clock time.
What I notice more senior people do is 1) expose clear SLAs to require their help and 2) get in the habit of producing more artifacts while they concentrate so they can refocus faster after an interruption.
In a manner of speaking he did pull the andon cord by speaking up in his team meetings and alerting people in Slack, but the cord means nothing if there is not a culture supporting the alert.
That’s what these companies need. The entire business comes to a screeching halt.
And if they really needed more motivation, production servers could be shut down if the issue was not resolved in 24 hours. That will really hold their feet to the fire.
In a room no-one enters;
Snow blankets roadblock.
Managers absolutely don't seem to care about actually building a team and cultivating a culture of success.
Engineering managers are way way worse than Soccer managers in this regard.
I would put this all on the hiring processes right from how we hire engineers and managers and what gets a promotion. But unfortunately, our industry would rather remain blind.
The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.
If only there was a way for employees to rate their Manager instead of the other way.
Then again, I've been very selective in where I work. People like to bash the "culture" stereotype, but it's definitely something I consider when I'm looking for a job... you know, how people are expected to interact with other people, not whether there are ball pits and the like.
No, it really, really isn’t. Maybe 1 in 1000 cases are like you describe but the rest is just that older engineers are harder to exploit.
When you have a recognized long-term leader that doesn't need to constantly re-justify their involvement and existence (something akin to a BDFL), more collaborative group efforts can be fostered, and individual gamification is much less useful, because the people who know your behavior are going to be there for a long time and there is a lot of personal continuity. This system is, of course, not without its own type of flaws, but it doesn't have the same negative feedback incentives for individual contributors.
It's hard to get that long-term involvement in the tech industry specifically because the rapid rate of technical change limits career length and portability. Skills in language/system/framework X rarely retain marketability for more than 3-5 years. Most people don't have the stamina, interest, or whatever it is that's needed to keep up with the constant re-education and re-justification cycle into their 40s and 50s. They look for an out: early retirement, promotions into non-coding management positions, etc.
To the extent that individual metric gamification is higher-than-normal in tech, I would attribute most of it to the effect of shorter career tenures, both overall and at specific companies.
I think short-term thinking by superiors causes short-term behavior by reports.
If the management pays fairly, with fair raises, fair balance, fair acknowledgement of all kinds of work and not just the flashy stuff, most reports would focus on the right things, do their jobs well and not look to switch jobs all the time.
But if the management is always trying to escape giving promotions/raises, does not acknowledge the underlying effort to get something to production, only thinks about their own empires (basically short-term selfish thinking) it will cause a disproportionately high number of reports to behave the same aka look out for their selfish interests.
I am absolutely certain that top companies look to retain good players (top != stock price or market cap).
In fact, there are many social group situations in which asking specific people is far more effective than asking questions "to the group".
The bystander effect is real, but I wouldn't expect to see it in organisations with explicit hierarchies. Can you imagine this happening in the armed forces? If this happens under your watch as a leader, you're not good at leading.
Nah, let’s just alternate between micromanaging and being totally absent; fret about lack of productivity or lack of progress; maybe institute a daily stand-up.
Source: am a manager.
Good: "Hi, Sumitra. Can you help me with this or recommend someone who can?"
Good: "Hi, $MANAGER. Can you help me with this or recommend someone who can?"
I've never been at such a company and I hope I never will.
We're humans. Unless there's been a training day or a Readme file explaining HOW to report a bug, I think it's perfectly reasonable to expect this protocol to work:
"I'm blocked!"
"Why?"
"{reason}"
If nobody ACKs the "I'm blocked" message, it's reasonable for someone to think that nobody cares or nobody is listening. This is a normal human protocol, as used in most human environments.
"{problem}!"
"What's happening? How can I help?" (any considerate person nearby responds)
I just cut your protocol complexity by half. ;-)
Those people should never be managers.
It’s rather unrealistic for the manager to be understanding all the time and coax a team member to give all details of every problem...
Dig as far as you can, record it all, then escalate. You also have to gauge how critical it is and how much of your time (esp. if other things are building up) to spend on it as a factor of when to take it up the line.
Tbh, I haven't had any managers lately that have been that great but I'm still holding out hope.
> Source: am a manager.
> I'm blocked, woe is me" is garbage
As a manager, are you prepared to put your real name to these comments?
This is an anonymous public forum with a massive audience and great content. Let's keep it civil and not target individuals. Please don't try and start witch hunts to ruin someone's career just because you do not agree with him.
Comment sounds like typical 'pull yourself up by the bootstraps', meant to put down new talent, ignoring that complex, modern dev environments have many parts that are completely out of reach for newcomers without adequate onboarding.
Like you said, why not both? The employee is already asking for help, that's their part. The manager needs to come in and assist, unless he enjoys churning his dev team.
That is not asking for help. Asking for help would be "Can somebody please help me? ... rest of message here...". Even better is asking an individual (or individuals) directly.
Say what now? Mentioning you are blocked, in a stand-up, multiple times is a cry for help. What is the point of having stand-ups if you're not assisting blocked team members?
The standup is for blockers to be announced. It's the 3 stage of the standup.
Sounds like poor management, don't blame the new guy, he did say he was blocked in standup. How is he to know who to ask. Whose time can he impinge upon. It might be he asks someone who helps him but he gets in trouble because he now took up that persons time from something else.
The manager should see oh he is blocked, I'll assign so and so to help unblock him.
Sometimes it's on me.
Source: I manage managers
I just want to point out that that is a lot of assumption based on the limited (probably paraphrased) context we have here.
When a member of your team can't perform because he's not given the proper resources(access, help, info, etc), it should be your number 1 job to find out why is that the case and do everything in your power to rectify that.
One could argue that it's your only job actually.
You can bet I was a hell more specific about both the problem and who should help me.
People ask for help in different ways based on personality, skill set and experience. It’s more important to meet them where they are than sit back and smugly suggest they lack individual ownership.
You actually expected that what I wrote was a literal quote from the only thing I ever said during those days? It probably was something more like:
"Tried to run project X but kept getting error Y. I tried to figure out where it comes from but it seems to missing some kind of value it pulls from somewhere. Tried every step in the README and installed twice. I think the information in the README is incomplete and there's another step. Nobody else had to use this repo before here so the guys here can't help me out either. Can you help me out @colleagueFromTheUS1 or @colleagueFromTheUS2?"
After 48 hours I get very specific about being completely blocked and that I have exhausted every way thinkable to get it running. So nobody would be living in the fantasy the problem was going away by just ignoring it long enough.
This is very good- something managers should do for all of their direct reports. If not every day, then often.
Otherwise, a common issue for a team with colocated workers mixed with remote workers is a facility to ignore calls and messages.
Central people get easily overworked, interrupted and drown into tsunamis of requests. One of the coping mechanisms in these situations is to just ignore most requests, and only deal with people getting loud enough to be heard. In a mixed environment, the coworker siting 10m away has an easier time grabbing attention than the icon in the chat room with a unread badge.
Even simply knowing when someone is taking breaks can help to time requests to get them at the right moment.
I have remote days every now and then, and it’s interesting to see how the game is completely different, and how often I end up asking someone physically there to go talk to people on my behalf.
(Note that being remote in an otherwise physical team makes this significantly more complicated as well.)
It's the same thing.
CPR for example. It's one of the primary tenants. Assign individual responsibility to people to ensure this group paralysis doesn't happen.
Certainly it might've been more efficient if one of your colleagues helped you debug the issue. But in the absence of help, it's not clear why you didn't dive in and start debugging on your own (rather than doing nothing). You'll learn more that way too.
Also it's not clear to me that learning how to use Process Explorer + using it, when that's not your job, is actually meaningfully more efficient than staring out the window all day.
I’ve generally heard “blocked” from weaker team members when it pertains to working on our stuff.
Sure, you can be blocked due to infrastructure / external dependency, but if you have the source code, unblock yourself, mate.
Programming is going to be a frustrating career for you otherwise.
It's not time efficient for everyone to work separately down to reverse-engineering the machine code to work out what's missing every time.
This happened to me once a few years ago, once I finally figured it out I put all this silliness into one single bootstrapping function you could call to get the pig of an application to run, and asked the lead dev to add it to the core library. Later that day I got called into my manager's office as apparently my behavior was disruptive and problematic.
(not saying it was necessarily about something real, just that it could be)
While I agree that it would have been nice if somebody helped you, you are in control of your own destiny. If nobody is helping you, you need to personally escalate it and reach out until you get the job done. If somebody did this on my team, the first question I would ask them was why the hell they let themselves sit blocked for days.
...and of course my team would have been more proactive on helping you because one of our core values is help your co-worker, but that is besides the point here.
Unfortunately most people I have met do not think like this.
The company needs to take at least partial blame here.
Note that I am not convinced that this is the case here - I simply don't have enough information to make the judgement.
Wat?
My other thought was to file blocking bug/defect issues on the relevant software because obviously if it can't build in the first place it's certainly not passing QA.
Some of this may get to the level of passive-aggressive or aggressive-aggressive bridge burning.
And didn't you have backups of that repo?
I can imagine situations where you should care about the company's performance, like a non-profit or certain startup situations, but I think the majority of enterprise developers fall under the above.
When you're co-located with someone you develop better comradery with that person. You'll know them better and they'll come right to your desk when they ask for help so you're more likely to help them. And you sit with them as they execute commands so you can see exactly what's going on.
remote coworkers are easier to ignore, harder to help, and harder to socialize with.
If not, you should be able to at least start debugging. You should get some error message (maybe that indicates some env variables not set, something not installed, etc). It seems odd to have not spoken directly to your supervisor or product owner to say "hey, this isn't working because X. What do I need to do / who can I talk to for help?"
Not necessarily. In my case, we have a web application where it eventually turned out that the variable was read from an environment variable. On a server where I didn't have access.
pfft. If it's a web app (from 2015-2018) I have even more sympathy for the OP than on any other platform.
Here's an example from last year-ish:
* Get repo from external contractor (let's ignore the 1+ weeks trying to get an install of Git approved)
* Try to get npm working - can't get through our firewall
* Figure out the right chaining proxy to use
* Spend a non-zero amount of time trying to work out all the right bits to flip to turn off ALL SSL verification from npm because interception proxy
* Hit the Windows MAX_PATH limit and have to spend ages trying to delete files that NPM's created (original developer used Linux)
* After npm starts downloading stuff correctly, suddenly it needs a binary dependency (and thus more build tools)
* Give up and check in said binary dependency from elsewhere
* Finally build all the CSS and minified Javascript and check it all into source control with a warning to other devs not to rebuild it unless absolutely necessary
If you are assisting, and this includes providing support for someone else's code, or doing "invisible" tasks (setting up a redis cluster or writing end-to-end tests), this often finds its way into one email group or another. In fact I remember the names of the "helpers" as you put it by the virtue of their emails and to that end I value them, just as much if not more, for keeping us shipshape.
IMHO, you should find these emails, and I am sure they exist already, and use it as your metric.
Scott Fitzgerald wrote “Show me a hero and I’ll write you a tragedy.” I say show me email chains, and I will show a hero.
Of course I am not stating the obvious fact - which is that your manager, if he or she is worth their salt, should totally value the role "helping" plays in making good software.
In my experience people also ask for help through private messenger discussions (slack/skype etc), which of course don't leave any "official" trail and are not supposed to. Of course, a not-so-bright manager could force his/her direct reports to only use "official" channels for work-related communications, but then people would be afraid/ashamed to ask "stupid questions" in public/through an official channel and then disaster happens (it's also my experience that lots of serious bugs have been caused by people afraid/ashamed to "just ask").
I've had the experience several times where extensive, detailed emails would always meet the same reply: "Thanks. Let's talk about it in the morning." These people are wise to the game, and they rely heavily on the imperfect nature of human memory; memorialization in the written record must be approached very carefully.
The email chain that shows Employee A to be a hero equally shows Employee B as a victim in constant need of assistance, obstructing other work, taking valuable time from others. As such, "Bs" will avoid asking in a recorded form, avoid giving credit to helpers when writing about their work, and so forth. Even if they mean well and earnestly want to credit the many people who've helped, it's too easy for a malevolent actor to turn it against them, so after a few raw experiences, they learn to avoid it -- just like what happens in the article.
The only real answer to these questions is to have an informed, rigorous, and fair-minded chain of command that has experience and cares deeply for the company's long-term well-being, which is, needless to say, quite rare. It is also worth noting that such noble persons are likely hurting themselves by acting this way and making enemies for themselves, as people who truly didn't deserve promotions, etc., whine and search for flimsy excuses.
Will show you a hero six months after they tendered resignation.
There's only one way to actually measure someone's output, and it's working close to the team and witnessing their actual productivity. Getting involved. 1-on-1s.
Of course the farther removed from this process the more politics come into play.
This is why I generally dislike measuring individuals against specific metrics. I try to set individualized metrics for all of my direct reports — for example, if I had a developer who keeps checking in code without valid tests, code coverage might be a metric I track with him just to help him understand how he’s doing against his personal goal. Even within the same job description there is often room for a significant variation in technical and interpersonal skills, and you need a team with a good mix of both to be successful. A one-size-fits-all approach to individual metrics just leads to a team of people with the exact same skill set.
I think the way you measure teamwork is at the team level by having a consisitent set of team-level metrics the entire team is judged against. This means individual personality and career path variations don’t matter as much. I’m talking things like say, number of broken builds, velocity improvements, production issue counts, etc. These should be business outcomes that the product folks care about. If you make it the team’s responsibility, you’ll find teamwork happens more naturally.
This approach to performance management is in direct opposition to stack ranking, and a big part of why I refuse to work for a company that forces its managers to stack rank within teams. The question of “what makes a good employee great?” is so difficult to answer that if you have multiple high performers, it’s effectively arbitrary. It also tends to punish people who are maybe less technically brilliant, but have strong interpersonal skills (after all, how else does a mediocre programmer make it through a CS degree?) Those interpersonal skills often lead to better technical discussions and avoidance of miscommunication between technical folks.
Most of the time other people leave or move to other teams.
Being a decent human being is not about getting practical advantages - otherwise sociopaths would be the most helpful people around.
Instead, many large corporations want to instill a culture of competitiveness and often cynicism because competing is what they do.
Cooperation, lasting relationship between employees, mutual help, solidarity are increasingly scary words for many companies.
Sociopaths are exploiting the macro-level heuristics we've developed as a species to come to an immediate, reasonably-likely evaluation of safety, tending individuals toward trust, and danger, tending individuals toward defensive action. It takes knowledge and experience to differentiate between a good read based on sincere action and a bad read based on intentionally-deceptive action.
Sociopaths often will appear like the most helpful people around, and sometimes may actually be the most helpful people around, for the duration of the time that they need you to be on their good side. Then they'll dispose of you ruthlessly. If you don't pick up on the signals ahead of time, you don't find out until you've been backstabbed. If the sociopath is skilled, they ensure that you can't "come back from the grave" and cause problems for them.
It's not that corporations don't like cooperation in principle. From a high level, in fact, many corporations are actively and honestly trying to cultivate it. It's just that our systems keep the exploits too open to the relatively-rare maladjusted power player (normal people will sometimes flirt with the same tactics to avenge personal grudges, etc). This forces everyone into a defensive position, if it doesn't force them out of the game entirely.
Once an organ grows to exceed the direct influence of a very small handful of truly good and wise leaders (the more palatable tech word may be "visionaries"), it will inevitably mandate this weird perceptual bastardization.
Even on the team level you're still reading tea leaves if you're going into the issue tracking system. The only measure that should matter is execution towards a business goal. A team that is killing it consistently is doing the right things, or is being given the right projects.
Interesting management approach. My questions are:
1. How do you account for new team members in a team's metrics? A new junior dev will take some time to become productive so do you add the new member's progress to the team's metrics by making it responsibility of one or two experienced teammates? For instance, you might have internal progress indicators like - by month: 1 the junior should have read access to certain repos that are crucial to a good understanding of the application architecture; by month 2: made a certain number of commits; by month 3: written X number of tests etc.
2. How do you use these team metrics to recommend promotions and raises for individuals?
2. I don’t! Well, not directly. Team metrics usually have some impact on bonus money and raises, but that’s all based on budget so it’s not consistent year-to-year. Metrics should be used to drive behavior, but behavior should be used to determine promotion. Is the person a team player? Have they developed the skills necessary to be successful at the next level? What does the next level look like for them — is it management or engineering? A lot plays into it, and you have to have career path discussions with folks. Can’t solve this one with metrics :)
Businesses don't handle processes that produce variable outcomes very well since it opens them up to risk. Or stated another way, businesses love the notion of fungible employees and a one-size-fits all process to shepard those employees.
Fungible employees makes sense if you are in manufacturing where low skill workers are the norm, but not so much if you are in the knowledge industry, where there are variations in the skills each employee excels at.
IMHO, the dynamics of knowledge work is similar to a team sport like soccer/football but businesses would prefer that the dynamics be similar to manufacturing line workers.
So basically the long-term effect of these systems was me to slack on whatever my manager deemed important to get done to whatever extent I could while I did whatever would win me clout points with other developers or let me learn a cool skill.
I also got pretty jacked from sneaking off to the gym etc. Lol it was lit
So anyway I think that was probably valued by our project manager who is also a former techie, because she probably realized if I didn't do it, that PR wasn't going in that release.
A point that Dev 1 gives to Dev 2 will not likely be equal to a point that Dev 3 gives to Dev 4.
This will be especially true if everyone has the same quota of assist points to assign, as people may very easily receive different amounts of help, and thus their "actual help per assist points assigned" values will differ.
The only thing we know matters is the team does well or not. So I suggest trying different methods of building/running a team, and let them go. See which teams succeed and try to copy that success or give them more power.
To give some flavor to my idea - maybe the level of helpfulness you should ideally give is very low. Perhaps it enables weak members to suck up lots of time. We just don't have good data in this area.
You could give as many kudos as you wanted, and it had zero impact on performance appraisal/raises, but it sure gave people the warm and fuzzies reading about random mini-stories of someone going above and beyond here and there.
I think it was pretty effective at fostering a culture of collaboration, and it also helped surface issues-masked-as-heroics, such as people working chronically late on some projects. It also gave greater visibility to the existence and importance of the various departments, which one might not have gotten an appreciation of otherwise.
Its interesting that throughout my career I've found it has been challenging to communicate group and individual contribution in meaningful ways to people without the whole picture. That is especially true when the activities don't translate directly to sales revenue.
As a result, you get people who leave who were much more important to the organization than the organization understood and the folks left behind are stuck trying to recover and make up the loss.
If there was a manager measure of 'OQ' (organizational quotient) it would measure the ability to recognize and optimize the net productive energy of an organization. Groups without that awareness seem to wither as they pursue one or two 10x employees without regard to how to support their activities.
As you say, zero impact to people in terms of their performance reviews (which were a topic of discussion in their own, each employee having to write a mini-manifesto for their year ahead) and kinda became a popularity contest where people were giving kudos to their office buddies.
And don't get me started on the people that left heart stickers with messages like "thank you for starting the best company in the world" on Benioff's profile.
Another issue is that tech orgs are extremely political. There was one person who had single-handedly created a viable migration path from the company's aging proprietary framework to .NET MVC5, but no kudos there. Just lots of pushback and skepticism.
On one project I shaved about 40 minutes to an hour per day of finger twiddling frustration off of everyone’s work. For the team size that paid for itself in under two months. Only ever got appreciation from subordinates and flack from my good for nothing boss.
But what I figured out not long after that was that you understand the work a lot better when you see it from other peoples perspectives, and you only learn about that if you are willing to help and to be candid about the state of the project. People open up. They share maybe-bugs before filing them (especially from the QA team) and then when the inevitable OH SHIT meeting happens you are the only one who has had time to think about a solution ahead of time.
Anyone from Shopify here? If I recall correctly, this was tried at shopify and has since been removed due to people gaming the system for their friends.
However as the writer of the article pointed out often times you can't see when other people are improving your ability to do work whether that's through writing more documentation, improving some internal infrastructure, or other often invisible things that can drastically improve your life as an engineer.
I think an effective approach would be through time tracking (i.e: writeup on how you spent your time for the day) in conjunction with some analysis on how the time you spend on certain things correlates with what other engineers are doing. This of course would rely on everyone being detailed in their writeups and the analysis still might not catch certain things because it's difficult to write down exactly how you spent your time. Perhaps you could only write down the three most difficult/annoying problems you ran into and just track that.
I remember reading about some company that is trying to make this easier by tracking computer use and creating graphs of how people interact within their organization and how that changes over time but that doesn't seem like it would work everywhere.
I don't know if there is a way to truly quantify teamwork or organizational impact. I think the important thing is to encourage your organization to communicate more: talk about what you're doing, why you're doing it, and how it helps others within your organization. If your organization is fairly big write about it and share your writeup internally. Train people within your organization to speak up if they feel they aren't being appreciated for the impact they made.
Ultimately I think it's an extremely hard problem because it stems from the question of what having a positive impact means. The answer to that can branch off into millions of different small tasks that could be totally unique to a subset of people within your org.
----
The best you can do is:
* Measure what you can.
* Know that's not the entire picture and it never will be.
After that try to create a culture that:
1. Speaks up about their own impact
2. Shares the impact of others' work, especially of those who might not speak out much
3. Is openly appreciative of and encourages 1 and 2.
Although your peers saying you were helpful is not enough, you need to demonstrate impact (and other attributes depending on your level).
From my experience it works amazingly well. It's silly, but if you are ever having self-doubt, a gift card from a coworker really helps.
I completely agree with you on this. Also, I like the idea of formalizing with "assist" metric, so that people are sure that their work won't go unrecognized.
Using this, everyone can know what other people is working and who is helping who like that. For every month at a team meeting, people who got more points will be appreciated in front of the whole team. The total points is calculated using a formula such that a member who just start giving/receiving more points per jem than other so that new comers will be appreciated more.
It works really well and at performance review, managers will consider this stats. Also the performance review contains two peers (chosen by us), and all kind of managers who we are reporting.
This was highlighted to me recently when someone in Slack noted that one person had ~50X the kudos of everyone else and asked how that happens... and they said "just go hang around in team X's channel, they'll give you a 'taco' any time your answer a query."
Given Google's promo system (where a committee looks at candidates from very different teams) this then means they'd have to try to normalize the data for it to be useful.
Even if it is - don't be that manager of the group with the least group kudos/tacos?
Is the goal of using something like this to help people show more gratitude or is it for performance feedback?
And can those two things coexist or do they conflict with each other?
Would love to hear your thoughts.
I don't think they should be used for perf as they are not intended to be objective feedback.
Years ago I worked at a desktop software company that hired me to be their "Windows expert". They had a team of strong programmers who mostly had a Mac background, and they wanted to improve their Windows offerings.
I often spent a couple of hours a day doing what I called "house calls": finding out who was having trouble with a Windows issue and stopping by to lend them a hand.
This was before "pair programming" was a common term, and full time pair programming would drive me nuts, but these house calls were very productive. The other team members knew the product code much better than I did (being a newbie), and my Windows experience helped them work through platform issues. Plus sometimes just having another pair of eyes look at a problem.
Often a 20-30 minute house call would save a team member many hours of work.
At one point, a teammate thanked me for helping with a tough problem and asked me, "How can you afford to be so generous with your time?"
Some time after that, the VP of engineering (who I'd worked with previously and was on good terms with) asked me if everything was OK. He had noticed that the other developers on the team had lately been more productive than ever, but my own productivity wasn't quite keeping up.
I think I mentioned that some of my time had gone into helping the other developers work through their Windows and other issues, but I didn't have the presence of mind to say, "Maybe my help has been one reason their productivity has gone up. I thought that's what you hired me for. Can we make it part of my job description?"
I'd be cautious of directly measuring "assistance" outside of peer input in perf to avoid an unhealthy incentive. The most helpful people I've worked with in the past tend to grow through strong peer reviews and having the most opportunities to join new projects.
The OP here really misses the point of demonstrating impact. Doing the right thing ethically then for the business is a strategy that is, well, rarely the wrong thing. Optimizing just for getting promoted might is a greedy strategy that might get you promoted once, but good luck finding peers that want to work with you again.
Just talk like normal people. The more you talk openly about who's contributing and who's not the easier it becomes.
People who had a lot of "assists" at our company regularly brought in 1000+ points a month, which then translated in $100+ in amazon gift cards or steam points.
I think that's a better system, because one person may have 2 first author publications and 3 second author publications. Another person may have just 1 first author publication but 12 second author publications. So you can weigh and evaluate each person based on their assistance and contributions to others.
However, you need to strike a balance between helping out peers and having impactful projects.
It helped us discovering the importance of assists, so now we have support teams dedicated in assisting project teams.
Project-driven environment + no estimate or log = politics
Disclaimer: I work at Google.
Isn't that a metric?
The metric might be a good idea, but I think the real problem goes deeper than that.
Take a step back and ask yourself a more fundamental question: should everyone who does good work be promoted?
By definition, promotions are limited and each level is more difficult to attain than the last one. Obviously, you can't promote everyone. Even worse, not everyone will be happier when promoted. So why does literally everyone want to be promoted? Why do they work so hard to get it?
It's because there are no other ways of rewarding good work. And by "rewarding", I don't only mean "giving people recognition" or "giving people fun work". Those are important and should not be overlooked. Nevertheless, if you don't also give people money, sooner or later they'll fall behind their needs or just the rising costs of everything around them. Then they'll have to choose whether they need money more than intrinsic rewards. And then we're back to the original dilemma: do I play the promotion game or do I just bugger off somewhere where I can get what I need?
TL;DR: Retention shouldn't be only about promotion. Give people real rewards and incentives for doing a good job at their level.
That's not really the case if the promotion ladder is a skills/experience based ladder and not a responsibility ladder. If being a "senior engineer" just means you have reached a certain level of proficiency, then there's no reason everyone can't be promoted to that level.
Players will game the system, the mere fact that the game exists itself will change the overall dynamics, this and that everything is in constant, natural change, all makes it necessary to maintain the gaming rules.
You'll see patterns in the upvotes and downvotes. The upvotes might signal "This person helped me a lot." The downvotes can catch interpersonal problems that might otherwise be hidden from you. For instance, someone on your team might be guilty of sexual harassment, but they are clever about hiding it from you. Your only clue will be that, say for instance, all the women keep downvoting that person.
While I appreciate the goal, I have been put in such situations before and must say I hate such questionaires and ratings. Of course they are not anonymous. And if that is so, do I tell the truth or do I lie? I don't want to lie. But I also don't want to cause trouble for my coworkers because of some misunderstanding.
Admittedly, I don't have a better alternative though.
For example, when downvoting: flip a coin, if it comes up heads, downvote that person. If it comes up tails, only downvote that person if you think they deserve to be downvoted.
Doing it this way, each person can be expected to get roughly 50% of people downvoting them. If the number is enough higher than that, then that person probably deserves the downvotes, but you can't tell who they came from.
Track management only.
As a former manager, the closest I came was making a point to observe who was helping who within the team. And following up by asking people during their 1 on 1s if they felt anyone was being especially helpful to them, explained things well or not, etc.
People who helped their teammates very much got a boost in their prestige in my view, and that was good for additional job security or additional pay. If they struggled with a couple tasks, but had helped some teammates when they DID understand what to do, that very much increased my willingness to help them or give them extra time to figure things out.
Sounds like a super fun place to work. ;)
If you know ahead of time that you are doing "the dirty work", which usually you don't, do you know how long you are going to do it for, and if it makes sense to apply for a transfer?
Would your manager approve of your ladder transfer if he/she needs to back-fill your position when a good engineer is hard to find or keep to begin with? (Actually, there are scenarios where a manager wants to keep underperformers from transferring out, too)
Lastly, did you really want to be a Tools and Infrastructure engineer to begin with? It started with just being scrappy in order to get the project to a place where you can contribute shiny new features, which everyone is waiting for you to do, yourself included. If you transfer ladders, what are the chances you will be able transfer back in any reasonable amount of time to get credit for doing a good job on what you wanted to work on?
Michael's work situation seems prevalent through a Google-like org, and a ladder transfer is unlikely a realistic solution for that.
In a previous company we had a better mix of peer reviews and input from technical leads (that were not your bosses). This was by far the best system I've seen to date for a company of that size.
In small companies there is typically good visibility into what everyone is doing. If you have good management then things tend to work very well. If you have bad management it can be worse than large companies.
One thing I've come to learn is that this sort of stuff, call it culture, has to be a priority for the company's leadership, they have to keep inspecting it and fixing it. They need to talk to people and understand their concerns. Otherwise it always drifts the wrong way. The Google system from what I read here sounds terrible.
EDIT: Having people try to optimize to play the system, just like the article describes, is inevitable so you must ensure the incentives are aligned. Make sure you find ways to look at the stuff that really matters and make sure you're not antagonizing your employees with your review system.
It has slack integration so sending /yei @someone is super easy. I probably do it multiple times a day.
I have to say, after it was introduced, there definitely was a slight shift in culture.
I strongly believe your 10x programmers are the ones that help the whole team become 10x by building great tools and showing best practices that makes everyone move faster.
I busted my ass at a startup for years and also lost the political game. So I'm speaking from experience here.
You can either get all mad and worked up and pissed off about it, and waste years of your career (as I did) being pissed off, stubborn, and refusing to change. Or figure out how to play. I'd like to think there are places with better politics but I think it's pretty endemic of large organizations. I'd love to be proven wrong.
The thing is, "working for yourself" is so flawed in so many ways. In the first place, nobody "works for themself". You might work for customers, or clients, or whatever, but not "yourself". Second, you're a lot better off working at a good company -- MUCH better off -- unless you have a pretty damn concrete idea of what you're doing. In addition to the income, the big company will provide better networking, more credibility for anything you do subsequently (whether a new job, fundraising, hiring--ANYTHING), it's an all-around better gig.
I'm just trying to save you a lot of wasted years and time here. Take it or leave it.
Just to be pedantic, I'd say if you've got enough in savings to live without further work-based income & retire, then you are "working for yourself". You paid yourself via saving that money up to "work" on whatever you want. Even if it's just a tan & cirrhosis. :)
I disagree. There is a whole category of people who want high reward for their efforts. There exists no way to get high rewards or royalties outside of starting your own venture. The downside is the risk of course.
I do agree that you shouldn't be angry, but there are so many new ways to exist and survive these days.
My point is opportunity cost. Unless you have a very clear idea of what you want to do/build--which many people do--you're better off with a day job.
I see a lot of people essentially rage-quitting (let's be serious, that's what happened here) and then wasting years of their life working bottom-of-the-barrel contracting/crappy startup jobs because they "don't like big companies". I made this mistake and it's cost me enormously in money, time, and career development.
That's basically what I am doing for exactly those reasons. But I don't think my jobs are crappy.
I traded stupid amount of money for more freedom to choose what I work on. I don't want to be a monkey on a keyboard nor do I want to put with the bureaucracy of a big corporation.
Or am I getting it terribly wrong? My brief view of a large organization terrified me and I don't want to work in such a place. Are big places really that much better if I am basically paid the same amount of money?
I basically mess around writing software—something I like doing—for 6 hours a day, attend a few meetings, and every month somebody deposits a ludicrous amount of money into my bank account. And I'm not even working for one of the larger companies with correspondingly better salaries.
I'm certainly not going to become a cash millionaire off the back of it, but I'd wager that in aggregate the amount of investment one makes into a stable job at a large software company pays out more on average.
don't be so sure. invest 10-20% wisely and you may be one sooner than you think ;)
People routinely get paid £100k straight out of university to write code in London, just not in the tech scene. Total comp in the financial sector with 5 years experience is commonly £200k.
Which is not 'ludicrous' but more than you might imagine from seeing £40k job postings in the web dev sector.
Total comp of £200k/year is clearly possible but also just on the investment side (not writing software for support systems) and usually involves some risk (i.e. income is volatile). Finance easily pays 2x that of tech in London but only because tech doesn't pay very well. A lot of startups pay programmers not more than you'd get with any other office job which is clearly not comparable with the US.
A lot of software engineers fail to realize that at a corporate gig you get to focus on being a programmer. Once you move out on your own, you also take on the job of sales, accounting, HR, etc. Your next step is hiring people to handle those jobs but that moves you from writing software to being a manager. Running a business is a different set of skills from software engineering so be prepared to learn something new.
Yes, you might have customers to answer to, but you can always tell them to fuck off if you want.
You suffer the consequences and reap the rewards. Your actions, small or large, matter.
Yes, working for a corporation is safer and more stable. In the grand scheme of things, this is the risk-adverse, safe thing to do.
The OP may waste years of his life, or he may not. He may end up poorer than when he left or he may not.
You never know until you try. Take it or leave it.
In regards to rewards vs consequences, my point is that in a workplace you're abstracted away from the direct results of your actions (as OP mentions in his post).
You can be rewarded for other people's contributions (while having made no contributions of your own) and vice versa. When I worked in corporate, this lead me to experience a somewhat "wtf is the point" type of existential crisis.
When you're running your own shop, you have a much more "direct" relationship to your actions and the resulting outcomes. Not just in terms of costs and rewards, but also in terms of just seeing the direct "value" your actions provide. I mean think of all the countless cubicle jobs or professional services jobs where the sum of your productivity is basically meaningless, just random filler designed to keep the machine moving... (think of all the business consultants spending 80 hours week at the client site putting together decks that no one will read or remember in a few months)
It's the process overhead that most people complain about. Instead of adding value to the company, much of your time is spent on managing process for the sake of process.
For example, defining your work to maximize the chance of promotion may only correlate with company value.
My point is less applicable to freelancers with one/few customers and more directed towards operators that manage product/service oriented businesses with dozens/hundreds/thousands of customers.
> single client
You described the difference.
So it's all fit & personality.
It's similar to having FU money as an employee but on steroids.
This. But to take it further, you better be ready to hustle your ass off. Because you need to bring money in which means meeting new clients 24/7/365.
Good luck. It’s an impossible amount of work to do alone so hopefully you have a good network.
The "trick" is being socially skilled and interested in others, to get them to trust you with jobs that are large enough so you don't have to be constant lookout for new assignments. (I do not mean to imply that you lack social skills). I have a small client pond (50-75 contacts on first name basis) where I'm becoming the big dev fish and people have started sending referrals my way nowadays.
Your point about going it alone is valid - I chose to partner up because of the crazy amounts of context switching solo operations require.
The thing that had the biggest impact on my quality of life since I left the corporate world is the ability to say no.
A thread full of people talking about how bad working for yourself is had me questioning my upcoming decision to quit and try to do something for myself, and what you said is the biggest reason why I want to. I love hard work, but I don't love pointless work. I already do some low pay contracting on the side, but it's with a couple of small companies that trust me 100% so they never tell me "no". Don't get me wrong, they will question the hell out of my decisions and I've changed quite a few in response to the questions, but at the end of the day they trust me to do what's best for them.
I already have the house paid off, have no other debt, and have low 7 figures in reasonably liquid investments. Working for myself has been a dream of mine as long as I can remember. I don't need much money, just enough to get by.
Anyway sorry for the rambling. Just wanted to say thank you, you made me feel better about going into work today. Maybe I'll make today the last?
A lot of the book is simply explaining Psychology of people trying to gain power or in power what you need to do so you can manage politics. Things like not making your boss look lesser than you or not realizing that, yes, everyone has their place and you can't just say whatever you want AND ALSO get whatever you want. For a lot of people this needs to be explained and proven and the stories in that book provide good, if not a bit hard to relate, examples of the laws.
(Reading the book now on Audible. Pretty interesting, but the parent is totally right that it advocates a pretty dark/negative world view.)
My favorite book by him is The Art of Seduction, because it chronicles human motive in its most direct, unfiltered form. All influence is really thinly-veiled seduction.
To the grandparent, because I'm throttled on HN and probably won't be allowed to post much more, if this even goes through: the key to a successful career is the same as any other interpersonal success. Learn psychology and influence. Understand how other people see the world. However you see it, it's not how most other people see it. Resist the temptation to assume that your assumptions and defaults are valid for others.
You have to accept the existence of the game to really have success, but you don't necessarily have to embrace it. Indeed, many successful entrepreneurs are successful entrepreneurs because their personal tolerance for the game is sufficient to make sales, but not sufficient to suck up to a cadre of bosses for years on end.
Whatever you do, you will not be reasonably free until you get a baseline of "fuck you" money established and invested in a diverse set of safe, reliable instruments and institutions. Once this happens, take heed not to become too ostentatious and comfortable, or you will become Martin Shkreli; someone who didn't do anything actually wrong, but allowed himself to become the subject of the public's contempt. It is probably best to keep a low profile and live an unassuming lifestyle, grateful to be one of the few with freedom.
-----
P.S., tried to post, and yep, throttled. I can't post for some more time now; this is because I was politically imprudent and criticized YC darlings, including some companies they've invested in, on HN. I will save this and repost later.
Egalitarian facades from BigCo or PowerfulPerson are just that: a facade. And the people in power, no matter where their power lies, will be happy and cooperative as long as your conduct is biasing people in a direction that is favorable for them. But never expect them to sit idly by while you threaten or criticize them, even if the ultimate impact is small or indirect. They know that big collapses start out as small cracks, and they proactively and subtly work to stop these.
Never mistake the cooperation, praise, or accolades of a group or establishment as representing anything other than their satisfaction that your conduct is helpful to them in the immediate moment. One of the most common and simultaneously most fatal mistakes I see is the assumption that satisfaction with one's conduct is implicit or automatic. That past positive responses guarantee future positive responses. The truth is, no one cares about you personally. They like your thing because it gave them what they wanted. If you disregard that for your next thing, they will have no qualms whatsoever about dismissing or disregarding you.
Human response is a "hits business"; there is a formula that makes people happy. Meet that formula, and you will be rewarded. Deviate, and you won't. It is fickle, timing is important. Music, movies, and video games are all optimized "hits" businesses with billions of dollars at stake, and even they have misses more often than not.
Everyone is irrevocably and intrinsically self-interested, as a biologically-dictated matter of individual survival. Do not expect anything else. Do not try to fight this -- you can't. You cannot undo the eons of evolution that have dictated it. Good system design understands and incorporates this unchangeable reality by triggering psychological phenomena that are biologically interpreted as pro-survival when they're acting in concert with the system, and not doing so when they aren't.
Please note that despite the acknowledgment of this reality, this is not necessarily a nihilistic or pessimistic worldview. These things are not automatically bad. They are just components of the human psychological system that enables our survival. They can be used or abused, for good or for evil.
An insistence on remaining ignorant of human action and motive based on the religious tenet that "people are nice" only leaves one liable to more manipulation. That is exactly what the worst, most ravenous predators want, because it allows them to operate virtually undetected. All the better if they can get the duped to engage in a hostile charge against those who are finding enlightenment (and they usually can).
Anyone who wants to operate effectively within the system must know and understand it. Don't shy away from this reality. Accept it and use it for good. We have way too many timid people who have been programmed to take what they're given and shut up, and not to inquire into how the system works. It doesn't have to be that way.
If you start that from day 1 you'd be 2 years ahead of the author.
Honestly, it sounds like a really shitty way to live. I personally prefer doing great work and having faith that it will work out.
It has, a lot slower than that, but I'm proud of the work I've done and enjoy my work daily.
Of course, this only works if you have managers you feel like you can trust and respect in the first place.
But that doesn't mean you should be consistently selfless all the time. If you think the projects you are working on aren't going to get you promoted, discuss it with your manager. Tell them some of your thoughts, and if they aren't amenable to giving you other work, consider moving to a different part of the organization.
- Your impact on revenue (if you work in ads)
- Your impact on search quality (as assesed by independent raters)
- Etc.
My advice would be to try to come up with your own project ideas (related to what your or other very close team is already working on). Often times, people stick around in their teams for a long time and there is not much inovation -- you are a new guy can bring some fresh perspective.
People who get promoted the fastest are usually those who are self driven and start projects from their own initiative.
For example, if you see a problem, you should socialize a solution to that problem. If the feedback you get is "Yes, this is a problem, and that solution would be valuable", then go for it. Of the feedback is more meh in nature, then either convince people it is valuable or move on to something else.
Be organized in this process, write RFCs and design docs, document your conclusions. Then when it comes time to discuss impact, you will know (and can demonstrate) that you worked on impactful things.
Once you have experience as a manager you'll appreciate how great it is having a"can do" person like this on your team.
This is a philosophy you can wear comfortably too, as it's not based on sucking up.
If you have a decent boss, they'll make sure you share in the glory.
If you haven't, you'll need to move on to some of the darker arts.
My advice would be to just try to keep people happy, primarily your manager and your manager's manager. Some people are saying to focus on metrics that make you look good, and that might work at some places, but it won't mean people enjoy working with you.
My advice? Be honest, don't be scared to admit when you're at fault, solve problems, help people when you can. Networking is great, but don't be the guy who only BSes and doesn't get things done. You need to be someone people like to work with. If someone needs to send someone else to you for whatever reason and they say "Go check with popcat, he's awesome and knows this really well", that person is going to see you in a positive light from the get-go. Reputation is more valuable than any metrics can be.
Also, communicate with your manager often. Suggest improvements, mention problems, and ask for advice. Put yourself in their shoes - What you you want them to tell you if you we're the boss? Listen to podcasts like Manager Tools if you want to gain knowledge of large companies operate. It will be a huge help when trying to land a big raise or promotion.
Next thing you need to know is the rules of the game in YOUR organisation. Every company is different and the rules are different. Google is unique, so at other companies the game is very different.
Then you need to move the needle on whatever matters. That might be improving metrics, that might mean becoming drinking buddies with the right people, it might be purposefully going to work for a failing team so you can be given the chance to take it over and prove yourself.
Focus on demonstrable, measurable impact for your company's customers in the area that your team focuses on. If you do that, then you'll find that you're aligned with your boss and your boss's boss pretty much all the time.
You can argue for what you believe when you have data to back you up. If not, respect the judgment of your superiors. Figure out what your management chain wants to accomplish and then find the best measurable way to accomplish it. If you don't know. Ask.
Remember that the game is a long game. Software Development is unusual because many people expect to be "senior" 3-5 years out of college. In other fields, that will barely get you out of an apprenticeship.
I think about it this way:
1. Not all effort is equally valuable.
2. Not all value is equally visible/measureable
3. Not all value is equally aligned with your team/company's priorities
Find what efforts produce the most value that can be measured, in alignment with your company's priorities.
Usually when engineers feel like they have to "play the political game", they fall into one of these traps:
1. They are doing work that isn't actually valuable (e.g. an unprompted huge refactoring)
2. They are doing valuable work that is hard to measure (e.g. adding tests to a codebase without a plan to demonstrate improved developer velocity and/or product quality)
3. They are doing valuable, measurable work towards the wrong goals (e.g. building product-wide localization support without the company intending to localize their content)
The issue in Michael's case is not politics, and I don't know how HN gets on this stupid tangent about the "political game."
The issue--speaking as a Big Company engineer/manager--is quite obviously misalignment, either between Michael and his manager or between his manager and the committee.
If you don't know what your manager thinks is important or disagree with it, you have a problem. (Possible solutions: ask, argue, switch teams.) If your manager's priorities don't match the org's, you may also have a problem (depending on your manager's ability to protect you). (Again, possible solutions: discuss with your manager, discuss with your skip, move.)
The idea that there's a "political game" that you can play to get ahead is, mostly, belied by my experiences. It's probably true in some places some of the time, but it's unclear to me that it yields better results (faster promotion, greater happiness) than being smart and motivated.
nail on the head... so many people don't get this simple fact that if you DO NOT have clients, you DO NOT have a business. You can't ever "pay yourself", some outside entity have to pay you for your product.
If you're doing b2b, yes admittedly you work for clients, yet a client is still very different from a boss (he can't order you around or give you "performance evaluations", etc.)
BUT if you're doing b2c and selling something to many anonymous customers you don't interact with, you're truly working for yourself; that thing can be a piece of software, an object, a novel, etc.
In the last 14 months I switched to making physical products sold to end users (b2c) and it's great, but having clients wasn't that bad.
You also can't fire investors. Remember that before you go "work for yourself" and take seed money to do it.
Running a start-up can be a pretty good gig, too.
There's a third way. Don't go to Google. There are literally thousands of smaller places you can work for/in/with, some of them do pretty cool things. There'd be politics too, probably, but not as much as in Google, and you could control your destiny to a more significant degree. Small(er) companies - if you pick right - tend to have significantly better environment in that regard (not perfect, mind you, but better).
Or, if you want that specific experience and line in your resume, and of course all that sweet cash and stock, do it with the open eyes - don't expect it to be a fairy land where unicorns crap out rainbows, expect it to be a humongous bureaucratic corporation where you will get exactly your share of care and agency - the full 0.001%. Approach to it transactionally, know what you came for to get and what you are willing to pay for it, and if playing exhausting games is not part of it, get what you can for the price you're prepared to pay, and move on. Don't let the fact that you can't get some things for the price you're prepared to pay get to you and make you think you're somehow unworthy. If the price for getting title X in Google is behaving like you'd hate to behave, then you can't get title X at Google. So what, there are probably tons of things you can't get and always will be. Don't let it bother you too much.
If you're making 200k on your own terms vs 250 at Google, I wonder who's better off. At that level of income, things like how stressful your work is, how interested in it you are, the length of your commute, etc. seem to matter more than earning another 50k of income.
Obviously everyone has their own circumstances but I think the obsession with earning as much cash salary as possible seems a little myopic.
So it is a significant trade off.
Early retirement is almost always an option for middle-class or better Americans. It's just a question of how much pain you want to put up with in terms of housing, lifestyle, where you want to live, whether you want great education for your kids, etc.
I used to agree with your comment but don't anymore. I have enough money at this point to earn 10s of K/year investing in real estate or doing something else. I don't because I like working in tech, being part of a team, using my education and talents, and generally working on making the world a better place.
I don't really want to "do whatever I want".
These guys are right: https://signalvnoise.com/posts/1930-mojito-island-is-a-mirag...
Your middle-class also seems to be a bit different than my middle-class, especially in cities where jobs are.
List them. Especially the ones where you do not need to sudy for several algorithmic puzzles.
Wasn't my experience. Of course, YMMV.
> since you don't have clearly defined process of goals that lead to promotions and pay raises.
Looks like Google does have defined process. Did it help the OP? Doesn't seem so. Defined processes are good if they're defined with your goals in mind. If they are defined explicitly to prevent you from reaching your goals, they'd be only an impediment, and one that you'll fail to overcome, as "this is our defined process, we know it doesn't work in your particular case, but we can't start special-casing people, so you'll have to take one for the team here".
This applies to being a leader in a volunteer organization, or being a leader in an open source project --- or being a leader in a corporate environment. In my experience the last is often actually easier and simpler than the first two!
As far as your goals are concerned, you should be clear to yourself what they are. For me, it wasn't primarily about the money. Sure, I'm at Google now, and I'm enjoying the compensation --- but I spent nine years at MIT before I moved on to VA Linux Systems (and doubled my salary, before equity --- most of which ended up being worthless).
If you know what your goals and desires are, the next trick is to understand what others' goals and desires are, and trying to help them achieve their goals while also making yours a reality. This is true whether you are working for yourself, or working at a big company. (And at a big company, sometimes it's a matter of finding the right team. Don't assume that just because you had a lousy time on one team that the characteristics of your situation are universal across the entire company.)
No. Politics is when 1 among the 3 people, wants more than his share using all means possible.
Simply be realistic: the company will not be perfect, will not be accurate in assessing value, but it will not necessarily be evil about it. It will simply be imperfect, just like anyone else including yourself. There are always reasons why things work the way they do. The ability to understand and work with those reasons is a valuable skill that a CS program will not teach you.
Working at Google ruined my mental health. Granted, it hasn't been great to begin with, but being in SRE made my absolutely miserable. Every night, coming intellectually wasted and couldn't even work on my own project because of draconian IP clauses in my contract.
Quit half a year ago, went (back) into freelancing and I couldn't be happier. Don't care about the money or prestige anymore.
Is this standard Google policy?
Which is okay if you work on one personal project at a time, but breaks down if you hop from project to project with friends. Waste of everyone's time.
I believe it more resonates with the fact that your livelihood does not depend on a SINGLE SOURCE.
Sure, a business is responsible for it's clients (notice the plural here), and if some of them leave, it may lose profit, yet it does not completely goes under.
Whereas an employee is fully at the mercy of the employer.
The difference is, you don't have one boss... So your risk(s) are well diversified (or, at least better than if you're an employee).
If I employ a brick layer I can easily judge the quality and rate of their work, it's easy to compare with the guy I hired last week.
Contrast that to programming where there is no physical artefact, it's not like we can measure lines of code or numbers of files and derive some value, in most cases less lines of code is better.
People know this so instead of doing good work they start to play games to get ahead.
That's not to say a good leader can't fight against it but to think it's not there is naive.
I have personally worked at at least 2 companies now that I would describe as "non political." This was achieved by having small, well-defined teams. One company had extremely clear paths for promotion and raises, the other had no framework whatsoever. In each case, the culture was defined every day by a manager - company 1 was the sales division lead, company 2 is the CEO who sits several desks to my right.
I not only think it's possible to have a non-political system, I've lived it twice. I think cynicism is easy, and that's why people call folks like me "naive."
What can a higher-up do to prevent the political game?
Having one boss that can fire you sucks, having 100 clients that can fire you is fantastic (you can also fire them).
Now it is difficult to get to your necessary X number of clients (I'm 44 and on startup #8). But not having to deal with stupid inane bullshit incessantly while working is like winning the lottery.
My current full time employment is run like a middle school popularity contest. The company is so shittacular I don't think I've been at worse in my ~30 years of working. This is saying a lot as I've also worked in fast food, construction, healthcare, my own shitty startups, a MLM, among many others.
I don't really see what the political game is here that he lost. What I think he failed to do was show impact in a clear a visible way.
Don't get me wrong, there is salesmanship required here in terms of clearly demonstrating your value, but it's not like Google was giving the promo to some other guys who always went out to dinner with his boss and sucked up to him, or the guy the boss went to college with, or the guy who throws his team under the bus to make himself look good. that is politics, "politics" being defined as acts that make you look good but are detrimental behavior to the team and the company. And I think that's what google is trying to avoid with their promo panels where you get feedback from peer, peer team managers, and make the judgement as an impartial panel.
Also I see this as a manager failure. Clearly this manager isn't well calibrated, because he continues to get "strongly exceeds expectations" and yet can't get you the promotion you obviously deserve if you strongly exceed expectations. They also should be helping you both with your promo packet so that you're putting your best foot forward, and talking to you about how you can improve and demonstrate your value when you do your work to make sure you can get an even strong promotion packet the next time. Given this manager failure, I'm not surprised the employee quit.
As a manager it's your job to figure out what my impact is.
If you make it my job to show what my impact is I (and everyone else you are responsible for) will simply spend my time coming up with ever more creative ways of doing this instead of engineering.
But hey, maybe I'm being silly and your company has no problems finding competent engineers, all your projects ship on time and under budget etc. etc. etc.
But as to your point, on the roles and responsibilities of managers and engineers, I mostly agree with your comment about the role of a manager, which as I said before should be responsible for working with the engineer both to show their impact, but also making sure they're actually doing impactful work.
I disagree that if it's your job as an engineer to show what your impact is that you'll come up with creative ways of doing this. You can try to come up with creative ways of showing impact, and maybe a promotion panel will agree with you, but maybe they won't and you'll be left without recognition (I've seen this happen before).
To your last comment about competent engineers, I don't know what company you work at, but at mine, shipping projects on time, and under budget, especially when they are large in scope and involve complex technologies or large teams that you've led, and especially when those projects have impact on the company's bottom line, those project are considered major impact and and those engineers are amply rewarded.
Wasn't the point of the article that the Grunt work that has to be done and makes things better for everyone in the future isn't rewarded at all? That work may have an impact on the bottom line of the company, but be spread out over years of maintenance and prevented (potentially disastrous) bugs. However, as the author states, it's almost impossible to quantify that.
You cannot tell your selection committee 'I refactored code and that'll save us probably 100 bugs in the next year, times 2 hours per bug, at $300 per man hour, a $60000 savings.'.
Whereas it's easy to tell them 'I built a new feature x, in the past 10 weeks it's been running it's improved sales by 3%, leading to increased profits over the next year of $60000'.
Both 'earned' the company the exact same amount of money, but the first one is much more speculative.
You make an interesting point, and I'd like to suggest an alternative lens to view it from, as a thought experiment. Let's say company X values work that benefits company X, and that's why they hired you and pay your salary. You've given two examples of promotion rationale, one in which you clearly and objectively demonstrated the impact of the work. And the other, speculative, as you say. Now speculative implies not necessarily real -- it's possible that your guess about how much it will probably save could turn out to be wrong. If you don't have a way to measure this, how do you know that it's the case? It feels good to refactor the code, but just consider for a moment the possibility that you could travel through time and see the future results of current behavior. What if you fast-forward and discover that refactoring that code had no benefit? Now return to the current time: is it actually worth doing? If you're spending time refactoring that code at the expense of developing the feature? Maybe this is why company X prefers to promote people based on actual impact rather than speculation.
Perhaps another solution here is to look for ways to measure the impact of that refactoring. Surely your bugs go through some kind of bug tracker, and you would be able to count the before and the after? Is there no line on no graph anywhere that shows an improvement attributable to the refactoring? Can peers at least speak to how crappy the code was before and how much easier it is to work with now? Perhaps the new employee got up to speed in record time because of it? If, at the end of the day, there's absolutely no way to show that this work was valuable, then perhaps... and here's the part we don't like to think about as engineers... perhaps it wasn't all that valuable. Here's the part we like to think about even worse: you could spend 6 months of your career working really hard on something that turns out to be a dud. And it may be entirely rational that you don't get a promotion on the back of that work.
I'm not saying this is how Google works, or describing any particular situation, but I find it valuable to consider different points of view.
If all features were equal, like widget production, we'd definitely be able to prove or disprove the productivity boost, but I haven't ever worked in a context where this is the case. There's no guarantee that feature implementation time will go down, maybe it did just not go up as much as it would otherwise, maybe people manage to make more useful features in the future, or at least not as much less useful as they would have been (we would expect utility/feature to go down as a system matures)
When I worked in a two-person team it was easier, of course, the time I spent on improving the code base I soon got back when I had to implement new functionality on a short deadline, this reflected well on me in performance reviews. The problem in a larger team is that it might be someone else who is able to implement a feature quickly due to my improvements.
My guess is that we should be lucky that there are guys like the OP who naively spend time on "low impact" code improvements even though they might not reap the rewards. Without them we would only have people doing the bare minimum to implement new features with a big ball of spaghetti as a result, where projects are abandoned just because no one is willing to maintain them any more. (does this sound like some company we know?)
I guess what I'm describing is that we might end up with a prisoners dilemma situation, where optimising for short term measurability represents defection.
You can't? Especially if you have documentation of the bugs that were previously happening, this is very solid evidence. Another one I've seen, "This would cause a weekly page a 2 am, and half the time ended up being an all day problem that needed to be put out. This no longer happens and is worth $X of engineering time."
I would agree though that second example "built a feature that saved $60000" is a stronger statement because it's so much more quantifiable to the businesses bottom line.
To go back to my original point though, we all (not just managers, but the entire team) should constantly be pushing to get ourselves to objective measure. The more subjective measures are used ("I refactored this code which is now easier to read") the more you allow the bad politics I outlined earlier where a boss and his buddy team up to get raises. It's very toxic and should be avoided at all costs.
SWE did good work, got passed over for promotion several times, got mad and quits cushy software job to freelance. Everyone sympathizes because everyone thinks they do promotion-worthy work.
I can relate to this. I became bitter and angry when I did not get promoted several times and was told that the company expects "more". I became a person I am not proud of.
My question is how does one extricate onself from such a bad place?
What makes so sure? Have you started your own thing? Glad to hear about your story/lessons learned.
I too was hoping for a senior level promotion. The last project I worked on, I was the only non-senior level developer in a team of 5. I went out of my way to ensure we released a well designed, built and tested system on time. At times I felt like I was committing more to the project than any of my more senior comrades. Come release time, I even saw one of the design decisions I had insisted on save us from down-time. All of this I was sure would lead me to the desired promotion.
Come performance review time, I was rated at the top performance tier, as I had the past couple of years. Unfortunately however, I was informed not enough time had passed since my last level increase, but I was sure to get it if I kept it up for another 1-2 years.
It's hard to describe the feeling of defeat I felt at that point. I resigned and left within the next few months. What I found most off putting, was when meeting my skip-manager (your managers manager) for the first time during my exit interview, all doors for a senior level promotion were suddenly open, to incentivise me to stay. Doesn't feel great when negotiations with your employer are comparable to those had with your cable provider.
Wow, that's one hell of a way to look at things. Thanks for that perspective.
I always got frustrated with counter-offers upon resignation, as it’s the most vivid “yeah we could definitely have paid you this because you’re worth it, but only if we know you’re really mad”
This is a huge issue... You should have more actively met with them.
Undoubtedly there are places where this is not the case, but in any workplace where politics have taken over skipping the hiearchy leads to nothing but political warfare
To be sure I'm not downplaying your commentary. It's extremely illuminative and very well written. After almost 20 years in the industry I've learned the burning truth of it all, though. Loyalty to individuals is worthwhile. Loyalty to companies is meaningless. Be earnest and caring in your interactions with individual coworkers but feel nothing as you squeeze every drop you can out of the company because that's exactly what they're trying to do to you.
Cause that's a shitty thing to do. And, as shown, it leads to people leaving.
EDIT: Note I said "companies like this". There are clearly companies that are run at the top by compassionate, non-shitty people and those values filter down through the org. However, as companies get larger and especially once they are beholden to investors and ESPECIALLY when they are beholden to public investors that seems to die a gradual death.
In fact, it took me another couple of years, and witnessing that the grass is no greener in the startup world, to finally come to this conclusion.
Even though I have come to terms with this, I have not really been able to completely adapt yet. Which is why, again much like the author, I have currently landed on working for myself. I do miss working on more ambitious projects with bigger teams, that a job like that enables, but for now, I have no interest in playing the game to achieve my career goals.
If you're already putting in as much as the senior folk without being one the company has no upside in offering a promotion with the exception of employee retention/reducing employee turnover, so it is fitting that they'd offer it when you are about to leave.
Did you meet anyone who had taken that option? I thought it was commonly viewed a bad idea to take a counter offer, since most companies will lay you off or never promote you again due to perceived disloyalty?
I too would be interested in knowing if that has actually worked out for anyone long term.
* I didn't actively seek out employment elsewhere. A place I'd interviewed at and turned down in the past contacted me again after they'd finished a large fundraising round. They had a new office, and I was curious just to see how they'd progressed. The whole thing happened fast and they ended up offering me a 50% raise.
* I preferred my current workplace in basically every way except for money.
* I had a great relationship with my boss, who also held a lot of power in the company.
* I wasn't really "just another" developer at the company but was doing some pretty important work.
They matched the offer (exceeded it, really), I took the counteroffer and stayed, and two years later I've been promoted two levels and given multiple further raises and bonuses.
IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine.
So certainly "can fix bugs and write docs and tests" isn't sufficient for that promotion. A junior engineer and a manager who is at least partially paying attention can get that done.
I also don't really disagree with the evaluation that 6 months of Senior level work isn't enough for a promotion, especially if nothing actually shipped.
I get that constant reorgs are frustrating. That alone is enough of a reason to not work at Google or another BigCo. That's the real problem here.
... > Senior Engr. > Staff Engr. > Sr. Staff Engr. > Principal Engr. > Sr. Principal Engr. > Distinguished Engr.
Indeed you can become a senior fellow at Google, but you aren't expected to. You are however expected to hit senior at some point in your career. There's no requirement to grow further, so the bar for senior is high.
Well there's your problem. If fixing those bugs isn't aligned with the priorities of upper management then you are either working on unimportant bugs or your org is screwed. You going rogue certainly isn't the solution.
I see this a lot. Developers place their priorities and biases over actual business direction. And then feel shocked when they are told their contributions weren't impactful. I've shipped enough dead code that nobody really used but it checked a box on a sales call to know that quality software isn't always what we're selling.
In that case, developers are expected to read between the lines, which is quite an antipattern in doing business with any company. If you're essentially being lied to, the deal can only get worse from there.
Developers having a level of autonomy to address problems is what you consider "going rogue"? I guess it looks that way if I squint, but if developers can't decide on their own to address problems, that's not somewhere anyone should want to work. I wouldn't even want to be the slavedriver who sees their developers who are solving legitimate problems as escaping the plantation. A good manager should, rather than see this behavior as rogue, try to work it in to the existing process. A healthy development cycle should allow developers to allot a level of time or effort to address issues, and even junior developers can know better what needs to be addressed than someone who hardly touches the code.
You're right, going rogue isn't the solution; it's a sign that leaving the organization may be the solution.
There is a balance between the developer's priorities and that of the business. A business that doesn't care about a developer's judgment is totally myopic and self-deluded into thinking that it knows best about the nuanced facets of its operation. Concurrently, developers have been paid to do a job, and if they divert too much from what that job is, that can be doing wrong to the hand that's feeding them. Yet, if they are being set up to fail by the company(e.g. insufficient time allotted to maintenance), they are faced with the choice to "go rogue" in an attempt to save themselves and perhaps the company if they can see a rude awakening up ahead. As much as you may see this as transgression, this kind of situation is ultimately set up by the employer and they are solely responsible. We're not talking about employees doing their own side projects on the company time; they may literally be trying to save the company from itself.
Employees are going to going to exert some form of autonomy even when it's not granted to them. Those who are in positions of power can choose to harness that initiative instead of viewing it as a threat.
The lack of metrics is a problem. But the bigger problem is the interesting non-maintence-mode projects went from 0 to somewhere, or from 7 to 8 and a bit features' and that's a lot 'cooler'/'bottom-line demonstrable' than 'I made the thing break less often and less breakable and more understandable'.
It also says something that Google isn't measuring itself very well, although this is one anecdotal data point, I'm sure it's not the only one with the 'defrag' reference, relocation/churn etc. etc.
I also take issue with your documentation reference. The existing lack of documentation was probably caused by other Senior Software Engineers?
When we don't value docs and bug fixing, we create undocumented and buggy code. When we don't value it by relegating it to junior developers, we miss opportunities to mentor others by both explaining the system at a high level and also using failures as teachable moments at the line level.
A Senior developer who shows understanding of multiple systems at a high level (making docs) in an organization as well as being able to understand and deconstruct the work of others (fixing bugs) consistently is qualified for a higher level role where they work across multiple teams of developers.
The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
In some cases, the biggest problem is building and launching something shiny and impressive. In other cases, the biggest problem is fixing bugs. Refactoring complex/unstable systems to make them more simple/reliable. Figuring out the things that no one knows, and writing clear documentation for it so that no one will need to be blind again.
The sign of a good leader is correctly identifying the right thing to work on, and then getting it done, regardless of how "menial" it may seem. A culture where people are only recognized for working on shiny things, leads to organizational clusterfucks like Google's hangouts/allo/duo fiasco.
Yeah, right.
People who hold the current power will never let you do it. For one simple reason. No one likes to be promoting their next boss.
In fact in most companies merely talking about 'biggest problems plaguing an organization' can get you fired. No likes to be told that the current bosses aren't up-to their job.
Organizations that wish to be successful are designed so that you can't promote your next boss. Engineers and management are different things. Engineers can be promoted and do impactful work and identify problems and get promoted some more, without ever threatening to become anyone's boss.
Then, your engineers can be rated based on how well they solve engineering problems, and management can be rated based on how well they manage human capital and allocate between the various engineering problems that need to be solved. Certainly there's some politicking based on prioritization, but that's not a bad thing. You don't want to accidently solve problems that no one really needs solved, its a waste of time.
Sure shitty organizations exist. That doesn't mean organizations are always shitty.
At my current position I have been hired to help rewrite an application and I was literally taken aside and talked to for saying, verbatim, that "the application was built for business needs that no longer exist, and we need to update it for our current requirements", because it upset people by implying that the code they wrote 5 years ago was no longer perfect.
It seems like any organization that grows beyond 2 layers of management turns into an organization that spends the majority of it's time posturing rather than attempting to get anything done
You're missing the crucial step of advocating for these problems to be solved. Until you know this is actually something important to the organization, you're just scratching your own itch.
In OPs example, did it really matter that the data was occasionally bad? Quite often analytics exist to check a box in a sales pitch, but nobody actually looks at them. OP couldn't quantify this impact for the promotion committee because they likely didn't quantify it for anyone but themselves.
Ok. Let some apps choke to death. Once it dies, you'll have your response to "Did it really matter"
I worked on one such app. It was lost in the cross fire, I was asked to try to fix a bug. I came back and said this wasn't a bug, it was a badly built system. If they wanted me to work on it, I'd need a few sprints dedicated to it. They passed. A month or two later, it was impacting some crucial flows. We revisited it and funded it. I AB tested the rewrite against the original and saw a statistically significant improvement in user behavior. We retired the original, I presented my findings to our product team. They agreed it was impactful.
I think there needs to be some recognition for people who saw that there was a real need for some grunt work, and the business was suffering because of it, and went and did the work. The key part about this that I would consider "senior" is being able to look at everything that is going on and figure out what is actually critical.
Without knowing this is actually detrimental to the org, I don't find this to be a problem in and of itself.
> there was a real need for some grunt work, and the business was suffering because of it
I would expect a Senior Engineer to be able to advocate and justify this grunt work.
> The key part about this that I would consider "senior" is being able to look at everything that is going on and figure out what is actually critical.
"Actually" is the operating word here. This requires external validation. If you feel you've saved the company but can't convince anyone of it, then you probably didn't save the company.
- Expanding on op here, senior software engineer isn't one who is doing more junior work: It is pretty much a different job profile. You are making higher order decisions.
- Promotions come with a lot of timing as well: Honestly talent evens out after a bit and luck/timing/inter-personal skills tend to take over. I have seen excellent code bases that nobody cared about. I have seen a lot of pretty crap code generate billions of dollars (and trickle down to the devs as money/levels).
- Re: Reorgs: life is mostly unfair. I heard this in an ad and it stuck, 'we lose more than we win'. I am surprised you stuck with that manager/team for that long though. Career is a lot about making the right bets in terms of companies / managers / teams as well. I have had reorgs affect me negatively and positively (they shutdown the project and promoted me anyway - a long time ago in ms), so there might be some survivorship bias here. I guess I do try to project every situation into what the protagonist could've done better instead of sympathizing :/.
In an ideal world, we will have people who can grow (and make more money / level etc) in both dimensions: Vertically in terms of responsibilities and horizontally in terms of quantity of same level work / team dynamics etc. In practice we have a system pretty much everywhere where growth is defined solely vertical. This leads to a ton of actual problems too: You get a person really really good at coding / execution but shit in big picture thinking / broad system design choices / cross team work etc. spend a bunch of time in a level. Now you have to either promote him into a spot where s/he will fail OR lose em to attrition. Either choice tends to break.
A quick note since I have seen some people change / grow / learn in these unsuitable positions against odds: All these actions have a probability function in they way they work out. so take my points here about eventualities of various promos with a pinch of salt. Some do end up working out and these anecdotal statements obviously don't apply there. I do know whenever we choose to push / recommend a promo, we definitely are hoping for it to work out though :)
I hate this issue, and see it occur in so many companies. Why are we so opposed to simply paying more/increasing benefits of people at the same level? Why can't an "regular" Engineer just get a large raise for being an amazing Engineer, because that's what you need! Instead, they need to be come a "Senior" Engineer who also has some kind of other management-type job that they suck at.
“OK So I guess I need to leave.”
“Why oh why can’t we retain our talent????”
So ridiculous. You need an IC career track that is rewarding and achievable.
1: yes, they actually pointed to a physical book that described some industry standard of what software engineers must be paid.
One off large stock grants. Enough to keep your pay ‘up’ above your band for a few years
It doesn't take a senior engineer to fix a bug, but I believe that it is a senior-level skill to be able to identify subtle bugs and pick which ones to fix.
The current situation creates perverse incentives because nobody wants to fix bugs, and everyone suffers for it. The team executes slowly because everyone has to wade through dead code, undocumented code, buggy other components. Time you invest in fixing things would probably be a net savings for your team/Google, but are probably not a net savings for you personally.
I adopt the Joel Spolsky measure of a developer as someone who is "smart and gets things done." I think a good reward system should incentivize picking the right tasks and making high-value contributions to the team, regardless of whether a lower-level employee could have theoretically done the work if it was specified and assigned to them.
Everyone calls it out as playing politics, but really it's just metric driven career development. If you can't/don't measure it, how do you know it improved? How do you know there was a gap in company value to start with?
At a certain level promotion is not about just doing something well. Funnily enough, his plans now are to go do other things (presumably well) without a particular sense of direction and hope that it works out.
If you word it that way, it sounds incredibly easy. Actually, what that person did was identify problems in legacy software, reverse engineer them (a hard thing), document them (reduces maintenance/extension costs), and fix problems. A company Google's size will be making most of its revenue on legacy systems that constantly need extension, repair, and refactoring. They'll sometimes do something clean-slate but improving legacy stuff is a high-impact skill.
So, a mix of hard and useful work on numerous legacy systems that can be used to improve revenue-producing systems does sound like it merits some senior, software engineers. Heck, at a lot of companies, there's always senior software engineers guiding people through legacy projects just out of fear of breaking mission-critical systems. Usually a mix of a knowledgeable veteran and some junior coders for grunt work. Whereas, making new features on well-documented, well-tested systems is so easy in comparison that it surprises me that this alone can get people into senior positions if evaluations are done right.
They have since backpedaled on that, and now it's not an expectation. But you can imagine what kind of frustration this can lead to if you're continually passed up for promo to that level.
That depends on difficulty and complexity of bugs you are fixing.
You fit the profile of what Reid calls the "Smart but Stationary Manager" - a guy who is a lot smarter than a lot of the people who do get promoted, but who doesn't optimize for the right factors. Reid's point is that a lot of these guys get habitually overlooked as they optimize for the success of the company, rather than themselves, and assume they will be evaluated on their work alone.
The idea that when you go to work, you are there first and foremost to work on your own career development (rather than the goals of the company) crops up again and again. Even in failing companies, you see people make spectactular career gains.
https://www.amazon.co.uk/Stealing-Corner-Office-Strategies-B...
A month after I left to become a remote employee by boss called and said my salary raised 20K. No title change, just plain old doing what I wanted to do.
That, of course, is not the truth everywhere, but anecdotally it's a lot truer than most people complaining about other people sucking up thinks it is.
If fixing bugs in the data pipeline is indeed valuable to the company, you can explain to the promotion panel how (after all, you convinced yourself).
Before - make sure 3-5 key people know that you're working on something cool and are bought in
During - make sure any potential disrupters know about your work and see it as important (also minimizing the chances of someone crushing the project halfway through)
After - making a case to your line manager / promotion committee so it gets the rewards it deserved.
Otherwise, you've got a strategy for doing work that you personally may find rewarding, but which is unlikely to result in the career gains you want.
The important point is that helping the company and being promoted are not necessarily correlated and may in fact be orthogonal.
Yes, perf is garbage and management is chaos, but let's be honest with ourselves. Four years' worth of GSUs oughta be enough for anybody.
"Devoted employee" followed by "expert at gaming the perf system" followed by "project cancelled and adrift" is, sadly, the normal progression for a Googler, from what I've seen.
Stock compensation in the form of actual shares (not options) that vest over some time period.
Thanks a lot for the clarification!
No. Not even close. There's a reason it's called golden handcuffs. It all depends on where you are in life. If you have a mortgage, it won't be enough depending on the house you have. If you don't have a house, you will have a lot of FOMO. Big time.
It's all about pscyhology - you need exactly 0$ if you are dedicated and don't have dependencies. Ok, let's say just couple thousand for a room and food.
And the best thing to do after leaving a job at Google is to move somewhere cheaper!
"$640K in GSU over 4 years ought o be enough for anybody"
That's actually the ballpark for a senior engineer.
If author wanted to express this opinion I completely agree.
I can't say why it worked only for one of us.
Google managers might not be the ones doing the promotion, but a good one can help you get there
The author of the blog post was going for senior (L5), which you can't get just by maintaining code.
I think a piece working against me with the pipeline was that it was kind of an oddball part of the company. The clients of the pipeline were all external researchers and the data was all free, so I couldn't point to increased sales and the clients couldn't write me recommendations for promo.
I think I would have had better chances if my clients were other internal teams who could say, "Yes, this pipeline is much more stable now."
I think you answered your question. You had a metric that was tied to value for the business.
Promotion at Google is a process filled with selfishness and dishonesty and I think hackers need to know about this. The promotion committees are a joke. They typically have no idea about your product, your team, your quality of contribution and whether what you're telling them in the promo package is true or a lie.
The way promotion works at Google is actually a direct consequence of their desire to "empower" the engineers and keep managers in a rather passive, supervisory role. The assumption behind it (completely misguided IMO) is that engineers will "figure it out" on their own and "handle things among themselves" just fine.
The big problem with this is that it strongly incentivizes the kind of anti-social behavior that's normally associated with Wall Street: dishonesty, short-term thinking, greed, narcissism.
To the promotion committee, my teammate’s project was the big, important work that demanded coordination from multiple developers. If they hornswoggled me into helping them, it’s evidence of their strong leadership qualities.
That's exactly right. Manipulating your coworkers to your own advantage is the fastest route to promotion at Google. Lying about your contribution to things would be the runner-up. This is simply because there's a lack of authorities who could see, recognize and penalize such behavior.
I never understood why Google favored this over a good old proven management model where your boss would handle things.
I know I may be the exception but I actually value having a boss who's got things under control and looks after the team, as opposed to a lord-of-the-flies type situation where the promotion goes to the biggest liars and manipulators.
Source: I worked at Google as a SWE
Then I worked in a place where I had actually good middle management. They were smart and capable. They supported our team and helped us succeed. They shielded us from most of the political BS. They advocated for us to other elements of the business. They invested, both time and money, in our professional development.
To make it concrete: in a company where the other engineering teams (five or six of them) were consistently experiencing churn, having morale problems, and shipping buggy code six months late, our team had zero turnover, a shrinking bug backlog, and consistently delivered things _ahead_ of schedule.
I'm 100% on board with the good old proven management model now. You just need to have an actually good manager.
So when people get frustrated with shitty management, they turn to whatever other idea,.
If people read and __actually implemented__ the stuff in Peopleware (or any other classic SWE management book that's highly regarded) we'd all be better off. But instead we're stuck in this equilibrium where we constantly chase management trends (see: open offices which are consistently shown to be nefarious for productivity).
Lol, I feel like that's too much to ask. I'd be happy with management that actually read Brooks instead of just pretending like they did.
I almost always interview my immediate management chain (immediate manager and boss of my immediate manager) before taking a job.
But then you're back to the initial problem they're trying to solve, which is that some person will get a manager who's way too friendly and promotes too many people, while some other poor soul gets stuck with a harsher manager than never promotes anyone. In short, it's hard to enforce consistency across a company that large.
There's always the route of complaining to your boss' boss. But I guess then Google would actually have to start to give a s#!t about their managers actually performing proper managing tasks. I can imagine though that VPs and their C-level would consider such mundane affairs to be far below Google's aspirations...
VPs don't know who you are by default, they have too many reports. And if you're assigned unsexy work like keeping the trains running, well the better you do your job ironically the more you become like wallpaper.
I'm not saying you have to be a kissa*, although that does work at a remarkable number of companies, I'm saying you have to make yourself known to a person with power. Otherwise you're just a name and easy to reject.
You want to believe in meritocracy but in my experience the correlation between effectiveness and promotions is weak to nonexistent. If you want to get promoted -- besides doing a good job (and sometimes not even then) -- the reality is you probably have to market yourself upwards.
The OP complains about not having enough metrics in his assignments but do committees promote people based on stone-cold, anonymous metrics? I'm guessing a lot of it is how they 'feel' about someone.
But these days as a developer the sad reality is you probably need to switch jobs every 3-5 years if you want to keep moving upwards, unless you're really lucky.
So I'd like to propose a new slang term, "kissa"...
The answer, from what I gather, is yes. The hiring / promotion committees are essentially an anonymous collection of fellow engineers, perhaps a step higher than you, but somewhat random in composition. As such, there is no reliable way to grease hands or build meaningful relationships with the wide range of people who might be on your committee.
The larger problem OP faces is simple: his senior engineer projects are not being protected by his manager. And possibly sabotaged indirectly by executives above. In that sense, he does need an executive sponsor, simply to protect the project assignments he needs to build his stone cold anonymous metrics case.
You only need that person's recommendation, not that of 15 random fellow engineers.
Besides, your data 'proving' your value likely has no context or comparable benchmarks, after 30 seconds of numbers it's straight to your soft skills.
But yes, agree with your second point that it's up to the manager to protect his projects or champion his employees.
The good news is that, based on reports from Googlers here, it sounds like the system is changing for the lower promotion tiers.
It's not about 'overriding' the committee, it's about having a champion on the inside.
You seem to believe there's no human element to this process. It's all number crunching -- like they're picking stocks with a good P/E ratio.
But the higher up you go the more your people skills are valued and none of that will show up in data. Guarantee you nebulous categories like 'personality' and 'fit' are bandied about frequently in these discussions.
If promotions were strictly numerical as you seem to believe then they'd be more meritocratic, but I believe the OP's point was he felt the process was unfair.
> But the higher up you go the more your people skills are valued and none of that will show up in data. Guarantee you nebulous categories like 'personality' and 'fit' are bandied about frequently in these discussions.
Remember we're talking about promoting an engineer to a higher level engineer, not into management. I don't know panels discuss, but given the odds are that nobody on the panel knows anything about you other than whats in the committee packet, it seems at least possible that soft skills are not considered.
> If promotions were strictly numerical as you seem to believe then they'd be more meritocratic, but I believe the OP's point was he felt the process was unfair.
I'm not sure about that. My reading is that the OP left because the committee was saw themselves as numerical, but ended up being pathologically and myopically so. The metrics they see are the ones that can be calculated, often easily. Getting dinged for finding more bugs than you fixed in legacy software, when they mistake known bug counts for actual bug counts. Treating unquantifiable results like unreleased software as invalid. Ignoring necessary but difficult results to quantify like interviewing candidates, documenting code, and writing test suites.
Such a pathology can't be solved by knowing the right people, especially not when the system is designed to prevent this exact technique. The senior executive's ear OP needed wasn't one on the promo committee, it was the one(s) reassigning his team projects every quarter. Or barring that, one at another company.
At most of the companies I've worked, if a VP or senior exec likes you they make it known to the committee or a key person on it.
This just comes from my personal experience working at large companies. It's also true of just getting something done: usually the most efficient way is contacting a VP (or relevant executive) who can move things. I've wasted years of my life trying to wade through bureaucracy.
> Remember we're talking about promoting an engineer to a higher level engineer, not into management.
You don't need to be in management for your people skills to matter. If you're a senior engineer / team lead / whatever, you're seen as authority, an expert, someone consulted for wisdom. If you're hostile or rude it reflects badly on the company, hence these committees look at your people skills.
> it seems at least possible that soft skills are not considered.
I can't speak for Google explicitly but I can say your soft skills are always considered. Always. They consider them when they hire you and most places absolutely place a premium on them when promoting.
It's one of the reasons the requirements for promotions are so ill-defined everywhere. It's not just a concrete list of achievements, it's how your coworkers and manager view your personality.
> but ended up being pathologically and myopically
Yep -- politics. That's unfortunately how it works. You can assume it was an aberrant anomaly, in my experience politics rules the roost when promotions are being doled out.
> The senior executive's ear OP needed wasn't one on the promo committee
The senior executive wouldn't be on the committee, he or she would put in a good word for you.
Look, you don't have to take my word for it. If you know any senior HR people at your company or other companies, ask them how promotions are handled. It won't be uniform but I'm guessing politics, reputation and soft skills are most of the time (unfortunately) going to outweigh programming metrics.
/my two cents
Like, half of OP's blog post is about how Google specifically is not most of the companies you've worked for. Your advice would be useful virtually anywhere else, and were the subject anywhere else I would likely agree. However, in this specific case, "Look kids, this is just how the business world works" is poor advice and treats industry as homogeneous, despite your statement to the contrary.
Google's insanely profitable market position allows them to be wronger for longer on many things, ranging from server design to management practices. There was a time in which Larry Page fired all project managers, and I've seen no accounts saying 'This was a triumph -- huge success.' So if the rest of society has converged on a solution where management should be in charge of level promotions, this doesn't mean Google has adopted this (likely efficient) method.
Which is the point of this article: a warning to those that would fill his empty seat, that social norms, rules and processes are vastly different than you expect, and may persist despite not working in anyone's favor.
But no matter how much of unicorn they are I'm guessing human nature still applies. I think the OP will see that Google, despite its attempts at meritocracy, is probably a lot like other places in that you have to market yourself upwards, and probably to someone who can help.
"Facebook will give me a sr software engineer position after 5 hours of interviews, here is that offer letter" is a very strong position. Market dynamics are a lot faster than internal promo dynamics at bigco.
Once you reach sr although, you usually have to go through the promo game from what I can see. Most companies do not hire staff engineers unless your already staff engineer somewhere else at another bigco. This is why people tend to become manager after this point, because you see its more effort to become a staff engineer than it is to become a 'sr manager', which is about equivalent to a staff engineer. People also become a manager for the learning experience. Understanding 'the other side' can be quite enlightening.
Previously it used to be, as Michael says, very much in the hands of the committee members who never heard about you or even your team.
Now the committee will be composed of your manager and some other two managers from a related team. The committee will not see your own promotion rationale or your own description of your projects and achievements, rather it will be the job of your manager to present these points and advocate on your behalf. The committee (except for your manager) will also see only limited peer feedback compared to before -- no free form text, only multiple choice questions/answers.
If all three managers agree that you meet the bar, you get promoted.
The point being, it's much easier for me to manage the relationship with my manager than with some anonymous committee that doesn't even know me. The manager is already important enough that I would not keep him if he seemed more interested in personal agendas than his subordinates.
I also started off in a corporation, it wasn’t google but it was a large organization where politics played a major role in one’s carreer. I had a very good friend, an architect who worked there for over 10 years, he was excellent in corporate politics and taught me a whole lot about it. The bottom line is that unless you have metrics to back up your claims (whatever they are), your claims mean nothing. Unfortunately, corporate culture encourages this kind of selfish attitude, where in order to get promoted you have to lick asses heavily, and the rest is just a background noise, even your performance. If you know the right people and if you have a good realtionship with them (also, if you are ‘famous’ within the company), then you will almost certainly succeed. This is how it works, almost everywhere, not just corporate environments.
It may appear that the author recklessly quit Google without having another job or even idea for a business, and I did the same thing, I had to leave, because I simply couldn’t bear the fact that I was doing better (this, obviously, is subjective) than people 2-3 levels above and my promotion was put on hold just because there were corporate rules that forbid promoting employees that have been already promoted once within 2 years time period. When I informed my manager that I am leaving, he almost panicked, as he did not see that coming and they heavily relied on my experience and skills. They offered me a promotion and over 90% raise but I simply did not care anymore, I could not work there any longer. I also quit without having another job on the horizon. As a consequence my depression and insomnia almost disappeared, I am less nervous and feel generally a lot better. Do not judge the author for leaving Google, he did the right thing for himself, even though it exposes him to a serious risk.
What this should tell you is that they indeed could have easily promoted you and given you a raise but deliberately chose not to because they bet you’d work for below market. Only when they realized they were wrong did they suddenly admit they could treat you fairly. You made the right decision clearly.
You've also recognized why upper management, particularly execs, are more likely to be sociopaths (or at the very least, admittedly selfish).
And fortunately you've come to understand that being the boss/owner is the best way to make your hard work actually pay you accordingly. The downside to being your own boss is that your work ethic and motivation may drive you to work every waking hour. This is bad, and I hope you learn balance.
I don't think there's a solution to the problems you described - at least not a solution that includes staying in a company and working for someone else. There are people who are happy to stay mid-level and just churn out work for pay. Sometimes they play for the team, and sometimes they're a little selfish. But most importantly, they are satisfied or complacent. Others, like you, are neither.
Cheers and good luck!
I would add that people here may tend to have the kind of personality where they naturally assume that : if you are helpful to other people they will be helpful back; being helpful to other people is a rewarding thing in itself; if you are a good person you should be rewarded.
If this sounds like you (anyone reading, not the parent) I feel it is worthwhile pointing out that not all humans are like this. In fact most aren't. Surprisingly (it took me many decades and about 20 psychology books so...ymmv) it can be very difficult to realize this, if you have this sort of trusting personality type. fwiw I'm talking about the subconscious parts of the brain, so whatever you think you think, and whatever you hear other people saying...that's not really relevant. We are all Chimpanzees throwing feces inside.
That is the true test. You are supposed to pretend only to buy into it but never really believe it. Understanding that things function on two levels is critical. One level is the superficial "we are a family, community, we are not evil, making the world better". But that's the trap to catch all the naive people and extract extra work hours from them (possibly at the expense of family or personal time).
There is a second level of unspoken rules - "it really is about business and internal politics". You are supposed to discover and navigate a set of unwritten rules. And these usually don't get spelled out for you, because they are kind of ugly and often diametrically opposed the official rules from the first level.
Slavoj Zizek likes to talk about this when he talks about institutional ideology and how there are rules and meta rules. The meta rules dictate how you relate to the official rules. Which ones you are supposed to break to get ahead, for instance. The other side is that you are given permission to do something but you are not really allowed to take advantage of that or you get in trouble. For example the whole "take any vacation time you want, we don't have fixed days". But you are expected to not really take more than a few or you'll be laid off eventually.
Here is an excerpt where he talk a bit about that: https://www.youtube.com/watch?v=pfO9gL28pAs (warning, he likes to use gross jokes and you might find his style unpalatable)
If you think a promotion committee is tough to handle, wait till you hit a real board of directors with millions of dollars at stake, shareholders, regulators, colleagues fighting for your role and a million other competing pressures.
This is a crucial skill for middle managers. Their role is often making sure their team executes on executive vision without questioning the vision (imagine how messy things would become if each middle manager would start questioning executive strategy and push back on projects).
At the end, Google process worked as they designed it for. People like you, who don't like to just do what they are told to do, choose to move on. And people who accept it get promoted and go on to become effective middle managers from a Google executive standpoint.
https://www.daedtech.com/ blog is (by quick reading of two posts) career advice for software developers. Very thoughtful, very well written and explicit, with analogies, anecdotes, and opinionated advice.
Whether that advice is any good, I'm the wrong person to judge; I still work as a wage slave (: basically he's telling everyone to go out as independent consultant and solve customers' problems instead of being "an entry in someone else’s Gantt chart. If you can’t autonomously deliver value with your expertise, then you’re specializing in the wrong thing."
Wow, your answer also precisely describes right-wing politics. Some naive leftists talk publicly about some of these meta rules and get hated.
Assigning caricatures to the “other side” like a football rivalry also describes politics. People have opinions. Sometimes these opinions align with a broader group. Sometimes they don’t. Sometimes opinions evolve, and if you respect “the other side,” yours might, or theirs might.
Extrapolating to pejorative classifications of the left or right as a group is precisely what’s wrong with politics because it caters to competitive human nature, and the attitude that the other side must be defeated, bipartisanship (remember that?) be damned. There is no middle or consensus in a knife fight. This is applicable not only to national-level politics, as you've turned the discussion, but also to corporate politics, the subject of the thread.
“Politics is broken. Because of the {left,right}.” is a self defeating approach, and it amazes me how many otherwise intelligent people fall for it. Sadly, we might be too far gone to fix this, and what I would consider a reasonable opinion, like mine, seems every day to be more and more in the minority.
Also, any chance of submitting a referral? :)
Commenter asks for referral from author who knows nothing about them.
My other suggestion would be to learn from my mistake and be realistic about your relationship with the company. It's filled with a lot of great people and they build a sense of community, but at the end of the day it's a business relationship, so you should decide what you want out of it and work towards getting that.
* Do NOT buy any line of the form "It is our policy to hire people with $YEARS of experience / $DEGREE degree / $OTHER_PROPERTY at level $LEVEL only"! It is all lies!
Of course from my perspective, I want them to care about things like bugfixing or supporting my teammates. But then you have to put controls on that so that people can't just never really do anything except bugfixing or riding their teammates' coattails.
I think the right direction is weighing manager feedback more heavily so that if a team member is doing things that benefit the whole team, the promo committee can accept the manager's word that the person had an impact even if they can't quantify it with metrics.
From other comments, it sounds like in the last month, they've gotten rid of committees for promotion decisions up to the level of Senior Software Engineer, so it does sound like they're moving in the right direction. I suspect in practice, there will be thorny incentives there as well, but I'm hopeful for them.
I am not good at wording things, but here goes: I didn't see you call it out directly, but I also find employees are discriminated by project. if you are not working on a valued project, any value you provide to the company will be shrank by how unimportant they feel the project is.
Priorities shifted. Management traded my project away to our sister team in India. In exchange, that team gave us one of their projects. It was an undocumented system, built on deprecated infrastructure, but it was nevertheless a critical component in production. I was assigned to untangle it from our sister team’s code and migrate it to a new framework, all while keeping it running in production and hitting its performance metrics.
I agree that choice of project has a large effect. Projects that involve collaboration with a lot of partner teams increase your chance of promotion because the more people your work impacts positively, the better your set of peer recommendations when it comes time for promotion.
It's much harder to "sell" a project whose effects are only directly visible a few people, even if it's valuable work.
Has your opinion changed about this at all? I am not sure how indicative these descriptions are to overall quality at Google ... but if they are indicative I'd be furious at the situation as a Google employee, where my (otherwise very smart) fellow Googlers are delivering what sounds like very poor products.
I think the lack of tests was more symptomatic of bad incentives that good developers were forced to follow. Developers were rewarded for flashy things they could show promo committees, and rigorous tests or well-written documentation.
It was unusual to find code with no tests because a code reviewer will usually insist on at least some tests. But it was common to see complicated behavior with just a single test associated. Or a complicated interaction between components with no end-to-end tests.
There's not really a strict cultural expectation for documentation, so it's very easy to find code that's either not documented, documented inaccurately, or documented unhelpfully.
I'm especially looking at the Keto Queso recipe. If you wanted to monetize that by instantly adding those ingredients + plus low carb chips into an Amazon shopping list, I would be buying through your affiliate link immediately.
Edit: I removed my comment about profiting off of others content being a 'very google' thing to do. OP does a great job linking directly to the recipe source.
No questions, but it was a good read. I'm sad to hear that the gaming of the promo system is still such a large concern. Unfortunately that was also the case way back in 2005, through 2010, and until I left.
What's new to me is the shuffling of projects back and forth to India. That's not something that seemed to be an issue when I was there, and it's sad to hear this new concern for keeping engineering talent.
What's your experience been post-Google?
The funny thing is that after more than one promo disappointment, I just started working on open source projects at work. I did that seriously for the last 6-7 years of my 11 year tenure (maybe 30-60% time instead of 20% time).
That ended up improving my skills a lot, and I never got the sense of my work being thrown away (which would have led to me leaving much earlier). Like you, I always had a lot of respect from my coworkers and manager, and they never questioned what I was doing. I was always maintaining some legacy system that everybody knew was important but nobody wanted to touch (or knew how to touch).
I did eventually get promoted, but somewhat to my chagrin it was for a committee-friendly project -- C++ that handles a lot of qps. In contrast, I think all the developer tools I wrote in Python had a lot more impact on the company. I got a lot more positive feedback on those (just not from the right people apparently, as non-engineer or junior engineer feedback isn't counted that strongly, as it was explained to me).
I guess my view was that the promo committees cared more about technical difficulty than impact on the company, which leads to the obvious situation where people invent difficult work to do.
In my mind, it's not a coincidence that most Google products are now slow and full of bugs -- at least the ones that make it past the all-too-common "just barely launched" state. I never worked on front end code, but I noticed that front end engineers also get the shaft. The products show it.
-----
I was disappointed in certain things at Google, and there was a certain amount of "believing your own PR", but overall it was fantastic for me. Otherwise I wouldn't have stayed for so long.
I don't have any illusion that other companies are better. They might not have these problems, but they have other problems that Google doesn't. (I know plenty of people who stayed at Google for 5 or more years, then went to another company and left that company after a year.)
I think you might feel the same way, since your choice was to start something on your own rather than take a job at a similar company.
Employees just hold Google to a very high standard, which is both fair and good for the company!
His career trajectory has been similar to your story, in that he was a line engineer who went independent. The think that makes patrick great, though, is that he took the time to write up all his lessons in a blog that is essentially a how-to guide for engineers who want to make the move from "I just write code" to "I am a sucessful self-employed software consultant.
If you haven't come across him before, I strongly suggest you check it out
https://www.indiehackers.com/podcast/013-patrick-mckenzie-of...
I am very much influenced by his story. I agree that he does a great job documenting what he learned.
The big question that I didn't quite get from the post, is why did promotion matter so much to you? Everything seemed to hinge on that, but you didn't quite explain why it was so important, other than "what a great title - people would be so impressed". It sounds like when you were happy with your title, you were happy with your work - you "lovingly" fixed the old pipeline, wrote documentation, helped colleagues etc. Were there particular benefits to being promoted that would have increased your daily happiness?
It was mostly just the status. I think having the title of Senior Software Engineer has a lot of value in itself because it brings better job offers and more credibility if I go off on my own.
Also, people tended to be assigned more interesting projects the higher their level.
I'd enjoy the extra compensation, but that wasn't as strong a factor.
I am writing to add one point I did not see mentioned elsewhere:
You are making an implicit assumption that working on a "smaller" idea (like the ones mentioned in Indie Hackers) is somehow less risky than aspiring to be the next Zuck. Empirically, this seems to be false.
I have worked for ~15 years on startups. I have many friends, who are also entrepreneurs. I have observations on all sorts of efforts - from small side projects to large VC-backed bets to bootstrapped businesses.
My takeaway is that technology startups are characterized by a tremendous amount of risk and require a lot of hard work - regardless of the type of venture. I encourage you to talk to founders (in person, not reading PR-oriented websites like Indie Hackers) and verify that for yourself.
If I had to make up numbers to illustrate this notion, I'd say that making a $1B/year business might be 0.001% likely, while making a $1M/year business might be 0.1% likely - but for all practical purposes, both are incredibly challenging to pull off. If that's the case, might as well aim as high as possible and justify the risk involved.
Turns out the one thing that really matters is having a strong idea, which is forgiving to the many mistakes entrepreneurs inevitably make. In that regard, I wish you luck and hope you end up with a strong concept sooner rather than later.
My conclusion is that starting a small indie business is less risky than aspiring to be the next Zuck.
First, it's harder to fail, because there are fewer forces pushing you to make risky decisions. For example, you can start doing contract work, take on clients, and use them to support you while you build your indie business. Hell, you can keep working at your full-time job if you want to and build your business on the side. Those are bedrocks of income that can last you more or less indefinitely. Often, your employer ends up being your business' first customer. Additionally, you don't have an investors telling you to quit your job and use their capital to scale up your business' costs beyond the level that your revenue can support, which is one of the primary reasons that funded businesses go under.
Second, the business opportunities are simply more plentiful. The bigger you get, the fiercer competition gets. The more money you aim to make, the fewer paths there are to get there. If you want to find your first 10 customers, you can go out and talk to 50 or 100 or 200 people yourself. Every marketing channel is your oyster. None of your competitors feel threatened. The niches you can fill are endless. If you want to go from 1M to 10M customers, however, you need an exceptionally clever strategy, brilliant insights, a lot more resources, and a much higher degree of luck.
It's difficult to actually measure success rates without agreeing on the answer to this question: What counts as someone trying to start a business?
With small indie projects/companies, I'd wager there are a lot more people starting who aren't really serious and never take more than a couple of sincere steps. They might lower your perception of the success rate, especially compared to VC-funded companies if your denominator there only includes those who've actually raised a round. More people fail tryouts for the high school basketball teams than tryouts for the NBA. People filter themselves.
But I assure you that, if you're committed to the task, your chances of succeeding with an indie business are much, much higher than 0.1%.
I honestly don't know whether I or you are right or wrong. I know I am working with a limited data set (i.e. the people I have met and what I have read and absorbed online). Sounds like your experience is much the same, with the added benefit of doing this for a living via Indie Hackers (which is awesome btw). I am not aware of good places to find solid statistical data. Even if there were any, I'd say that they may not be valid - exactly for the reasons that you mentioned such as commitment, which is impossible to measure.
I think part of the problem is one of definition - what do we mean by "risk" really? If you mean the % of companies that, say, raised VC money but did not end up succeeding in the typical goal to reach $1B in valuation, is that actually risk? I don't think so - it is an outcome in the form of statistical probability for a specific goal, but it doesn't make sense to me to think of it as risk, at least with the common definition of the word from an entrepreneur's point of view. It may be a risk from the VC point of view, but that is rather unique because most entrepreneurs can't spread their bets.
That's why perhaps I should have used a word such as "effort." Making your goals smaller definitely gives you way more options - that much I 100% agree with. There are simply more ways to make $100K than $1M than $10M than $100M. But the effort does not seem to be any different from my (limited) experience. My friends working on bootstrapped companies have different problems - but are working just as hard as those with VC backing. The former are (sometimes) more in control of their companies since their goals are lower, while the latter find themselves chasing a bar that keeps rising. But both are working their butts off on a daily basis. I am not seeing things like competition being weaker or them having an easier time (again: limited data set so beware).
Experientially, my impression is that it is all about the product market fit. If that product market fit is strong and in a great market, the business is a powerboat that you can simply pour gas in to make it go faster and farther - as much as there is potential, which sometimes turns out to be a large enough for VC. On the other hand, if the business is a sailboat, then you are at the mercy of the winds. If they are in your favor and so strong that you can't keep the boat afloat, raising VC makes sense. But if they are not, then VC backing is a poor fit - gas is useless because it is finite and the moment you run out of it (i.e. out of cash), the winds will push you back or sink you or you will sit still. Most of the drama around financing stems directly from not understanding the nature of the business and therefore financing it incorrectly (e.g. aspirationally raising a VC round for what is really a non-VC company / sailboat). That's why the best companies rarely need a lot of money to show traction - because they have great product market fit in a fantastic market, which simply pulls them.
The thing is, you can't control or change product market fit. There seems to be a good chance you can't even analyze it without doing things. You discover the type of boat you have by getting out there and sailing.
> The problem, as I discovered at promotion time, was that none of this was quantifiable. I couldn’t prove that anything I did had a positive impact on Google.
I briefly took a part time job in college. It was at a mall, walking distance from school. It was a mid-range clothing brand that I can no longer remember the name of.
Ostensibly, it was a sales position. I'm pretty sure the word sales was in the title. Anyone who has ever walked into a store like that knows there is very little sales (as in salespeople exhibiting selling skills to make sales) occurring. It's 99% "can I help you?" followed by "just looking".
After a couple weeks my manager took me aside and said my sales numbers were bad. It wasn't a threat -- they were having a hard enough time keeping staffed -- but she pointed it out to me.
So, under no pressure to actually change those numbers, I decided to do it anyway. I figured out that if you stand at the cash register and the customer didn't explicit tell you who helped them, you could claim the sale for yourself.
A couple weeks later my numbers were through the roof! My manager congratulated me.
I don't think it's uncharitable to say that my story would equip anyone to navigate 95% of the corporate world.
There's a lot of FUD in this thread about working independently. So one more data point: I've known a number of people over the years that everyone here would know (by title if not by name). What do they have in common? They all struck out independently at some point in their careers.
It's not either / or. Going independent early can be a great way to sidestep a lot of the ladder-climbing sillyness you'll have to do. It will also, if you're doing it right, make you a lot better at your job.
The perks and "easygoing" atmosphere play into this facade and are designed to delay the process of discovery. If you are after [significant] material benefits, by all means go work for Google but be prepared to be treated like a commodity. Ideally you will go through the same process of discovery the author did, faster, and will be able to adapt to extract the most out of the situation.
If you think programming is an art and despise corporate processes that constantly devalue it, then Google is one of the worst places you could be.
While reading your article, I got the distinct impression that Google set up the system that way so they didn't have to give promotions. They get so many applications from the best software engineers in the world that they don't really have to work to retain people, and if they need a manager, there are plenty of those applying, too. I would suspect that in order to be promoted, you truly have to be exceptional and almost worthy of knighthood. The fact that your manager, who has intimate knowledge of your abilities, has no input into your advancement, and the fact that the metrics they look at are naturally difficult to achieve due to project churn makes it appear that they really don't want to promote anyone unless they have a very good reason.
That said, I do think that the system is biased in Google's favor. It's designed much more strongly to filter out false positives (promote someone underqualified) than false negatives (withhold a promotion from someone qualified). As a result, it lets Google pay people at their lower-level title even though they're doing higher-level work.
But it's still a risk to lose good employees, talent is very valuable.
So basically Google is like any run of the mill tech department in a boring corporate environment, but with free food and a side project on self driving cars. Got it.
This applies to nearly every single tech company in the Valley at this point.
I didn't realize it at the time, but I was put on a project that was doomed to fail from day one. I was looking at it optimistically. It was a problematic system, and I knew I could improve it dramatically.
What happened instead? My improvements brought to light a lot of horrible stuff, and the new code was catching and alerting on previously hidden errors. This lead people in high places to believe I was reckless and shipping dangerously bad code, when it reality, it was not any worse off than before.
This led to my downfall. It was a sad lesson to learn, but office politics are everywhere. It's so important to recognize when you're being backed into a corner and given projects that are designed to fail.
An other thing is - don't get pay by the hour. If you want to maximize your ROI you need to generate passive income there's no other secret. Your day is limited to only a few hours.
That being said, promotion processes do seem to be pretty screwed up in general (personal experience with 3 different companies), and fail in various ways. So it's worth keeping in mind that the "external promotion process" (getting another job) is always available.
edit: grammar.
Even worse, managers generally used the success of their reports as part of their success criteria, so they we're always actively trying to promote people because if they didn't then they weren't successful at their jobs. So managers would help that one or two people get promoted, even if they we're generally useless. And the other devs on the team would get ignored.
It was a unique time in my career, when I had a performance review rating of "Exceeds Expectations" in a review that described my contributions as "mediocre".
To be fair, my manager was actually pretty good and acknowledged the disconnect is the review. I had been down leveled in an acquisition and was doing a job 2 levels higher than my own, and he wanted to give me useful feedback and knew nobody would actually read it but me.
For myself, the bullshit with perf and the awful corporate culture stuff became apparent within 6 months of landing here at Google as a result of acquisition. After working at a startup or small company (aka "get your shit done and fix all the things or we'll go out of business!") and getting drafted to work here (and ahem, eat the free food and take all the money they give you...) it's very apparent.
But I've stayed and slogged it through, and just stopped caring and just keep my head down and try to do the work I think is useful. Luckily Google has stopped promulgating the line that one _has_ to get promoted to Level X after Y years, or get ejected. There's a recognition now that people can just contribute at a certain level and be good employees and not play the promo game.
I know very few people who are believers in this culture internally. Anybody who has been through promo is cynical about it. Which is I guess why there's been some incremental changes to the process recently. We'll see how it shakes out.
Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!
That's fair.
I've wondered about that myself. Will I just end up resenting "the customer" the same way I resented "the committee?"
My hope is no because I feel like with a customer, I can learn more from failures. If I launch a product and it doesn't sell, I can try a totally new product or adjust it somehow and see how that affects things. I can talk to customers and get their feedback. With the promo committee it felt very opaque and my opportunities for feedback were so rare. Plus I felt like if I got better, I'm just getting better at working the perf system which is probably only useful within Google or other Google-like companies. If I get better at selling to customers, that should be useful in a much broader way.
>Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!
Thanks for reading!
Customers have "skin in the game". They spend their own money, not somebody else's, and they presumably use what they bought.
Promotion committees have little skin in the game. They meet for an hour and make decisions, and they don't see any consequences of those decisions. They're following rules they didn't make that are supposed to lead to a good result, but they may not in practice.
If the results are bad, they don't really get any feedback until years later. Maybe this blog post will be taken as feedback. Unfortunately this story sounds pretty familiar to me (having worked at Google).
Talking to a customer is (usually) a human process involving an actual conversation. Back-and-forth, incremental, and to the point about business needs of the customer and how you can satisfy them. As a sibling comment said, they have 'skin in the game', they're there to get shit sorted out, they need that shit sorted out and you're there explicitly to help them do it.
Pitching to a promo committee is filling out a form (including fantastic questions like "what's one thing you're good at") where you have no feedback on what the other side is thinking until they tell you 'yay' or 'nay' a month later. Good luck again in half a year. Oh, and those committees will give your packet just a couple of minutes because there's a few hundred of them that they need to handle. Hopefully your packet doesn't get reviewed right before lunch when they're cranky.
I've been freelancing as a developer for the last 20 years and have turned down interviews from Google / etc. in the past. It's a fun ride.
> Optimizing for promotion
This is one of many reasons why I'll never work a "regular" job.
Thanks so much for signing up to that course.
If you have any questions you know where to reach me!
Edit: Found my answer in this blog post of yours https://mtlynch.io/how-to-hire-a-cartoonist/
> Illustrations by Loraine Yow
which links to https://www.linkedin.com/in/lolo-ology/
I wondered if anyone would have not read to the end of the article and, like we both did, assume that the author had created the cartoons.
On a side note, I don't understand the fetish with Google; where does this reality distortion come from that they have the best engineers? At _every_ company I have worked for I have been told "we have the best engineers" :) (I've been in Silicon Valley for 17+ years and Google is not that exceptional).
Did you realize that Google is the single company in which people are actually bragging about interviewing there? (even if the outcome was negative)
They also select a specific type of engineers that are influenceable enough to be convinced that everyone at Google are the absolute best. Those same engineers are then writing those type of Blog posts in which they pound the message over and over about being the best. It's a win-win. Good for their own ego, and good for the company as side marketing.
Now, I'm not saying that they are below average, but in the valley, I don't think Google has any more talents than other companies that don't make such a big deal about being the best
Regarding what to optimize for promotion: I would say it's choosing the right manager (and peers, to a lesser extent).
I know somebody who has struggled to get promoted for multiple cycles (funnily enough, in the same large group you were in). Then he decided to move, and the new manager went out of her way to get him promoted, and he got it relatively quickly.
I've seen this scenario happen a lot in the last few years.
My experience is that oftentimes people at Google-style companies play not even a zero-sum game, but more like a negative-sum game (if there is such a thing). If you're helping someone out, people will take that as an opportunity to take advantage of you.
You then of course need to sell your contribution:
- It was nothing less than ciritical for the success of the project
- It required deep technical knowledge
- It required communication with other teams
- It required mastery of several technologies, etc.
This is not as insightful as it seems....risk tolerance should be a function of percentages, not square numbers.
But not all costs are proportional to company size. I could screw up a command on my AWS account and rack up tens or hundreds of thousands of dollars cloud costs. I could make that mistake at a $1M/yr business or a $500/yr business.
Percentages are hard to calculate in large companies. Is it a multiple of the engineer's salary? A percentage of the team's budget? The org? The company?
This one might be ironic, but am I the only one feeling really annoyed by the fact that every engineer working at Google feels like every other engineers at Google is "the best in the world" ? Beside the obvious arrogance, I cannot tell if it's a subtle brainwashing or a complete lack of critical thinking.
(not only for Google, I saw the same remarks from Facebook and a couple of the other big ones, but Google is by far the most prevalent)
It's crazy once you realize how easy it is to make the employees repeat the ego-flattering "talk-the-talk" without them realizing they are part of a huge marketing machine.
Ha! I think the promotion committees have a rubber stamp with that justification. It's so vague and unactionable, yet they tell _everyone_ that on their first go round.
The second time around, you get to point their feedback and say "Last time you told me to do X, Y, and Z. I did X, Y, and Z. Shit or get off the pot."
Now that sounds naive, but the reason this works is because you are actually in power. You can easily find another job granting you more pay, especially with something like Google on your resume.
In my 20+ years of software development I've never asked for or even pursued a promotion. If the job wasn't taking care of me, I went elsewhere with a nice 20% raise.
I play the game like most people do, of course. But it's a stupid game.
If you already know what you love, then additionally pick a company that's great at that.
If you don't, then pick a company where you get a chance to be exposed to a wide variety of different things. If you aren't getting that in the company you pick, quit and pick another one.
Why?
I have had people say this to me before but I think it is silly advice for where I am at. No one has really explained what a mentor is supposed to do in regards to a software engineer who is mid-level.
When I think "mentor", I think "hand-holding". I don't need hand-holding. I just need to be on a team with peers who push each other. Is that mentoring? What does "mentoring" look like when someone grows beyond a junior role?
I recommend new developers start at large, successful companies where software is a first-class citizen (e.g. Microsoft, Google, Facebook).
My first full-time job ever was a developer at Microsoft, and I'm really thankful for that job. I felt like within a large company, it was much easier to learn effective development practices and why they're important. At successful companies, good practices have a good way of percolating through, whereas at smaller companies, it's easier to fall into "cargo culting" of just doing things because that's how everyone else is doing them.
I think you can see this in things like the Google Python Style Guide (https://google.github.io/styleguide/pyguide.html). It only allows imports at the package or module level, even though most examples online do star imports or imports of particular functions. But when you build large systems that way, it creates ambiguity when you read the code because if you see a function call, it's hard to identify where it came from. There are a lot of things like that where the rule seems arbitrary, but in a large company, you can get context about why it helps you maintain your code and helps others understand it.
~10k/year * ~40 years of compound interest is significant. Most young people have debt and getting rid of that fast opens up a lot more options and flexibility.
On top of that company's that pay more have more incentive to maximize your value. On the other hand if you make little then they have incentive to burn you out and replace you ASAP.
I can't say I blame author for leaving Google. So called "senior" devs who crank out garbage and then foist maintenance on lower level devs aren't people I want to work with either. They're going to keep you down as mid-level janitor until you get the stats to back your story up. Static code analysis can paint that picture quite nicely for management. Sadly, that didn't seem like an option at Google.
If enough janitors leave, the whole place will stink soon. I think the author was wise to stand up for himself. Other Googlers who feel that way should join him.
It ironic that Google's share class/structure relieves its C-level management from short-term/quarter-by-quarter thinking, but at the same time it pressures the rank-and-file to have short horizons.
I appreciate the message around difficulty in quantifying impact, but just putting this into practical perspective, I think OP's manager may have failed to manage his expectations around what constitutes promo material.
My main takeaway from this piece is that it's easy for the incentive structure at big tech companies to get all out of whack. The most useful, most necessary work is often times not the work that benefits the employee most. This is pretty basic management 101 where you want to incentivize good behaviors by aligning the company's interests with those of the employees. When that incentive alignment is working it eliminates the need for employees to choose between the company and themselves. Everyone wins.
When it isn't working you get stories like the author's — the individual becomes unhappy and leaves and the company loses a valuable employee.
Whole story seems like a CF frankly and representative of the reasons why I've never even considered interviewing at Google.
Didn't take me long to realize that most company events and get-togethers and volunteering and other assorted non business activities are bullshit and a complete waste of time.
Like he said.. "it's a business relationship"
If the (good) work you did wasn't reflected in the metrics, then you need to figure out how to change the metrics, or change what you work on.
There's nothing inherently scummy or "political" about influencing the collective direction: identify problems, come up with good ideas for solutions and how to measure (partial) success, and talk it over with your team and manager around the time goals are being set. People are biased, distracted, and fallible, but generally recognize good ideas when they are communicated clearly.
If you're not good at documenting your successes, reflect on what is and isn't getting documented, and find ways to set yourself up for success the next time. Talk to people who've gotten the promotion you want, and figure out what you've missed.
Learning to independently identify problems, devise solutions, measure success, document success, and advocate for your ideas and yourself are essential skills for the human organizational / business part of writing code for a living. This is true whether you work on your own, at a startup, or at a bigco like Google.
Good luck! :-)
In other places these things end up as a massive disaster and end up creating a culture of sabotage. There is a lot of backroom dealing that goes in these 'anonymous' committees. People who sit there aren't individual evaluators like in a public exam. They are generally people who come from teams around you. And they try to optimize and sabotage based on what is good for them. For example, a well deserving candidate's promotion can be turned down for a total irrelevant reason, while some political lackey could get promoted by adding all sort of cooked up recommendations to their 'promotion packet'. Most of the times all this is done so secretly that when promotions are announced the come across as a shock to most people. Of course people see through this all the time, and cubicles full of employee always talk of 2 + 3 not adding up to 5 in these cases.
Another huge scam in these things is the 'important work' bogey. You could have contributed way more code, fixed a lot more bugs and added a lot more value, but your promotion can be denied on the grounds of not doing 'important work'. What the definition of 'important work' is nobody knows, as its largely defined by work done by the guy getting promoted, no matter what work that is.
There are more things to this. For example, salary negotiations play another toxic game here. In most companies budgets are fixed. So a manager is likely to reward his lunch buddy far more than other people in the team. Eventually over 3 - 4 years you realize some of your team mates are now making way more disproportionate money compared to their peers and the work. This spills into all sorts of other opportunities.
The best thing I heard was from one manager, who told, if your manager isn't telling your for sure a few months in advance that you are getting promoted, you most likely aren't.
In most companies its already decided who gets promoted, they just have to do these 'promotion packet' and 'anonymous committee' rituals to cook up documentation to justify it, to protect themselves from law suits later.
All of this called 'negotiation' by those who benefit from these schemes. In reality it is getting financial and other favors in return for proximity and servitude to power.
Sounds like you were in a gnarly situation and did well to get out. You are what you do, and those types of places can have a long-term corrupting influence on your professional habits and instincts.
The observation that “all companies have politics” is about as useful as the observation that both Venezuela and Denmark have imperfect governments. These statements are correct only in the narrowest sense.
Those pointing out that you never work for “yourself” are also technically correct. If you own a business, you have a responsibility toward your customers. The good news is that it’s possible to find a niche in which you actually like your customers and enjoy doing right by them. Running your own company also gives you the opportunity to optimize for what you think is important, both personally and professionally.
Best of luck.
I like your analogy about Venezuela and Denmark. : )
I do think they have a point. Throughout this process I've continually tried to consciously avoid a "grass is always greener" mentality and recognize that starting my own company will have difficult challenges as well. So I appreciate the feedback from both sides.
That said, Indie Hackers is filled with stories of people who left corporate jobs and found greater satisfaction in their own companies, so I think it varies by person and requires some luck. I'd like to see what happens regardless.
A lot of Google's philosophy is about automating things a person normal would use their judgment on and just choosing not to perform some human-centric functions at all (e.g. customer support).
It's hard to get internal culture right in the best of circumstances. When you treat like an algorithm and you don't get that algorithm right, it encourages all sorts of maladaptive behavior, politicking, etc.
To be fair Google's promotion board is not as flawed as say, Microsoft's old stack ranking system. But it does set up incentives in such a way that to advance people may optimize their work in a way that doesn't benefit the company.
however i can't say that i agree with your main thesis. It's pretty wild if you think about it that someone would work at Google with all those perks yet focus on such petty negatives. No x-mas gift? join the 90% of all other companies. No "Senior" title before 3 years? This is not at all unusual. At least your company had a framework for promoting employees and they were willing to give you a chance every 6 months (even if its not a perfect evaluation, it's a system that may get improved over time). Nope no sympathy here but i do hope working on your own gives you more happiness! I did find your project details helpful and inspirational
Btw anyone know what the number of promotion slots a year for the eligible population is in google?
When I worked in Systems engineering division (67k FTE) in BT there where 18 or so mpg2-> mpg4 every 18 months (if we were lucky) approx. 600 would pass the paper shift to get on the short list.
I was told by my boss that getting on the short list meant they thought you where capable of doing the job group finance wouldn't approve of small in crease in pay quanta - I knew some people so desperate they took a transfer to payphones to get a promotion.
The simple solution is that direct superiors and co-workers are the best resources for determining viability. The junior engineer he trained is better informed than the entire promotion committee with their metrics packet. Maybe it works sometimes but for all the millions(billions?) Google has invested into dissecting how teams and human resources work, this is a case where they totally failed and a very basic solution would have worked.
Sounds like this would lead to "easy" teams for getting promoted in while others with higher standards lag. End result would be grade inflation where titles becomes even less meaningful.
Nobody cares if you work hard over time unless your projects are late.
Lessons learnt spend time with your loved ones.
At Google you got paid a great salary, had great 401k and perks to work on projects that most likely go nowhere.
Working for yourself you're sacrifcing all those perks, to work on projects that will most likely go nowhere.
That said, definitely do it. It will teach you a ton in the process, everyone should go out on their own, mostly to realize how hard it can be.
New perspectives are invaluable, so I applaud your decision and wish you all the luck in the world!
When he was only focusing on the metrics, he was ignoring everything else. That is unethical. That is calculated. That is unreal. That is the yellow brick road to unhappiness and a horrible career.
The main problem was the constant reorg. He couldn't get a project done with completion.
Sadly, if your project’s value is not well understood, you need to get off of it.
At least he learned a lot, has Google on his resume, I'm genuinely happy for him.
I hope he really makes it! More indie hackers the better.
Assuming the free food and massages will keep a lot of talent there, why would they bother incentivizing the average individual employee with interesting work and promotions? If you leave, they'll replace you, likely without shedding a tear.
Other companies may have to search hard to find excellent software engineers, but Google does not.
Yes, if someone leaves after 4 years, it's possible to hire someone else of the same ability level, but you're going to spend time and effort to make them as effective as the person who just left.
There's so much resentment in this thread about colleagues who have titles, when they aren't producing superior work. You're clearly judging your peers (and by extension yourself) based on quality of work, so why care about the title? If you can write good code, or design great APIs, or build excellent tests or clean up outdated codebases, I don't care if your title is Emperor of the Universe or Junior Intern, you're welcome on my team any time and I'll be glad to have you on board and build awesome products with me.
If you want to get that title, then by all means go play the title game like the author. Focus on metrics, forget about producing meaningful work, and you'll be on the fast lane to become one of those people that you resent right now.
Anyone remember those "unprofessional" titles like "Chief Executive Ninja" and whatnot that were so popular in the startup scene a while ago? These people were simply signaling that they didn't really care about titles and cared about other things instead, like building product, or adding value in some form. I used to work at a startup where everyone could pick their own title; so anyone could be a senior engineer if they wanted to. Ofcourse it didn't matter if they did, because nobody was judged by their title, but by their work. If that's what you want, then go and find a place like that; they exist!
Kudos to the author for figuring out what he wants.
To the young everyone has high hopes for you mostly because they want that energy and drive. At a certain point however you aren't valued based in your individual technical contribution but your ability to support existing narrative structures.
The shock from people feeding you your own narrative heroes journey to expecting you to kiss ass and support existing stories is specific to tech because of the relatively new and parallel "journeyman engineer" career path that tops out around 300k. The remaining paths are the thought-leader/genius path and the traditional corporate man.
This line is the best summary how most companies treat their employees, despite whatever the company promote about internal community, team building, etc...
This is how the whole industry works. They will be more than happy to keep you low, doing useful work relatively cheaply, indefinitely.
On the other hand, cry me a river. There are a million and a half families, including 3 million children, in the US living on less than $2/person/day.
This was the beginning of the end for me. I don't care about the gift at all; if I wanted something I would have already bought it. But it was the idea that an easy way to cut costs was the solution to everything. Ignore the fact that there are three separate teams working on literally every problem at Google. No, what's really costing them money is buying everyone a phone every year. (Which, BTW, you can just order from TechStop. You don't own it, of course, but what value does a phone have in two years anyway? The cost of buying it is the same to Google whether or not you keep it forever or for the duration of the contract. But ordering the phone from TechStop doesn't buy much goodwill, like maybe getting a free phone and giving it to your family does.)
> The pipeline’s failures increased because I made it fail fast on anomalies instead of silently passing along bad data.
Anyway, I kind of heavily disagree with the promotion/performance review complaints. I was on a promotion committee a number of times at Google, and my committees always loved stuff like increasing reliability, adding metrics, and doing the "dirty work" to keep things running smoothly. This, if true, is the pinnacle of what's valued as solid engineering work.
The thing is, I was reviewing people a level below me (that would be the L3->L4 committee -- like the author, I was a senior software engineer), and that's the kind of work I expect at that level. To get from Senior to Staff (L5->L6), you expect this kind of thinking but across multiple teams. It is not as simple as sweet-talking people into doing stuff for you (which is what a lot of people think leadership is), it's more of facilitating productivity in your area of expertise. So if your general area of work has a lot of problems with flaky pipelines -- you need to get the metrics in there, you need to teach other people how to use the metrics to direct their development goals, you need to make the changes easy to test... basically, you need to make the less-experienced of your teammates able to operate in your specific area as efficiently as you. Because then those people can go out and get the dirty work done (getting promoted in the process), and you can bring your bigger-picture analysis and implementation skills to a new problem.
Something I saw while on committees was people that were performing the responsibilities of their level on the "ladder" spectacularly. That does not necessarily mean that they are doing anything at the level that they're requesting promotion to. A new level is a new job, not just doing your current job really well. (For that, you just get a pay increase, not a title change.) I really think that's what was going on with the author; he was performing Senior-level work really well. That does not make you a Staff engineer. Additionally, there is no particular demand that you ever become a Staff engineer. I think my W2 for the last year I worked at Google was something like $270,000 as a Senior engineer. That is good money. So the question is, do you need more, so you're mad that you're not getting promoted... or do you just want something because there are levels and you want to be the highest?
Certainly, by working for yourself you can avoid all of this. You can always tell yourself that you're the best person in the world and nobody is going to disagree with you. I always saw the ladder as a way of suggesting what sort of classes of problems to work on to work more efficiently and effectively, and by working in that direction you were growing as an engineer.
The promotion committee noted that in the past six months, I clearly demonstrated senior-level work. These were, uncoincidentally, the months when I was optimizing for promotion.
But they felt that six months wasn’t a long enough track record, so… better luck next time.
But I can tell you this. I would not have been this productive if I'd stayed on at my cushy software developer job. I've had way more fun too.
The best you can do is find a place where those with the power to promote also have skin in the game. Usually that means working directly for an owner, or being an owner yourself.
Politics dominates when those who do the promotion do not suffer the consequences of losing good people or promoting bad people.
All organizations become shit after they grow to 10,000+ people. It’s not possible for politics to be kept out at that scale. Google may be worse than many other places because its steady profits allow it to keep many useless individuals on the rolls, who would be fired elsewhere.
I work in a very small team, where promotions don't exist, but I am more aware now, that I often try to work on taks which are more easily recognizable as "wow you did something cool", instead of focusing on quality of code and work. And that's just because I fear to seen as a slacker.
Unfortunately in the real world, hardly anyone wants your new product, and people are so accustomed to polished products that work on every platform, that one person can hardly deliver something pay-worthy nowadays. Not to mention it's so difficult to land on an idea that people really want, and that idea itself is something doable by one or two persons at most (bootstrap model)
After 6 months of hardly any income, had to eat humble pie and get back to employment (for now).
Good luck.
I'm happy with what I'm doing anyway.
You find this in every single industry. I used to work in public accounting and it was just like this. Google isn't special in this regard.
To author: good luck! If your startup takes off, let us know!
Getting on a company that becomes Google/Amazon/etc (or more likely doesn't but that's life) is one thing, getting sucked into the corporate dystopia described in that blog post is quite another.
I guess I'll continue to work at smallish start-ups because the idea of being swallowed by a programmer black-hole doesn't appeal :-)
If you want control over your economic destiny, you need to be in business for yourself. There is no middle ground between being a serf and being a merchant. At least not in our profession.
To try and hold onto that which cannot be held onto is the path of good intentions that leads to hell. It is the temporary victory of bean counters while the human spirit nurses it's wounds.
> No, managers at Google can’t promote their direct reports. They don’t even get a vote.
This isn't quite true. It's true that the promo committee doesn't include your manager and it's that committee's vote that determines your promotion BUT your manager does get to say whether or not they support your promotion.
Anecdotally, committees expect to see manager support so if a potential promotee has it, it doesn't mean a lot unless there is a lot of specific information that the manager can provide to support the promotion (ideally peer feedback should do this anyway). It tends to be an issue if your manager doesn't support your promotion however. And this happens. It also happens that people get promoted without manager support.
Personally I never understood how this situation arose. I operate under the principle that there should never be "negative surprise". So if your manager doesn't support your promotion (which, hopefully, is solely because it's the manager's informed belief that it won't pass committee) then the report should already know this before they decide to submit for promotion. If they don't, that's a giant manager fail.
If the report goes up anyway, if I were a manager there's absolutely nothing to be gained from not supporting the promotion.
Moving on to the other points:
> Metrics or it didn’t happen
There's a lot of truth to it but not in the way the guy intends I think. He goes on to say that there were no metrics for what he was doing.
Well that's the first problem. You should create them. And it sounds like this guy was looking to a T4 to T5 promotion. There's a certain amount of independence and proactiveness required for T5+ so not creating the metrics to measure his successes by is an issue.
The manager again bears some responsibility for this. One of the primary jobs of a SWE manager (IMHO) is coaching their reports for situations like this and building their careers.
A better way to say this is that impact matters. Working on a bunch of small, unrelated things is not impact. Promotion isn't a matter of doing a lot of work or being helpfully necessarily. By T5+ it's an issue of having impact across your project and to your wider team.
Also, it's worth noting that often people do have to go up for the same promo twice. The natural instinct for committees is not to promote and they'll give you feedback as to why. So then 6 months down the track you submit an updated packet that includes all the ways you've addressed the previous committee's feedback. That's really common.
As for the holiday gift, yeah I was there for that. All I was say is that it was bad optics, particularly in light of say, how much money was handed out to Levandowski. The argument was that it was too expensive to adminster across so many different countries. This may be true but it feels like penny-pinching and cost-cutting. And as they say, as soon as they take away the free drinks it's time to pack your bags. The issue isn't the free drinks, it's what it signals.
Project cancellation! Been there twice. It's highly demotivating.
Having been on a promotion committee a number of times, I have to say that manager feedback is generally pretty useless at face-value. A good manager will make sure the right peers write reviews and that the candidate didn't forget anything important. But the candidate can smooth over all of this themselves; my committee promoted someone who's manager feedback read something like "TODO: write this". That reflects poorly on the manager, not the candidate.
> looking to a T4 to T5 promotion
I think he was looking for T5 to T6 actually.
> Project cancellation! Been there twice. It's highly demotivating.
RIP us.
> If I just kept going, I’d soon be promoted to the next level, Senior Software Engineer.
That's (being promoted to) T5.
That's where the culture failed.
Serious question, why is Quitting Google such a big deal?
For all the projects I've done over the years, I didn't "wait til the end" to ship something. Get a feature done and ship it out. If you wait until "it's finished" it will never be and you risk both losing interest and losing clients.
Working for yourself is risky at the very beginning, but anti-fragile, given you know what you are doing.
(either new Senior hire, or joined Google within the past 2 years)
It requires beyond stellar technical work to overlook the influencing aspect.
- Dhruv
The Indie Hackers community is awesome. I've been thinking about starting a tech cooperative along those lines [1], where the members have full control of their own projects and can work on whatever they want. The goal would be to build some small SaaS products or mobile apps, and generate a bit of money. The value of joining a cooperative is that we could try many different ideas in parallel and share a fraction of the winning ideas, similar to a VC who invests in a large number of startups. The other benefit is that we can build a much closer community than Indie Hackers, because everyone has a stake in the company. We'd be independent, but could still work together to help each other succeed.
Anyway, if this sounds like something that appeals to you, feel free to fill out this application form [2]. (I've heard from some really awesome people but will keep the form up for a while.)
[1] https://m.signalvnoise.com/avoiding-the-trap-8df59e718f3e
[2] https://docs.google.com/forms/d/1dnm-SZxbcKuQ7PUU9ArRnlD1LiK...
If it's new development, how do they know this feature or thing is going to work, or is needed? What work has been done to verify these assumptions, and what is the risk? If there is any data collected, user stories, or customer interviews, ask to see that information. Ask to see any roadmaps or presentations given to higher level managers. Ask to be included in any product meetings or customer interviews. If they balk at any of this, it's a red flag that they are unwilling to be open with their plans. In my experience, this normally means they know their own plans are bullshit or they simply don't exist. It's really amazing how many managers and senior level people at these companies operate on bullshit. I've seen it so many times.
The purpose of all this is to insulate and protect yourself from the failure of your own management. If a manager keeps cancelling your projects, ask why? Personally after a manager has cancelled one of my projects more than once and there isn't a good explanation why (i.e. something I myself wouldn't have seen coming), I start to question and doubt his decision making ability, and I'm less likely to want to work on his team or do his assigned work. I immediately start looking at other options for how I can benefit the company. This is a tricky situation in itself, however. I've had managers who have let me run with my own ideas and have praised me for leading projects and working closely with various areas of the business, and I've also been fired because my manager couldn't stand the fact I wasn't willing to be his slave and work on another of his (soon to be cancelled) projects.
In many tech companies who only care about end of the line results, it's simply not enough to do a good job. You have to do a good job on something that actually matters. When you're up for promotion, you're up against other people who have done a good job at things that have mattered, and the quantification being done is how much of these good things matter when compared to one another.
It's really a shame in this case that it seems like the OP was really stuck under very poor management who clearly didn't know what they were doing.
If Google holds it engineers to results, why doesn't it let them at least decide what they get to work on? It seems they've forgotten the part that if you're going to decouple someone's direct management influence, you need to decouple that manager's ability to assign that person work or dictate what projects he or she works on. Just goes to show even at a company like Google they don't have everything figured out...
Everything to the sister company in India!