Why I Quit Google’s WebAssembly Team, And How It Made Me Sick

Katelyn Gadd
6 min readMay 11, 2022

I joined Google in early 2015 to work on the V8 team as one of the first authors of the WebAssembly specification. This is a partial story of what went wrong with the process and how it permanently damaged me. My hope is that this story will help people recognize toxic cultures in their own workplaces, or help new hires have a better career at Google. Any story about WebAssembly is going to be biased due to the complex history of the project, and this is no exception. I’ll do my best despite my poor memory.

At the time I joined the V8 team, I had spent the last few years maintaining a transpiler that converted .NET applications to efficient JavaScript. This started at the same time as Emscripten, the app that turned into a standard and then inspired WebAssembly. I was lucky enough to work with asm.js’s creator Alon Zakai at that time and I learned a lot from his advice and expertise. This experience made me a natural fit for the WebAssembly team.

Over the last two decades I’ve managed to be productive despite struggling with chronic illness, and I owe a lot of this to the people I’ve worked with. Despite that, Google is the worst place I’ve ever worked and it quite literally gave me brain damage. If you find your job is making it hard to sleep, making you feel on edge every day, or making you constantly question your own self-worth, I would encourage you to look for a new job.

WebAssembly was full of potential. Mozilla and Google had both worked hard to turn asm.js into a way for every application to run on the web and overcame most of the challenges in their way, but it became clear that some of the problems were too hard to fix, so the WebAssembly process started: To learn from asm.js’s strengths while addressing its weaknesses, and build a spec that could be easily implemented in existing JavaScript runtimes, using their code generation, debugging, and other infrastructure.

Joining this spec process as one of the first few contributors was exciting. While I had web platform experience, authoring a specification poses unique challenges and the whole committee have to act as PMs, advocates, and programmers simultaneously. People like JF Bastien, Luke Wagner, Alon Zakai, Ben Titzer and countless others worked hard to put together the framework of something that would go on to be used by billions of people.

If you’re building a product that billions of people will be stuck with, however, this can lead to a little stress. The history of the web is littered with bad APIs, ill-considered specs, and tangled piles of security vulnerabilities. Something a programmer puts together in a week can consume decades of engineering time in the future. WebAssembly could not and would not release as a half-baked or ill-considered spec because as browser developers we all understood the costs everyone would pay for that.

That stress and the importance of the project were central to our struggles and the toxicity of the environment. Many design discussions became heated and two experts in their fields from competing corporations would fail to agree, convinced that their informed opinion was correct. Meetings would go off the rails and before you knew it, an hour had passed with no result. In a healthy environment, a team has PMs and leads who recognize these problems and work to mitigate them so progress can continue.

We did not have a PM. We knew we needed one, we tried to get one, and at best we had a part-time PM for a brief time who volunteered and then moved on. This left complex social and organizational challenges in the hands of overworked engineers with little experience solving them. I’m certain that in the end, the MVP of the spec was delayed, its quality was reduced, and contributors were driven away. This is hardly a unique story in the history of open source, but it’s still sad to see.

Worse still, our leads were overworked and lacked the power to create change. Any team needs expert leadership to thrive, and expert leaders need support from the people they report to so they can do what’s necessary. Our leadership did not have that support. The V8 team as a whole had the misfortune of reporting to the leader of the Chrome organization, a careless man who continues to have one of the worst approval ratings in the entire company. In my career I’ve seen managers cry multiple times, and this is one of the places that happened. A manager should never have to ask whether they’re a coward, but that happened here.

When a team lacks resources and the leaders lack control over planning, resources and schedules, a small problem quickly becomes worse. Interested people from elsewhere in the company inserted themselves into the project, hoping to apply their expertise to “fix it” or make a name for themselves by having a big project to put in their next promo packet. This was a problem. The WebAssembly spec ended up being built on obscure and ill-suited technology and this made it harder for people to contribute while frustrating many members of the committee. In the end the spec was released in great condition, but a price was paid for the problems this created.

Earlier in this post I made the absurd statement that WebAssembly gave me brain damage. Unfortunately, this is true. My two years at Google were spent perpetually stressed, acting as an unofficial PM, helping run meetings and document decisions while dealing with sometimes hostile colleagues. Thankfully other members of the team were working hard to manage these same issues, but it took a toll nonetheless. Over time I slowly lost my mid and short term memory, to the point that some days I couldn’t find my car in the garage or forgot entire conversations. I had to take very detailed notes. Eventually my physicians put me on forced medical leave, and they strongly encouraged me to quit; advice I later took, but not soon enough.

Near the end of this process, I decided to do something I’ve done in the past despite it never working: I scheduled a meeting with an executive. I don’t recommend doing it, but every team needs an advocate and we didn’t have one, so this was the last thing I could think of to try. It was a bad meeting.

My first salaried job was at a game studio in early 2007 as a game designer, and I quickly pivoted into the role that would define the rest of my career: a tools programmer. I have focused my life on helping other people do their jobs by understanding what causes them stress and gets in their way. This is often a thankless role but it’s an essential one, and I’ve been blessed with colleagues and leads who have seen the worth of it and supported me. The end of my time at that game studio was when I sat down in a meeting with a company’s only remaining founder and explained how the project was behind schedule, the team were stressed, and our work was low quality. I explained how we could address these problems and save the company money. The founder told me that we would change nothing and lie to the team so they’d continue crunching, and that title shipped many years late.

Every toxic workplace I’ve been in was usually the result of bad executive leadership, and this was no different. Here as well, I explained to a Google leader how the WebAssembly project was struggling without support from his organization and how people were being driven away from the project. He agreed with my assessment and then told me nothing was going to change. In the end, the team changed things on their own.

My time at Google ended quietly and without drama. I returned from my forced medical leave to discover that our WebAssembly team had essentially disbanded — multiple people had quit, and others had fled to other parts of the company. My new manager informed me that I would now be working on an unfamiliar part of Chrome with different people. I gave my notice and sat for a brief exit interview, and my last day was ~1 week before my next share vesting date (oops). I spent the next couple years unemployed, working with my physicians to try and recover my health while occasionally writing code. I’m happy to report that I’m partially recovered at this point and being paid to work on open source, but I’ll never be the same.

I hope you never experience what I did, and I hope you’re able to thrive and build the career of your dreams.


Discuss on Orange Website

Edit: Replaced some game industry lingo with more common software industry lingo. Oops!



Katelyn Gadd

Game Designer, Web Platform Contributor, and Tools Programmer