Poehnelt argues he did everything by the book — built workspace-cli on personal time, on personal hardware, and disclosed it through Google's internal IP review process — yet was fired anyway under the assignment-of-inventions clause. His framing is that this is a fundamentally unfair application of contract language that should protect the company from misappropriation, not punish a DevRel engineer for filling a gap in the very ecosystem he was paid to evangelize.
The editorial argues that 'relates to the company's business' is doing enormous interpretive work in FAANG contracts — read literally, a Google engineer cannot build anything that touches a Google API on personal time. California Labor Code §2870 was supposed to narrow this, but enforcement like Poehnelt's firing shows the carve-out is weaker in practice than employees assume.
The editorial notes that the npm package has quadrupled its weekly downloads since the thread went viral, and that commenters dug up a clean, well-tested MIT-licensed CLI with ergonomic flags Google itself never shipped. By firing Poehnelt rather than absorbing or endorsing the project, Google amplified both the tool's adoption and the narrative that its first-party Workspace tooling is deficient.
By submitting the story with the framing 'Fired by Google for Creating the Google Workspace CLI,' the submitter — appearing to be Poehnelt himself — drove the post to 372 points and 242 comments within hours. The implicit position is that public exposure is the appropriate response to a termination he views as unjust and disproportionate.
The editorial points out that the firing came six weeks after Google's latest round of 'efficiency' cuts, and frames Poehnelt as 'not the first DevRel engineer this has happened to.' The implication is that the assignment-of-inventions clause provides convenient legal cover for terminations that are really driven by headcount reduction in the DevRel org.
Justin Poehnelt, a long-tenured Developer Relations engineer at Google who spent years writing sample code and docs for Google Workspace APIs, posted on X that he was fired for building `workspace-cli` — an open-source command-line tool that wrapped the same Workspace APIs he documented for a living. The post hit Hacker News at 372 points within hours, with commenters digging up his GitHub history: a clean, well-tested Node.js CLI, MIT-licensed, with the kind of ergonomic flags (`--drive`, `--gmail`, `--calendar`) that Google itself has never shipped.
Poehnelt's framing is unambiguous: he built it on personal time, on personal hardware, and disclosed it through Google's internal IP review process — and was terminated anyway. The stated reason, according to his thread, was that the project competed with or duplicated Google's own (nonexistent) first-party CLI, and therefore violated his employment agreement's assignment-of-inventions clause. He is not the first DevRel engineer this has happened to, but he is the most visible in 2026 so far, and the timing — six weeks after Google's latest round of "efficiency" cuts — has not gone unnoticed.
Google has not commented publicly. The repository remains live on Poehnelt's personal GitHub. The npm package has 4x'd its weekly downloads since the thread went viral, which is exactly the Streisand outcome you'd expect.
Every FAANG employment contract contains some version of the same paragraph: anything you invent during your employment that *relates to the company's business* belongs to the company. The phrase "relates to" is doing enormous work. Read literally, a Google engineer cannot legally write a Gmail client, a Drive uploader, a Calendar sync tool, a Maps wrapper, a YouTube downloader, or essentially any code that touches a Google API — even on a Saturday, on their own laptop, for zero dollars. California Labor Code §2870 narrows this somewhat (it carves out inventions done entirely on personal time with no company resources and unrelated to the employer's business), but the "unrelated to the employer's business" clause swallows the carve-out when your employer is Google and you work on developer tooling.
This is not new law. What's new is the enforcement appetite. For two decades, Big Tech effectively tolerated — even celebrated — side projects from DevRel and infra engineers, because those projects fed the ecosystem the company depended on. Kelsey Hightower's `kubectl` tutorials, Kent C. Dodds' testing libraries, Addy Osmani's performance tools: all built by employees whose employers benefited massively from the goodwill. The unwritten deal was that as long as you weren't building a direct competitor, nobody from Legal would read your GitHub.
That deal is dead. The HN thread surfaced at least four other recent terminations at Google, Amazon, and Microsoft over OSS side projects in the last 18 months, and the common factor isn't competitive threat — it's that Legal departments now have AI-assisted GitHub crawlers flagging employee accounts. The audit is cheap. The firing is cheaper. And in a market with 30% fewer open senior IC roles than two years ago, the threat of termination has teeth it didn't have in 2021.
There's also a perverse self-own here for Google specifically. The reason Poehnelt built `workspace-cli` is that Google never shipped one — the company that ships a CLI for every other product line has, in 2026, no first-party command-line tool for the productivity suite it sells to 3 billion users. Firing the guy who fixed that gap, for free, on his weekends, is the kind of decision that only makes sense if you've never had to do developer relations.
If you work at a large tech employer and you maintain anything on GitHub under your real name, three concrete moves:
One — get the waiver in writing, before the commit. Most FAANG IP-review processes will grant a waiver for a clearly-scoped personal project if you ask in advance. The waiver is a one-page document; getting it after the project goes viral is impossible. Treat it the same way you'd treat a code review: not optional, not retroactive.
Two — assume your GitHub is monitored. Don't use your work email on your personal account. Don't commit during business hours from a corporate IP. Don't use the same SSH key. This sounds paranoid; it is now the floor. The cost of a false positive from a Legal Department crawler is your job; the cost of being careful is fifteen minutes of git config.
Three — if you're a maintainer at a small company depending on a FAANG-employee maintainer, get a bus-factor plan. The `workspace-cli` repo is fine today because Poehnelt no longer works at Google. But every active OSS project with a single Big Tech maintainer is one Legal review away from an archive notice. Audit your dependency tree for solo maintainers with `@google.com` or `@amazon.com` in their commit history, and have a fork plan ready.
For hiring managers: this is a signal you can exploit. A senior DevRel or infra engineer fired for shipping useful OSS is the highest-quality hiring signal available in 2026 — pre-vetted by a top-tier employer, demonstrably ships in public, and now available. Poehnelt's DMs are reportedly full of recruiters. They should be.
The broader trajectory is grim and predictable: as Big Tech consolidates around fewer, larger platforms and the labor market softens, IP enforcement against employees will get more aggressive, not less. Expect the next 12 months to bring at least one high-profile lawsuit — likely from a fired employee whose side project got acquired — that finally tests §2870's "relates to the business" language in court. Until then, the practical advice is unchanged from what it should always have been: if you work at a place that owns your nights and weekends by default, the side project isn't yours until a lawyer says so in writing.
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