The Engineer Who Built Too Well

A Google Firing Story That Hits Home

Photo by Tim Mossholder on Unsplash

Two months ago, an engineer at Google created something genuinely useful: a Google Workspace CLI.

In days, it exploded, #1 on Hacker News, thousands of GitHub stars, and real users adopting it enthusiastically.

Then he was fired. The official announcement of Google’s own Workspace CLI came just two days earlier. The irony is brutal, and the story is painfully familiar to anyone who’s ever shipped code from inside a large organization.

This wasn’t some rogue side project with stolen IP. It was a tool born from real engineering frustration and ingenuity, exactly the kind of initiative big tech claims to celebrate.

Directors and leaders initially reached out asking what they could learn from it. Then the legal team got involved over branding. The real issue, according to the creator, wasn’t the CLI itself but the deeper anxiety around what AI agents and automation mean for existing Workspace products and teams. Innovation was welcomed until it felt threatening.

For engineers, this story resonates on multiple levels. We live for velocity. We see a painful workflow and instinctively build the tool that fixes it.

That’s what happened here: one person shipped something thousands of colleagues and external users clearly wanted. The rapid adoption proved the market need. Yet the response from the organization was fear, not celebration.

This highlights a classic tension in mature companies. Early Google famously ran on “20% time” and tolerated (even encouraged) creative chaos.

Over time, scale brings caution: brand protection, internal politics, risk aversion, and protection of existing revenue streams. The result? Brilliant engineers get punished for doing what engineers are supposed to do, solve problems and ship.

The creator’s seven years at Google, supportive teammates, and manager make the ending even sadder. Talent and loyalty met institutional fear.

What this means for us as engineers

Own your creations. Ship anyway. Document your story publicly, not for revenge, but for clarity and healing. The open-source community rewarded this project precisely because it delivered value fast, without bureaucracy. That’s a powerful signal. Big tech needs builders who care more about users than internal optics, but sometimes those builders pay a price.

The most important takeaway: real innovation often feels disruptive to the status quo, even (especially) inside the company pioneering it. If you’re an engineer reading this, keep building tools that matter. Push boundaries. The GitHub stars, the grateful users, and the personal growth from owning the full story, these are yours forever. Corporations come and go. The artifacts and lessons you create don’t.

This engineer turned a painful exit into an act of transparency and ownership. That’s class.

And it’s a reminder to every engineer grinding in big tech: your instinct to make things better is not the problem. Sometimes, it’s the solution the company isn’t ready for yet. Keep building. The world notices.

More reads

[embed]The JSON Tax: Why We’re Wasting Bandwidth Engineers always obsess over CPU cycles, memory allocations, and elegant algorithms. Yet when it comes to shipping data…amjohnphilip.medium.com