Remembering Google
I spent twelve and a half years working at Google, much of that time as the Ruby language lead for Google Cloud. As I transition out of the role, I look back on what made Google great, and what made it not-so-great.
I quit my job at Google early this month.
It has sometimes been difficult to explain to people why I, or anyone, would leave Google voluntarily. To many, Google is the poster child of the cushy tech job, with its playful office spaces, free food, lavish perks, and Big Tech salaries, not to mention the allure of sharing oxygen with some of the top minds and heroes of software engineering.
But we’ve seen a lot of changes over time, especially in the past few years. Post-COVID belt-tightening has taken root at Google, as at many tech firms, and there have been several large rounds of layoffs. But even prior to the pandemic, Google insiders will tell you the company culture had shifted noticeably over time. Internal trust and transparency has been eroding, as have the company’s famous historical commitments to “don’t be evil” and “focus on the user.” The Google of today seems to look much more like a stereotypical tech behemoth, and much less the idealized image of the nonconformist tech utopia that we might have imagined twenty years ago.
I won’t deny that these changes influenced my decision to leave, and to leave now. Of course they were a factor. But insight, like the devil, is in the details. So I wanted to reflect a bit on my twelve-plus years at Google, what I liked about it, what I didn’t, and where both I and the rest of the industry are going.
Joining Google
I joined Google as a refugee from a failing startup.
Besides an 18-month tribulation at Amazon (a mistake I will not repeat), and a few years break to return to school, I’d spent much of my earlier career at startups. None ever panned out for me financially, and the work was difficult, but I generally look fondly on those startup experiences. I acquired some lasting friendships out of the small engineering teams, and had opportunities to develop experience and interests that would later serve me well at Google.
But in early 2013, as I saw yet another startup starting to collapse around me, I decided to switch gears and try something different. I responded to a Google recruiter who had been pinging me off and on for several years, and started interviewing.
Google interviews at the time were very much the design-puzzling, whiteboard-coding affairs that are rightfully notorious. But what stood out to me wasn’t my struggle with the interviews, but the interviews’ struggle with me. My last few startups had built their technology on the Ruby programming language and the Ruby on Rails web framework, so Ruby was my most comfortable language at the time, and I used it in most of my Google interviews. But Google generally doesn’t use Ruby internally, and Google engineers typically aren’t familiar with the language. I could tell that many of my interviewers were a bit lost when I started coding. They didn’t have informed follow-up questions on my code, and would whip out their phones to take photos of my answers, presumably so they could later search for an internal colleague who might know the language to help evaluate my work. I passed the interviews and was hired as a senior engineer, so it worked out, but this was my first exposure to Google’s technical monoculture and some if its implications.
Like many new Googlers—”Nooglers,” as we are called internally—I bounced around a couple of teams before really finding my calling. During my first few years I had both good managers and terrible managers, and worked on both interesting well-established projects and poorly-conceived disasters. But I missed being a Ruby developer, and when an opportunity came up to work on some Ruby as a “20% project,” I jumped at it.
“20%” was a big part of early Google culture. Engineers were encouraged to spend 20% of their time engaged in personal projects or helping outside their normal areas of work. The theory is that doing so would stimulate creativity and employee growth. By the time I started in 2013, there were indications the program was in decline, but many people still took advantage of it, and there were still cases where a 20% project would grow into a full-fledged Google product or program.
Mine was one of those. I joined a small ragtag group of Ruby enthusiasts, organized by a product manager who himself was a NodeJS nerd but loved programming languages and language communities in general. We started building out Ruby support for Google’s fledgling cloud platform, as well as producing content for Ruby developers, engaging the Ruby community, going to conferences, and generally having a blast. And it worked. We started getting noticed externally in the Ruby developer community, and internally at Google. Within a year, Google Cloud had funded a full program to solidify its support for a set of popular programming languages, including Ruby, and had brought in some of our 20% group to full time roles in that program. I in particular was tapped to lead the Ruby language effort.
Highlight of a Career
My time working on Ruby at Google Cloud was easily the best period of my career, for a number of reasons. Being one of the few experienced Ruby engineers in a company that otherwise explicitly didn’t use the language, meant that my skills and expertise were in high demand, and I quickly became the go-to Ruby expert for the entire Cloud organization and beyond. It was a chance to be involved with a large number of Ruby-related projects across the company, from API clients to serverless runtimes to documentation and support strategy to developer outreach. Even with a relatively small, scrappy team, and not a lot of support from the company as a whole since it did not have much Ruby development infrastructure, we were able to bring Google Cloud’s Ruby support on par with the other, largely better staffed, languages.
It didn’t hurt that I had some of the best colleagues one could ask for. The aforementioned NodeJS nerd, who would later become my manager, exuded the same love of community and care for customer needs that I aspired to. Google would hire several additional Ruby enthusiasts that I knew, and though not all were directly on my team, we would collaborate on a number of projects together. And our partner teams supporting other programming languages were staffed by some absolute luminaries from their respective language communities, people who were a real inspiration for us.
But I think the best part of the role was the transition to what was termed Developer Relations Engineering. Like many tech firms of the time, Google had a strong Developer Relations (“DevRel”) organization. Many of my early collaborators were part of DevRel, and, after a few early organizational missteps and reorgs, I, along with some of the other traditional software engineers working on programming language support, also transferred into the role. As DevRel engineers, we really began to flourish.
DevRel is often difficult to define, and different organizations have different spins on it. I see it as an integrative role that combines engineering, content, and customer support and engagement, with the overall goal of making customers of a developer-oriented product (such as a cloud platform) successful. Google’s approach to DevRel is rightfully engineering-focused. (Some other companies try to treat it as an arm of marketing, which I think is a mistake that will make it less effective. Marketing is a side effect of successful DevRel work, not the core of the work itself.) And it was a perfect match for what we were doing. We built things for the Ruby community (such as SDKs, tools, and runtimes), open sourced them, and then talked about them, wrote articles, went to conferences, and generally had a great time.
It was the conferences, I think, that were the most fun. A group of half a dozen or more Googlers would team up to attend RubyConfs and RailsConfs together. In some cases we would staff a booth, some of us would give talks or lead workshops, and otherwise we would all be there talking with attendees and customers and enjoying the community. As a Google engineer, I was a speaker at six major Ruby conferences (and an Elixir conference), and attended a number of others, not even counting numerous smaller meetups and customer calls. Although public speaking isn’t necessarily easy for me, the experience was exhilirating and brimming with positive energy.
DevRel-based Ruby work at Google lasted well into the COVID pandemic. But pandemic-induced changes, along with larger trends both within Google and in the tech industry at large, were already putting increasing pressure on the role, and things soon began to give.
The Decline of Google
It’s not a secret these days that employee morale at Google has been taking hits over the years, and not just post-COVID. Even by the time I first joined the company in 2013, I could see early signs of discontent about corporatization of the internal culture, changes being made to long-running traditions and institutions, and an increasing divide between company leadership and the rank-and-file of the engineering staff. I’m going to be vague about details because it’s not my intent here to litigate this particular topic. But my generalized opinion is that much of what we observed was an inevitable consequence of the rapidly growing size of the company. When you no longer have the ability to have met most of your fellow employees, or to fit the entire staff in the same room, some of the trust, transparency, and availability you might expect in a smaller organization, simply becomes infeasible. And as an organization gets more and more successful financially, the pressure to maintain that performance and trajectory, and the public scrutiny that comes with it, can overwhelm other considerations.
But whatever the reasons, these changes were happening. And so, even as the Ruby work at Google grew and matured, and as many of us involved were riding high, the larger work environment was slowly losing its luster. Employee morale, and the sense of pride in Google as a workplace, were I think still relatively high by industry standards, but were definitely on the decline. Personally, I was generally okay giving Google as a whole a bit of a pass, seeing those trends as the cost of success. And I still greatly enjoyed my particular role in DevRel as a Ruby expert in an organization like Google. But it also meant the situation gradually became more brittle, and more sensitive to any future shocks to the industry.
The COVID-19 pandemic that hit in early 2020 has had numerous lasting effects. As those familiar with the industry are aware, Big Tech overhired during 2020-2021, and has been paying for it ever since. Remote and hybrid work has forever altered what was before a very strong collaborative in-office work culture at Google. Furthermore, COVID had a lasting impact on what developer communities are and how they function, and these shifts put a lot of pressure on Developer Relations as a discipline and a role. By 2022, Google’s DevRel organization had a partial implosion, and roles like mine that were seen as straddling DevRel and software engineering, were reorged back under more traditional engineering organizational boundaries. My NodeJS nerd manager left Google for a different role; I think he had decided to quit while he was ahead. Over time, several others in the team would do similarly, a number that would eventually also include myself.
Back under the traditional software engineering umbrella, the Ruby work at Google began taking on an increasingly different character. Ruby community and customer engagement work, while not officially discouraged, was no longer given significant support, and in fact the last time I attended a Ruby conference as a Googler, in 2023, I had to pay for it out of my own pocket. Many of the open source based systems we had developed as DevRel, were reconceived and redesigned more in accordance with internal Google engineering practices and tools, or dropped altogether. There was a slight but noticeable shift away from prioritizing idiomaticity and fidelity to language community norms, and toward more heavily prioritizing cross-language consistency in order to streamline our internal engineering processes. In general, there seemed to be a shift in our values, away from serving customer needs, and toward optimizing our revenue and expense numbers as well as covering our asses as an engineering organization.
I won’t say I necessarily disagree with all the changes that took place. The work made significant and needed improvements in security both of our products themselves and the processes used to build them. We transitioned from a DevRel-based attitude of being scrappy and just getting useful things out there, to a more disciplined engineering attitude of building things in a sustainable way. There was more emphasis on cost efficiency and fiscal responsibility, values that have also increasingly characterized the company as a whole, and indeed much of the industry during this time.
But, and I don’t know a better way to say this, the work was no longer fun.
I spent my final few years at Google fighting to preserve the character of Google Cloud’s Ruby offerings and the engineering culture we had used to build them. The Ruby community in general has a maverick streak, embracing creativity, diversity, and openness to the weird and crazy, and an emphasis on programmer happiness. The Rubyist Googlers who built Google’s Ruby products, brought this culture into our work and processes, and it was instrumental in driving our success. But later we struggled to sustain this Ruby happiness, in the midst of the larger corporate pressures on our team and Google as a whole that seemed bent on extinguishing it. I fought burnout for a while, and then decided it wasn’t worth fighting it any longer.
I was most valuable to Google not as a Ruby developer, but as an ambassador from the Ruby community, one of very few at Google who was in a position to make a difference. Now that the company has increasingly decided not to value that role, and has been making it more and more difficult for those trying to fulfill it, it seemed my time was up.
The Future
One thing my departure from Google absolutely does not mean is that Google’s support for Ruby will wane. By myself I am not that important. And during my time at Google Cloud, I was involved with building strong teams supporting Ruby in many parts of the organization, teams that I’m confident will continue to thrive and ensure the platform works well with the language. Google also has developed strong partnerships across the Ruby community that will serve its continued Ruby support well.
It also does not mean I personally am done with Ruby, or with Google as a customer. As I write this, I’m actually renewing some earlier involvements with Ruby CNCF projects that had taken a back burner in recent years due to Google’s inward turn. And I know from ten years experience how strong Google’s Cloud offerings are, and for obvious reasons I’m uniquely positioned to know how to effectively use them with Ruby. I’ve personally been a Google Cloud customer for a long time (e.g. including this very blog), and that will almost certainly not change.
I expect I will, after a few months career break, return to software development work, (perhaps as a freelancer rather than a salaried employee), and I would love for any such gigs to involve Ruby and/or Google technologies.
But I think my story is reflective of some trends in the industry in general.
Tech firm belt tightening, and the layoffs and erosion of the employee experience that have come with it, is the new normal. The days of the cushy software job are over, and as much as it negatively affects people like me, I have to say it’s an overdue correction. The software boom of the 2010s reflected, I think, problematic reliance on and overvaluing of social media, devices, and tech-mediated discourse and commerce, along with a corresponding overvaluing of the workers that built them, relative to their actual value to society. I’ve spent enough time in my career taking advantage of the disproportionate privileges of my profession, and I look forward to society having more of a come-to-Jesus moment about our relationship to tech, and to the associated correction to tech workers’ status. (Unfortunately, the current AI craze will probably delay that. I’ll get to that shortly.)
One thing I learned while working in Developer Relations was the value of treating a tech product holistically— that it should comprise not just the tech itself, but also the galaxy of communities, content, and human engagements that revolve around it. Google was one of a number of tech firms exploring this area and making great progress back in the day. But DevRel today, though it remains a force at Google, seems a shadow of its former self. Unfortunately, the role is often one of the first to suffer when economic headwinds manifest, because although the value cannot be denied in the abstract, it is difficult to measure and thus difficult to justify to the bean counters. I can only hope that once the current correction takes its course, Google will reinvigorate its investment into this area.
Another thing I learned at Google in general is that big organizations operate in a certain way that is simply endemic to being big. I struggled a bit when I first joined Google from a startup, to learn and find my footing about how being a senior engineer and a leader looked different in a large organization versus a small one. And during my twelve and a half years at Google, I saw the company itself struggle to learn how operating as a large and growing organization looked different from operating as a smaller organization. It’s a fundamentally different experience, big tech vs startup tech. When I mentored younger engineers, I would often advise that they accumulate experience in both settings, because you learn different skills, and I now double down on that principle. For my own part, I expect to shift back to smaller firms for my next role.
Obligatory AI Comments
Isn’t it telling that, in the current climate, one feels an obligation to talk about AI? Well, I didn’t want to, but since it’s topical…
I’ll start by clarifying that I don’t think anyone really knows yet what will happen with AI tech or how it will ultimately impact the industry. So-called experts have predicted everything from imminent utopia, to the imminent collapse of societal norms and structures, to the imminent bursting of the bubble and all of us waking up, as if from a fever dream, to discover that, much to stockholder chagrin, it was all a big nothingburger. (I personally lean toward the latter, but my guess is worth about the same as anyone else’s at this point.)
In some of these scenarios, the software engineering job market implodes over the coming years as AI takes over more and more of that function. Advocates of that scenario might question the wisdom of leaving a software job now, as I have, rather than “job hugging”, trying to milk it for as long as possible until the job apocalypse arrives. Now I personally don’t think that scenario will happen, but even if it does, there are better ways to weather such an event than holding on for dear life to a position you no longer care for, and that no longer cares for you.
Regarding Google, obviously the company has invested considerable effort into AI and machine learning technology, and, indeed, has done so, publicly, for many years even long before the current craze. And like many other firms, Google is investing considerably in the training of its own workforce on use of AI in its various roles.
Despite my concerns about the future of AI, I agree that AI skills are useful, and that it’s a good idea for knowledge workers, especially in the tech industry, to develop them. This is for the same reason skills in social media, and even coding in general, not to mention older “soft skills” such as leadership and negotiation, are all useful to develop, even if your next gig doesn’t use them directly. Because it’s clear that AI as a tool is here to stay, even if AI as a disruptor of society may or may not fizzle out. So that’s one final take-away I bring from my time at Google: the importance of studying up on and experimenting with AI coding and engineering tools. I intend to spend some of my career break doing just that.
