My learnings at Google

I just quit Google after almost 7½ years. When I had joined Google in 2016 I was exploring to start up with a travel planning, sharing and booking platform. But then when I got the chance to join Google I told myself that I will stay for 3-4 years and learn how Google's culture makes it build products that people love, at scale. Also, their engineering culture was something I had heard a lot about and thought this is my best chance to learn about and implement it in my startup. But then I managed to overstay at Google for various reasons. 

There are various posts talking about what is wrong about Google here, here and here. But I wanted to look at its positives and I hope companies adopt it rather than a toxic culture which is brewing everywhere.

Here are a few things which stood out for me (in no particular order):

1. Blameless postmortems : Blameless postmortems are a powerful tool for learning from incidents and improving system reliability. The key aspects of it are

 a. Focus on Learning, Not Blame: The goal is to understand the root causes of an incident and identify actionable steps to prevent similar issues. The person leading it is not considered at fault but the a crusader who is out to ensure this kind of thing does not happen again.

b. Psychological Safety: A blameless culture fosters open communication and encourages everyone to share information freely. Everyone just tries to find a fix for future problems than blame or reason why the person is at fault. It assumes its a process and not a person problem.

c. Root Cause Analysis: Identify the underlying factors that contributed to the incident, not just the immediate trigger. It also helps with finding the right steps to avoid this kind of incident in future

d. Actionable Steps: Define concrete steps to prevent similar incidents or mitigate their impact. There are almost always followup work wrt to change in process, adding more checks or tests.

e. Continuous Improvement: Regularly review postmortems to identify trends and implement improvements.

2. Tools and automation - Google invested a lot in tools and automating all tests. Manual tests are done only for sanity and initial development. Automated end to end tests are mandatory for teams to implement. Only in rare cases that manual tests are done where automation is not possible right away due to hardware or other constraints.

3. Product, UX and Eng teams working as a unit - This is something I experienced even at Intuit. There are several benefits to having product, UX, and engineering teams working together as a unit. With Eng, Product and UX working together, they build a shared vision. Each learns from the other and leads to a much better user experience overall. Its not that UX dreams something which the users dont want or the eng implements such that its not usable. Each team gives feedback to the other and improves efficiency of implementation as well. True innovation comes when all three brainstorm and come up with a truly unique solution. I can give perhaps several examples of it during my time with GPay and Assistant(Gemini) especially but cant put them here for various reasons.

4. Product does not scale by burning developers : This is something I saw at Google early on but its changing now. Even at other places like Intuit and Adobe, I saw this first hand. We do have to pedal hard near the finish line but dont have to do it all the time. Having to burn weekends and night, day after day, leads to general unhappiness, creation of technical debt and lower quality(because people want to take all the shortcuts possible) and in the end you lose your top developers.

5. Code in the open : All code that you write, all prototypes are all in the open. Anyone in the company and search and look at the code that you have submitted and pending changes. This ensures that you can learn from anyone. I could potentially learn from actual working code instead of that hypothetical, non-working example from stack overflow. This is especially useful when you are new to a framework or language. Also helps to quickly answer the product and UX team if something is possible to do or not.

6. Code reviews and readability : Google has this culture of language readability. This is where all code submitted has to be approved by experts in the language. This helps ensure all the idioms and features of  a particular language is utilized well and acting as gatekeepers of code quality. There are two types of reviewers other than this, feature reviewers and owners. Sometimes both are same but often this also enables cross team collaboration between product teams where changes are being done by someone else but owner is aware and approves the changes. This was such a strange and alien concept when I joined but now its seems the obvious way. Kind of like an open source project where anyone at Google can contribute.

7. Make people comfortable at workplace : All the facilities at Google were ensured to make employees feel comfortable to do their best work without worrying about other things. Early Google did things over the top but they still worked in the best interest of the company because if employees are not thinking about daily chores and its easy to take care of while in office, its more time to do things at office. If I do not have to think about where to order food or which restaurant I should go to, it one less thing to worry about at lunch time. Having worked at companies which did not provide food and we had to spend 30 min discussing where to go today, I think free food is much more beneficial for an employee than the company. But Google did not just provide any food, its always delicious and at the same time on the healthier side.

8. Hiring Generalists instead of specialists : Though this may not be true anymore, this was the first company I ever encountered which did not mention language and instead focused on concepts. Google hired generalist software engineers who are comfortable with anything thrown at them. This is true because changes happen so quick that you need people who are not tunnel visioned with their ponds. Software engineering truly requires adaptable, fast learners who can do not lose focus of the big picture. The language and frameworks deprecate faster than one of think. COBOL programmers though have their place, but not in an innovative fast changing environment in which Google likes to operate.

9. Ladder, Performance Reviews and Promotions : This is not perfect at Google but there are parts of it which I like. There are just a handful of levels, which is different from many other companies which I have worked in. They just invent levels for people to move in while their work remains unchanged. But with Google they did clearly define things expected from them at each level. There are different ladders for individual contributors and managers and not everyone is expected to become a manager. Performance reviews and promotion depend on the person and not just the manager. Each employee has to write a justification as to why they should be promoted. I would be lying if I said, manager does not play a role. I know folks who decided not go for promotion and have been at the same level for some years now. They are happy and they are at the target level. While there are others who know how to play the game and make most of it. 

As I mentioned before, I’ve been wanting to start my own company for a while now. Over the last few years, I’ve been exploring different ideas. Now that I’ve left Google, I have a much better idea of what I want to build. I’m hoping to incorporate the best aspects of Google’s culture into my startup, while avoiding the parts that don’t work. As soon as we have something substantial to share, I’ll post more details here. In the meantime, my dear friends, please don’t hesitate to reach out.