Author here. Happy to answer any questions about the post or about my experience at Google.
Has your opinion changed about this at all? I am not sure how indicative these descriptions are to overall quality at Google ... but if they are indicative I'd be furious at the situation as a Google employee, where my (otherwise very smart) fellow Googlers are delivering what sounds like very poor products.
I think the lack of tests was more symptomatic of bad incentives that good developers were forced to follow. Developers were rewarded for flashy things they could show promo committees, and rigorous tests or well-written documentation.
It was unusual to find code with no tests because a code reviewer will usually insist on at least some tests. But it was common to see complicated behavior with just a single test associated. Or a complicated interaction between components with no end-to-end tests.
There's not really a strict cultural expectation for documentation, so it's very easy to find code that's either not documented, documented inaccurately, or documented unhelpfully.
No questions, but it was a good read. I'm sad to hear that the gaming of the promo system is still such a large concern. Unfortunately that was also the case way back in 2005, through 2010, and until I left.
What's new to me is the shuffling of projects back and forth to India. That's not something that seemed to be an issue when I was there, and it's sad to hear this new concern for keeping engineering talent.
What's your experience been post-Google?
The funny thing is that after more than one promo disappointment, I just started working on open source projects at work. I did that seriously for the last 6-7 years of my 11 year tenure (maybe 30-60% time instead of 20% time).
That ended up improving my skills a lot, and I never got the sense of my work being thrown away (which would have led to me leaving much earlier). Like you, I always had a lot of respect from my coworkers and manager, and they never questioned what I was doing. I was always maintaining some legacy system that everybody knew was important but nobody wanted to touch (or knew how to touch).
I did eventually get promoted, but somewhat to my chagrin it was for a committee-friendly project -- C++ that handles a lot of qps. In contrast, I think all the developer tools I wrote in Python had a lot more impact on the company. I got a lot more positive feedback on those (just not from the right people apparently, as non-engineer or junior engineer feedback isn't counted that strongly, as it was explained to me).
I guess my view was that the promo committees cared more about technical difficulty than impact on the company, which leads to the obvious situation where people invent difficult work to do.
In my mind, it's not a coincidence that most Google products are now slow and full of bugs -- at least the ones that make it past the all-too-common "just barely launched" state. I never worked on front end code, but I noticed that front end engineers also get the shaft. The products show it.
-----
I was disappointed in certain things at Google, and there was a certain amount of "believing your own PR", but overall it was fantastic for me. Otherwise I wouldn't have stayed for so long.
I don't have any illusion that other companies are better. They might not have these problems, but they have other problems that Google doesn't. (I know plenty of people who stayed at Google for 5 or more years, then went to another company and left that company after a year.)
I think you might feel the same way, since your choice was to start something on your own rather than take a job at a similar company.
Employees just hold Google to a very high standard, which is both fair and good for the company!
The big question that I didn't quite get from the post, is why did promotion matter so much to you? Everything seemed to hinge on that, but you didn't quite explain why it was so important, other than "what a great title - people would be so impressed". It sounds like when you were happy with your title, you were happy with your work - you "lovingly" fixed the old pipeline, wrote documentation, helped colleagues etc. Were there particular benefits to being promoted that would have increased your daily happiness?
It was mostly just the status. I think having the title of Senior Software Engineer has a lot of value in itself because it brings better job offers and more credibility if I go off on my own.
Also, people tended to be assigned more interesting projects the higher their level.
I'd enjoy the extra compensation, but that wasn't as strong a factor.
From other comments, it sounds like in the last month, they've gotten rid of committees for promotion decisions up to the level of Senior Software Engineer, so it does sound like they're moving in the right direction. I suspect in practice, there will be thorny incentives there as well, but I'm hopeful for them.
I am writing to add one point I did not see mentioned elsewhere:
You are making an implicit assumption that working on a "smaller" idea (like the ones mentioned in Indie Hackers) is somehow less risky than aspiring to be the next Zuck. Empirically, this seems to be false.
I have worked for ~15 years on startups. I have many friends, who are also entrepreneurs. I have observations on all sorts of efforts - from small side projects to large VC-backed bets to bootstrapped businesses.
My takeaway is that technology startups are characterized by a tremendous amount of risk and require a lot of hard work - regardless of the type of venture. I encourage you to talk to founders (in person, not reading PR-oriented websites like Indie Hackers) and verify that for yourself.
If I had to make up numbers to illustrate this notion, I'd say that making a $1B/year business might be 0.001% likely, while making a $1M/year business might be 0.1% likely - but for all practical purposes, both are incredibly challenging to pull off. If that's the case, might as well aim as high as possible and justify the risk involved.
Turns out the one thing that really matters is having a strong idea, which is forgiving to the many mistakes entrepreneurs inevitably make. In that regard, I wish you luck and hope you end up with a strong concept sooner rather than later.
My conclusion is that starting a small indie business is less risky than aspiring to be the next Zuck.
First, it's harder to fail, because there are fewer forces pushing you to make risky decisions. For example, you can start doing contract work, take on clients, and use them to support you while you build your indie business. Hell, you can keep working at your full-time job if you want to and build your business on the side. Those are bedrocks of income that can last you more or less indefinitely. Often, your employer ends up being your business' first customer. Additionally, you don't have an investors telling you to quit your job and use their capital to scale up your business' costs beyond the level that your revenue can support, which is one of the primary reasons that funded businesses go under.
Second, the business opportunities are simply more plentiful. The bigger you get, the fiercer competition gets. The more money you aim to make, the fewer paths there are to get there. If you want to find your first 10 customers, you can go out and talk to 50 or 100 or 200 people yourself. Every marketing channel is your oyster. None of your competitors feel threatened. The niches you can fill are endless. If you want to go from 1M to 10M customers, however, you need an exceptionally clever strategy, brilliant insights, a lot more resources, and a much higher degree of luck.
It's difficult to actually measure success rates without agreeing on the answer to this question: What counts as someone trying to start a business?
With small indie projects/companies, I'd wager there are a lot more people starting who aren't really serious and never take more than a couple of sincere steps. They might lower your perception of the success rate, especially compared to VC-funded companies if your denominator there only includes those who've actually raised a round. More people fail tryouts for the high school basketball teams than tryouts for the NBA. People filter themselves.
But I assure you that, if you're committed to the task, your chances of succeeding with an indie business are much, much higher than 0.1%.
I honestly don't know whether I or you are right or wrong. I know I am working with a limited data set (i.e. the people I have met and what I have read and absorbed online). Sounds like your experience is much the same, with the added benefit of doing this for a living via Indie Hackers (which is awesome btw). I am not aware of good places to find solid statistical data. Even if there were any, I'd say that they may not be valid - exactly for the reasons that you mentioned such as commitment, which is impossible to measure.
I think part of the problem is one of definition - what do we mean by "risk" really? If you mean the % of companies that, say, raised VC money but did not end up succeeding in the typical goal to reach $1B in valuation, is that actually risk? I don't think so - it is an outcome in the form of statistical probability for a specific goal, but it doesn't make sense to me to think of it as risk, at least with the common definition of the word from an entrepreneur's point of view. It may be a risk from the VC point of view, but that is rather unique because most entrepreneurs can't spread their bets.
That's why perhaps I should have used a word such as "effort." Making your goals smaller definitely gives you way more options - that much I 100% agree with. There are simply more ways to make $100K than $1M than $10M than $100M. But the effort does not seem to be any different from my (limited) experience. My friends working on bootstrapped companies have different problems - but are working just as hard as those with VC backing. The former are (sometimes) more in control of their companies since their goals are lower, while the latter find themselves chasing a bar that keeps rising. But both are working their butts off on a daily basis. I am not seeing things like competition being weaker or them having an easier time (again: limited data set so beware).
Experientially, my impression is that it is all about the product market fit. If that product market fit is strong and in a great market, the business is a powerboat that you can simply pour gas in to make it go faster and farther - as much as there is potential, which sometimes turns out to be a large enough for VC. On the other hand, if the business is a sailboat, then you are at the mercy of the winds. If they are in your favor and so strong that you can't keep the boat afloat, raising VC makes sense. But if they are not, then VC backing is a poor fit - gas is useless because it is finite and the moment you run out of it (i.e. out of cash), the winds will push you back or sink you or you will sit still. Most of the drama around financing stems directly from not understanding the nature of the business and therefore financing it incorrectly (e.g. aspirationally raising a VC round for what is really a non-VC company / sailboat). That's why the best companies rarely need a lot of money to show traction - because they have great product market fit in a fantastic market, which simply pulls them.
The thing is, you can't control or change product market fit. There seems to be a good chance you can't even analyze it without doing things. You discover the type of boat you have by getting out there and sailing.
I am not good at wording things, but here goes: I didn't see you call it out directly, but I also find employees are discriminated by project. if you are not working on a valued project, any value you provide to the company will be shrank by how unimportant they feel the project is.
Priorities shifted. Management traded my project away to our sister team in India. In exchange, that team gave us one of their projects. It was an undocumented system, built on deprecated infrastructure, but it was nevertheless a critical component in production. I was assigned to untangle it from our sister team’s code and migrate it to a new framework, all while keeping it running in production and hitting its performance metrics.
I agree that choice of project has a large effect. Projects that involve collaboration with a lot of partner teams increase your chance of promotion because the more people your work impacts positively, the better your set of peer recommendations when it comes time for promotion.
It's much harder to "sell" a project whose effects are only directly visible a few people, even if it's valuable work.
His career trajectory has been similar to your story, in that he was a line engineer who went independent. The think that makes patrick great, though, is that he took the time to write up all his lessons in a blog that is essentially a how-to guide for engineers who want to make the move from "I just write code" to "I am a sucessful self-employed software consultant.
If you haven't come across him before, I strongly suggest you check it out
https://www.indiehackers.com/podcast/013-patrick-mckenzie-of...
I am very much influenced by his story. I agree that he does a great job documenting what he learned.
I'm especially looking at the Keto Queso recipe. If you wanted to monetize that by instantly adding those ingredients + plus low carb chips into an Amazon shopping list, I would be buying through your affiliate link immediately.
Edit: I removed my comment about profiting off of others content being a 'very google' thing to do. OP does a great job linking directly to the recipe source.
Of course from my perspective, I want them to care about things like bugfixing or supporting my teammates. But then you have to put controls on that so that people can't just never really do anything except bugfixing or riding their teammates' coattails.
I think the right direction is weighing manager feedback more heavily so that if a team member is doing things that benefit the whole team, the promo committee can accept the manager's word that the person had an impact even if they can't quantify it with metrics.
Also, any chance of submitting a referral? :)
Commenter asks for referral from author who knows nothing about them.
My other suggestion would be to learn from my mistake and be realistic about your relationship with the company. It's filled with a lot of great people and they build a sense of community, but at the end of the day it's a business relationship, so you should decide what you want out of it and work towards getting that.
* Do NOT buy any line of the form "It is our policy to hire people with $YEARS of experience / $DEGREE degree / $OTHER_PROPERTY at level $LEVEL only"! It is all lies!