Why I Quit Google to Work for Myself

I don't know that it is so much that the Google hiring process has selected for adept internal politicians as it is that Google hasn't paid as much attention to human factors as it should.

A lot of Google's philosophy is about automating things a person normal would use their judgment on and just choosing not to perform some human-centric functions at all (e.g. customer support).

It's hard to get internal culture right in the best of circumstances. When you treat like an algorithm and you don't get that algorithm right, it encourages all sorts of maladaptive behavior, politicking, etc.

To be fair Google's promotion board is not as flawed as say, Microsoft's old stack ranking system. But it does set up incentives in such a way that to advance people may optimize their work in a way that doesn't benefit the company.

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.

I've been working on open source software for the last couple years (links in my profile).

The funny thing is that after more than one promo disappointment, I just started working on open source projects at work. I did that seriously for the last 6-7 years of my 11 year tenure (maybe 30-60% time instead of 20% time).

That ended up improving my skills a lot, and I never got the sense of my work being thrown away (which would have led to me leaving much earlier). Like you, I always had a lot of respect from my coworkers and manager, and they never questioned what I was doing. I was always maintaining some legacy system that everybody knew was important but nobody wanted to touch (or knew how to touch).

I did eventually get promoted, but somewhat to my chagrin it was for a committee-friendly project -- C++ that handles a lot of qps. In contrast, I think all the developer tools I wrote in Python had a lot more impact on the company. I got a lot more positive feedback on those (just not from the right people apparently, as non-engineer or junior engineer feedback isn't counted that strongly, as it was explained to me).

I guess my view was that the promo committees cared more about technical difficulty than impact on the company, which leads to the obvious situation where people invent difficult work to do.

In my mind, it's not a coincidence that most Google products are now slow and full of bugs -- at least the ones that make it past the all-too-common "just barely launched" state. I never worked on front end code, but I noticed that front end engineers also get the shaft. The products show it.

-----

I was disappointed in certain things at Google, and there was a certain amount of "believing your own PR", but overall it was fantastic for me. Otherwise I wouldn't have stayed for so long.

I don't have any illusion that other companies are better. They might not have these problems, but they have other problems that Google doesn't. (I know plenty of people who stayed at Google for 5 or more years, then went to another company and left that company after a year.)

I think you might feel the same way, since your choice was to start something on your own rather than take a job at a similar company.

Employees just hold Google to a very high standard, which is both fair and good for the company!

Not really - the counterpoint to that is that giving supervisors too much direct power is also an invitation for bias, blindspots, or abuse of power. You also don't want to slip into stack ranking (witness how demoralizing it was at Microsoft), which is easy if you don't have a way of getting globally calibrated.

Just to try to put this in a (unfair to you) constructive context:

> I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run.

>> I can give some insight from my own experience. In my current position, there are a large number of "things" that I've had to figure out, either by reverse engineering, reading code, or intuition. So I get constantly bombarded with helping others get unstuck.

This is why I always try to follow readmes, log my progress and fix errors as I find them. Also document hidden assumptions etc.

That way others can help themselves - follow the readme, look at the up to date network/architecture diagram etc.

Partly this is because I really cannot be bothered to keep such details in my head, anyway.