> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time.
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?
I worked in a remote team once helping a company in Seattle (that perhaps had a bit of a jock culture problem). 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. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.". To be sure to repeat a message like that every four hours in channels like Slack.
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.
On the one hand it is indeed disappointing that nobody would help you with this. On the other hand, there's a more pro-active role you could have played yourself in this as well. "When everybody is responsible, nobody is" - what often helps is specifically asking people, by name, to sit down with you for a bit and help you get through it.
In fact, there are many social group situations in which asking specific people is far more effective than asking questions "to the group".
If a manager of some kind were to notice the Slack messages and ping someone specific to help, that would be a perfect example of the kind of management that is so sorely lacking at so many companies. Many employees are too burned, or proud, to even put out an SOS... so a cry for help is actually a gift to management. If only it were someone’s job to think for a few minutes each day about each employee and notice if there is some small action that would help them.
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.
Why not both? I cringed when I read OP's comment where he spammed "I'm completely blocked" in the chat without asking for specifics. What a complete lack of individual ownership. Even the best manager can't help somebody who is unwilling to help themselves.
> I cringed when I read OP's comment where he spammed "I'm completely blocked" in the chat without asking for specifics.
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.
One of your jobs as a manager is to debug these people issues, right? So when you get a "bug report" like "I'm stuck", you should investigate the bug and look for a solution, which might be something like "Hey Bob, Jim is having trouble getting the Frobnicator running on his machine. Can you please give him a hand with this later today? Thanks". (This assumes that Jim's SOS was issued in the first half of the day; want to make sure the issue gets resolved promptly while also not interrupting Bob's own productivity/flow.)
Yes that's true, which is why I said "why not both?" The manager should do more, but so should the employee. Sitting there and saying "I'm blocked, woe is me" is garbage compared to saying "I'm blocked. Can you please help me Mr/Ms XYZ?"
I think your specification of a "correct way to report a problem" is company specific, or your personal preference, or the way that you think an ideal problem report would be stated.
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)
You will get a lot of downvotes for making that statement here... but let me just say I agree with you 100%. The people I see that get the most work done aren’t the ones crying publicly for help on a nebulous problem, but asking very specific questions about specific problems. In cases one doesn’t make progress, escalate to the manager giving details about exactly what is going on, how many times you reached out to another team and got no answers. That gives the manager ammunition to talk to their peers on other teams or escalate to higher ups.
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...
That's how I was taught (via managers on reddit actually, not irl).
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.
I agree with you that employees that you cannot trust should be fired. Skepticism doesn’t necessarily mean lack of trust. It’s possible to trust dishonest people and without a skeptical view to be aware that people may be dishonest, even in small ways, it is easy to fall into that trap of trusting good liars.
> 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.
A new repo, likely a new employee on a new project. I have to disagree with your statement since you don't know the context at all. If all they're given is a repo with inadequate instructions, there's not much more you can do than keep asking for general help.
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.
> I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.
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.
Nonsense, this is asking for help. As a former manager of a tech team, if I had seen this I would've taken action, and as a team player individual contributor I would've taken action even if I were not a manager. I appreciate you sharing your perspective, but in my opinion you're leaning too far to try to find some way to blame this employee for processes that an employee should reasonably expect a competent management team to have solved already.
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?
He mentioned that he brought it up in the standup. The standup is when you announce blockers. Was no one else in the standup listening when he said he was blocked? That's when someone goes oh here is what you do.
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.
This person probably DID ask more specific questions. They were just describing the gist if the interaction. Not a literal copy paste of the exact messages.
Having my blockers completely ignored for a significant amount of time was a major factor in deciding to find a new job. There are only so many times you can beg for libraries, source code, permissions and other essential tools before coming to a conclusion that maybe somewhere else there is a place where you don't have to deal with this bullshit.
When someone under-performs, I always look at who they report to. Nobody wants to perform poorly. Typically the lead / manager has given inadequate guidance, or there is a serious skill set mismatch, both of which are on the lead / manager.
You should stop being a manager. Or get training to become a better one. Seriously.
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.
I don’t see the reason to assume that was litterally the entire message posted to the channel, it seems more likely OP just pharaphrased what they actually said when the made that commen on a public discussion board.
Nitpick s/he said s/he couldn’t run the repo. If someone posted that in our slack someone would jump in and ask what errors s/he was getting. Once we found a solution we would get the docs updated, usually by the person who found the problem since they have the most context.
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.
Could you please give an example of a message with more ownership? Keep in mind that he didn't know at the time that he was missing some undocumented configuration step.
What kind of company or culture is that, when someone asks for help from a group
and no one volunteers to even suggest to them a person that would be the best candidate to help them?
I've never been at such a company and I hope I never will.
I've worked at different companies that just culturally have very different approaches. Where I am now, I will basically corner people until they help me or provide a better option on where to seek the help I need. At my previous employer, there were certain mailing lists where you could ask questions and if your questions reflected real effort, you could expect helpful responses.
This is similar in emergency situations. When you need somebody to call 911, don't ever say "Somebody please call 911!". You have to look at someone, point at them, and tell them "I need you to call 911". Most people will either stand in shock or think that someone else is on it.
> Most people will either stand in shock or think that someone else is on it.
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.
It occurs in explicit hierarchies all the time. Watch the opening scene in "Saving Private Ryan." Most of the troops are scared shitless, waiting for someone to tell them what the hell to do. And these were troops who had been trained for 3 years before hitting Normandy.
I like that the problem is remote specific, and the first image you have is “asking people, by name, to sit down with you”. Your image is nit wrong, but a symptom of how we can be hardwired for physical proximity.
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.
I agree that remote is more difficult than physical, but it's still much easier to ignore a general comment in a chatroom than one that's specifically addressed to you. Most chat applications will even highlight lines mentioning your name.
(Note that being remote in an otherwise physical team makes this significantly more complicated as well.)
It's good you pointed this out because many people don't know. I took a first aid class and they taught us in an emergency situation, never say "somebody call 911!" Because everybody will think someone else will do it. Point to a specific person and say "you, call 911!"
This is a big challenge for remote employees. At some point when do you just give up and settle for what you can get done and not worry about what you cannot change. Its a poor attitude but it happens at a lot of companies.
What makes my stomach turn is the interpersonal aspect. How can all your teammates see you fail through no fault of your own for days and pretend they don't notice. Unfortunately in my experience, that's not a rare occurrence.
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. Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done.
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".
It is also easy to get irked when people are seemingly unwilling to do any digging or reverse engineering on their own and go straight to asking for help. Allowing someone to search for an answer for several hours may seem like a waste of their time, but it also could allow them to learn how to figure out a problem on their own. Of course their is a fine line between being a jerk and not helping someone because you want to maintain your technical superiority and not helping someone because you want them to learn how to problem solve. Clearly you do not want to leave someone roadblocked for 48 hours when they are trying hard and you know the fix is some stupid bug. But, it's not always super straightforward either.
Yes. Unfortunately, by the time you start to think people are asking for fishing lessons just to get lunch, it can become difficult to recognize a true student.
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...
I struggling with this constantly. If I have to fix another VPN issue caused by weird DNS server entries in OS X I’m going to scream. “Anybody else getting this error?” No, figure it out. I’m at a loss to explain how so many people wind up in software dev roles while lacking the most basic of problem-solving skills.
Capability and responsibility become conflated very easily. You start off as the superhero who can fix problems, but that gradually creates dependency.
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.'
Managers inadvertently create this dynamic when they are focused on attacking obstacles rather than creating infrastructure. If <employee> knows how to do something, and that thing is not getting done, then <employee> is the obstacle. The discussion often doesn't make it to the point of 'why doesn't anyone else know how to do this?' Management needs to think more like logisticians rather than tacticians.
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'.
Start by actually talking to your management instead of just trying to be a rock star. "Hey, I'm spending a lot of time doing Team X's job and it's impacting on my assigned work, if you want me to keep doing this then put me in charge of Team X, otherwise let's all sit down together and clarify who is responsible for what."
So I'm asking this not to move the goalposts, but because it's the situation I'm in - what do if your manager is too weak/distracted/uncaring to actually act on this information and/or the projects in wait state on you are not actually within your manager's sphere of influence?
Hmm, tough one. The default answer is "follow it up the chain" - if your boss isn't doing the right thing, talk to their boss, and so on. Another approach is to talk to the manager of the team who's leaning on you, and let them know (if they don't already) how much they're depending on you and that you should really be in that team. This can cause drama with your immediate boss (they're seen as 'poaching' you) but if said boss doesn't care then this might not be a problem.
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.
Unless something is keeping you there, just find a new job, here are some reasons:
- 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.
That's neither healthy nor sustainable. You're the one that sees a problem; you absolutely need to make your boss aware of that situation and that the company needs to arrange for better utilization of man-hours. If management doesn't fix that to be healthy, consider moving to a healthier position.
Just to try to put this in a (unfair to you) constructive context:
> 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.
> Well, when it comes time for a project meeting, those on the meeting are far removed from the other groups that I constantly have to help out. And it sounds like I'm just giving excuses of why my work isn't done.
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.
I'd best describe myself as a "computer person". Other than the first few years when I first started at around 15, my job has been Unix Systems Administrator / Engineer, but I've always thrown a lot of programming at my job too. Not just systems automation programming, but various utilities, apps, etc.
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".
I've actually slowed down a bit in recent years, however the main driver is that the work is fun. During the day I do the necessary (but not necessarily fun) work. After hours, I work on stuff that is mentally challenging and needs concentration, but only if I find it fun to work on. I do this instead of watching TV for example. As long as I get in enough time for other activities (hiking / bicycling, woodworking, designing my own creations, time with family) then hopefully I have a balance. But I have always had a slightly unhealthy fixation on sitting in front of a computer screen and creating (whether I'm doing it for work, or personal projects).
Having been the 'goto build guy', I've had to cut people off who were seeking me out for very self explanatory issues. For example, when the build threw an error because it couldn't find a file, pointing out where in the error to get the file, but the person seeking help didn't even try reading the error. Basically I limit my intervention to prevent enabling helplessness. The amount of help given also depends on the role of the person as well, junior devs get more hand holding then senior devs.
This to me sounds like a complete lack of self-ownership on your part. You literally sat blocked doing nothing for days, without reaching out to an individual to help with this? Instead you just spammed Slack saying you're blocked?
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.
And even if everyone completely ignored them when they direct messaged their teammates... why do nothing. Why not dig in and figure out how to get it to build and update the Readme? I don't understand why someone would just sit there and do nothing instead of trying to fix the problem.
I did that once and then rewrote the repo. Everything was fine for months on our team until another team merged their exact copy with new changes that broke what I was doing. Everyone senior left my team and it looked like I was doing nothing for 4 months. Communication should come first and the manager needs to step up.
I agree that communications is important and was the primary thing wrong here. It was more that even on top of that, they just sat there doing nothing vs. at least trying to be productive and figure it out for themselves.
Sure I have backups. The other group took a copy of the repo and changed it over a three month period and never checked back in. The versions were very different and merging my copy in was difficult and required a rethinking and rewrite.. in the end it became three separate components. All of this happened during a management change so the timing wasn't perfect.
It also appears to assume that someone could help them. There are plenty of times where knowledge of a project or component is simply lost, either the developers don't remember or are gone, it's one of the costs of employee turn over.
OP said slack. DM is as simple as doing "/msg @joe.blow I'm blocked, can you please help me?". If no response, go to @joe.blow's colleagues. If still no response, go to their boss. If still no response, go to their bosses's boss. Repeat until you run out of people to escalate to, at which point you find another job.
If they are willing to pay a blocked remote worker for sitting on their ass doing nothing, why should the worker rock the boat so much that they burn all bridges at the company and finally have to get a different job? Remote jobs seem somewhat hard to come by and can be a sweet deal.
The company needs to take at least partial blame here.
No need for worker to do that. But that's then their conscious decision and they shouldn't express their frustrations over it. On the other hand, if they want to make a progress, they should escalate appropriately.
Note that I am not convinced that this is the case here - I simply don't have enough information to make the judgement.
So someone wanting the system they are a part of to work appropriately without them having to be an excessively aggressive asshat about it needs to swallow their frustration entirely and not even vent about it on an online forum?
Even!more than that, at some point you start including "You are paying me $xxx/day to do nothing productive because I'm unable to get 15 minutes of time or even acknowledgement of requests from persons X, Y and Z."
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.
> Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.".
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.
Maybe it's not the initiative per se. Did you name the function silliness(), runPig(), or give any other blatant display of contempt? It's dripping from your comment.
(not saying it was necessarily about something real, just that it could be)
Nope, any contempt would have only been after the other developer displayed his contempt for productive use of shareholders money. I always find it funny how so many people seem to think that is a matter of opinion rather than a matter of fact.
This is endemic to our industry. The problem really is short-sighted management. They only value something that shows themselves in good light with their superiors.
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.
Often the non-technical reasons are "management doesn't want to assign the super-lead to the work, but also doesn't want to let the new hire have free reign to rewrite a legacy product. Just fix it."
I've often wondered whether this dynamic is exactly the reason tech culture is ageist. If we hired older developers, the culturally-assumed "gravitas" of age would make their relative social status to more-"senior"-but-younger devs illegible. We might actually have to sometimes give them the right-of-way on making the changes they want to make, even though they're new!
Every company I've worked at for software development has had review / feedback opportunities for my manager. I can't imagine working at a company where feedback from direct reports wasn't a major factor in someone's job performance evaluation.
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.
I don't think it's specific to our industry. I think it's specific to the corporate system we have, and that it correlates with the sense of ownership and freedom that we give people. When it's "every man for himself", you're going to see that optimization toward individual metrics and protection of personal reputation, even if it means that a colleague's reputation is deprived.
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).
I can't say for sure but your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it. If people aren't helping you then according to their cost benefit matrix it isn't worth it. Maybe they are supposed to be doing other work and they can't calculate how many hours they would have to spend helping you. Maybe they are just afraid of not knowing how to get it running either and will get entangled and implicated in what is currently YOUR ignorance alone. (I've worked with plenty of these crappy apps with undocumented dependencies where if you get the AUTHOR of the repo to try to build THEIR project on a machine other than their own it craps out on them in which case they fucking bail or defiantly say 'it works on my machine'. These same people will snort derisively if any junior tells them of problems building their project, with a line like 'its not rocket science you know' -- until you confront those mofos with the demand to actually build their own fucking project. At that point you discover that not only did they not document all their dependencies, but they can't even read a simple node error message complaining about how node-sass is not defined, because their project depends on node-sass being globally installed and they didn't realize it themselves.)
>your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it
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
> I can't say for sure but your mention of 'CSS' makes me guess this is a web application, in which case you should be able to read the source code and figure out how to build it.
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.
Isn't the Toyota's idea of Kanban supposed to alleviate this? As in if there is some problem with the production line, anyone can push the stop button, and everyone assists?
Just to clarify your point, I believe you are referring to andon[0], the system of alerting people to an issue, rather than kanban[1], a system for inventory management.
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.
No, the equivalent would be as soon as he raises the issue, no one can type even one more line of code, not even a character, and their editor would be completely blocked.
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.
There are other issues at play when it comes to helping out remote team members.
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.
I have generally chosen to deal with this problem by refusing to acknowledge the existence of bonuses or promotions. It is harder for a warped incentive structure to warp your behavior if you refuse to be motivated by its prizes.
That's noble, but many aren't inclined trade personal profit for the company's profit. I don't think they should be, either. It's the company's job to ensure that their success is aligned with their employees'. Raise the issue to management, and if no action is taken, then you've done your due diligence.
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.
> 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. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.
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.
That's not really undebuggable. Process Explorer shows registry calls, and IIRC even marks them in red when the key is missing. Again not arguing that this is efficient, just that doing nothing is less efficient.
I generally assume that when someone says "blocked" they're not literally staring out the window, they're just not operating with anywhere close to the efficiency they should be.
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.
If learning to use Process Explorer can aid you in performing your job duties, then I feel it would definitely be more meaningful and efficient than just staring out the window. I can't judge OP's situation because I don't know all the details, but I think there is something to be said for being willing to dive in and "unblock yourself" like some people have said. There's obviously a gradient between being helpless and the situation being genuinely out of your hands, though.
I think the point was that it's silly for someone who's meant to be on a team to spend possibly days trying to debug something as silly as that, instead of someone on the team just spending the few minutes to help them and give them the registry key they need.
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.
Are you a junior dev or was the work in a domain unfamiliar to you?
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?"
Most jobs I've been at if you're the first new hire in a while you are going to experience something like this, and it's important that you spend a lot of time adding to the documentation to make it easier for the next new hire.
I don't have an answer to your question, but I've certainly felt that pain.
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've never tried it, but I suspect you'll run into the same issue that sports does, where "assists" don't accurately reflect the people who are making things happen on the court.
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.
> 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".
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.
> The NBA has an advanced metric for that called gravity. As you could imagine Steph Curry's gravity is through the roof.
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.
I can't think of any one particular article that goes into the details of gravity and some of the related metrics (respect and distraction being the others). Maybe lookup NBA gravity scores and SportVU. I believe the company that sells the SportVU system are the primary ones tracking that metric (and delivering it to teams).
Gravity isn’t metricized (and it would be hard to do so), the best we can do at the moment is indirectly measure it via +/- or other stats like what SC30’s teammates’ true shooting percentages are with him on and off the floor.
Second Spectrum has supplanted SportsVU for tracking, and is also the generator for all the advanced metrics that are now provided for the NBA as well as ESPN.
You're forgetting that you could also track secondhand assist as well.
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.
A person’s projected morale is very under-appreciated. I don’t know if I’m at the point in my career that I boost morale just by being on the team, but I do know there are people who, if they left my company, would have an impact on my morale even though I never ask them for help or work directly with them.
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.
I've seen people like that, and I've been that guy. Ironically, I've been that guy only because I left years after those other men and women that I'd looked up to had moved on, and I'd filled their role for the junior devs who were hired after.
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).
A family friend (manages a programming group) kept a basically incompetent but calming, friendly programmer on her team for 2-3 years because of his effect on the emotional state of the rest of the team. She his pay was worth it for that reason. Unfortunately the company's owner eventually realized that he was paying the salary of someone who couldn't program and fired him.
The problem is much more about underperforming teams than well or overperforming teams. In order to dissect the problems of an underperforming team, they need some objective metric (even if it doesn't tell the whole story) to look to, or else you have to deal with people flinging accusations around and poisoning the entire culture.
This is what +/- and its variants are for. Especially useful for sports like hockey where scoring is rare. Of course, in a work environment this is even harder to try and measure, if for no other reason than that people are almost never 'off the court' and if they are there are many confounding factors.
Yeah, there's a bunch of advanced stats that more accurately model this in sports. My point is twofold:
(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").
This is what I worry about, and what I hope to avoid by asking who's tried it. I am hoping that my analogy is more imperfect than that. ;) Requiring people to hand out an assist quota to anyone that helps them, I hope, might be closer to each player rewarding assists to anyone else who passes them the ball. Since it's all players giving assists for any reason to each other, and not a single ref only handing out assists for the shot, perhaps that will allow for a fuzzier definition of success and a system that is harder to game?
My experience coaching a college sports team for a few years is that even very good players are often pretty bad at assessing the contributions of their teammates. They tend to significantly over-weight the contributions of players who have a similar style of play to themselves, and underweight the contributions of players who play other positions (or play the same position differently).
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 NHL at least takes into account not only the person who passed to the player who scored, but sometimes also the person to passed to that person as well.
In one of my previous teams, we did away with individual metrics because they "punished" team players. If an engineer spent most of a week helping another with their issue, it made them look bad in whatever tracker we used by almost every metric. I prefered sticking to trying to optimize whole team velocity and using 1 on 1s and peer reviews to track individual performance where it was needed (eg: compensation review and promotions).
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.
relatedly, a friend of mine worked at a place where everyone was on "20% time = bug time". You were expected to spend ~ 20% of your time taking bugs from the bug tracker and fixing them. Bugs closed were part of a metric towards bonuses.
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".
> It's still frustrating to know that this mentality infects so many professional "thought workers".
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.
Ah yes, bug counting. There is an even worse variant: when the manager only looks at the number of open bugs/issues, rather than what has been closed, or code that was checked in, etc. I had the misfortunate to work under such circumstances.
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.
In my naivety I've never heard nor thought about "what gets measured gets gamed". It's been my intuition for a while, but it explains much of what used to frustrate me -- I wish someone had told me this 15 years ago.
It's worth explicitly considering the two concomitant problems:
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".
This was one time where I appreciated living in the bay area. I found out 3 months into a new job that such metrics mattered. I was out before 6, and could've been before 4. Now I know to ask questions to prospective employers and look for signs of such crap.
It sounds like you need a 'reasonable person' clause - when considering bonuses, each metric gets looked at by a randomly selected group of peers and they can jointly decide if someone's gaming the system.
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.
Yeah we don't do metrics, we gather short appraisals from a list of people that you provide, that you worked with throughout the year. You are encouraged to provide names of people that are outside of your group. So if you helped some other team, this is the way you cash in on that.
Helping other teams succeed is a cultural thing and your organization has to encourage it with its practices and procedures.
The issue then is the other side of the story: you end up with popularity contests. Someone with a silver tongue will always win in peer review-based processes. No solution's perfect.
That is gamed too. You just don't include the names of people you have wronged: the bugs you have left for others to fix, the undocumented code, the projects you were supposed to complete but got reassigned so that you could work on something with higher promotion possibilities, the delays you cause in other people's work, etc...
This is exactly what I've seen happen in my experience and have often wondered about alternatives. Bridgewater, for example, uses a system that allows for feedback from anybody at any time [0], but I suspect that presents new issues like negative reviews from rival employees. Additionally, a lack of context could result in negative feedback for decisions that actually help the business (e.g. passing on requests to help colleagues with relatively low-value items in favor of focusing on higher priorities).
Nope; the benefit of being a good team player is that it helps you build relationships. Those relationships often turn into opportunities down the line. But it’s hard to drive that behavior at an individual level without creating some conflicts of interest.
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.
> 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.
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?
1. I normally just dedicate sprint points to training up new resources for a few sprints. I’m not so heavy-handed with the internal policies so it’s up to each team how they do it, but most have some form of pull request review / gating process.
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 :)
Good points but the thing that will prevent adoption of your approach is the element of variability.
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.
>Being a decent human being is not about getting practical advantages - otherwise sociopaths would be the most helpful people around.
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.
Tbh that's one of the reasons I always focused on teamwork at my last job, even though I was evaluated only on how fast I closed out my specific tickets. Since everything at the company was dysfunctional, I didn't really care about being employed long-term or getting promotions. Thus the only things relevant to my career beyond doing enough to maintain my salary was to build relationships with my team mates (building out my network) and developing transferrable skills for the future.
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
> 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.
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.
In a previous company, there was a feature in the intranet to give kudos to other people. Everyone in the company could see a kudo as a post in the global intranet "chat" sidebar (not really chat, more like a communal facebook wall of sorts that would bump posts to the top any time anyone commented on them)
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.
I think I may have seen a system like that, it had a sort of bluish tint to it :-).
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.
At SFDC we bought and used internally a tool called Rypple (later work.com) that was precisely that.
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.
Hah, similar thing happened for me. I think the main issue was that departments that relied on creative problem-solving (e.g. business development) ended up being way louder than others that didn't as much (e.g. QA)
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.
Every lead developer position I ever got came from helping people, but that doesn’t always stop the judging on output.
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.
At Google you can ask your coworkers to write feedback that would be included in your promo package. I wonder why the author didn't ask the developers that they helped to write a few sentences explaining how much time they'd saved thanks to the author's help. The hiring committee wouldn't ask for any metric if there were already a few people testifying that "I saved XX hours".
I am manager who has a few levels under me (Total team of about 100 people). I find it difficult to buy into your experience, and hear me out. I am arguing in your favor.
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.
Yea if a developer helps someone there is no guarantee that there will be an email chain generated as proof. If you truly believe this in all due respect you are out of touch with reality. People still walk up and ask for help. Maybe not in remote teams but in the office all the time.
Supposedly making these type of interactions possible is the whole point of open offices
Yes, people who have been around the block come to the same realization that the author does re: filing bugs. Any type of written communication or record that is not either undeniably necessary or unambiguously favorable must be avoided.
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.
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").
That reads an awful lot like you're optimizing for people good at leaving email trails, i.e. at office politics.
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. Weekly or bi-weekly 1:1s + read the check-ins. Check-ins don't lie. If you are not reading check-ins as an engineering manager, then you are going to be heavily affected by politics.
I've spent a few weeks working on an extremely high priority business issue and the only artifacts are a few issue tracker stories, my team's slack channel, and a "huge thanks to @...." on a public chat. If you're at a high enough level that you can't value someone's contribution from those artifacts, then you need to be trusting those under you and asking about people... you'll be missing why high performers are leaving.
The irony is that Google actually has a separate eng job ladder (Software Engineer, Tools and Infrastructure) which is designed to reward that kind of work specifically. If he had ladder-transferred (a fairly easy process) and gone up before a SETI committee with that same data (peer feedback on stuff like saved development time carries weight that metrics may miss), it probably would have turned out very differently.
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.
At my job, we use HeyTaco, a Slack bot. Every day you can give up to five tacos out by @mentioning somebody with a :taco: emoticon. If you answer a question or help somebody out, they will probably give you some tacos. The app keeps track of who gets the most tacos with leaderboards and the like. This has instilled a culture of helping others out on the team, by gamifying it and making it visible.
We use something like this in my org, and Google has "kudos", but I've found that the problem is their usage is highly variable even within a medium-sized or (we're roughly 1,000.) On some teams, the average employee will have hundreds of these kudos, whereas on others, the average might be 1 or 2.
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.
At least at Google I don't think that was their original intent - the idea was to provide a way for employees to express their gratitude away from the perf context.
I don't think they should be used for perf as they are not intended to be objective feedback.
Some roles (ops, sales) are just naturally a lot more inclined to use these kinds of systems. I generalize like that after having watched similar systems at 3 companies; you hardly ever see an engineer give a "taco" for a code review, but someone in another team might give one simply for someone knowing which room a meeting is happening in. It's hard to normalize the culture. I think peer bonuses (which usually require manager approval on one or both sides) tend to be a bit more normalized across teams.
That's what's dysfunctional about a lot of companies/our society. You persuade others to do/[help with] your work you are showing leadership and get promoted.
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.
In our team, we have our custom implementation of a web app like https://bonus.ly . The idea is, every member would be given a certain points(we call it jems) at the start of the month. He/she can give those points to other members who help them with the reason specified and it will be posted on a slack channel through slackbot.
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.
We estimate and log our time at my company Matters. Teams estimate a large budget if they don't know how to do it. When you assist another team you generally deal with the task in way less time than planned, therefore performing greatly.
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
At my company we use something called bonusly. You get 30 bonusly per month to give out to your teammates, and each bonusly is worth $1. You can buy basically anything with the bonusly you receive (amazon gift cards = anything). On top of being able to buy stuff, it also keeps metrics on which teammates help the most. The only downside is that you must give out all your bonusly at the end of the month (if not it's wasted money), so sometimes you start giving it out without really taking into consideration which teammate has helped you the most.
In my experience this often just becomes a popularity contest/give to whoever you eat lunch with.
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.
Yes. You can't change people. Your actual job description is worth 20% or less of your workplace success; as long as you're doing enough to stave off disaster, you are pretty much fine.
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.
I 100% agree that you have to put a lot of focus on how you interact with your coworkers. And further--most people can't take criticism well. At the end of the day business is all about people.
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.
> 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
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.
You're right that there are definitely people who are competent and have accepted the necessity of the surface-level accoutrements. The problem is that their direct knowledge of the worthlessness of those tokens means they will never wear them as sincerely and earnestly as an incompetent person, who believes that the surface-level tokens are competence itself.
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.
I really don't understand your point. It's not as though wearing clothing "good enough" to get "social brownie points" is difficult in most places. An ironed, well tailored outfit and simple color coordination is usually good enough to signal to people that you're credible. Most folks will not need to get into the finer points of fashion like the very latest trends and brand names. So I don't see where sincerity plays in when the bar to just reach the level of "looks like they have their things together" is pretty low.
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.
At Google there is a peer bonus benefit. You can peer bonus someone for doing something awesome. Each peer bonus is $150 before tax. You can list your peer bonuses on your promo packet. You can give as many of these out as you want ... within reason. Sometimes at Google they do something called a peer bomb, where many people will peer bonus a single person.
I can't imagine working at a company with this kind of system. Sounds a little too much like MeowMeowBeenz (http://community-sitcom.wikia.com/wiki/MeowMeowBeenz) from the TV show Community. ("MeowMeowBeenz™ takes everything subjective and unspoken about human interaction and reduces it to explicit, objective numbers.")
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 :)
Yep - See some of the work my last team published here while we were rebuilding deployment tooling: https://blog.coinbase.com/scaling-developer-productivity-d23.... For hard to measure metrics, softer measurements like repeated team surveys work fine too.
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.
It would be nice to have some sort of metric for this. I haven't experienced any.
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.
Where I work we are big on peer review. So in theory helping others should have value. It's still not perfect. For example, a junior may not be able to asses the value of your help, or anything else for that matter. People will still tend to rank their friends higher. While your boss doesn't rank you whether he promotes your work to others has a big influence on how they view you.
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.
> 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 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.
I academia, if you're a PhD student that writes the paper, you're the "first author", but anyone who helps you do research or process data or other contributions is a "second author".
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.
This system is actually designed to disincentivize assistance because only first author publications will net you scientific credits when it comes to jobs or funding.
At my workplace (Mixpanel), we use youearnedit.com. Everyone gets 2000 points per quarter and you distribute them out to whoever helped make you life easier or reward others for their effort.
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.
So, would you mind helping me see if I understand quadratic voting correctly?
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?
That's basically it. So say you had 10 people on your team, each person gets 9 votes. Say someone wanted to give only one person all their votes, the recipient would accrue 3 votes (sqrt(9)=3). Or they could give 2 people 4 votes each which would accrue as 2 votes (sqrt(4)=2) each for those two people and then you'd have one left for someone else. Then you tally up all the accrued votes (not votes spent) for all the people and then you'd be able to rank people according to how helpful they are (but this ranking wouldn't be transferable outside your team; you can't use it to compare them with the helpfulness of people on other teams).
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.'
If you are referring to the same QV paper I read, it spends most of the paper arguing for money but then at the end suggest a virtual currency at the end for those who can't accept their argument for allowing buying votes with money.
We use bonusly. As a proof-of-concept, I imagine it'd tackle some of your requirements. Bonusly points are tied to real world rewards, so there's incentive to use it.
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 don't have much experience with this, but I find it a very important topic. My opinion is that there are so many different aspects to teamwork and social cognitive biases are so huge, it's an intractable problem to do on an individual level.
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.
The company I work for has a kudos system. You can give any gift, but in practice everyone gives $25 amazon gift cards since they are almost cash. Employees are encouraged to give at least one a month to someone who deserves it. I haven't been through a performance review yet, but I wouldn't be surprised if they are taken into consideration.
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.
The company that I work for employs a system of peer review - where at the end of the year your teammates write reviews for you and your appraisal is based on that. It seems to work pretty well our case and definitely aligns the incentives of the employees with having an impact on the people around them.
> For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded.
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.
Google actually kind of has a partial solution for this. Your performance review is not just based on manager's assessment, but you also need to gather reviews from your peers.
However, you need to strike a balance between helping out peers and having impactful projects.
I work at Microsoft, and I know around promo time in addition to people on your team, managers ask for feedback from people not on your team that you’ve interacted with as well so that can be used in conjunction with whatever projects work you’ve completed.
The first thing that comes to mind is peer reviews. Although it's not inherently quantitative data and doesn't remove any of the bias/politics/etc. it can be a good indicator of who others feel are helping them.
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.
Googler here: The google performance and promotion process does, in fact, rely on reviews from your peers. The process happens once every 6 months, every other being non-mandatory.
Although your peers saying you were helpful is not enough, you need to demonstrate impact (and other attributes depending on your level).
One easy way to track this is tell every employee that each month they get 3 upvotes and 3 downvotes. The votes are anonymous. (If you have less than 20 employees, then maybe just 1 upvote and 1 downvote.) They vote for their co-workers.
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.
If you can see this from the data, then the votes are not anonymous. They are just not published to other members of the team.
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.
You can still collect this data anonymously. Rather than giving people a fixed number of votes, you have them vote for everyone, but use random methods to conceal the source. (This has the effect of hiding single complaints, 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.
> I've been planning to implement the "assist" metric,
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.
The first concern I had is that assist points that people assign to other won't be directly comparable -- so an "assist leaderboard" might be misleading and potentially cause more trouble than it's worth.
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 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.
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.
Lloyd Shapley already figured out a "fair" way to do this, called the Shapley value.
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...
What most companies do is give bullshit senior level promotions that way they can get 5 good years out of someone before they get the same realization it took him to get to in 2 years.
Once a team is settled in this can be hard to measure. For me personally I was able to show mine by changing teams and helping drastically inflate overall team velocity, not just by the number of points I added, but how much more productive everyone else became. It is hard to do on an established team where you're already part of it, though, and that's a problem I don't know how to solve.
Go on vacation for a decent period of time? In finance, key employees have mandatory two-week leaves, which serve to detect embezzlement. Here we could have the same, but to detect positive influences.
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.
maybe I'm being optimistic but a couple days ago I spent basically the whole day helping another developer getting a fix done so they could make a pull request before the deadline, I think that was noticed because we are in an open layout so me telling him do first A, then B, if you do C that won't work. It isn't working in QA because of this reason etc. etc
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.
One previous company had a system where one can reward someone who assists you, in cash. It shows up on their w2, post tax and in performance reviews. The amount you can reward depends on your level.
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.
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.
There are politics no matter where you are. Whenever two or three are gathered together, there is politics. Politics is just what people call interpersonal dynamics when they don't like a particular setup. The bottom line is that people all have their set of goals, and if you are lucky, your goals, their goals, and the goals of the company are well aligned. If they aren't the question is can you find a way of changing the situation so that they are better aligned?
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.)
It's definitely much worse in bigger companies, I see it in my customers all the time. Small organisations can't afford the sort of bullshit that goes on in a big business.
And probably the other way around, too. You can't have thousands of engineers without those politics and cultures that people will try to game. Google's ideas on how to structure promotions were great (removing manager bias and just judging by achievements). But once your organisation grows it's impossible to keep it in a way that's impossible to game. I've yet to hear of a large corporation where promotions are done fairly and talent is always recognised.
I thing I wonder is what role lifestyle factors play.
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.
The difference between Google and others is far more than 25% when you factor in total compensation. At least in my area, the difference between Google and the big players is more like 50-60%.
I'd choose a $200k job that gives purpose and makes me happy over a $300k job where that's not the case. At those levels where you're well off but still have to work (can't retire after 5-10 years from the salary earned), the increased happiness of 50% is often not that much.
If that works for you, sure. But most would seriously weigh that trade off. With another 70k / year after taxes you could retire way earlier and do whatever you want.
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.
Seems like you already earned your nut. Those that haven't might want to take that Google tradeoff, esp. if young and unencumbered, so that can get to where you're at.
Your middle-class also seems to be a bit different than my middle-class, especially in cities where jobs are.
The message you're responding to is literaly saying that you need to play the politics game in small startups as well. Perhaps even more so since you don't have clearly defined process of goals that lead to promotions and pay raises.
> 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".
And in my experience, it much depends on industry. There are truthfully awful places to work. Google doesn’t sound like it qualifies for that rung. I would be willing to bet many startups do.
The last time I was interviewed by phone at Amazon, I was asked to write a binary tree to a file. Time given: 30 minutes. Does that count as a puzzle? Did lot's on exercises on binary trees before but was not prepared for that question.
Nah, that sounds pretty simple - you just need to know how to walk a binary tree (basic knowledge) and how to write a string to a file (even more basic knowledge) - provided binary tree stores strings (and with right serializer, everything stores strings). Unless I am missing something. Don't think this qualifies as a puzzle. Puzzle would be something that requires non-trivial knowledge or exceptional insight to solve.
OK then do it on the phone with the interviewer looking at you as you're typing and your brain has suddenly blanked. I've been coding since I was 9 years old, have a massive (relatively) side project with a couple hundred users, have shipped multiple projects in multiple jobs, and I know what a binary tree is and how to traverse one, but I'll be damned if I can figure out how to do it under those conditions. I absolutely hate interview questions where they make you code on the spot. Just look at my Github, I swear I wrote that code.
That's not a puzzle, though. A puzzle would be something barely related to computer science, like "How can I find which ball out of 9 is heavier weighing them twice on a two-sided scale?"
Basic algorithmic knowledge questions are not puzzles, and whoever is calling them that is wrong. Those questions still can be stressful, especially for people that don't do well in interview environment, but puzzle is something else. Puzzle is something that requires some non-trivial insight or trick to solve, usually one that the person has no experience with and it is not obvious even for a person with the knowledge of the basics. That's why they are puzzles - they are "puzzling", which the dictionary defines as "confusing" or "baffling".
I forgot to mention the key part of the task. The key was to constitute the tree back by reading it from the file. The writing part is trivial, the reconstitution part is not. Try it. While not impossible for a decent programmer half an hour is not sufficient who does not deal with binary trees ona daily basis.
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.
First, just to make sure we are on the same page, are you in agreement that this wasn't politics, but perhaps a disagreement in the roles and responsibilities of a manager and an engineer and what an engineer is expected to do at google? I just want to make sure we're on the same page on that, which was the crux of my point.
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.
> 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.
To me, this thinking seems like a sure way to get an unmaintanable mess. Now, just polishing a codebase forever without adding any features obviously isn't a valuable way to spend time. But the difference between changing one value in one configuration struct and it having no unforseen side effects and having to go trough multiple classes and reasoning about possible thread races etc. Can make a huge difference in feature adding time. However, how do we measure this?
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 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.'.
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.
> Second, you're a lot better off working at a good company -- MUCH better off
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.
Yes. All intellectual property you work on, including in your spare time at home on your laptop, belongs to Google and you have to go through a reassignment procedure where they declare they're not interested in your work.
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.
Genuinely curious how enforceable it is, and how often it is enforced. That is, if you jump from project to project with your friends, on your own time and equipment, is there a legal case that despite whatever you signed its null? Similarly, how often does Google go after people like this?
"In the first place, nobody "works for themself". You might work for customers, or clients, or whatever, but not "yourself"."
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.
The customers still dictate your work. If you don't build the features they want, you won't have a business. Essentially you're still working for them.
Yes, sure, you're working for them; but it's still better (IMHO) to have clients than bosses. A boss is someone that uses you to look good to his own boss, but doesn't really care about what you do. A client, most of the time, actually needs what you produce.
I've been an independent consultant / contractor for over 20 years. I don't esp. defend clients, they don't know what they want and tend to change their mind often, but they're a million times better than a bad boss. (A good boss, I don't know, I never had one.)
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.
I know people who have quit full time jobs to write algo trading software for themselves to use -- the market pays them but I wouldn't call it a customer.
Interesting you went here. I've thought for a long time that trading your own money in the markets is the closest (urban) thing to leaving the cave in the morning, killing your food and dragging it back. The thought is appealing to me on so many levels.
As a junior engineer, what the best way to learn about and master the political game? I feel like it all goes way over my head. Does anyone have any recommended reading?
I think the author said it in the article: Optimize for promotion. Work from day 1 to game the metrics. If it helps your metrics, do it, if it doesn't approach with caution.
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.
There's another position that's similar but less gross, which is to have some humility about what you think is important vs. what work your manager/manager's manager think is important. Try to work on what they think is important not (just) because of a cynical desire to game the system and get ahead, but because they have probably more experience and (often a lot more) context than you do.
Of course, this only works if you have managers you feel like you can trust and respect in the first place.
That's definitely true too. There's a lot of developers who spend way more time beautifying code than they actually do driving the business. While sometimes great code leads to great business results, that's not a law of nature. The inverse and converse can certainly be true too.
Spot on. Most organizations spend time on how to do thinks than actually doing it. What i found out was to get some data as soon as possible, even if it has large caveats. That is more important than getting it right, becaude you wont.
I mean, there's a balance you can definitely reach. In alot of organizations, depending on the process, playing some Machiavellian game in order to try to get promoted the quickest is going to backfire.
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.
To add on to this, many jobs won't have good metrics in place, so promotion will depend on emotion and cognitive biases. Learning how to work these two factors is crucial.
You can do half and half. You don't have to game everything to make sure it boosts your metrics, but you also have to make sure you're not doing nothing that boosts your metrics.
Googler here: I think that gaming metrics is not that easy. Here by metrics I mean things like:
- Your impact on revenue (if you work in ads)
- Your impact on search quality (as assesed by independent raters)
- Etc.
If you can "game" these, I think you are solid.
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.
"optimize for promotion" is one way to frame but, but alternatively I'd suggest to only work on things you can prove to have value. You can do this by either actively convincing others it has value (politics) or more passively always relying on external validation of your judgement.
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.
As a senior engineer, I'd recommend not thinking about a "political game" most of the time.
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.
I'm a young software developer and I recently got promoted to manager of my team. Honestly, I feel like I'm not good at politics. I never focused on it, and I'm not particularly social. Of course, you always need to be at the right place at the right time. I think the managers I've had at my current company are great, so that helps.
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.
Technically sure, but that's not what people generally mean when they say "politics." Crappy politics is where you become friends with the "right" people, or throw the "wrong" people under the bus, or where you adapt your behavior to look good, instead of doing actually good things. Parent comment is saying instead you could consider how your actions can positively impact someone else, rather than just telling people what to do and what to give you. The latter is technically politics, but more generally is just the general way a good person interacts with the world. Think "win-win" from 7 habits of highly effective people.
Twenty years ago I worked as a contractor for a political operator inside an advanced tech part of IBM. He had plenty of technical chops, but more importantly he was a very good politician. We joked about us someday writing a book entitled "Rock Soup: The Art of Political Engineering". He told the rock soup story often, but it is more commonly known as the Stone Soup story. Study it carefully, as it describes some fundamental principles in an organization. When you are first starting out, you have ideas and energy but few resources. You must know how to paint a glowing picture of the future to those with necessary budget. Think of those people with budget as your internal VCs, except their risk tolerance is much less.
First thing is you need to actually be a good engineer. No point optimising if you suck, just put your head down and learn.
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.
I don't buy all this. Do your best work. Be nice to others as much as humanly possible. Don't treat it as a game, you might end up losing and get disappointed. Don't get your hopes up too high. We can't control everything. Be thankful. And surprise, you might just get the promotion for being more of a human than a machine.
I’d call it a must not, because then you’d be the type of person who takes life advice from books such as “The 48 Laws of Power.” It’s not a good look for most people, and not a good way to think about the world, IMO.
I think you're right, but I'll add that it's a great book to read and understand in a sort of "better at protecting from hacks by hacking"-style of learning. Understand and learn about the darker way of thinking and how power works so that you can navigate around these issues.
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.)
That’s fair, but readers should not assume that others are operating on these rules. I’m reminded of a conversation I had with a woman who bought a copy of The Game, at the recommendation of another woman, to “find out how guys think”, and it was difficult to explain why this was misinformed and would make her worse off.
Yes, all of Robert Greene's books are superb. Whether you buy into his philosophy and interpretations or not, there are many excellent, mind-expanding historical vignettes to learn.
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.
You can absolutely work for yourself. Google has customers too. If you work for Google, there is you, Google, and customers. If you work for you, there is you, you, and customers. You could metaphorically think of your customers as hiring and firing you, sure, in which case you have potentially millions of “bosses” and you can decide which ones you want to try to appeal to.
> In the first place, nobody "works for themself". You might work for customers, or clients, or whatever, but not "yourself".
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. :)
Also it's amusing to consider that someone got fed up with the politics of a workplace to 'work for themselves' where they'll need to battle the politics of many different clients.
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?
What about making your current employer one of your clients? This could even be seen as "taking one for the team" in the course of some restructuring process in that company? Just a thought.
I think you are misunderstanding the definition of "Work for yourself" in this context.
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.
In theory... yes you are diversified. Which why being a successful businessman is always more rewarding than being an employee. The keyword here is 'successful'. Diversifying your customer base to the point where you are not dependent on a few 'bosses' is really hard. Exciting yes. But hard.
And if you think there's no political games in your company then you're very naive. Your either not seeing it (which is bad for you) or its being hidden from you (which is also bad).
I suspect you are right, especially with the nature of our work.
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 automatically reject any premise that contains the word "naive" or comes across as if me, by virtue of believing in the greater good or the good in all people, am just being overly optimistic, so I'll do my best to engage at the merit of the arguments here.
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."
Politics is how people organise and group. There are always ploys for control and expansion. Politics is practically biology, there is a pecking order and it is inescapable. What determines in and out group varies but it is always there if there are three or more people present.
I think what you're describing, I'd describe as "organization," rather than "politics." When I refer to "politics" in this conversation I mean something along the lines of "performing actions that are not company-goal-optimized, or, potentially detrimental to other employees, in order to advance oneself."
I don't know if I agree. I work directly with clients together with another dev and I do most sales. It's not 24/7/365. I sell, network and meet new contacts maybe about 35-50% of my week during intense sale periods. I work 35 hour weeks. All year through I have about 4h per week in sales activities.
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.
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.
That doesn't really follow. As an independent worker, you answer to your clients. As an employee, you answer to your single client. It's basically the same deal.
It's not quite true: places of employment that are ok with you firing a client, while they exist, are rare. When I was an independent contractor, I was loath to fire a client because they can be hard to find, but knowing I could and doing so was a good feeling. I don't know if the positive of that offset the mental stress of generating clients, but it was one of the positives. So was the freedom to work when you want. I now work remotely full-time for a company with an incredibly flexible attitude toward getting your work done, but I still feel guilty for running errands on "company time". The flip side to that is when I worked for myself, all time was potentially company time.
It's not really the same. You have way more control as an independent operator. Yes, you have to answer to your customers, but only to the extent and to the degree you desire. It's not at all the "same" as working as an employee.
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.
Not really. In a workplace you're forced to follow all sorts of rules. As an independent operator, you set your own rules.
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)
The larger the company, the more process overhead there is.
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.
>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
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?
Don't think only of the political angle. Think of your work as a product that needs clients, value, exposure, and which has to compete in a crowded market against similar products from other people. Understand the balance between work that is pleasurable to perform (challenging problems, etc) and work that others find valuable. Don't be cynical about all this, lest you become a dick (there are hints of this in the OP).
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.
But, not the ones who know how to play politics. Tyrion is still very much alive, whereas Ned Stark, who was a very righteous man, who thought himself above politics, is dead.
> Second, you're a lot better off working at a good company -- MUCH better off
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.
I suppose that depends on what you categorise as 'high reward'.
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.
Just clicking on your profile I see you work in London. From what I can tell most programmers don't get paid 'ludicrous amounts' there. Though maybe you have a rare role, or maybe you just have a very low threshold for what you consider ludicrous.
You are correct about the tech industry here (low salaries relative to US) but developers working in finance in London make comparable money to Bay Area tech firms.
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.
That is so no true in my experience as someone working in finance in London. Can you name 1-2 companies paying 100k for graduates or 200k after 5 years?
That's not true as such. £100k with no experience is very hard to achieve, even with long-term comp. Maybe if you work at an algo trading company and get paid by the performance of your algorithms. But then it's more like being self-employed (they just provide seed money and some basic salary).
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.
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.
Same here. At some point I was disillusioned with the idea of working in a corporate because I thought I was just "selling my soul out for golden handcuffs" (doesn't help to watch some Mr. Robot, Fight Club, etc.), but in reality I was just a junior dev who didn't fit much into social hierarchies. I tossed away a good 2.5 years at two startup jobs, one that I co-founded and died slowly (even though I had already read Lean Startup et al...), before slowly realizing I just wasn't making any meaningful amount of money nor progressing in my career because I didn't have a senior/mentor/best practices guiding me. Now I'm back at the cubicle but realizing there was so much I missed out on that wasn't obvious to my younger naive self before.
What sorts of things did you miss out on? Is starting a company still a valid option if you have a senior/mentor and are familiar with best practices? How do you get those things so that you are successful?
>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"
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?
Working for yourself is no guarantee of higher rewards but it does have the possibility for higher rewards. The key is to focus on opportunities that have the highest potential outcome. I like to think about business opportunities as something that can generate FU money in 10 years or less. If it doesn't meet that level, you might be better off on the slow and steady upper-end corporate gig.
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.
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.
The article really resonated with me, as it's eerily similar to my own experience at Microsoft a couple of years back. Constant reorgs, resulting in projects being cancelled, resulting in lack of motivation, as months of your hard work are thrown out due to unclear decisions by the management.
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.
> 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.
Both are businesses, and most successful businesses are sociopathic. That includes game theory both with customers and internal resources. You are a "human resource", not a friend.
This is where I think academia has got it right. When you do something, you get full credit on it -- your name on the paper, your face on the book and department website, you're the one giving the presentation, you're the one who gets the benefits if it's commercialized (after the university takes its cut). Loyalty also is valued (or a less negative word to use is being a team player), as people write recommendation letters for each other and their reputation is at stake when they do anything.
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”
From the company's perspective it's always a game of getting maximum effort/value for minimum price. From the employee's perspective it's the exact opposite: maximum price for minimum effort/value. If they can dangle that carrot in front of you and get you to give 110% at your current pay scale for 1-2 more years then why the hell wouldn't they do it? And how many people grind away on that treadmill after having that conversation with their boss? For every post like this there's gotta be hundreds if not thousands of people at these big companies that put their noses back to the grindstone to keep chasing that promotion.
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.
"If they can dangle that carrot in front of you and get you to give 110% at your current pay scale for 1-2 more years then why the hell wouldn't they do it?"
Cause that's a shitty thing to do. And, as shown, it leads to people leaving.
Yes, (most) people care that it's a shitty thing to do, but again companies like this do not. Their goal is to grind as much productivity out of you for as cheap as possible. It sounds fatalistic but it's just how it is. Romanticizing things just leads to heartbreak.
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.
I can see that now and completely agree, but back then - much like the author of the original post, I was eating up the whole idea of being more than just an employee, of all of us being in it for a larger goal.
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.
>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.
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 know of someone (not in the same company) who was offered a one time large cash bonus to stay for at least 12 more months. He took the offer. Unfortunately I don't know where that has lead to in his relationship with the employer.
I too would be interested in knowing if that has actually worked out for anyone long term.
It worked out for me long-term. It really depends on a lot of factors. In my case:
* 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.
Well that's the difference then, you were headhunted and they wanted you to stay. That isn't perceived disloyalty, it is the exact opposite: you wanted to stay there but be compensated the same way.
Sometimes they can be caught off-guard with your unhappiness. Usually, you're not announcing that you're interviewing at other places for the same reasons. It's all in the game, I guess.
Well, the goal of a promotion is to both enable the employee to get more responsibilities and the company to get more out of the employee.
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.
Wow, this just brought me back to a "career ladder" conversation I had once upon a time, where my manager said that they promote people to positions when they're already operating at that level. Sounded good at the time, I never realized the implications until now.
Everywhere I have worked, if I had gone to my manager's manager without his explicit instruction to do so, would have led to my manager spending 100% of his time trying to get me fired because I would not be a wild card in terms of messaging to his boss.
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
Sounds like your bosses have been a little micromanagey. Talking to more senior managers have been great ways for me to gain valuable perspectives on their goals and ask questions about how to achieve them. They should also be interested in a more unfiltered view from talking to the rank and file.
I've been in corporations where this is not always possible. (Mostly, politically speaking, though IIRC at one job my grandboss was not located in my building/city.)
Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front.
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.
> Writing documentation and fixing bugs is in fact not the bar for a senior software engineer.
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.
> The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
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.
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.
>>The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.
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
The role of a senior software engineer totally is to handle bugs and produce docs. The difference is that seniors should expect to work on more difficult systems, bugs, and documentation tasks.
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.
To me a senior software engineer can, with mid and junior engineers at their disposal, design, document, implement, deploy and maintain systems that have a demonstrable ROI for the organization for a long period of time after deployment.
The notion that "a junior engineer and a manager who is at least partially paying attention can get that done" is a horseshit excuse that could be applied to 99% of what any given developer does. Moreover, developers find themselves having to write tests and fix bugs because the priorities of upper management didn't allow it or foster it for the last developer.
> developers find themselves having to write tests and fix bugs because the priorities of upper management didn't allow it
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.
The problem is dishonesty. I've never worked for a company that would at least admit "our primary focus is selling rather than software quality". I know it should be implied, but when work is advertised as "looking for ninja pro engineers dedicated to their craft to help build top notch software", no wonder people get misaligned on values.
Have you ever worked for a company that was faced with running out of money? Things get real pretty quick when you hear you only have X months of runway.
Then upper management needs to be forthright in their priorities. Have you ever worked somewhere that didn't tell their developers something like "we expect clean code and quality software"? I don't think I've heard of somewhere that owned up to the fact that their primary interest was to pump out software despite a lack of code maintainability. I'm sure that the teams that produce hot garbage for Oracle tell themselves that they care about code quality.
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.
Yeah, I agree with you that you can't build a system where people get promoted to Senior Software Engineer just for fixing bugs and writing documentation. I do think it should be worth something.
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.
Certainly it counts for something. And I fully support it leading to great reviews for OP. But being good at your job isn't the same as being able to do the next job up the promotion ladder. OP was likely on if the most impactful engineers at his level, but he failed to demonstrate he could perform the job of a Senior Engineer, which has a much greater scope than bug fixes and documentation.
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?
The issue with this is that it leads to people choosing projects based on what they think is promotable and doing the bare minimum on anything else. Which is how you get code with no tests or documentation.
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.
> Which is how you get code with no tests or documentation.
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.
I obviously don't work for Google - so an outsider's opinion:
- 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 :)
> 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.
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.
Yea this is maddening. “We can’t pay you anymore because The Book [1] says we can only pay people at your level from $X to $Y and you’re at Y. We can’t promote you because you are at the highest individual contributor level. And we cant make you a manager because you’re on a 2 person team and there is nobody to manage.”
“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.
Diving into a old undocumented codebase and then deleting code, rewriting code and document it without breaking stuff can be more challenging than designing and writing new code.
"terminal level", in the sense being used by the OP, doesn't mean "end of the IC track". It means a level that you can be at "forever". Often times the junior engineering levels have some expectations around eventually being promoted (ie, "up or out").
IIRC, at Google the levels below Senior Engineer require progress toward a higher level as a job requirement. So that even if you're performing well at that level, if you aren't showing progress it gets counted against you in perf increasingly until eventually you are at risk of being pushed out.
Terminal level and Max mean different things here.
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.
I think google itself follows that same path of promotion, ending in a fellow position after distinguished engineer? I wonder how many people at google have the fellow title.
It doesn't sound like they meant that senior was the last possible level, just the last level to which promotion in a career should be expected through "normal" growth and development. It looks like less than 1-2% of engineers at my company (FAANG) are above "Senior".
yeah, but responsibilities (and technical complexity) grows with each step, and many people, for whatever reason, stall out at one level for most of their career.
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.
I think you are mostly correct. But the problem with Google's promo/perf process is that there has until very recently been the expectation that all employees eventually get to Level 5 (Senior Software Engineer). When I started it was outrightly stated that if you didn't get to this level within 5 years, you would probably end up getting, ehh... scrutinized.
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.
There's also the problem of comparing apples and oranges.
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?
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.
This covers a lot of the same ground as Brendan Reid's "Stealing the Corner Office"[1], which gives a playbook for helping stuff like this work in your favour, rather than against you.
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.
I guess my question is: Can you get job satisfaction from promotion-focused work? I'm proud of what I've done. When I make someone else's life easier, that makes me feel good/satisfied with my work. I can't fathom satisfaction from impressing a promotion committee and tacking on a bigger title.
It's not necessarily a binary choice: you can do the same work, but be more strategic about how you promote it, before, during and after.
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.
Except none of that would matter if some rando on promo committee (at Google) or just your skip-manager elsewhere (that you don't have access to) can't see value for whatever reason. OP doesn't even begin to scratch the surface of all the fuckery that was going on with Google's promo committees which is why they recently moved away from that for <L5 promos.
I don't give a shit about titles I just want to be paid appropriate to the value I create, and unfortunately in most companies, the best way to get a big salary bump is to get an upwards title change.
I remember one company I told them flat out - I'm going remote. Love it or leave it. They let me do it, but told me because - state has a lower salary in general, you may see some kind of 5% pay decrease at some point.
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.
The general idea is that the things that would impress a promotion committee are things that you have done, that are good for the company.
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.
The problem is in measurability of a change. If I improve a developer or analyst workflow that makes 100 people 1% more successful, that's likely both more beneficial and also harder to measure than a change that makes 5 people 10% more successful.
That's the bit where the GGP's "optimising for the right factors", or something adjacent to it comes in. Many things can't be objectively measured, and upon realising that, many techies give up. But there is subjective truth, which for sure is a lesser truth than the objective sort, but truth none the less. How did you come to believe that you've made 100 people 1% more successful? If you can convince yourself that you've done good, important work, you can probably convince other people too -- but you have to do it, they're not going to convince themselves. Collect the evidence, such as it is, and articulate your case.
The point is that it's on you to articulate the value of what you're doing. Some activities are "batteries included" when it comes to metrics, but a great many aren't.
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).
It might be good for the company. But the point is you need dollars and cents metrics that prove it is, not just righteous feelings that less bugs is better. Engineers at ground level are often well insulated from the actual business impact of the work they do. Because they aren't given any insight into the business side they instead optimize for measurable metrics like bug count and data accuracy.
Because google has a "technical ladder" document which mentions words "complexity" and "impact" like a dozen times and the word "quality" like once or twice ;-) That document is supposed to be used by promo committees to eval if you are "ready".
Agreed. In the book, “Secrets to Winning at Office Politics”, this type of person is know as a Martyr: Someone whose actions help the company but hurt or do not help themselves.
The important point is that helping the company and being promoted are not necessarily correlated and may in fact be orthogonal.
<holds envelope to forehead> Because you made enough money that it was an affordable risk?
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.
The compensation made it both easier and harder to leave. Easier because I had a giant safety net squirreled away, harder because they kept offering more.
"Four years' worth of GSUs oughta be enough for anybody."
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.
I thought "oughta be enough for anybody" was an obvious "640KB" joke, but maybe I'm just old. Anyway, it certainly is enough money to appropriately cushion an attempt at freelancing.
And the best thing to do after leaving a job at Google is to move somewhere cheaper!
Whenever anybody pays you good salary or even adds stock shares to it, doesn't mean they can wipe their feet on your personal attitude or consider your job efforts as garbage.
If author wanted to express this opinion I completely agree.
How is four years of GSUs enough? Four years is in the low six digits. Being financially secure in the Bay Area requires an order of magnitude more than that.
I'm also a Googler. Upon joining I was also given the keys to an ancient data pipeline, due a redesign for at least five years at that time. The person handing me the keys left almost immediately. My task was also keeping the thing adrift and nursing it back to health, whatever it takes. I did get promoted for that. The metric I used was pretty much the amount of developer time that went into supporting it that was saved by my damn ugly hacks. It was collected by asking nicely for the affected folk to confirm their lives got better.
Were you going from junior (L3) to intermediate (L4)? If you were, then the task you described seems appropriate - you don't have to do much to go from L3 to L4.
The author of the blog post was going for senior (L5), which you can't get just by maintaining code.
To be fair, a lot of that can depend on your manager. Your manager (should) have a better perspective on what resonates with the committees, help you gather/frame the data, and polish the package.
Google managers might not be the ones doing the promotion, but a good one can help you get there
Because you didn’t show graphs but showed testimonies form actual humans. Which I would assume, I don’t know for sure, that business people see graphs or hear grand ideas all day long and just really wanna know “yeah but is this actually improving anything for anyone?”
Well, glad to hear the system rewards good, unglamorous work sometimes!
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'm glad you put in the work to write down your experiences, and I'm glad that HN is rewarding this.
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.
I used to believe that middle managers were useless shits who wasted my time and got in the way of work. I imagined that the flat organizational model made more sense: since this is what my day to day life is, anyway, at least we get rid of idiots who get paid more than me.
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.
The problem is that management is basically an art and no one knows how to create consistently good managers. Because it's the epitomy of soft, unmeasurable, skills.
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).
Exactly! I had the oppsoite tragectory - first worked in a company with decent mid-management, then no management startup then Google. The lack of oversight seemed liberating at first, but man was I not impressed with the outcome by the end of it (including my own performance). In Google's case it was additionally complicated by the fact that most senior people avoid as much as possible to take on leadership roles - lower levels will have no say on their promo packet.
> I never understood why Google favored this over a good old proven management model where your boss would handle things.
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.
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...
After 15 years of doing this my theory on corporate promotions is simple: you need an executive sponsor.
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.
> The OP complains about not having enough metrics in his assignments but do committees promote people based on stone-cold, anonymous metrics?
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 can't befriend everybody, true, which is why you should identify one senior executive you think can help and market yourself to him or her (again, I wish it didn't work this way, but it seems to).
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.
Anywhere else, yea, but at Google specifically, not an option. Executives don't override the committee, except maybe Larry and Sergey. And if your advice is 'be friends with the CEO', I'm sure that'll scale right up.
The good news is that, based on reports from Googlers here, it sounds like the system is changing for the lower promotion tiers.
How did 'a senior executive' become the CEO? Obviously absurd and clearly not what I wrote.
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.
I didn't say the committee was numerical, though their reputation is such. OP's challenge is that Google's promotion committee isn't an executive panel, or subject to appeals except from perhaps the highest executives. It's a random panel of experts who you'll likely never have met, because the company is 100k engineers, and working on your small corner of Maps or whatever makes it unlikely you'll have ample opportunity to meet people from Security, or Search or Adwords or Adsense or Golang or Youtube or Nest or any of the myriad of other products besides yours from which the promotion panel is randomly pulled. You're essentially suggesting that to go from say Software Development Engineer 2 to Senior Software Development Engineer, you need to simply schmooze a few thousand coworkers.
> 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.
> Google's promotion committee isn't an executive panel, or subject to appeals except from perhaps the highest executives. It's a random panel of experts
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.
> 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.
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.
It's certainly possible politics and soft skills don't play prominent roles in promotions at Google -- I've never worked there.
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.
This is why people change companies every two years. It's easier to get a promotion by studying for interviews on leetcode than by spending the extra time promo gaming in one's career.
"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.
This has been true everywhere I’ve worked in tech. It is far, far easier and a straighter path to “level up” to a different company than to get promoted internally. Without a single exception, and even in the depths of two tech hiring downturns.
So I just checked out leetcode... it's supposed to be for juniors or undergrads, I assume? The hardest problems on there seem pretty trivial, especially when compared to the problems on projecteuler.
Google is changing the promotion process such that managers have much more power (for all promotions up to level 5 == senior swe).
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.
Sounds like googlers should go manager shopping then. If your manager is too passive or doesn't care for what you're working on, you'll be in the same boat.
I would trust my manager to not abuse that power. If he would start using it, I'd first try to change team or, if not possible, just change employer. Hopefully, for the sake of the organisation, people quitting would reflect badly on the manager over time.
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.
> They offered me a promotion and over 90% raise but I simply did not care anymore
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're describing knowledge work at many companies.
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.
Happy to see this post because reading the thread I was poised to say much the same thing.
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.
> Google does a good job of building a sense of community within the organization.
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)
There is an excellent book I read recently called Developer Hegemony [0] which goes into depth on your first point. It calls the naive folks "optimists" -- unfailingly devoting themselves to the company ideal. It discusses two other factions, the pragmatists (come in, do work, get paid, go home) and the opportunists (take every opportunity to rise to the top). I recommend checking it out, and the author's blog too [1];
Sounds like a "nicer" rehash of the Gervais Principle. I haven't read Developer Hegemony, but from the looks of the author's blog, I would recommend "cutting out the middleman" and going straight to the source material: https://www.ribbonfarm.com/the-gervais-principle/
Not at all. Gervais Principle is a joke, though some serious research may have been done around it. It's about organizational dynamics.
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."
This is absolutely correct. These rules are also specifically there to self-select only those capable of understanding and navigating the meta rules, as only people with the capacity will be able to run a company like google at a senior level.
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.
The promotion process at google self-selects for a very important skill: you are given a certain goal and you find the optimal way to achieve it, regardless of whether you agree with it or not.
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.
Slavoj owes much of the theory to Hegel (which Stavoj is a follower of).
This video is a very light intro to Hegel by Rick Roderick:
https://www.youtube.com/watch?v=2MsNyR-epBM
> 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
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.
As I've progressed from job to job (and everything in between), I've learned how important tracking your personal metrics are. I've trained my mind to always record the before/after for any project I work on and keep a written, screenshot'd record of the impact. Every single time. You should ALWAYS be ready to answer the question (presented to you in a direct or indirect manner), "Why should we continue paying you $X."
Early on in the article you describe the excitement your younger self had a the prospect of working with the "best engineers in the world". However further down you describe your difficulties with some products - undocumented code with no unit tests and silent failures which are hard-to-diagnose.
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.
No, I found developer quality to be very high at Google throughout my time there.
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.
Did you really believe you were working with the best developers in the world though? Did you not realize this was all part of a marketing machine to make you feel good?
I too was also intrigued by the statement "best engineers in the world" and then subsequently reading that Google engineers suffer from the same BS as any average software company.
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.
I've been working on open source software for the last couple years (links in my profile).
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!
Thanks for sharing this, I've not been (and never will be) a SV employee, so it's interesting to see such a different perspective.
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.
Is your experience common for rank and file Googlers or specific to your role/department? Lots of unrecognized maintenance work, constant project changes, lack of transparency between employees and management. Sounds like an undesirable situation, are these issues that are so widespread there that transferring to another project isn't a likely solution?
Yeah, I think my frustration with the promotion process is pretty widespread. People recognize that the promotion process is flawed, but they also recognize that it's hard to fix. And Google is aware and working to fix it, but making changes to something so important in a 70k+ employee organization is slow.
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.
You are a good writer and I enjoyed reading the article. I agree with many of the other points written here such as politics being omnipresent in the corporate world.
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.
I'm not the author of the article, but I did create Indie Hackers, I've talked to many hundreds of smaller indie founders, and I also went through YC where I met many hundreds of moonshot founders (and was one myself), so I have some perspective here as well.
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 very much appreciate the reply (only saw it now).
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.
nice article although its sad you couldn't get recognized for the value you were adding.
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.
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.
Except, if I got the sequence right, it turned into "bait and switch:"
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.
Are you familiar with the writing of Patrick Mackenzie? patio11 on hackernews, kalzumeus.org.
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
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.
Oh, thanks! Yeah, for most of the blogs I link to, I'm in communication with them and they react really positively to the site. I want to have a symbiotic relationship with them as much as possible.
Nice. Do you think large companies would benefit from a different scheme that rewards employees who "think like an owner"? (pardon the oft-used phrase)
Yeah, but in fairness to Google, it's not an easy problem to solve.
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.
At risk of stating the obvious, not all the medium/large tech companies work as described in this article. At Atlassian, for example, the direct managers are the ones who make promotion recommendations, it’s very much driven by your contributions on your team, whether accompanied by shiny metrics or not.
True, but conversely, many large companies outside of tech have a very similar disconnect between the reward system and the actual work that benefits the firm. I saw this when I was working at a bank. Even in a profit-transparent business, politics and optics played a larger role than raw performance and team support.
It is, to some extent, a direct function of scale. The larger you get, the more you need to rely on systems instead of individuals - because it's easier for bad apples to hide in the noise. (How's that for a horribly confusing metaphor? ;)
I don't think so. Although it's worth noting that Google isn't big on deadlines. They set quarterly goals, but on the teams I was on, they weren't taken very seriously because it was so common to be pre-empted by other tasks. But I never got any kind of feedback that my projects were shipping too late.
I'm going to be applying there soon, 4 years into my career. It'll involve a loong move and big changes: what advice can you give someone who wants to spend a couple years (or more?) with the big G?
I recommend applying for a promotion early, even if you don't think you're actually ready. It's valuable just to go through the experience end-to-end.
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.
* Negotiate the title hard! very hard! Harder than you ever have. It is much easier to get a higher level at hiring than ever after.
* 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!
> I proudly and lovingly nursed the pipeline back to health. I fixed dozens of bugs and wrote automated tests to make sure they wouldn’t reappear. I deleted thousands of lines of code that were either dead or could be replaced by modern libraries. I documented the pipeline as I learned it so that the institutional knowledge was available to my teammates instead of siloed in my head.
> 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.
Google has one of the worst monocultures I've ever seen in my life with a heavy emphasis on commoditization. It's a giant machine treating software engineers as nothing more than easily replaceable cogs.
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.
I recognized your username from all your work in the Sia community. Thanks for helping to make it better.
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.
I think that Google does try to treat their employees fairly. I don't think the promo process is the way it is because of greed.
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.
I can understand why they do it, having someone incompetent in an important position is way more dangerous for the company than having someone competent stuck in a lower position.
But it's still a risk to lose good employees, talent is very valuable.
Wow, that was exactly the mechanic I observed when working there. The result was pockets in the company where people worked on stuff that they didn't understand and were not (yet?) clued in that nothing they did would get them promoted and yet if they broke anything it would get them fired. Helping those groups to change things for the better should have been a pretty impressive thing, but my observation was that wasn't understood by the promotion committee.
A cacophony of management dissonance, bureaucratic internal processes, your job being outsourced to India and then being asked to clean up the mess created by said India team...
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.
"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 have had exactly the author's experience at prior jobs. Quite literally the EXACT experience.
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.
When someone tells me "I'm a software engineer at XYZ", the first thing I ask is - in what team are you in? If your role is to maintain internal web pages or to build random tools for the marketing team then yeah... it doesn't have any meaning. Sure, you still get the benefits of being an employee at XYZ, but it's not super fulfilling. I'd say %30 of developers work on cool things in these companies and the rest of the dev just fill in the blanks. I've worked at a few of the Big-5 and that's what I've observed mostly.
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.
Completely anecdotal but I was talking to a Googler who had basically the opposite experience and recommended working at Google because of the promotion panel. The fact that their manager had no say in the process and that they could put together their promotion packet on their own was a feature in their mind, because their experience included their manager "forgetting" to put them up for promotion repeatedly at other companies.
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.
I worked at Yahoo during a time of pseudo stack ranking (QPR). Managers had a target for average rating, and most managers would identify a few people for promotion and give everyone else "Meets Expectations" reviews so they could give the promotion candidates "Exceeds Expectations".
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.
Frankly there are far more toxic and awful large companies to work for. I think with the perf/promo process being what it is Google was intentionally trying to avoid the really bad nepotistic and political parts of some other large (or not large) corps. But they introduced other problems, which the article writer alludes to.
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.
Pretty much why I left as well. Wasted years on improving existing stuff rather than building new stuff. Google doesn’t value improvements, even very significant and quantifiable ones, except if you’re improving CTR or relevance. Promotion-wise working on a hot new project which will flame out in a few years is 10x better for you to “demonstrate impact”. Quality be damned. If you launch new shit, you get a lot more brownie points. Googlers, don’t be stupid the way I was. If you’re looking to get promoted, get on a hot new project and steadfastly maneuver away from any and all work that doesn’t look worthwhile in your promo packet. This sucks for Google in the grand scheme of things. But the alternative will suck for you, and your first priority should be you, in spite of what anyone says. Anything else just leads to suckage and unhappiness.
As a business person, you're going to have to sell yourself/your services to other people. Perhaps that's not too different from pitching yourself to an "anonymous promotions committee"?
Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!
>As a business person, you're going to have to sell yourself/your services to other people. Perhaps that's not too different from pitching yourself to an "anonymous promotions committee"?
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!
I prefer pitching to customers because they really do get more value out of your product if you better communicate what it does and how it helps them. With committees it sounds more like playing a zero-sum game.
I would argue it's different, because customers are harsh but rational, while promotion committees are more capricious than
harsh.
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).
> As a business person, you're going to have to sell yourself/your services to other people. Perhaps that's not too different from pitching yourself to an "anonymous promotions committee"?
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.
Good luck with your new programming adventures. Just based on reading your article I would say your mindset is in the right spot to be successful on your own.
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.
My first full time job was as IT support for financial auditing/IT auditor. I didn't stay there long, but I learned this quickly: get a paper trail going ASAP. You never know when you'll need it, either to toot your own horn or to fight back, especially against bullshit :)
This question may be an odd one, but how did you create the little cartoons in your blog post? I feel like they really improved my experience as a reader, and if I were to create content in the future I wouldn't mind knowing if there was an easy way to include something similar for someone with little to no artistic skill.
Thats not just google mate, every large company is like this. We join thinking that our engineering will make a difference but it does not work like this. If you want to climb the ladder either join high, or grow through a smaller company.
Thanks for writing this and good for you to finally leave that wasteland. I learned an important lesson on my first job "Don't be suckered into being loyal to your company because, no matter what they say, they are loyal to share holders, not to you".
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).
It's part of a subtle marketing machine. It starts with the interview process
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
Thats coz, You sign a waiver as part of your "1 week intensive keeping secrets bootcamp + orientation" that Thou shalt not blog about anything while you are employed at Apple. That means anything. Infact there is a very stringent policy on what is acceptable and not kosher when it comes to posting on social media. Thats why you dont see anything from Apple employees. Not that they didnt buy in to the Steve Jobs Think Different, Your work is so much more important than yourself Koolaid. Its just that posting anything without approvals can be a career limiting move. Source- Have a couple of friends working on Hardware side and one working Frameworks test group.
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.
Yup. If you don't have a manager who works their ass off to help your career, you don't have a good manager. You recognize them by the fact that they usually talk a lot about what management means, and what it should do, and aren't afraid to change that opinion if they learn something new.
On several occasions, I put my projects on hold for weeks or even months at a time to help a teammate whose launch was at risk. It was the right decision for the team, but it looked unimpressive in a promo packet. 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. I was just the mindless peon whose work was so irrelevant that it could be pre-empted at a moment’s notice.
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.
This sounds harsh. In cases you are a significant contributor to a launch it should be signifiend in the "launch entry" (there's an internal tracking tool for all launches).
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.
The teammate in question should hepefully support these claims.
Sidebar: This was really great writing for a software engineer! It's a skill a lot of highly-technical people lack but can have great impact when you combine storytelling with technical expertise. I saw one of the author's plans was to write more and find ways to monetize it -- I wish him luck and gave him a Twitter follow to keep up.
> If I ever made a mistake at Google that cost the company $10 million, I would suffer no consequences. I’d be asked to write a post-mortem, and everyone would celebrate the learning opportunity. For most of these founders, a $10 million mistake would mean the end of their business and several lifetimes of debt.
This is not as insightful as it seems....risk tolerance should be a function of percentages, not square numbers.
I think that's true, and obviously there are a lot more situations at Google than a small company where you're even in a position to lose $10m.
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.
> This is not as insightful as it seems....risk tolerance should be a function of percentages, not square numbers.
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?
If you %s/google/<your-current-company>/g , the story wouldn't change. It depends on the way you showcase your work to your management and peers is the secret of the success. But for some it is against idealism and "do good" nature. This same story happened to me but in another enterprise. The solution that worked for me is to find a Manager who knows your talent and gives you freedom and he does the marketing for your work knowing your strength. But it is uncommon to find a good manager that fits above qualities.
> I was surrounded by the best engineers in the world, using the most advanced development tools in the world.
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)
Google, Facebook, Palantir, Microsoft - it's a narrative that those organizations spend dollars to support because it helps them in recruitment and in b2b consulting. It is similar in investment banking and management consulting. The employees lap it up, and learn to talk-the-talk. Each of these tech companies are cash cows with huge locked-in revenue streams that do not depend so much on innovation for survival. IMO Amazon and Apple seem to be organized around accountability and sink or swim projects which create a different walk-the-walk culture, similar to start ups. Though I'm just an outsider looking in.
My feeling also. The whole "At Google everyone is THE smartest in the world": This is marketing "talk-the-talk".
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.
> I submitted my first promo packet, and the results were what I feared: the promotion committee said that I hadn’t proven I could handle technical complexity, and they couldn’t see the impact I had on Google.
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."
Yeah, exactly. I only found out after I did my first promo attempt that the committee is expected to grant the promotion if you've fixed the gap the last committee identified. I wish I'd known about that earlier so I could have gotten my gaps defined explicitly.
You don't try to get promoted in engineering. You do a kickass job, and those above you notice and promote you or at least give you a raise/bonus.
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'm glad that this has worked for you but it's not like that for everyone. Also it's very stupid in many ways that people constantly just have to jump ship to get a raise. I might really love my work, be learning a lot, work with great people, but I have to fight tooth and nail to get a raise -or- waste a bunch of my time constantly talking to new companies. And then my current company loses someone with a lot of domain knowledge too. I love programming. I really do wish I could just sit down and code. Companies are always talking about wringing out the last drops of productivity but they don't reward programmers for focusing on code, but instead the business side of things and constantly jumping ship.
I play the game like most people do, of course. But it's a stupid game.
As someone who will be entering the industry, I loved your perspective on your job at Google. Also, having read Cal Newport's "So good that they can't ignore you", I couldn't help but notice the hunger for independence in good software developers. Would you recommend newcomers to join smaller unstable( more independence) companies or bigger, more stable( Top 4) companies(lesser independence)?
>Would you recommend newcomers to join smaller unstable( more independence) companies or bigger, more stable( Top 4) companies(lesser independence)?
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.
I highly recommend optimizing for salary for the first 4 years.
~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.
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.
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?
The existence of a BigCo is stable, but a job there isn't always. Between up-or-out, re-orgs, RIFs, defrags - you just might find yourself effectively reapplying for your own job on a yearly basis.
If you are still in college I would recommend joining your university's co-op program and try to work for companies that have gotten decent reviews from former co-op students.
Almost everything this guy learned except the exact details of the process, could be learned while you are still in college so you can make an informed decision on your first real job and probably have the opportunity to continue with whichever company you co-oped with after graduation if that is desired.
Personally, I would recommend a smaller unstable company. At the time, I didn't recognize it as being such (but certainly not Top 4), and I wouldn't have possibly learned as much and as quickly in a less dysfunctional organization. To be fair, that's also why I eventually ended up leaving, but responsibility and opportunity can be very available in understaffed and unstable companies. Definitely find some good mentors wherever you end up.
A smaller company will certainly give me more independence but it will be difficult later when I want to transition to a bigger company. How can we identify good mentors?
I started 4 years ago and want to recommend starting somewhere with a good program for new hires and preferably some kind of follow up program after starting.
Google doesn't use something like SonarQube I guess. That's full of metrics like "fixed x bugs, improved code quality y%, reduced SQALE technical debt to z."
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.
Wow!. Really inspiring write-up. Thanks for sharing. No. You are not an idiot. When you find time, please pick-up "Anything You want" by Derek Sivers. Essentially, You don't need a business idea. You just make something that "helps" people however vague that might sound. GOod luck with your venture and Indie Hackers is Great and Channing Allen has built a Great community around it with an awesome podcast to boot!. Who knows you could even be back at Google after "successfully" bootstrapping your startup for a few years.
I always knew Google incentivizes the launch of "new" products, but the breadth and depth of the extent wasn't apparent. I now understand why Google Talk has so many short-lived reincarnations. On the flipside, this also disincentivizes maintenance/up-keep of old products - Reader never had a chance.
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.
With 11 years of experience, maintaining a legacy system and writing docs does NOT sound like sr. level promo material to me. At <Equivalent BigCo>, sr. level promo was tantamount to rearchitecting an existing product, leading a team in multiple-person-years development effort.
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.
That attitude is pretty illustrative of a larger problem. Maybe the work of bug fixing and maintenance of legacy systems is undervalued, which might explain why those systems get into such sorry shape to begin with at big companies like Google.
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.
> Wait a second. I was in a business relationship with 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.
I dunno, it seems like the learning process of putting together a series of unsuccessful promo packages might be the exact training you need to become "senior".
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.
This might work for a company with no competition and railway cars full of advertising money coming their way regardless of their actions.
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.
Hi, Indie Hacker here who also has some experience with politicized corporate environments. I’d like to encourage you to ignore some of the bad advice in this thread.
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.
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.
The more I hear about the inner workings of Google, the less impressed I am. It seems their vaunted hiring process has let in folks who specialize more at internal politicking than getting things done. It doesn't take too many of those kind of people to ruin a culture, and cause a company to stagnate or go backwards.
I don't know that it is so much that the Google hiring process has selected for adept internal politicians as it is that Google hasn't paid as much attention to human factors as it should.
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.
this is a highly enjoyable read, and i am glad i found your pet project since I am trying keto diet myself :)
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
A good rant and first foray into politics for the OP, I would imagine. C'est La vie. IMHO, the next step for OP is to learn how to play the game and add "finding a paying customer" to that list of what's next. Google "persuasion reading list".
Strange that you don't personally go before a board to present which was my experience at a Large tech company in the uk - relying only on written "packets" would seem to discriminate for neurotypicals.
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.
This is an perfect illustration that a company gets exactly what it rewards and it measures. Initially it works out just fine because the field for the company is wide open so regardless of what it measures and it rewards the results look good enough.
I thought google was supposed to be an industry leader in assessing and managing human assets. This whole thing boils down to making a simple problem complex.
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.
Not really - the counterpoint to that is that giving supervisors too much direct power is also an invitation for bias, blindspots, or abuse of power. You also don't want to slip into stack ranking (witness how demoralizing it was at Microsoft), which is easy if you don't have a way of getting globally calibrated.
Under this system, how do you keep a semblance of uniformity in promotion standards in a large organization?
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.
Thanks! Yeah, I recognize that's definitely a possible outcome. Perhaps it's statistically the most likely outcome. But I agree with you that it's worth doing if for nothing else to see what it's like. At worst, I go back to being an employee again somewhere.
Hate to be the guy who says matter of fact things so matter of factly, but the author just stated that when he was programming he was happy and when he was calculating how to exceed at the game, he almost got promoted, but wasn't happy.
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.
The best thing an employer can do for an employee is assign explicit value to that employee’s work. Otherwise, the burden lies on the employee regardless of the fact that a manager may declare solid performance. If the value of your work isn’t clear, you will suffer in the long run via missed promotions and potential layoffs.
Sadly, if your project’s value is not well understood, you need to get off of it.
This is exactly how many many many people feel, with one difference - most people don't even get the chance to pick up good skills, tech or otherwise. They are stuck doing the same thing for months and years. Add to it visa, family complications and the situation gets worse.
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.
A little OT, but I wonder what recruiters / interviewers think of people who took time off to bootstrap their own business but ultimately went back to applying for a regular job. Having the option to go back to working for a big corporation is a good safety net, so it would be an important factor if taking a year off would drastically reduce the likelihood of being hired again.
This is why its healthier to always run with the premise that you're leaving at some point and its the employer's responsibility to keep you there and give you interesting and rewarding work.
If you're asking them to promote you then its the wrong way round, they should be asking on you about whether you're staying there. That's how the market is today.
I doubt Google cares if the majority of it's people stay or not. Beyond the rock star employees who they absolutely know they need/depend on, they have an unending pipe of software engineers who want to put Google on their resume, in part due to the value of having the resume item and in part due to all of the perks.
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.
afaik their "average individual employee" is actually pretty damn good. Anyway that's the point, if they don't care then you shouldn't remain there trying to impress them, especially if that doesn't align with your life goals.
Sure, I didn't mean to suggest otherwise. I just meant, if they have an endless flow of "pretty darn good" employees, they have no particular need to try to retain any given one.
Other companies may have to search hard to find excellent software engineers, but Google does not.
It's still really important. There's a cost to training and getting an engineer to understand the problems and scale that Google faces (some might come in with that, but many do not). There's also domain/google specific knowledge that's expensive to replace as well.
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.
Reading through this comment section I get the feeling a lot of folks here are rather confused about what it is they really want. On one hand they care about producing quality work, and value doing meaningful work like helping others or solving problems nobody else wants to touch, and on the other hand they expect to receive this senior title in recognition of their efforts and get disillusioned when they fail to do so.
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.
I think because tech is well off compared to other industries, tech workers delay a certain type of adulthood maturity. This isn't functioning in society maturity but the maturity of finding and knowing your place.
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.
> You’re in a business relationship with Google. If you’re disappointed that Google isn’t “romancing” you with gifts like you do for your wife, you have a misguided notion of the relationship.
This line is the best summary how most companies treat their employees, despite whatever the company promote about internal community, team building, etc...
This article may as well be used to describe my employer or many other companies that have more people than the quantity of work. My suggestion: join a company that figures out how to manage visibility, such as Netflix. Or join a company that does not need to manage visibility, such as a fast-growing startup.
> It was because they refused to buy me a Christmas present.
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.
FWIW, he was a Software Engineer aspiring to be a Senior Software 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.
Noticed your new project is a keto recipe webapp - this will have to compete with some good ones: https://ketodietapp.com/, and https://www.ruled.me/keto-recipes/ . Fascinated by how ruled.me in particular seems to have won the 'indexed by google' game for 'keto recipes.' Also fascinated by how much ruled.me might be making with adsense. Also generally fascinated by special interest communities and how to monetize them, any content around strategy here would be greatly appreciated!
Whenever I sense politics is more important to promotion that great job, I am leaving. I went into this field idealistic, driven for creating technology that can change lives for the better, and way too often artificial red tape is put everywhere by clueless or outright evil managers in order to drive their agenda and increase their chances for promotions and more $ into their pockets. It's literally negation of every single value I stand for and often have no choice but to leave and work on my own projects. Even the best companies like author mentioned aren't immune to human nature and have many blind spots.
Politics is everywhere. Misaligned incentives are everywhere.
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.
This guy spent 2 years realizing that "it's a business relationship". I worked at another smaller bay area company and I only spent 2 months to realize that. Google is already much better.
Thank you for sharing this. Your story actually made me think about myself - whether I am actually doing something because I believe it's best for company goals, or I am doing something because I want my work to be visible and viewed as valuable.
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.
I've been there, done that (quit another MNC, not Google).
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).
Google always was one of the few companies I wished to join. That feeling has decreased over the years, and now this article might have killed it completely.
Well, Google is a big company. Politics are a thing. A lot of younger hires don't know how to navigate that kind of environment. I had a lot of trouble in that area. I joined a smaller firm and things improved dramatically. As the smaller firm grew, I grew into understanding and learning how to navigate politics gradually.
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!
Is it just me, or do stories like this make it increasingly clear that working at large companies like Google, Amazon, etc are a mistake?
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 :-)
It really depends. Smallish companies cannot afford to pay nearly as well as the big ones. Sometimes a few years of dystopian hellish work is worth the money. For example, if you then use said saved money to start your own venture with no need for Other People's Money.
There is no reason anymore for the ambitious to work for the man. They will forever be trying to think of a lord-serf relationship as a mercantile one. Aided by earnest attempts by the company to help them delude themselves into thinking so.
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.
Once Quality is defined it no longer is Quality. Instead it opens the way for gatekeepers to stand guard around their moat and claim Quality eventually corrupting the original definition.
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.
Speaking as a >6 year veteran (Xoogler) some of this rings true. Still a couple of points:
> 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.
> committees expect to see manager support so if a potential promotee has it, it doesn't mean a lot
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.
Heck yeah! It's great to read this. Large companies will bleed you dry and not remember your name. It's better to be the survivor of a failed startup than a star at a huge company. Better than being the survivor of a failed startup is the owner of a successful one. You'll never know that last one if you don't try.
I used to work at {OTHER_BIGCO} and felt the same. It was so bad at one point, I could basically toss a coin if I was going to work on something different that week. It was at point I realized there was no chance the promised promotion would come (well that and the lack of senior devs to observe) that I decided to move on.
>So if Google and I have a business relationship that exists to serve each side’s interests, why was I spending time on all these tasks that served Google’s interests instead of my own? If the promotion committee doesn’t reward bugfixing or team support work, why was I doing that?
Because it's touted as the company to get a job at and leaving it means something is wrong with you and you need to write up a blog post justifying why you left teh best position ever!!!!1!
"I was in a business relationship with Google".
The point that most employees especially in the US forget. It's strictly business for the company. Whatever incentives they offer is for the company's well being. Feelings like "proud to work for xxx company" is stupid.
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.
I think Paul Graham's old "Hiring is Obsolete" post sets the right framework for thinking about this, why it happens, and the arbitrage opportunity that is present.
This is exactly why I am going to start my own company in my own name and start being a contractor with my 'employers'. Why be a slave when we only have a limited amount of years on this planet?
Where is the metric for being a team player? Patrick Lenceoni's book, 'The Ideal Team Player' defines the 3 main traits of a team player: Humble, Hungry, and People-Smart.
Good luck, mate! Really, I believe you've taken the right decision. Even if you fail, that will be much better than continuing the environment you've described!
So, I don't think Google described what senior engineer means to him. Senior engineer means first that you a practitioner and can execute on software projects, but second it means you can influence others. From his own description, I would not be in favor of promotion as there was no evidence of influence. Instead of writing E2E tests, he could of influenced others to write E2E tests and the metric would be the number of diffs where he got people to write E2E tests.
It requires beyond stellar technical work to overlook the influencing aspect.
haha, I have a guy like this in my job. He won't do ANYTHING that couldn't be represented in a promotion document. Which is annoying but at the same time he is always successful with his promotions
This was an excellent post, and I loved the comics. But the situation sounds like a real nightmare. I recently read a blog post about burnout [1], and "lack of control" was one of the main factors.
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.)
Working at big companies it is very important to choose which projects to work on, and which to not work on. You should be asking your manager, product manager, whoever, to explain in detail how your project is going to be helping. Why is it even necessary? If it's a smaller part of a big system, what is the bigger system doing, and is this project really going to help it in some way? And in some way I mean some way that can be easily measured and demonstrable. The business case must be crystal clear.
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...
Teams are spontaneously disbanded and their projects are moved to other countries because it prevents people who share the same allegiance or ideology that runs counter to Google's from conspiring to hide "accidental" exploitable bugs in the code which could later be used to damage the company. The project gets audited by the next team's fresh eyes and if an exploit is found then it is patched and can be traced back to the moles who can then be monitored or fired. Rinse and repeat until launch.
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?