The editorial frames this not as an isolated HR incident but as evidence that the old Google narrative around 20% time and side-project mythology has been functionally dismantled. It argues the math of innovation inside a mature hyperscaler in 2026 is 'genuinely brutal' — even an engineer who followed the IARC disclosure process on personal hardware and personal time can be fired when the artifact gains visibility.
Points out that Google shipped gcloud for GCP in 2014 but has shipped zero equivalent for Workspace in the twelve years since, despite Workspace being a $10B+ ARR line. Admins have been openly asking for this since 2016 and have had to rely on the community-maintained GAM tool or hand-rolling against six different REST endpoints with incompatible OAuth scopes.
Poehnelt's own account is that he built workspace-cli on personal hardware, on personal time, with no Google IP, and disclosed it through the standard internal IARC process before publishing. He claims the committee initially cleared the project and only reversed course after the repo gained public traction, framing the termination as the result of a months-long back-and-forth rather than a single policy violation.
Submitted his own story to Hacker News under the title 'Fired by Google for Creating the Google Workspace CLI,' driving the narrative that the firing was disproportionate given his compliance with internal review processes. The post reached 443 points in a few hours, signaling broad agreement that the punishment did not fit the disclosed-and-approved nature of the work.
Justin Poehnelt — a nine-year Googler who worked as a Developer Relations engineer on Google Workspace and Google Apps Script — posted on June 23 that he had been terminated. The stated reason, according to his thread: he built and open-sourced a command-line tool, `workspace-cli`, that wrapped the public Google Workspace Admin SDK and Drive/Gmail/Calendar APIs into the kind of `gcloud`-style developer experience Workspace has never officially had. He says the project was done on personal hardware, on personal time, with no Google IP, and that he disclosed it through the standard internal IARC (Invention Assignment Review Committee) process before publishing.
The HN thread hit 443 points in a few hours, largely because the artifact in question is something Workspace admins have been openly begging for since at least 2016. The current state of the art for scripting Workspace is either GAM (a community Python tool maintained by Jay Lee, ~7k stars, the de facto standard) or hand-rolling against six different REST endpoints with OAuth scopes that don't compose cleanly. Google shipped `gcloud` for GCP in 2014 and has shipped zero equivalent for Workspace in the twelve years since, despite Workspace being a $10B+ ARR line.
Poehnelt's account — which Google has not publicly disputed as of writing — is that the termination came after a months-long back-and-forth with an internal review process, not a single policy violation. He claims the IARC initially cleared the project, then reversed after the repo gained traction. The repo itself was taken down from his personal GitHub within hours of the firing, though forks survive.
This is not a story about one engineer or one CLI. It's a story about what 'innovation' actually costs inside a mature hyperscaler in 2026, and the math is genuinely brutal.
The old Google narrative — 20% time, peer bonuses for shipping side projects, Gmail-was-a-20%-project mythology — has been functionally dead since the 2022-2023 layoffs. What replaced it is a legal posture in which any public artifact a senior engineer ships becomes a potential liability vector: trademark dilution, implied endorsement, API-rate-limit grey areas, support obligations the company never agreed to. The IARC process exists precisely to make those calls, and it almost always says no to anything that touches a product surface the engineer's day job touches. Poehnelt's project did exactly that, which is probably why it was approved when nobody was watching and revoked when it had 800 GitHub stars.
The deeper signal: Google has decided it would rather have no Workspace CLI than one it doesn't fully control, even when the alternative is a thriving community tool (GAM) it also doesn't control. This is the same pattern that killed the Google Reader API, killed Inbox, killed the unofficial Hangouts libraries, and that is currently strangling the Gemini API's third-party client ecosystem with frequent breaking changes. It is the rational behavior of a company whose general counsel's office now has more org-chart weight than its DevRel org.
The community response has been instructive. The top HN comment, from a former Workspace admin, points out that they filed a feature request for a first-party CLI in 2017 and the ticket was closed 'won't fix' in 2019 with the explanation that 'the Admin Console UI and Apps Script are the supported developer surfaces.' Apps Script — a JavaScript runtime that times out at six minutes and cannot be checked into git in any sane way — is not a CLI. Telling enterprise admins in 2026 to automate user provisioning via a browser-bound scripting environment is a posture that only makes sense if you've stopped competing with Microsoft 365 for the admin-tooling layer.
The career-industry read is sharper. Poehnelt was a Staff-level DevRel engineer — exactly the profile of person Google publicly courts when it wants to seem developer-friendly. Firing him over an open-source side project that solves a real customer problem sends a clean signal to every other senior engineer at every other large platform: your side projects are now a career risk, not a career asset, and the company's tolerance for them is inversely proportional to how good they are.
If you're running Workspace at any scale, the practical answer hasn't changed and won't change: use GAM, accept that it's a community-maintained Python tool with one primary maintainer and a bus factor of approximately one, and budget for the day Google decides to rate-limit it out of existence. There is no first-party path coming. The fork of `workspace-cli` that's currently circulating on GitHub will probably survive for a while as a Node alternative, but without Poehnelt actively maintaining it the API drift will catch up within 12-18 months.
If you're a senior engineer at a FAANG-tier company thinking about open-sourcing something adjacent to your day job, the calculus has shifted. The IARC-equivalent process at your employer is not a rubber stamp and increasingly not even a one-way ratchet — approval can be revoked retroactively if the project succeeds. The safe move is to ship side projects in domains your employer has no product in, not adjacent ones, even when adjacent is where your expertise actually lies. This is a real loss of leverage for staff-and-above ICs and worth pricing into your next comp negotiation.
If you're building developer tools as a startup, the gap Poehnelt was filling is now wider, not narrower. A commercial Workspace admin/automation platform that wraps the same APIs with proper auth, audit logging, and a CLI is a genuinely fundable thesis — the addressable market is every IT admin at every Workspace-using company, and the incumbent (GAM) is a single-maintainer project. Reach out to him; he is now available.
The second-order effect to watch is internal. Google's DevRel org has been hemorrhaging senior people for two years, and this is the kind of incident that accelerates the exit of the engineers most likely to ship the things that make a platform actually adopted. The first-order effect — no official Workspace CLI — was already the status quo. The actual news is that Google has now publicly priced what a CLI like that costs them in legal exposure, and the price is higher than the salary of the person willing to build it for free.
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