21 Lessons From 14 Years at Google

57 points by lalitm

srpablo

"Lessons from 14 years somewhere that never had to worry about costs, and where for ~95% of our products, we didn't have to care much about users, either."

I don't say this to invalidate the article entirely, just invalidate it in certain contexts. Too often people at startups. or non-tech companies that transition to include tech, or really anybody but a FAANG will read something like this and forget the very, very strange corporate and engineering environment a FAANG is.

Most places don't have hundreds of billions of dollars in revenue, 99% of which comes from a monopoly they established 20 years ago, the product for which you probably aren't working on. Most places don't get thousands of resumes for every position every day from every kind of applicant under the Sun. Most places won't have legal departments servicing every litigation-hungry crank and multiple national governments and their police. Most places don't rival developed nations in their security needs, and as being targets for espionage. Most places don't have billions of lines of code that you have to integrate with, and decades of norms and standards and custom tools, many of which were promotion vehicles for their creators. I can go on and on, but even with this list, all will impact how you build and collaborate, and isn't really generalizable outside the walls of the place.

Again: not to say it's all valueless (most of these are very high-level truisms said many other places anyway). But if you're at a startup or bootstrapping or doing open source or virtually anything else, most of these have a ton of wiggle room, or in some cases, may be counterproductive to you hitting your goals.

sjamaan

Good on you for ranting about Google, but your rant doesn't really apply to any of the advice here. All of these tips are essential when you're working inside an organization with other humans and getting paid for your work.
- telemachus
  
  All of these tips are essential when you're working inside an organization with other humans and getting paid for your work.
  
  Nearly all of these tips are empty nonsense, written in a mash-up of programmer cliches ("The best code is the code you never had to write."), corporate mumbo-jumbo ("Most “slow” teams are actually misaligned teams."), and self-help truisms ("Focus on what you can control. Ignore what you can’t."). I look forward to this blog post becoming a bestselling book, right next to the latest one by DHH and the other guy from Basecamp. (I can't be bothered to look up his name.)
  - esak
    
    #15 is Goodhart’s law - borrowed from economics, but seems generally relevant and pops up quite a bit in software discussions.
    
    #11 “ Abstractions don’t remove complexity. They move it to the day you’re on call” is one for my notebook, hits home.
    
    All Pithy? Yes. Nonsense and mumbo-jumbo? Ahhh, seems dismissive. I just take them for what he’s called them: lessons learned.
  - mond
    
    Meh. Empty nonsense is rough. Yes, you'll look at them and think they're "obvious" or "don't say anything", but understanding that something is true when it is presented to you and having internalized the concept and being able to apply it are completely different things.
    
    Even just having a name or short phrase for a concept (e.g. the classic "circle of control/influence/concern") can make it easier to work with it and internalize it.
    
    Stuff like "Code doesn't advocate for you, people do." is really valuable advice for young software developersz just because it is not something many of them will really have thought about at this stage in their career.
- Corbin
  
  Well, tip (8) isn't his; it's famously named after another Googler. (10) is a famous prayer used by anti-alcoholics. (15) is Goodhart's law, which has been independently rediscovered dozens of times and has multiple names.
  
  Meanwhile there's no mention of the actual important stuff to learn at Google, like how to read internal memos without giving in to the urge to leak them, how to properly back changes out of the merge queue when you've broken the GWS build, how to get the most out of your cafeteria by eating breakfast at work, etc.
  
  Elsewhere on Lobsters this same author is bragging about vibecoding. Please entertain the possibility that they aren't a serious skilled code-writer but instead focused on human connections and social impact.
osa1

I'm curious which ones of these lessons wouldn't apply in a startup? I thought it's entirely generic advice that you could give to anyone regardless of where they work.
rau
"Lessons from 14 years somewhere that never had to worry about costs, and where for ~95% of our products, we didn't have to care much about users, either."

His very first lesson is about obsessing over solving user problems.

But if you're at a startup or bootstrapping or doing open source or virtually anything else, most of these have a ton of wiggle room, or in some cases, may be counterproductive to you hitting your goals.

Which of these 21 lessons have a ton of wiggle room? Which may be counterproductive?
1. The best engineers are obsessed with solving user problems. [you yourself seem to think this is relevant outside FAANG]
2. Being right is cheap. Getting to right together is the real work. [applies any time there is more than one engineer]
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. [arguably even more true in a startup]
4. Clarity is seniority. Cleverness is overhead.
5. Novelty is a loan you repay in outages, hiring, and cognitive overhead.
6. Your code doesn’t advocate for you. People do.
7. The best code is the code you never had to write.
8. At scale, even your bugs have users. [from my own experience, this is true even when not at scale]
9. Most “slow” teams are actually misaligned teams. [misalignment may be more common and have worse results at scale, but it slows down teams even at very small companies]
10. Focus on what you can control. Ignore what you can’t. [good advice for life in general!]
11. Abstractions don’t remove complexity. They move it to the day you’re on call.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
13. The work that makes other work possible is priceless - and invisible.
14. If you win every debate, you’re probably accumulating silent resistance.
15. When a measure becomes a target, it stops measuring.
16. Admitting what you don’t know creates more safety than pretending you do.
17. Your network outlasts every job you’ll ever have.
18. Most performance wins come from removing work, not adding cleverness.
19. Process exists to reduce uncertainty, not to create paper trails.
20. Eventually, time becomes worth more than money. Act accordingly.
21. There are no shortcuts, but there is compounding.
- srpablo
  
  His very first lesson is about obsessing over solving user problems.
  
  Sure, but Intentions aren't the same thing as executing? When you look at Google's history, they haven't done great for users for a very, very long time. Their graveyard is a meme. Their messaging apps are a meme. The in-depth articles of how they messed up Search against the interests of users. Have you ever talked to someone who put their stakes in Stadia?
  
  I guess the point I'm making can be explained with an example: if two Math students are telling you about calculus, would you trust the one who had their tests graded, or one who never took a graded test? There's nothing saying the second doesn't know calculus, but I'd almost always take the advice of the first, because the second one never has to be right to still appear, to themselves and in their environment, as successful. These are things you could come up with just by playing the internal politics of Google well and reading a lot of books on engineering leadership and blog posts, but if you're early at almost any other company, you can't just act smart and play the internal politics well.
  
  Which of these 21 lessons have a ton of wiggle room? Which may be counterproductive?
  
  The ones I think have wiggle room or are counterproductive deserve much better treatment than I'll give them here. But hopefully they shed some light:
  
  Clarity is seniority. Cleverness is overhead.
  
  Novelty is a loan you repay in outages, hiring, and cognitive overhead.
  
  This is a bit of a hobby horse for me, but to me these are thought-terminating cliches that managers say to feel "mature," but they hold the field back. So much of tech leadership these days is by swimming in the dopamine of feeling like you're an "adult in the room" and sanding down the edges of creativity and removing risk, but removing risk is not the game of startups. Sometimes you can be clever or use novel tech and a) have much more motivated, invested, excited engineers, b) leapfrog your competition. There are big success stories:
  
  Figma, for example, built their own renderer in the browser using WebAssembly when it was way less mature, which allowed them to be a web app with consistent cross-rendering, which helped them trounce their main competitor in the early days (Sketch, a Mac app). WhatsApp used Erlang, and did bare-metal, manual deploys before they got acquired by Facebook (and served hundreds of millions of users with a staff of 50). Mozilla invested into creating Rust and using it to implement algorithms produced by academia to execute the Lightning rendering project.
  
  I'm listing the positive cases, and the industry had a real problem with "novelty-driven development" in the late aughts. But I'm so, so tired of being told that we have to just do what's most popular, and if you're early at a startup, it's a great time (provided you own your choices, don't leave, and have leadership buy-in... but maybe you're leadership!) to flex a bit and get clever. Again, it can frequently work against you, but it can also work great, per the examples above.
  
  You can read me say a lot, lot more about it here and here. But generally speaking, I don't think you get breakthrough success by following known, riskless process. I acknowledge (and remember!) the risk of being "clever," but I think the pendulum has swung way too far the other way.
  
  Your code doesn’t advocate for you. People do.
  
  At scale, even your bugs have users.
  
  These don't matter nearly as much pre-Series A. Of course I won't say "don't ever think of the future" but if you hit PMF and raise, you can hire people to worry about the unscalable/shortsighted decisions you made earlier. I've been hired post-A and spent my entire lifetime at certain companies working around founding engineer's design decisions, like a game of Viscera Cleanup Detail. But you know what? We had customers! And revenue!
  
  If you win every debate, you’re probably accumulating silent resistance.
  
  Writing forces clarity. The fastest way to learn something better is to try teaching it.
  
  Being right is cheap. Getting to right together is the real work.
  
  These are correct in the long run, but I see people in early companies try to make a great documentation culture and create lots of process and meetings when they, frankly, should be talking to customers and/or hacking. Again, just my two cents after 7 companies, some of which did very well: there is a lot of room to fix after-the-fact, but you have to get there first.
  
  I could write a lot more, but this is long enough and I've got other tasks 😅 I don't mean to trash the list; but I think it's mostly truisms you can "learn" from reading other blog posts, and in my experience, people cite them when they do things that sink early companies.
wink

I think the bigger problem is really that the bigger the org the wider the spectrum of experiences. "Would I want to work there?" just makes zero sense to answerr even if you, after 10 years, only could realistically say something about 5 out of 100 teams.

For every person being happily there for 5 or 10 or 15 years there are dozens who leave earlier because they hate it.

landon

Several of these sound suspiciously like Amazon's "leadership principles"