From Google to Twitter (initial thoughts)

2022-03-01

In 2021, I joined Twitter after 14 years at Google. Here are a few minor thoughts about some differences I have noticed so far.

A few caveats:

• 🏭 I haven’t been able to visit an actual Twitter office yet, so I can’t say anything about that side of things.
• 🧪 I’ve only been at Twitter since July 2021; I was at Google for a lot longer but I didn’t move around between projects as much as the average. So for both companies, my “sample size” isn’t that large.
• G I have never worked for another tech company apart from these two. The “early Google way” heavily influences what I would find “normal”, for better or worse.
• 💣 These are just mundane observations as a lowly engineer. If you’re looking for a perspective that is both a little higher level (company ethics, leadership, etc.), more lighthearted, and often a lot more critical, take a look at the two cartoon series “Goomics” and “Twittoons”.

So here we go:

• 💬 Slack vs email: everything at Twitter happens on Slack. One-on-one chats, team discussions that don’t need to be meetings, questions to leadership for all-hands meetings, requests for code reviews, social chit-chat, etc. It’s not uncommon that I don’t even bother to check my work email for a few days; that would never have happened at Google where most things are done over email (some people also use instant messaging, but those discussions aren’t assumed to be archived/preserved for the future). At Twitter, you will more likely find relevant information for your problem by searching Slack than other internal properties. The flip side is that if Slack is down for any nontrivial period of time, that’s a significant loss of productivity / knowledge.
• 🔃 If it’s not core, it’s outsourced: Twitter outsources a lot more things than Google does. Google likes to spin their own solution for pretty much everything. They even used to have their own HR system (named, wait for it, GHR) until they switched to Workday. Google has their own bug tracking system, email, calendar, online office suite, code review system, internal communication and social interaction tools, you name it. Twitter uses Google calendar, email, office suite, Jira (bug tracker, project management), Okta (single sign on), Phabricator (code reviews), Sentry (error monitoring), WorkDay (HR, goal setting, peer reviews), Splunk, Office Timeline, Duo (authentication – when I first joined and was told to install Duo on my phone, I was mildly puzzled as I thought that referred to Google’s video chat application). This also applies to more technical stuff and using open technologies. On the one hand, this makes Twitter a lot less of a “tech island” than Google is; on the other hand, authenticating into a thousand services at Twitter can be a little inconvenient (single-sign-on tools are making it mostly painless, but not always). The outsourcing can go quite far: I was surprised when my team did its first “retrospective” (discussion on what went well and what can be improved) and we were pointed to an external tool for that, too. It makes sense in many ways, but it’s the sort of things that ex-Googlers may find surprising.
• 🍎 Apple laptops: for some reason, I would have expected Twitter to also be big on using more open source software. It turns out 99% of employees use Mac laptops: it’s the only officially supported platform. A very small number of people use Linux laptops, and they need to jump through a bunch of extra hoops to get things to work smoothly. I expect that this will gradually change if the company keeps growing.
• 🗓️ Meetings : I sometimes hear that one company or the other has a more meeting-heavy culture. I haven’t really noticed that. From my experience, it depends more on the team/project you’re on, than on the company.
• 🤡 No Memegen: maybe I should make a Memegen clone for Twitter :-D
• 🌍 Distributed: Twitter is overall friendlier to remote work. Teams are distributed geographically (and likely even more so with the pandemic). Instead of trying to top-down “defragment” teams, the tools and culture are adapted to better fit a distributed workforce and be “async-first”. I would have expected Google to go further in that direction too with the pandemic: it has, to some extent, but not as much as I’d have thought. Twitter also has a lot more international offices than one would expect for the company’s size, so it seems like the the threshold for opening a new office is significantly lower.
• 💻 My other computer is not a data center: maybe paradoxically (given the previous item), it is very common for Google engineers to use a big powerful machine “in the cloud” (or in an office) and to drive it remotely using something lighter, that can be used from anywhere with good internet (I started doing that around 2008). I would think this is overall more cost effective, especially if the computing resources are dynamic/shared. That doesn’t seem to be a thing yet at Twitter (though there are some discussions). Hence, every engineer carries a beefy laptop around. Of course there are pros and cons.
• 🛠️ Hack week, 20%: Google has had its famous “20% project” policy for a long time; it’s all but moribund by now. I quite like Twitter’s “Hack Week” because it makes it clear and accepted that people aren’t expected to be making progress on their main project during that week. It obviously doesn’t quite amount to 20% though. I wonder what one “hack week” per quarter would produce.
• 👫 Gender diversity: my sample size is likely too small to tell if it’s really a difference between companies, but on average a lot more of my engineer co-workers at Twitter are women. And it’s actually the first time in my career that in many of the eng meetings I attend, I’m the only guy in the virtual chat room (out of 3 or 4 people). This is absolutely awesome.
• 👷 Manager technicity: again my sample may be biased, but it seems like managers at Twitter aren’t as technical, or actually, they are technical in a different way. While I was at Google, a lot of the time my manager could (maybe after a week or two for getting up to speed again) have done all, or most of what I did, and often times better and faster than I could. Come “performance evaluation” time, they could absolutely (and often would) look at some of the code changes I made over the period. Again maybe I haven’t seen enough yet, but Twitter “TLMs” (“tech lead managers”) are more managers and less “tech”. I mean, my current manager used to be an iOS engineer so she would absolutely kick my butt around the Earth five times before I can say “autorelease”, and she would definitely understand the gist of my code in a web application, but maybe not with as much of a deep understanding of the tech stack. This also has pros and cons, but let’s say that I spend three weeks on a really difficult task, but at the end of the year I forget to boast about it or to request a peer review from someone who was in the loop, it would likely go unnoticed.
• 🙋 Q & A with leadership: Googlers used to have a pretty open channel of communication with the company’s leadership during the weekly company-wide all-hands (TGIF). It’s much less open by now. Twitter’s “OneTeam” is still pretty open from what I can see, but the process for asking questions and get them forwarded to people on the virtual stage is pretty messy (all done on Slack). During the last “hack week”, I made an open source clone of Google’s “Dory” (known as Moderator for a little while) that I named Marlin. I then found out that Twitter used to have a similar tool, and there’s a bit of controversial history to dig up here. We’ll see where this goes.
• 📃 Documentation/comments: I don’t have objective data to back this up, but I feel like engineers at Twitter are less diligent at adding comments and documentation to their code. I would say that most teams at Google are far from great for this, but if anything Twitter is a bit worse. For instance, a good practice could be to provide for each toplevel “class” (assuming an object-oriented programming model) a short description of what it does.
• 🗝️ Code ownership granularity: Code “ownership” is a common pattern to guard against bad changes. To make any modification, you need to either be an owner of the piece of code you are changing (or of a superset), or get an approval from an owner. In most projects that I’ve seen at Google, the level of “granularity” for ownership is significantly lower, meaning that various sections and sub-sections of a piece of software can be owned by different people. With the general rule of thumb that the longer you’ve been on a project, the more you “bubble up” the ownership tree and can change or approve changes to larger chunks. Twitter, so far, has more of an “all or nothing” approach. Once you become an owner for the web application code (respectively the iOS client, the Android client, etc.), you can make changes to any part (with a couple of exceptions). I know there are discussions to potentially move to more granularity.
• 👀 Code reviews: I would say that the code review process at Twitter is both faster, and requires more effort. Google’s internal code review tools provide you with a simple and automated way to add a suggested set of reviewers for a given change. It takes into account code ownership, time zones, people out of office, etc. So you can generally just press a button and assume that your change will get reviewed in a reasonable time frame. At Twitter, the “code ownership” constraints will be enforced, but it is up to you to assign reviewers (as groups or individuals). Once you’ve done that, you need to explicitly ask for a review, either on a Slack channel, or to a given person (I made a simple browser extension to make it a little easier). The flip side is that you can usually get a review faster.
• 👨‍👧‍👦 Pods: I am still figuring this out, and I think this is specific to engineers working on the Twitter web application (I still need to read this article which specifically describes this in more detail). But my first reaction to seeing these “pods” was mostly puzzlement. They are not purely a social thing or it would probably make more sense to include engineers working on iOS, Android, Back-end, etc. They are not project-based either (pod members tend to work on different features). Nor are they related to the org chart, since pod members report to different managers. But there is a social dimension, with regular meetings for casual chat and/or playing games together. There is also a project dimension since pods seem to have meetings where everyone quickly describes their ongoing tasks. And there are regular meetings between the pod’s “tech lead” and the pod members. I’m going to guess the goal may be to bring people with various degrees of seniority together (but wouldn’t project-based teams tend to achieve the same purpose?), to spread knowledge about the various ongoing efforts, and to provide a smaller work group within which people can review one another’s code. So I’m still a little puzzled, and I look forward to reading the article above, but I thought I would share my impression before getting the “official” story.

I hope that wasn’t too boring, thank you for reading, and feedback welcome!