Multiple systems working posted on 26 February 2024

Coming from Google, here are two interesting things I recently-ish learned:

  • At Google every staff engineer and above (L6+) are all well rounded TL (tech lead) – they are very technical and have solid leadership skills. You can’t reach L6 by just writing a lot of code and not being able to communicate (and vice versa). At Databricks, we have multiple archetypes (e.g. fixer, product hybrid, subject-matter-expert etc.) that allow for more diverse/skewed profiles. I learned that other companies (e.g. Meta) also have similar archetypes.
  • At Google, every piece of code is owned by individuals/teams. Practically speaking if you want to update the code of service X, you need a code review from someone in X. Meta doesn’t have such a system – any engineer can modify any part of Meta’s code base and check-in at-will.

All these companies (Google, Databricks, Meta etc.) are successful but more importantly have

  • Top of the industry engineering organizations
  • Complex products yet stable and safe systems What’s very interesting though is that they achieved this through vastly different systems (different eng ladders, different code processes etc.). Until I joined Databricks and met some ex-Meta folks, I previously never thought there were other efficient ways to achieve good code quality, system stability, privacy correctness etc. in a way significantly different from what Google used to do.

To be honest, it still puzzles me how code management/release works at Meta without strong ownership – but this is a good reminder to keep an open mind when learning about new processes/systems.

What other cultural differences did you notice as you switched companies?

LinkedIn post