Lessons Learned at Google
When you have a new beginning (a new job, a new year), it is always valuable to reflect on the past.
As I begin my new job, I wanted to capture some of the lessons from my almost 4 years in my previous role. With any new position you learn things: domain knowledge, expertise, etc. However, when I think about my time here the lessons are a bit more meta and philosophical.
Below are my favorite lessons that I plan to take with me:
Duplication isn’t always bad. I can remember I was 3 months in, when I learned about 2 teams building things that had very similar purposes. This felt like sacrilege to me, because I am from startups where one is always constrained on time, people and budget, that any duplication could mean failure. I brought this to the attention of my manager and he said he felt the same initially, but in this case the company was so big that the cost of forcing people to use the same things could be more expensive than the duplication. Moreover, that if one solution was truly better, in time that one would win out.
This was not a way I was used to thinking, and when you aren’t constrained on resources this inefficiency can result in speed and better solutions. I am still not totally comfortable when I see duplication (I don’t like waste and inefficiency) - but I have learned to see the merits of different models and be more open to cases where this makes sense.Don’t solve problems you don’t have. One of the biggest problems I saw among teams was over-engineered solutions. Whether they feared the solution not being accepted by security or thought their plan wouldn’t pass a review. This de-risking resulted in engineers building more complex solutions that were warranted, often resulting in confusion and tech debt years later. If I was to give one piece of advice to the teams behind me it would be this, and to focus on moving faster. Look at decisions as one or two way doors and try to make everything a 2-way door where you can reverse your path if you need to.
Psychological safety and trust is what makes great teams. There is research that shows this, but during my tenure I had the opportunity to see this transformation take place on two different occasions. When teams know they can always trust one another, and that everyone has their back - they are more willing to take risks, be vulnerable, internalize feedback - and everyone grows and levels up. The whole truly becomes greater than the sum of the parts.
A bad performer in one team can shine in another environment. One thing Google does exceptionally well is hire great people. However, there are circumstances where a person’s performance can degrade or situations where people struggle. By making internal mobility so easy, and allowing people to move teams even with low ratings - employees are able to make changes when things aren’t working. I saw enough examples of people moving from “Needs Improvement” ratings to “Strongly Exceeds” by changing their environment that I have become a big believer in second chances and a stringent hiring process.
Easy internal mobility creates great managers. When I first heard about the transfer process I was shocked - managers had no say on the transfer, and new managers aren’t even required to discuss with the previous manager. All the employee has to do is file a ticket to initiate their transfer. My initial reaction to this was something like “What about business continuity? What about managing our poor performers?” However, over time I grew to love this philosophy.
It is up to the incoming manager to assume the risk of any transfer they take on and they can do as much or as little due diligence as they want. Moreover, knowing your people can leave at any moment encourages all the right qualities in managers - investing in their people, promoting from within, and growing through constructive feedback.Org structure can work for you or against you (Conway’s law). When you manage large teams you think a lot more about the way those teams were organized. And with software teams, the hierarchy that is imposed will reflect the way those systems interface. Too much distance between dependent systems can result in efficiencies and point solutions (where teams solve their own problems because the coordination and collaboration with the other team is too high - i.e. competing priorities).
Having strong leaders, incentivizing collaboration, and aligning the teams around common missions (and priorities) can help. However, a reorg should always be your last resort. In most cases, starting with the process and the people (and the incentives!) can work wonders.
And with any org design you always have to keep in mind what you want to optimize for: innovation, efficiency, reliability & redundancy, etc. Different models (including how you allocate headcount and budget) can call for different structures (for example product based teams, tech stack focused teams, or mission based teams). Always start with your goals, think 1-2 years out, then work backwards to evolve your people. Never start with the people.Weekly team syncs + demos. One of the teams I had the privilege to work with had this amazing tradition of Friday demos. It was so great because the bar for demos was low - a color change, a new api, a new button, etc. And so the full hour was often filled with 5 minute demos of the team’s work. Team members would present lessons learned from conferences they attended, or short talks on tips and tricks to be more productive. It was also where the leadership team shared pass downs. They celebrated birthdays and launches, and every Friday was a blast for the whole team. A celebration of the work, events and the people on the team. I loved this tradition so much and wish that more teams did something similar.
Love perf, hate promo. The perf process is one of the best I have seen. Managers own ratings and can do what is right (I have long held the belief ratings are free things you can give and can be a huge motivator). Reviews are 360 and peer feedback is rating as heavily (if not more so!) than manager feedback.
The promotion process, though, has so much bias built in. With the committees structured how they are, even though they might be objective, have resulted in so much time to “prepare” for promo. And packets have become an exercise in marketing your skills vs. just doing great work. I wish the managers (or management chain even) had more influence in the outcomes. I have just seen too many examples of great people, well deserving of their promos, not get it because of the wrong reasons. And of course the packets are so much work, the cost of failure becomes so high - and very demotivating for great people.
One thing other companies, like Facebook, do (that would be a huge improvement) is to have candidates going up for promo in the future get reviewed by *the same* people that will make the decision in the future. This gives managers early signals such that they can coach their people and set up the right opportunities for them.
Like any ending I am sad about the things I will miss - my amazing team, the great adventures and the accomplishments we had together. It is the only place I have ever been where you can assume that every single person you work with is amazing. And people are so humble - I can remember the time I learned one of my colleagues had a PhD and JD, or another had written a textbook I used in school. The people are what make Google great.
Every ending is a new beginning though, and I am super excited for what lays ahead.
Until then, with more to come…..
