Fired by Google for creating the Google workspace CLI

Original Article ↗ Hacker News Discussion ↗

Background and what happened

  • Discussion centers on a Google Workspace CLI, released on GitHub under a Google-owned org with Google branding and a “not an officially supported product” disclaimer.
  • The engineer who built it says they were fired afterward and attributes it partly to internal fear of disruption from “agents” and automation for Workspace.
  • The repo remains public and is linked from official Workspace documentation, which many find contradictory if it was truly a policy violation.

Open‑source / launch process and whether it was followed

  • Several current/ex‑Googlers describe well‑defined processes for:
    • Open‑sourcing code.
    • Using Google trademarks/branding.
    • Launching anything external (via IARC/Launcher tools, director‑level approvals, etc.).
  • Others say these processes are complex, constantly changing, and differ by org; DevRel teams historically had more autonomy and often published directly to GitHub orgs.
  • The engineer claims they followed the process and had “bits flipped” and a manager‑backed launch.
  • A self‑identified current Googler claims the engineer started the process, was confrontational in review, the launch was cancelled, and they proceeded anyway.

Branding, trademarks, and risk

  • Many argue the project name, tweet phrasing, org name, and logo made it look like an official product, which is exactly what policies are designed to prevent.
  • Others counter that dozens of Google repos use similar branding and disclaimers, and that legal concerns could have been fixed with renaming and logo changes rather than termination.

20% time, side projects, and IP

  • Commenters note that across tech, anything work‑related built with company time/resources is company property.
  • 20% projects never meant bypassing legal/launch review or competing with in‑flight internal products.
  • Some argue employees often misunderstand this, especially when coding on personal machines at home on work‑adjacent ideas.

Was firing justified?

  • One camp: violating clear policies, impersonating an official product, and ignoring legal/management decisions are legitimate grounds for firing, especially at a large, litigious company.
  • Another camp: at most this warranted a stern reprimand; firing a productive DevRel engineer who shipped a popular, API‑based tool is an overreaction and poor talent management.

Signals about Google culture and innovation

  • Many see this as emblematic of a shift from the old “20% time / build cool stuff” ethos toward risk‑averse bureaucracy, internal fiefdom protection, and fear of internal disruption.
  • Others argue that with Google’s scale and legal exposure, strong controls and centralized branding are necessary, even if they stifle some individual initiative.

Unclear / contested points

  • Whether the launch was fully approved or explicitly blocked.
  • How much the existence of an in‑progress “official” CLI or AI/agent strategy influenced the decision.
  • Why the repo is still up if it was truly unacceptable.