Leaving Google

Last Friday was my last day at Google. Of course, when you leave Google you have to write some kind of letter or rant. Seriously it's a rule: they won't remove your neural implant until you hit publish.

Jokes aside, this is more of a memoir than a polemic. Of course I have opinions, but now's not the time. This is more about reflecting on the last seven years of my life, thinking about what was important and what I'll do differently in the future.

What I did at Google

I moved to New York and started at Google at the beginning of 2015. I'd always wanted to work there. It seemed like the place where the smartest people worked to solve the most interesting problems. I liked the idea of an engineering-driven culture where experimentation was encouraged and the business was less important. The possibility of working on a 20% project that made it big like GMail appealed to me.

Google might have been that company at some point years earlier, but when I joined it was already transforming into a stodgy megacorp. I think it would have been difficult to start a "moonshot" project like self-driving cars or a new programming language in 2015. It's vanishingly unlikely today.

Docs, Sheets, and Slides

I started out on the Android apps for Docs, Sheets, and Slides. It wasn't quite the kind of work I was hoping for, but Docs was growing when I joined, and the people seemed great. It was interesting to work on mobile apps for a couple years, but the organization had some serious problems.

First, my team lacked mentorship and support. We inherited the Android apps from the Drive team in Sydney (originally, Docs, Sheets, Slides were bundled into the Drive app). Our team was all new hires (mostly new grads) and transfers from other parts of the company, so no one really understood the technical infrastructure, and we didn't know who to ask when we had questions.

Second, management was spread way too thin. My last manager had around 25 reports. We met for half an hour every three weeks, and for several months, she couldn't remember the name of my project. I gave up on ever getting promoted there.

Third, the organization was extremely product-driven. PMs made all the decisions. Engineers (at least at my level) had very little influence. We were expected to hit precise deadlines on multi-quarter projects (within two weeks), and when that inevitably didn't happen, we had to track all the time we spent on anything in 30 minute increments. It felt very cog-in-the-machine.

I got frustrated and transferred out after two years. In hindsight, I should have left much earlier. (Amusingly, another new hire joined my team on the same day. He transferred out within a week! We nicknamed him Waldo because we could never find him. Turns out he was talking to other managers.)

Some key lessons from this time:

1. Mentorship is really important, especially early on. It's absolutely vital to have someone early on to fill you in not only on the architecture of the project, but also the history and the organizational politics. Because of Conway's Law, those things are deeply interlinked. If you're joining a new group, find someone to spill the tea and give you that history.
2. Supportive management is vital if you ever want to get promoted. I joined Google at L4, which was at least a level below my previous job (staff engineer at Qualcomm). I thought I'd get promoted quickly, but it took over three years. My time in Docs didn't help me at all toward that.
3. Make sure you value the same things the organization does. Docs leadership was focused on delivering new features to paying customers. I value minimalist, fast, reliable software. Neither viewpoint is wrong, but they're in tension, and I was never happy doing the kind of work that was needed there.

Go support for Bazel

I joined the Go team in early 2017, initially building Go support for Bazel. At the time, Google was trying to open source or rewrite much of its internal infrastructure for the benefit of Cloud customers and new Alphabet companies (the formation of Alphabet was still recent). Bazel is the open source version of Google's internal build tool, Blaze. The Blaze Go rules had a lot of idiosyncrasies that didn't match the external way of doing things, so rules_go was mostly a greenfield project.

I didn't actually know Go or Bazel before joining the Go team, other than reading The Go Programming Language by Alan Donovan and Brian Kernighan, which came out a year earlier. Actually quite a few people on the team first learned Go when they joined. That's a valuable lesson in itself: "N years of experience" requirements are unnecessary gatekeeping. Smart people can pick up anything quickly, and diverse perspectives are valuable.

Alan was an extraordinarily good mentor. Early on, I reviewed code for his new Starlark interpreter. It was a fantastic way to learn idiomatic, performant Go. I don't think I caught many bugs in code review, but I took the opportunity to ask many questions and learned a lot. As one of the creators of Blaze, he helped me get up to speed quickly there, too.

I was also lucky to have supportive managers, and my work was closely aligned with organization goals at the time. Many companies and large open source projects like Kubernetes were migrating to Bazel, so having solid Go support was crucial. I was promoted to L5 after a little over a year.

Those kinds of tailwinds are nice when you can get them, but they don't always last. Soon after, the Go team was reorganized into Google Cloud, and Kubernetes decided to stop using Bazel, so priorities shifted. Go 1.11 shipped with experimental support for modules, and it was clear that dependency management would be really important going forward. Most of the New York team shifted to making modules production-ready.

I started working on the go command (go build, go get and all that) at the end of 2018. Early on, I improved performance, added better diagnostic messages, and rewrote go get (it's been rewritten at least twice since then). Later, I added the retract directive, the cmd@version form of go install and go run, and many other minor features and improvements.

Probably the most impactful thing I wrote was the module reference documentation, about 80 pages of text explaining how the module system actually worked, including a specification of all the syntax and protocols. Dependency management is complicated (due to innumerable many edge cases), and it was hard for developers to migrate to modules without a manual. Measuring the success of a documentation project is difficult, but anecdotally from watching mailing lists, Stack Overflow, and public Slack, it seemed fewer people were getting stuck, more advanced questions were being asked, and people were more able to help each other.

The project I was most excited about though was native fuzzing, which I worked on with Katie Hockman. It was a lot of fun to build a fuzzing engine from the ground up (of course, learning a lot and borrowing ideas along the way). Regrettably, I didn't stay around until it shipped. Go 1.18 will hopefully be the first release with native fuzzing. More work is needed to improve its effectiveness to match go-fuzz and other systems, but even in its early state, I think it will catch a lot of bugs.

The biggest drawback of working on the Go team was how overloaded everyone was. The team was full of incredibly talented, productive people, but every person was carrying a heavy load. It was hard to actually complete and discharge any project since everything requires a bit of ongoing maintenance. I ended up being at least partly responsible for six projects. It was frustrating to divide my attention so many ways and not make progress on anything. I'd spend entire days barely keeping up with issue triage and code review.

My key lessons from this time:

1. Limit the number of long-term projects you're focusing on at any given time. It's better to do one or two things well than six things poorly. If a great new opportunity comes up, take it, but drop something else. If the dropped thing was important, it'll get staffed. If not... why work on it?
2. Teams should be responsible for products, not individuals. Go had too many projects owned by one person. That causes burnout and orphaned packages.
3. Working at scale is important, though it can feel "lazy" at times. When I worked on Bazel, I spent a lot of time helping individuals fix problems directly. It felt productive and gratifying, but there was no end to those problems because the rules were underdocumented and too difficult to use correctly. In contrast, writing the module reference documentation was a more efficient use of time because it scaled better. People could mentally model the system and avoid problems without needing help.

What kept me at Google

The people I worked with at Google were amazing. I got to be close friends with many people there, well beyond the normal coworker congeniality at other companies.

On Docs, we stayed late many nights playing Coup or Pandemic Legacy (great game, not a great choice these days though). Sometimes we'd gripe about things at the bar under Chelsea Market.

On Go, we cooked together and had dinner parties. We had a great time at conferences; drinking frozen margaritas around the pool at Gophercon 2019 after the talks were over was a highlight in my memory.

It's hard to adequately describe how I positively I feel the people there and I how much I miss them already. I hope to stay friends with everyone, but I know it won't be the same. There's a group spirit that goes beyond individual connections.

My biggest fear about going fully remote is that it's going to be difficult to reproduce that kind of connection on any new team. Those bonds are formed in person. We only weathered the pandemic as well as we did because those were established earlier.

Why I left

The reason people write these letters (and everyone else ridicules them) is because we've been at least a little brainwashed into thinking a job at Google is the pinnacle of employment. Leaving a job isn't usually an action that requires much explanation.

Here it is anyway.

Burnout

I'm so tired. Everyone I know is burned out or right on the edge of it. I didn't expect this tweet to get nearly as much attention as it did. A few days later, I was surprised to see myself quoted in Burning out and quitting by Maya Kaczorowski. That article really resonated with me. I wrote about my experience with burnout through the pandemic earlier in the summer, but I didn't post it anywhere because it was just a long, boring personal story (kind of like this one). Maya's article was much better.

To summarize, I felt pretty stressed and overloaded before the pandemic. Everything that happened in 2020 pushed me over the edge. I started losing a lot of sleep, and I got a lot of headaches and back pain. I got a lot of "brain fog": inability to concentrate or make decisions. I started forgetting words and names and losing the thread of a conversation mid-sentence. I felt like I had no energy left for anything other than work, and I could barely manage that. I started making lots of mistakes that took time to fix later.

I tried just about everything I could think of. A few things helped, but not enough. I couldn't work anymore, and it was time for an extended break. From speaking with other people that have gone through this, it seems like the only thing that really helps.

Career and compensation

I could have taken a long leave of absence, then come back fresh; Google allows up to three months unpaid. I wanted to make sure I wouldn't burn out again though. Two big things stopped me.

First, Google was about to cut my compensation by 10% because I went remote. I moved back to San Diego in June before there was any remote work policy. I figured they'd have to come up with a remote work policy at some point, and I was willing to walk away if it was too unfavorable. A 10% cut is pretty damn unfavorable, considering I was doing the same work on the same team. It's not like the company couldn't afford it either. From the 2021Q1 earnings, Google Cloud revenue was up 53% year over year, and overall revenue up 61%.

Second, I didn't feel like I had any chance of being promoted to L6 for my work on Go. Google doesn't use the go command or modules, and since there's no direct measurable benefit to Google, it's very difficult to make the case. It's hard to get promoted beyond L5 for open source work that isn't directly tied to the business, so consequently, most folks on the Go team are piled up at L5. I felt that if I wanted growth, my choice was between finding a new job inside Google or outside.

Other thoughts

There were a lot of things that happened at Google that I was unhappy with. Maven and Dragonfly seem like a distant memory now. Quite a few activists and researchers were fired for asking Google to be a bit more ethical. I've also seen friends underpaid, underleveled, and treated with less respect than they deserved.

I wish I'd done more to fight those things, beyond signing petitions and walkouts. I'm not much of an activist though, especially with burnout. All I can say is that those people aren't far from my mind. Those events made the decision to leave easier, and I'll be thinking a lot harder about ethics in whatever company I join in the future.

What's next?

For the first time in my life, I don't have any plan on what to do next. I'm taking at least six months off, maybe a year. Call it a sabbatical I guess. Or a rumspringa.

I have some ideas on what I want to do during that time: train for a marathon, get better at cooking, start a vegetable garden, take a painting class, join a karate dojo, make some local friends... Mostly though, I just want to be a person without work for a while.

I feel extraordinarily privileged to be able to do this. My wife also works in tech and can comfortably support us both. I hope in a year, I'll be rested and ready to jump back into tech with a better sense of purpose and direction.