Poehnelt frames his termination as punishment for shipping a useful, well-received tool that filled a documented gap in Google Workspace tooling. He points to the rapid archival of the repo, the renaming to '-archive', and the rewriting of his authorship out of commit history as evidence that leadership wanted the work erased rather than productized.
Posting the story to HN, he surfaces the contradiction at the heart of Google DevRel: an engineer was fired for producing precisely the kind of developer-experience win his role was created to deliver. The 598-point thread and rapid forking (1.2k+ stars on a fork within hours) is cited as community validation that the tool was wanted.
The editorial acknowledges the sympathetic framing but argues the 'more uncomfortable' reading is that releasing a tool under the `googleworkspace/` GitHub org without legal or product sign-off is a real governance problem at any company past fifty people. Official-looking artifacts create implicit support obligations, security surface area, and brand commitments that an individual engineer cannot unilaterally make.
The editorial highlights that Microsoft 365 has had Connect-MgGraph and a supported PowerShell module since 2021, while Workspace admins fall off a cliff past `gcloud` IAM and resort to one-off Apps Script or raw REST calls. The Workspace CLI's instant traction — hundreds of stars in weeks, a dozen forks within hours of the firing — is treated as market proof that the gap is real and painful.
The editorial calls out that the repo wasn't just archived — it was renamed and Poehnelt's commit authorship was rewritten out. That move goes beyond a normal compliance takedown and reads as an attempt to scrub the historical record, which is what elevated the story from an internal HR dispute into a public credibility issue for Google.
On June 23, Justin Poehnelt — a Developer Relations Engineer at Google for nearly a decade — posted that he had been terminated for building and shipping the Google Workspace CLI, a command-line tool that wrapped the existing Workspace Admin SDK and Drive/Gmail/Calendar APIs into something Workspace admins could actually script against without writing 200 lines of OAuth boilerplate per task.
The project lived at `googleworkspace/google-workspace-cli` under the official Workspace GitHub org. It accumulated hundreds of stars in a matter of weeks and was, by every external indicator, exactly the kind of developer-experience win Google's DevRel function exists to produce. Within days of internal escalation, the repo was archived, renamed to `google-workspace-cli-archive`, and Poehnelt's authorship was rewritten out of the commit history. He was placed on leave shortly after and terminated this week.
Poehnelt's own account — corroborated by screenshots of the archived repo, the Wayback Machine snapshots, and a 598-point Hacker News thread that surfaced the story — frames the termination as retaliation for shipping a tool that legal and product leadership hadn't blessed. Google has not commented publicly. The Workspace CLI itself has been forked at least a dozen times in the hours since the news broke; the most active fork is already past 1.2k stars.
The surface story is a sympathetic engineer punished for caring. The actual story is more uncomfortable, and worth sitting with if you work at any company larger than fifty people.
Google Workspace has had a documented, years-old gap where Microsoft 365 has had `Connect-MgGraph` and a fully-supported PowerShell module since 2021. Workspace admins script against `gcloud` for IAM and then fall off a cliff the moment they need to bulk-update Calendar resources or audit Drive sharing — they end up writing one-off Apps Script or hand-rolled Python against the raw REST APIs. A first-party CLI is the obvious missing piece. Poehnelt, who already owned several of the official Workspace client libraries, was arguably the single best-positioned person on the planet to build it.
So why did this end in a termination instead of a launch blog post? Three things, probably, and none of them are 'Google hates good code.' First, Workspace is a regulated product: GDPR, HIPAA BAAs, FedRAMP High. A binary that auths as a Workspace super-admin and exfiltrates Drive contents is a compliance review, not a side project — even if the code is flawless. Second, the official `googleworkspace` GitHub org carries implicit support commitments. Customers who saw a Google-org-published CLI reasonably assumed there was a support contract behind it; there wasn't. Third, and most fatal: the tool shipped under an official org without going through the launch review that every other Google product endures, and by the time legal noticed, it had a user base that couldn't be quietly disowned.
The HN thread, predictably, split. The top comment ('Google is allergic to making developers happy') has 1,400+ upvotes. The most-replied-to comment is more careful: a former Googler pointing out that publishing under an official org is a legally distinct act from publishing under a personal account, and that the same code on `jpoehnelt/workspace-cli` would have generated a perf-cycle pat on the back instead of a termination letter. Both can be true. The mistake wasn't building it. The mistake was publishing it where customers would assume it was supported.
There is a quieter story underneath, which is that DevRel as a function has been load-bearing for big-tech developer ecosystems for fifteen years, and the role's implicit deal — 'we let you ship things that make developers happy, you make us look good externally' — has been visibly fraying since the 2023 layoffs. Google's DevRel headcount is reportedly down ~40% from its 2022 peak. The remaining engineers are being asked to do strictly sanctioned work. Poehnelt's firing reads as the loud version of a memo that has already been delivered quietly across the industry.
If you were planning to depend on `google-workspace-cli` — stop. The forks will diverge, none of them will get security patches from Google, and the OAuth client IDs baked into the original binary will eventually be revoked. Treat it the way you'd treat a 2017-era abandoned `awesome-*` repo: useful for reading, dangerous to deploy.
If you're a Workspace admin who needs the functionality, the boring answer is still the right one: write a thin Python wrapper around `google-api-python-client` for the three operations you actually need, pin it to your own GCP project's OAuth client, and put it in your internal tools repo. It's 200 lines. It will outlive any unofficial CLI. And it puts the auth surface inside your own audit boundary, which is where it belongs for a tool that can read every employee's email.
For engineers at large companies watching this from the outside: the lesson is not 'don't build things.' It's that the perimeter between 'personal GitHub' and 'employer's GitHub org' is the single most consequential policy boundary in your career, and 'launch and ask forgiveness' stops scaling somewhere around Series C. Build the tool. Open-source it under your own handle. Let your employer adopt it on their timeline, not yours.
The Workspace CLI will reincarnate — probably as a community project under a neutral org within a month, probably with a name that doesn't include the word 'Google.' Google will eventually ship a first-party CLI, and when they do, the launch post will not mention Justin Poehnelt. The interesting question is whether this incident accelerates that timeline or buries it for another two years out of institutional embarrassment. History suggests the latter.
Yikes. The lack of judgement involved in personally releasing something that could be confused for an official release (I was confused) by your employer is someone who has huge wildcard risk in the future. I would expect significant disciplinary action if they didn't follow procedure, and termi
I never worked for Google, but I do have fairly extensive experience with these kinds of situations. From that perspective, I assume there has to be more to the story for it to lead to a firing.In general, when a talented employee (like OP) does something like this, the response is usually something
Interesting that people here seem so sympathetic to the fired guy. Wouldn’t you kind of expect to be fired if you release a project under your employers name that’s not even associated with them and hasn’t been cleared? Working for them actually makes it worse because people could look up your name
Looks like a textbook example of Pournelle's Iron Law of Bureaucracy.[a]People like the OP, Justin Poehnelt, who build cool things out of self-motivation that others find interesting and want to use, are now at the mercy of those inside Google who care more about the company's internal bur
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I'm noticing a few commenters who work (worked?) at Google (inferred from comment history) who are critical of this person's actions.First: you ought to disclose that information when commenting on a topic that relates in some way to your financial incentives.Second: when I worked at Googl