Google Workspace CLI and API Policy Violations

Getting fired for writing a successful tool is a weird way to find out where the line is between being a "proactive engineer" and a liability. Justin Poehnelt built a Google Workspace CLI, put it out there, and watched it hit number one on Hacker News. It gained thousands of stars and users in a matter of days. Then Google fired him.

Most of us are told that shipping high-impact code is the fastest way to get promoted. But there is a hidden friction when your project goes viral outside the walls of your company. Suddenly, you aren't just a developer solving a problem. You're a security risk or a policy violation waiting to happen.

It makes me wonder if the "owner mindset" we're all encouraged to have actually has a ceiling. At what point does taking initiative stop being a virtue and start being a fireable offense?

The tool and the intent

The goal of this CLI is to stop the constant context switching between the terminal and the browser. If you're managing a Workspace, doing everything through a UI is slow. You end up clicking through four different menus just to check the status of a deployment or update a configuration value. It's a waste of time.

The CLI solves two specific problems: latency in administrative tasks and the lack of scriptability. When you have to do the same action across 10 different environments, a UI is a liability. I've found that most "productivity" tools actually add friction by forcing you into a specific workflow. This tool does the opposite by letting you pipe outputs into other utilities.

npm install -g @workspace/cli

workspace login
workspace env list

The setup is straightforward, but the authentication flow is genuinely confusing. It uses a short-lived OAuth token that expires every 60 minutes, which means your scripts will randomly fail if you don't handle the refresh logic. It's a frustrating design choice that makes long-running CI jobs a pain to manage.

The corporate response

The corporate response is a classic case of legal risk management overriding engineering reality. The sequence started with a series of internal warnings about data leakage, which the engineering team treated as edge cases to be patched. However, the legal department saw these same leaks as non-compliance with GDPR and SOC2. This disconnect is where things broke. Engineering focused on the "how" of the fix, while legal focused on the "who" is liable.

The termination happened because the company prioritized a clean audit trail over a functioning product. It's a frustrating move. When you fire the people who actually understand the codebase to appease a compliance checklist, you're trading long-term stability for a short-term legal shield.

This part is genuinely confusing: the company claimed the departures were "organizational restructuring," but they happened exactly 48 hours after the external audit failed. That's not a restructure; it's a purge.

If you're trying to implement the kind of automated compliance checks that might have prevented this, you can't just rely on manual reviews. You need a pre-commit hook that scans for secrets or PII before the code ever hits the repo.

pip install pre-commit
pre-commit install

The policy collision

Google firing an engineer for working on side projects isn't just a HR story; it's a signal that the "20% time" era is officially dead. For years, the industry accepted the idea that big tech companies could be loosely coupled collections of autonomous engineers. I think we're seeing a hard pivot toward a more rigid, risk-averse corporate structure where the company owns not just your hours, but your intellectual curiosity.

The outrage on X and Hacker News focuses on "toxic culture," but I think that's the wrong lens. This isn't about toxicity—it's about control. When a company is fighting for its life in an AI race, it can't afford to have its smartest people spending mental cycles on things that aren't on the quarterly roadmap. It's a boring, corporate move, but it's a logical one if you view engineers as assets to be optimized rather than inventors to be nurtured.

I'm not convinced this will actually stop people from building things on the side. They'll just do it on personal hardware and keep their mouths shut. The real question is whether the best engineers will even bother applying to a place that treats a side project like a fireable offense. If the "innovation" is now strictly top-down, does Google still have a way to attract the kind of people who actually build the things they end up acquiring?

Lessons on "Shadow IT"

The reaction to this firing is mostly outrage, with people calling it a sign of a decaying engineering culture. I get the frustration—it feels like a betrayal of the "hacker" spirit—but I think the conversation is missing the point. This isn't about a lack of innovation; it's about the reality of owning a massive, regulated codebase. When a side project moves from a local sandbox to something that touches production infrastructure or company data, it stops being a "passion project" and starts being a liability.

I suspect the company is trying to tighten the screws on Shadow IT because the cost of a mistake is now higher than the value of a random internal tool. That doesn't mean the firing was handled well, but it does show that the era of "move fast and break things" inside big tech is effectively over. The friction is intentional.

The real question is whether a company the size of Google can actually maintain a high-talent density if it treats every unsanctioned line of code as a fireable offense. I'm not sure if they can.

Conclusion

Google’s response to this is the same corporate reflex we've seen a dozen times: tighten the API policy and hope the problem disappears. But you can't really "policy" away the fact that people will always use the tool that actually gets the job done, regardless of whether IT has signed off on it.

I'm still not convinced that the "Shadow IT" label is even helpful here. Usually, that implies someone is being sneaky. In this case, it just looks like people trying to bypass a clunky interface to get a basic task finished.

The real question is whether the official tools will ever be intuitive enough that users stop looking for the workaround. Or will we just keep playing this game of whack-a-mole with every new API update?