Author writes article ranting about decision-making by groups of people who know nothing about them.Commenter asks for referral from author who knows nothing about them.

I recommend applying for a promotion early, even if you don&#x27;t think you&#x27;re actually ready. It&#x27;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&#x27;s filled with a lot of great people and they build a sense of community, but at the end of the day it&#x27;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 &quot;It is our policy to hire people with $YEARS of experience &#x2F; $DEGREE degree &#x2F; $OTHER_PROPERTY at level $LEVEL only&quot;! It is all lies!

I&#x27;m going to be applying there soon, 4 years into my career. It&#x27;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?Also, any chance of submitting a referral? :)

Yeah, but in fairness to Google, it&#x27;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&#x27;t just never really do anything except bugfixing or riding their teammates&#x27; 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&#x27;s word that the person had an impact even if they can&#x27;t quantify it with metrics.

At risk of stating the obvious, not all the medium&#x2F;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.

Nice. Do you think large companies would benefit from a different scheme that rewards employees who &quot;think like an owner&quot;? (pardon the oft-used phrase)

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&#x27;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&#x27;ve gotten rid of committees for promotion decisions up to the level of Senior Software Engineer, so it does sound like they&#x27;re moving in the right direction. I suspect in practice, there will be thorny incentives there as well, but I&#x27;m hopeful for them.

Is your experience common for rank and file Googlers or specific to your role&#x2F;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&#x27;t a likely solution?

The author did indicate a project involving machine learning likely being a better path to promotion.

Thanks for reading.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&#x27;s much harder to &quot;sell&quot; a project whose effects are only directly visible a few people, even if it&#x27;s valuable work.

nice article although its sad you couldn&#x27;t get recognized for the value you were adding.I am not good at wording things, but here goes:
I didn&#x27;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 too was also intrigued by the statement &quot;best engineers in the world&quot; and then subsequently reading that Google engineers suffer from the same BS as any average software company.

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&#x27;s not really a strict cultural expectation for documentation, so it&#x27;s very easy to find code that&#x27;s either not documented, documented inaccurately, or documented unhelpfully.

Early on in the article you describe the excitement your younger self had a the prospect of working with the &quot;best engineers in the world&quot;. 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&#x27;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.

Oh, thanks! Yeah, for most of the blogs I link to, I&#x27;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.

I love your Keto Hub idea!<a href="https:&#x2F;&#x2F;ketohub.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ketohub.io&#x2F;</a>I&#x27;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 &#x27;very google&#x27; thing to do. OP does a great job linking directly to the recipe source.

Thanks for reading. Sorry to hear you had the same experience.What&#x27;s your experience been post-Google?

(former Google engineer here)No questions, but it was a good read. I&#x27;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&#x27;s new to me is the shuffling of projects back and forth to India. That&#x27;s not something that seemed to be an issue when I was there, and it&#x27;s sad to hear this new concern for keeping engineering talent.

I don&#x27;t think so. Although it&#x27;s worth noting that Google isn&#x27;t big on deadlines. They set quarterly goals, but on the teams I was on, they weren&#x27;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&#x27;m curious, do you feel it took you too long to ship the projects you were working on? Or do you feel you shipped them on time?

Thanks for the tip. FYI the address looks to be kalzumeus.com instead of kalzumeus.org

Yeah, I actually discovered Patrick McKenzie through Indie Hackers. He was one of the early podcast guests:<a href="https:&#x2F;&#x2F;www.indiehackers.com&#x2F;podcast&#x2F;013-patrick-mckenzie-of-appointment-reminder" rel="nofollow">https:&#x2F;&#x2F;www.indiehackers.com&#x2F;podcast&#x2F;013-patrick-mckenzie-of...</a>I am very much influenced by his story. I agree that he does a great job documenting what he learned.

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 &quot;I just write code&quot; to &quot;I am a sucessful self-employed software consultant.If you haven&#x27;t come across him before, I strongly suggest you check it out

Promotions carry a corresponding salary bump that can be quite large. Check out <a href="http:&#x2F;&#x2F;levels.fyi&#x2F;" rel="nofollow">http:&#x2F;&#x2F;levels.fyi&#x2F;</a> (seems to be down right now) or the associated spreadsheet of salaries: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1IclsJmHUMWjZCECMKi1IS4w_6To5oMUtksPShuk1nuc&#x2F;edit#gid=1145296357" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1IclsJmHUMWjZCECMKi1I...</a>

Thanks for reading!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&#x27;d enjoy the extra compensation, but that wasn&#x27;t as strong a factor.

Thanks for sharing this, I&#x27;ve not been (and never will be) a SV employee, so it&#x27;s interesting to see such a different perspective.The big question that I didn&#x27;t quite get from the post, is why did promotion matter so much to you? Everything seemed to hinge on that, but you didn&#x27;t quite explain why it was so important, other than &quot;what a great title - people would be so impressed&quot;. It sounds like when you were happy with your title, you were happy with your work - you &quot;lovingly&quot; fixed the old pipeline, wrote documentation, helped colleagues etc. Were there particular benefits to being promoted that would have increased your daily happiness?

I&#x27;m not the author of the article, but I did create Indie Hackers, I&#x27;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&#x27;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&#x27; first customer. Additionally, you don&#x27;t have an investors telling you to quit your job and use their capital to scale up your business&#x27; 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&#x27;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&#x2F;companies, I&#x27;d wager there are a lot more people starting who aren&#x27;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&#x27;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&#x27;re committed to the task, your chances of succeeding with an indie business are much, much higher than 0.1%.

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 &quot;smaller&quot; 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&#x27;d say that making a $1B&#x2F;year business might be 0.001% likely, while making a $1M&#x2F;year business might be 0.1% likely - but for all practical purposes, both are incredibly challenging to pull off. If that&#x27;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.

Author here. Happy to answer any questions about the post or about my experience at Google.

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.

&gt;Join a company that has great mentors.Why?I have had people say this to me before but I think it is silly advice for where I am at. No one has really explained what a mentor is supposed to do in regards to a software engineer who is mid-level.When I think &quot;mentor&quot;, I think &quot;hand-holding&quot;. I don&#x27;t need hand-holding. I just need to be on a team with peers who push each other. Is that mentoring? What does &quot;mentoring&quot; look like when someone grows beyond a junior role?

Join a company that has great mentors.If you already know what you love, then additionally pick a company that&#x27;s great at that.If you don&#x27;t, then pick a company where you get a chance to be exposed to a wide variety of different things. If you aren&#x27;t getting that in the company you pick, quit and pick another one.

Thanks for the advice. This will be helpful to a lot of my friends who will be starting in the industry.

&gt;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&#x27;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&#x27;re important. At successful companies, good practices have a good way of percolating through, whereas at smaller companies, it&#x27;s easier to fall into &quot;cargo culting&quot; of just doing things because that&#x27;s how everyone else is doing them.I think you can see this in things like the Google Python Style Guide (<a href="https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html" rel="nofollow">https:&#x2F;&#x2F;google.github.io&#x2F;styleguide&#x2F;pyguide.html</a>). 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&#x27;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&#x2F;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&#x27;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.

Thank you but I am not in America. In India, we don&#x27;t have the co-op program.

If you are still in college I would recommend joining your university&#x27;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.

The existence of a BigCo is stable, but a job there isn&#x27;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.

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?

Personally, I would recommend a smaller unstable company. At the time, I didn&#x27;t recognize it as being such (but certainly not Top 4), and I wouldn&#x27;t have possibly learned as much and as quickly in a less dysfunctional organization. To be fair, that&#x27;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.

As someone who will be entering the industry, I loved your perspective on your job at Google. Also, having read Cal Newport&#x27;s &quot;So good that they can&#x27;t ignore you&quot;, I couldn&#x27;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)?

I don&#x27;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.

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&#x27;s a lot truer than most people complaining about other people sucking up thinks it is.

It&#x27;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&#x27;re working on something cool and are bought inDuring - 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 &#x2F; promotion committee so it gets the rewards it deserved.Otherwise, you&#x27;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.

I guess my question is: Can you get job satisfaction from promotion-focused work? I&#x27;m proud of what I&#x27;ve done. When I make someone else&#x27;s life easier, that makes me feel good&#x2F;satisfied with my work. I can&#x27;t fathom satisfaction from impressing a promotion committee and tacking on a bigger title.

Thank you for posting that - always interested in new approaches. =0

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.

This covers a lot of the same ground as Brendan Reid&#x27;s &quot;Stealing the Corner Office&quot;[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 &quot;Smart but Stationary Manager&quot; - a guy who is a lot smarter than a lot of the people who do get promoted, but who doesn&#x27;t optimize for the right factors. Reid&#x27;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.<a href="https:&#x2F;&#x2F;www.amazon.co.uk&#x2F;Stealing-Corner-Office-Strategies-Business&#x2F;dp&#x2F;1601633203" rel="nofollow">https:&#x2F;&#x2F;www.amazon.co.uk&#x2F;Stealing-Corner-Office-Strategies-B...</a>

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.

I thought &quot;oughta be enough for anybody&quot; was an obvious &quot;640KB&quot; joke, but maybe I&#x27;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!

Yes that&#x27;s how money works, if you start spending lots of it then you won&#x27;t have it.

&quot;Four years&#x27; worth of GSUs oughta be enough for anybody.&quot;No. Not even close. There&#x27;s a reason it&#x27;s called golden handcuffs. It all depends on where you are in life. If you have a mortgage, it won&#x27;t be enough depending on the house you have. If you don&#x27;t have a house, you will have a lot of FOMO. Big time.It&#x27;s all about pscyhology - you need exactly 0$ if you are dedicated and don&#x27;t have dependencies. Ok, let&#x27;s say just couple thousand for a room and food.

Whenever anybody pays you good salary or even adds stock shares to it, doesn&#x27;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.

The author is in New York and presumably intends to stay there. I&#x27;m fairly certain four years of post-tax GSUs won&#x27;t last him long.

&lt;holds envelope to forehead&gt; Because you made enough money that it was an affordable risk?Yes, perf is garbage and management is chaos, but let&#x27;s be honest with ourselves. Four years&#x27; worth of GSUs oughta be enough for anybody.&quot;Devoted employee&quot; followed by &quot;expert at gaming the perf system&quot; followed by &quot;project cancelled and adrift&quot; is, sadly, the normal progression for a Googler, from what I&#x27;ve seen.

On this track, the question you want to have a good answer for is &quot;Why should we pay you way more than $X?&quot;

As I&#x27;ve progressed from job to job (and everything in between), I&#x27;ve learned how important tracking your personal metrics are. I&#x27;ve trained my mind to always record the before&#x2F;after for any project I work on and keep a written, screenshot&#x27;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), &quot;Why should we continue paying you $X.&quot;

My first full time job was as IT support for financial auditing&#x2F;IT auditor. I didn&#x27;t stay there long, but I learned this quickly: get a paper trail going ASAP. You never know when you&#x27;ll need it, either to toot your own horn or to fight back, especially against bullshit :)

Article’s gist: I an young and idealistic and I went working for Google thinking they’re from another planet. That’s not true.

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.

Lloyd Shapley already figured out a &quot;fair&quot; way to do this, called the Shapley value.Basically it&#x27;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&#x27;t use this available tool is that it would probably rate management contribution on the lower end...

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&#x27;m struggling to come up with a good way to implement it that doesn&#x27;t just water everything down.The closest I can think of is how repo commits can be counted&#x2F;graphed per user. Works easily for code jockeying, but less so for softer talents like pair programming.

That&#x27;s what&#x27;s dysfunctional about a lot of companies&#x2F;our society. You persuade others to do&#x2F;[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&#x27;re a team and hard work is it&#x27;s own reward when it&#x27;s really just dog eat dog the higher up the food chain you go.

You&#x27;re forgetting that you could also track secondhand assist as well.I can&#x27;t speak for programming but in soccer this is well-known. It&#x27;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&#x27;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.

This is what +&#x2F;- 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 &#x27;off the court&#x27; and if they are there are many confounding factors.

This is what I worry about, and what I hope to avoid by asking who&#x27;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&#x27;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?

&gt; 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 &quot;assist&quot;.The NBA has an advanced metric for that called gravity. As you could imagine Steph Curry&#x27;s gravity is through the roof.Another related metric is +&#x2F;- for when a player is on the floor. That one is more nebulous and error prone but it is meant to describe a player&#x27;s impact on the floor outside of things like assists, points, rebounds, etc.

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.

I&#x27;ve never tried it, but I suspect you&#x27;ll run into the same issue that sports does, where &quot;assists&quot; don&#x27;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 &quot;assist&quot;. It&#x27;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&#x27;s pretty hard to measure without a clear definition of what &quot;success&quot; is and reams of data.

Yeah we don&#x27;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.

relatedly, a friend of mine worked at a place where everyone was on &quot;20% time = bug time&quot;. 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.&quot;Add button for X&quot; became* &quot;add button on form&quot;
* &quot;add CSS for button&quot;
* &quot;update CSS for button&quot;
* &quot;add CSS files to build process&quot;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&#x27;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 &quot;kept up&quot; with his team mates.No one else would touch that bug. Most people hadn&#x27;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 &quot;what gets measured gets gamed&quot; mantra.It&#x27;s still frustrating to know that this mentality infects so many professional &quot;thought workers&quot;.

In one of my previous teams, we did away with individual metrics because they &quot;punished&quot; 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&#x27;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.

That&#x27;s assuming that your peers aren&#x27;t willing to sabotage you to get ahead...

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.

So, would you mind helping me see if I understand quadratic voting correctly?Let&#x27;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 &amp; 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 &quot;common pool&quot; in order to ensure that, in addition to their vote for 5 &amp; 7, each policy also gets 2 extra votes?

If you are going to hand out points for people to vote with, may I suggest quadratic voting.[0][0] <a href="http:&#x2F;&#x2F;ericposner.com&#x2F;quadratic-voting&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ericposner.com&#x2F;quadratic-voting&#x2F;</a>

In my experience this often just becomes a popularity contest&#x2F;give to whoever you eat lunch with.I can have my head down all week neck deep in code but because of this I&#x27;m not interacting with people around me as much and basically get punished for focusing on work.

I can&#x27;t imagine working at a company with this kind of system. Sounds a little too much like MeowMeowBeenz (<a href="http:&#x2F;&#x2F;community-sitcom.wikia.com&#x2F;wiki&#x2F;MeowMeowBeenz" rel="nofollow">http:&#x2F;&#x2F;community-sitcom.wikia.com&#x2F;wiki&#x2F;MeowMeowBeenz</a>) from the TV show Community. (&quot;MeowMeowBeenz™ takes everything subjective and unspoken about human interaction and reduces it to explicit, objective numbers.&quot;)How do you feel bonusly avoids this potentially awkward gamification&#x2F;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 :)

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.

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&#x27;s wasted money), so sometimes you start giving it out without really taking into consideration which teammate has helped you the most.

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&#x27;t notice. Unfortunately in my experience, that&#x27;s not a rare occurrence.

Isn&#x27;t the Toyota&#x27;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?

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&#x27;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.

On the one hand it is indeed disappointing that nobody would help you with this. On the other hand, there&#x27;s a more pro-active role you could have played yourself in this as well. &quot;When everybody is responsible, nobody is&quot; - 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 &quot;to the group&quot;.

&gt; I could be stuck for days because following the README in a repo just wasn&#x27;t enough to get the project to compile and run. Every standup I was telling &quot;I&#x27;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&#x27;m doing absolutely nothing.Certainly it might&#x27;ve been more efficient if one of your colleagues helped you debug the issue. But in the absence of help, it&#x27;s not clear why you didn&#x27;t dive in and start debugging on your own (rather than doing nothing). You&#x27;ll learn more that way too.

&gt; Every standup I was telling &quot;I&#x27;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&#x27;m doing absolutely nothing.&quot;.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&#x27;s office as apparently my behavior was disruptive and problematic.

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&#x27;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.

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.

There are other issues at play when it comes to helping out remote team members.When you&#x27;re co-located with someone you develop better comradery with that person. You&#x27;ll know them better and they&#x27;ll come right to your desk when they ask for help so you&#x27;re more likely to help them. And you sit with them as they execute commands so you can see exactly what&#x27;s going on.remote coworkers are easier to ignore, harder to help, and harder to socialize with.

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 &quot;hey, this isn&#x27;t working because X. What do I need to do &#x2F; who can I talk to for help?&quot;

If the standup was part of a scrumesque process, this is a case where a scrum master could have really come to the rescue.

What&#x27;s a jock culture problem? Where everyone talks about sports and it&#x27;s alienating?

I can&#x27;t say for sure but your mention of &#x27;CSS&#x27; 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&#x27;t helping you then according to their cost benefit matrix it isn&#x27;t worth it.  Maybe they are supposed to be doing other work and they can&#x27;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&#x27;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 &#x27;it works on my machine&#x27;.  These same people will snort derisively if any junior tells them of problems building their project, with a line like &#x27;its not rocket science you know&#x27; -- 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&#x27;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&#x27;t realize it themselves.)

But it was! It was excluding you! Your lack of performance made everyone else look more productive.

Most jobs I&#x27;ve been at if you&#x27;re the first new hire in a while you are going to experience something like this, and it&#x27;s important that you spend a lot of time adding to the documentation to make it easier for the next new hire.

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&#x27;t enough to get the project to compile and run. Every standup I was telling &quot;I&#x27;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&#x27;m doing absolutely nothing.&quot;. 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 &quot;help&quot; 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&#x2F;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&#x27;t an interesting performance metric.Until this day I still can&#x27;t believe that everybody was just throwing tens of thousands of dollars of work out the window because helping stuck teammates wasn&#x27;t counting towards some kind of bonus.

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

&quot;I say show me email chains, and I will show a hero.&quot;Will show you a hero six months after they tendered resignation.

That reads an awful lot like you&#x27;re optimizing for people good at leaving email trails, i.e. at office politics.There&#x27;s only one way to actually measure someone&#x27;s output, and it&#x27;s working close to the team and witnessing their actual productivity. Getting involved. 1-on-1s.Of course the farther removed from this process the more politics come into play.

This is why I love using Slack and always have discussions in as public of a room as possible.

I&#x27;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&#x27;s slack channel, and a &quot;huge thanks to @....&quot; on a public chat. If you&#x27;re at a high enough level that you can&#x27;t value someone&#x27;s contribution from those artifacts, then you need to be trusting those under you and asking about people... you&#x27;ll be missing why high performers are leaving.

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&#x27;s code, or doing &quot;invisible&quot; 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 &quot;helpers&quot; 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 &quot;helping&quot; plays in making good software.

&gt; the benefit of being a good team player is that it helps you build relationships. Those relationships often turn into opportunities down the line.Most of the time other people leave or move to other teams.Being a decent human being is not about getting practical advantages - otherwise sociopaths would be the most helpful people around.Instead, many large corporations want to instill a culture of competitiveness and often cynicism because competing is what they do.Cooperation, lasting relationship between employees, mutual help, solidarity are increasingly scary words for many companies.

&gt; 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&#x27;re still reading tea leaves if you&#x27;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.

&gt; 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&#x27;s metrics? A new junior dev will take some time to become productive so do you add the new member&#x27;s progress to the team&#x27;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?

Tbh that&#x27;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&#x27;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

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.

maybe I&#x27;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&#x27;t work. It isn&#x27;t working in QA because of this reason etc. etcSo anyway I think that was probably valued by our project manager who is also a former techie, because she probably realized if I didn&#x27;t do it, that PR wasn&#x27;t going in that release.

The first concern I had is that assist points that people assign to other won&#x27;t be directly comparable -- so an &quot;assist leaderboard&quot; might be misleading and potentially cause more trouble than it&#x27;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 &quot;actual help per assist points assigned&quot; values will differ.

I don&#x27;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&#x27;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&#x2F;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&#x27;t have good data in this area.

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&#x27;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&#x27;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 &#x27;OQ&#x27; (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&#x27;t get me started on the people that left heart stickers with messages like &quot;thank you for starting the best company in the world&quot; on Benioff&#x27;s profile.

Google has both the kudos system as well as a peer bonus system. People don&#x27;t use it enough across the company imo.

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 &quot;chat&quot; 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&#x2F;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.

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.

&gt; I&#x27;ve been planning to implement the &quot;assist&quot; 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.

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

The first thing that comes to mind is peer reviews. Although it&#x27;s not inherently quantitative data and doesn&#x27;t remove any of the bias&#x2F;politics&#x2F;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&#x27;t see when other people are improving your ability to do work whether that&#x27;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&#x27;s difficult to write down exactly how you spent your time. Perhaps you could only write down the three most difficult&#x2F;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&#x27;t seem like it would work everywhere.I don&#x27;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&#x27;re doing, why you&#x27;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&#x27;t being appreciated for the impact they made.Ultimately I think it&#x27;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&#x27;s not the entire picture and it never will be.After that try to create a culture that:1. Speaks up about their own impact2. Shares the impact of others&#x27; work, especially of those who might not speak out much3. Is openly appreciative of and encourages 1 and 2.

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&#x27;t been through a performance review yet, but I wouldn&#x27;t be surprised if they are taken into consideration.From my experience it works amazingly well. It&#x27;s silly, but if you are ever having self-doubt, a gift card from a coworker really helps.

&gt; For several jobs in a row, I&#x27;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 &quot;assist&quot; metric, so that people are sure that their work won&#x27;t go unrecognized.

99% chance of just being &quot;friend&quot; points instead of having anything to do with code.

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.

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&#x27;re already part of it, though, and that&#x27;s a problem I don&#x27;t know how to solve.

In our team, we have our custom implementation of a web app like <a href="https:&#x2F;&#x2F;bonus.ly" rel="nofollow">https:&#x2F;&#x2F;bonus.ly</a> . The idea is, every member would be given a certain points(we call it jems) at the start of the month. He&#x2F;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&#x2F;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 use something like this in my org, and Google has &quot;kudos&quot;, but I&#x27;ve found that the problem is their usage is highly variable even within a medium-sized or (we&#x27;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 &quot;just go hang around in team X&#x27;s channel, they&#x27;ll give you a &#x27;taco&#x27; any time your answer a query.&quot;Given Google&#x27;s promo system (where a committee looks at candidates from very different teams) this then means they&#x27;d have to try to normalize the data for it to be useful.

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.

I don&#x27;t have an answer to your question, but I&#x27;ve certainly felt that pain.Years ago I worked at a desktop software company that hired me to be their &quot;Windows expert&quot;. 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 &quot;house calls&quot;: finding out who was having trouble with a Windows issue and stopping by to lend them a hand.This was before &quot;pair programming&quot; 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, &quot;How can you afford to be so generous with your time?&quot;Some time after that, the VP of engineering (who I&#x27;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&#x27;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&#x27;t have the presence of mind to say, &quot;Maybe my help has been one reason their productivity has gone up. I thought that&#x27;s what you hired me for. Can we make it part of my job description?&quot;

Yep - See some of the work my last team published here while we were rebuilding deployment tooling: <a href="https:&#x2F;&#x2F;blog.coinbase.com&#x2F;scaling-developer-productivity-d23ce491f869" rel="nofollow">https:&#x2F;&#x2F;blog.coinbase.com&#x2F;scaling-developer-productivity-d23...</a>. For hard to measure metrics, softer measurements like repeated team surveys work fine too.I&#x27;d be cautious of directly measuring &quot;assistance&quot; outside of peer input in perf to avoid an unhealthy incentive. The most helpful people I&#x27;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.

&gt;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.Just talk like normal people. The more you talk openly about who&#x27;s contributing and who&#x27;s not the easier it becomes.

We use bonusly. As a proof-of-concept, I imagine it&#x27;d tackle some of your requirements. Bonusly points are tied to real world rewards, so there&#x27;s incentive to use it.People who had a lot of &quot;assists&quot; at our company regularly brought in 1000+ points a month, which then translated in $100+ in amazon gift cards or steam points.

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.

I academia, if you&#x27;re a PhD student that writes the paper, you&#x27;re the &quot;first author&quot;, but anyone who helps you do research or process data or other contributions is a &quot;second author&quot;.I think that&#x27;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.

Google actually kind of has a partial solution for this. Your performance review is not just based on manager&#x27;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.

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.

We estimate and log our time at my company Matters. Teams estimate a large budget if they don&#x27;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

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.

At Google you can ask your coworkers to write feedback that would be included in your promo package. I wonder why the author didn&#x27;t ask the developers that they helped to write a few sentences explaining how much time they&#x27;d saved thanks to the author&#x27;s help. The hiring committee wouldn&#x27;t ask for any metric if there were already a few people testifying that &quot;I saved XX hours&quot;.Disclaimer: I work at Google.

By definition, promotions are limitedThat&#x27;s not really the case if the promotion ladder is a skills&#x2F;experience based ladder and not a responsibility ladder. If being a &quot;senior engineer&quot; just means you have reached a certain level of proficiency, then there&#x27;s no reason everyone can&#x27;t be promoted to that level.

&gt; For several jobs in a row, I&#x27;ve felt that helping others on a team is undervalued and under-recorded. I&#x27;ve been planning to implement the &quot;assist&quot; 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&#x27;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&#x27;s because there are no other ways of rewarding good work. And by &quot;rewarding&quot;, I don&#x27;t only mean &quot;giving people recognition&quot; or &quot;giving people fun work&quot;. Those are important and should not be overlooked. Nevertheless, if you don&#x27;t also give people money, sooner or later they&#x27;ll fall behind their needs or just the rising costs of everything around them. Then they&#x27;ll have to choose whether they need money more than intrinsic rewards. And then we&#x27;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&#x27;t be only about promotion. Give people real rewards and incentives for doing a good job at their level.

If you gamify you also have to maintain the game.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.

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&#x27;t want to lie. But I also don&#x27;t want to cause trouble for my coworkers because of some misunderstanding.Admittedly, I don&#x27;t have a better alternative though.

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&#x27;ll see patterns in the upvotes and downvotes. The upvotes might signal &quot;This person helped me a lot.&quot; 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.

I dont work on software, but shouldnt there be deliverables that matter?Track management only.

It would be nice to have some sort of metric for this. I haven&#x27;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.

&quot;I&#x27;ve been planning to implement the &quot;assist&quot; metric, similar to basketball, on my own team for a while.&quot;Sounds like a super fun place to work. ;)

Transferring ladders seems non-trivial.If you know ahead of time that you are doing &quot;the dirty work&quot;, which usually you don&#x27;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&#x2F;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&#x27;s work situation seems prevalent through a Google-like org, and a ladder transfer is unlikely a realistic solution for that.

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.

Where I work we are big on peer review. So in theory helping others should have value. It&#x27;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&#x27;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&#x27;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&#x27;ve come to learn is that this sort of stuff, call it culture, has to be a priority for the company&#x27;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&#x27;re not antagonizing your employees with your review system.

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 &#x2F;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.

&gt; 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&#x27;ve felt that helping others on a team is undervalued and under-recorded. I&#x27;ve been planning to implement the &quot;assist&quot; 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&#x27;t love the idea of gamifying it, all the places I&#x27;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&#x27;t work?

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.

&gt;As a business person, you&#x27;re going to have to sell yourself&#x2F;your services to other people. Perhaps that&#x27;s not too different from pitching yourself to an &quot;anonymous promotions committee&quot;?That&#x27;s fair.I&#x27;ve wondered about that myself. Will I just end up resenting &quot;the customer&quot; the same way I resented &quot;the committee?&quot;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&#x27;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&#x27;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.&gt;Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!Thanks for reading!

I would argue it&#x27;s different, because customers are harsh but rational, while promotion committees are more capricious than 
harsh.Customers have &quot;skin in the game&quot;. They spend their own money, not somebody else&#x27;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&#x27;t see any consequences of those decisions. They&#x27;re following rules they didn&#x27;t make that are supposed to lead to a good result, but they may not in practice.If the results are bad, they don&#x27;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).

&gt; As a business person, you&#x27;re going to have to sell yourself&#x2F;your services to other people. Perhaps that&#x27;s not too different from pitching yourself to an &quot;anonymous promotions committee&quot;?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 &#x27;skin in the game&#x27;, they&#x27;re there to get shit sorted out, they need that shit sorted out and you&#x27;re there explicitly to help them do it.Pitching to a promo committee is filling out a form (including fantastic questions like &quot;what&#x27;s one thing you&#x27;re good at&quot;) where you have no feedback on what the other side is thinking until they tell you &#x27;yay&#x27; or &#x27;nay&#x27; 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&#x27;s a few hundred of them that they need to handle. Hopefully your packet doesn&#x27;t get reviewed right before lunch when they&#x27;re cranky.

As a business person, you&#x27;re going to have to sell yourself&#x2F;your services to other people. Perhaps that&#x27;s not too different from pitching yourself to an &quot;anonymous promotions committee&quot;?Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!

I think that&#x27;s true, and obviously there are a lot more situations at Google than a small company where you&#x27;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&#x2F;yr business or a $500&#x2F;yr business.

&gt; 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&#x27;s salary? A percentage of the team&#x27;s budget? The org? The company?

&gt; 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.

afaik their &quot;average individual employee&quot; is actually pretty damn good. Anyway that&#x27;s the point, if they don&#x27;t care then you shouldn&#x27;t remain there trying to impress them, especially if that doesn&#x27;t align with your life goals.

I doubt Google cares if the majority of it&#x27;s people stay or not. Beyond the rock star employees who they absolutely know they need&#x2F;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&#x27;ll replace you, likely without shedding a tear.

It really depends on the economic climate, the size of the company and the risks you afford to take, otherwise I generally agree.

This is why its healthier to always run with the premise that you&#x27;re leaving at some point and its the employer&#x27;s responsibility to keep you there and give you interesting and rewarding work.  
If you&#x27;re asking them to promote you then its the wrong way round, they should be asking on you about whether you&#x27;re staying there. That&#x27;s how the market is today.

That conversation made me realize that I’m not Google. I provide a service to Google in exchange for money.

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&#x27;s still a risk to lose good employees, talent is very valuable.

I think that Google does try to treat their employees fairly. I don&#x27;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&#x27;s favor. It&#x27;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&#x27;re doing higher-level work.

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&#x27;t have to give promotions. They get so many applications from the best software engineers in the world that they don&#x27;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&#x27;t want to promote anyone unless they have a very good reason.

Where is the metric for being a team player?  Patrick Lenceoni&#x27;s book, &#x27;The Ideal Team Player&#x27; defines the 3 main traits of a team player:  Humble, Hungry, and People-Smart.

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&#x2F;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

Nit: as described by OP, promotions in Google are decided by senior engineers. Your hypothesis still sounds valid.

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

Right, that&#x27;s probably the difference.

Were you going from junior (L3) to intermediate (L4)? If you were, then the task you described seems appropriate - you don&#x27;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&#x27;t get just by maintaining code.

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&#x27;t point to increased sales and the clients couldn&#x27;t write me recommendations for promo.I think I would have had better chances if my clients were other internal teams who could say, &quot;Yes, this pipeline is much more stable now.&quot;

&gt; The metricI think you answered your question. You had a metric that was tied to value for the business.

I&#x27;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.I can&#x27;t say why it worked only for one of us.

Frankly there are far more toxic and awful large companies to work for. I think with the perf&#x2F;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 &quot;get your shit done and fix all the things or we&#x27;ll go out of business!&quot;) and getting drafted to work here (and ahem, eat the free food and take all the money they give you...) it&#x27;s very apparent.But I&#x27;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&#x27;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&#x27;s been some incremental changes to the process recently. We&#x27;ll see how it shakes out.

Hi, no problem.Thanks so much for signing up to that course.If you have any questions you know where to reach me!

Hi Nick just popped in to say Thank You for your SAAS Flask course. I am slowly working through it along with the updated Flask Mega Tutorial

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&#x27;ve been freelancing as a developer for the last 20 years and have turned down interviews from Google &#x2F; etc. in the past. It&#x27;s a fun ride.&gt; Optimizing for promotionThis is one of many reasons why I&#x27;ll never work a &quot;regular&quot; job.

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.

Terminal level and Max mean different things here.Indeed you can become a senior fellow at Google, but you aren&#x27;t expected to. You are however expected to hit senior at some point in your career. There&#x27;s no requirement to grow further, so the bar for senior is high.

&quot;terminal level&quot;, in the sense being used by the OP, doesn&#x27;t mean &quot;end of the IC track&quot;. It means a level that you can be at &quot;forever&quot;. Often times the junior engineering levels have some expectations around eventually being promoted (ie, &quot;up or out&quot;).

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.

It doesn&#x27;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 &quot;normal&quot; growth and development. It looks like less than 1-2% of engineers at my company (FAANG) are above &quot;Senior&quot;.

At many organizations, Senior Engineer is not the end of the IC track, not even close. For example:... &gt; Senior Engr. &gt; Staff Engr. &gt; Sr. Staff Engr. &gt; Principal Engr. &gt; Sr. Principal Engr. &gt; Distinguished Engr.

&gt; developers find themselves having to write tests and fix bugs because the priorities of upper management didn&#x27;t allow itWell there&#x27;s your problem. If fixing those bugs isn&#x27;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&#x27;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&#x27;t impactful. I&#x27;ve shipped enough dead code that nobody really used but it checked a box on a sales call to know that quality software isn&#x27;t always what we&#x27;re selling.

The notion that &quot;a junior engineer and a manager who is at least partially paying attention can get that done&quot; 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&#x27;t allow it or foster it for the last developer.

There&#x27;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&#x27; and that&#x27;s a lot &#x27;cooler&#x27;&#x2F;&#x27;bottom-line demonstrable&#x27; than &#x27;I made the thing break less often and less breakable and more understandable&#x27;.It also says something that Google isn&#x27;t measuring itself very well, although this is one anecdotal data point, I&#x27;m sure it&#x27;s not the only one with the &#x27;defrag&#x27; reference, relocation&#x2F;churn etc. etc.I also take issue with your documentation reference. The existing lack of documentation was probably caused by other Senior Software Engineers?

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.

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 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&#x27;t value docs and bug fixing, we create undocumented and buggy code. When we don&#x27;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.

&gt;&gt;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 &#x27;biggest problems plaguing an organization&#x27; can get you fired. No likes to be told that the current bosses aren&#x27;t up-to their job.

&gt; The bar for a senior engineer should be identifying the biggest problems plaguing an organization, and successfully tackling them.You&#x27;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&#x27;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&#x27;t quantify this impact for the promotion committee because they likely didn&#x27;t quantify it for anyone but themselves.

&gt; 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&#x2F;unstable systems to make them more simple&#x2F;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 &quot;menial&quot; it may seem. A culture where people are only recognized for working on shiny things, leads to organizational clusterfucks like Google&#x27;s hangouts&#x2F;allo&#x2F;duo fiasco.

&gt; Which is how you get code with no tests or documentation.Without knowing this is actually detrimental to the org, I don&#x27;t find this to be a problem in and of itself.&gt; there was a real need for some grunt work, and the business was suffering because of itI would expect a Senior Engineer to be able to advocate and justify this grunt work.&gt; The key part about this that I would consider &quot;senior&quot; is being able to look at everything that is going on and figure out what is actually critical.&quot;Actually&quot; is the operating word here. This requires external validation. If you feel you&#x27;ve saved the company but can&#x27;t convince anyone of it, then you probably didn&#x27;t save the company.

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 &quot;senior&quot; is being able to look at everything that is going on and figure out what is actually critical.

&gt; This leads to a ton of actual problems too: You get a person really really good at coding &#x2F; execution but shit in big picture thinking &#x2F; broad system design choices &#x2F; cross team work etc. spend a bunch of time in a level. Now you have to either promote him into a spot where s&#x2F;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&#x2F;increasing benefits of people at the same level? Why can&#x27;t an &quot;regular&quot; Engineer just get a large raise for being an amazing Engineer, because that&#x27;s what you need! Instead, they need to be come a &quot;Senior&quot; Engineer who also has some kind of other management-type job that they suck at.

I obviously don&#x27;t work for Google - so an outsider&#x27;s opinion:- Expanding on op here, senior software engineer isn&#x27;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&#x2F;timing&#x2F;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&#x2F;levels).- Re: Reorgs: life is mostly unfair. I heard this in an ad and it stuck, &#x27;we lose more than we win&#x27;. I am surprised you stuck with that manager&#x2F;team for that long though. Career is a lot about making the right bets in terms of companies &#x2F; managers &#x2F; 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&#x27;ve done better instead of sympathizing :&#x2F;.In an ideal world, we will have people who can grow (and make more money &#x2F; level etc) in both dimensions: Vertically in terms of responsibilities and horizontally in terms of quantity of same level work &#x2F; 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 &#x2F; execution but shit in big picture thinking &#x2F; broad system design choices &#x2F; cross team work etc. spend a bunch of time in a level. Now you have to either promote him into a spot where s&#x2F;he will fail OR lose em to attrition. Either choice tends to break.A quick note since I have seen some people change &#x2F; grow &#x2F; 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&#x27;t apply there. I do know whenever we choose to push &#x2F; recommend a promo, we definitely are hoping for it to work out though :)

Certainly it counts for something. And I fully support it leading to great reviews for OP. But being good at your job isn&#x27;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&#x27;s just metric driven career development. If you can&#x27;t&#x2F;don&#x27;t measure it, how do you know it improved? How do you know there was a gap in company value to start with?

Yeah, I agree with you that you can&#x27;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&#x27;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&#x2F;Google, but are probably not a net savings for you personally.I adopt the Joel Spolsky measure of a developer as someone who is &quot;smart and gets things done.&quot; 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.

Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don&#x27;t disagree with the promotion committee on that front.IIRC, Senior Software Engineer is a terminal level. You aren&#x27;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&#x27;s fine.So certainly &quot;can fix bugs and write docs and tests&quot; isn&#x27;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&#x27;t really disagree with the evaluation that 6 months of Senior level work isn&#x27;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&#x27;s the real problem here.

Why I Quit Google to Work for Myself