HN Debrief

Fired by Google for creating the Google workspace CLI

  • Programming
  • Open Source
  • Management
  • AI
  • Developer Tools

The post points to a tweet thread from a former Google Workspace Developer Relations engineer who says he was fired after building a Google Workspace CLI. The tool was published in a Google Workspace GitHub org, carried Google branding, and included the familiar disclaimer that it was not an officially supported Google product. That made the story easy to read as “employee builds something customers want, bureaucracy kills it.” But the strongest read from the comments is narrower and less flattering to the author. This was not really about whether a CLI is useful. Most people agreed it is. It was about whether an employee released something that looked like an official Google launch without clearing the open source, legal, launch, and branding process, possibly while an overlapping internal effort already existed.

If you let employees ship public tools, make the approval path unambiguous and fast, especially for DevRel and open source work that sits near product lines. If you are an employee, never assume internal autonomy extends to public branding, launch timing, or adjacent product areas without written approval.

Discussion mood

Skeptical and split. Many people felt the firing was harsh and symbolic of a more bureaucratic Google, but the dominant mood was that the author likely crossed obvious lines around branding, approvals, or launch process and then hurt his own case by refusing to answer the key question directly.

Key insights

  1. 01

    DevRel was not exempt from approval

    Even in a role centered on open source publishing, the cited policy appears to explicitly cover side projects and says DevRel engineers still need IARC and related launch approvals. That undercuts the idea that this was a gray area unique to evangelism work. If the author knew the process well enough to point to the documentation and still cannot say approvals were in place, the likely failure mode is not cultural misunderstanding but knowingly testing a boundary.

    Treat advocacy teams like any other public release function when the work can be mistaken for product. If your organization uses exceptions for DevRel or demos, document those carve-outs in writing before anyone ships.

      Attribution:
    • justinwp #1
    • anon84873628 #1
    • pinkmuffinere #1
    • Ferret7446 #1
  2. 02

    Google’s open source culture was uneven

    Publishing externally from inside Google was not one universal workflow. Some teams could push code to Google-managed GitHub orgs with little friction, while others needed legal, IARC, privacy, and launch reviews for even small projects. That inconsistency explains why some former Googlers see the firing as absurd and others see it as obviously self-inflicted. The company trained different instincts in different orgs, then expected everyone to behave as if the rules were uniform.

    If different parts of your company have different launch privileges, assume employees will generalize from local norms. Standardize what matters or expect costly misfires when people move across org boundaries or publish in public-facing spaces.

      Attribution:
    • genxy #1
    • cdata #1 #2
    • qmarchi #1
  3. 03

    The GitHub org itself created ambiguity

    A lot of confusion came from the repository living under a Google Workspace GitHub organization rather than a personal account, while still carrying a disclaimer that it was not officially supported. That combination is legible to insiders but muddy to users. Several commenters focused less on the code than on the governance failure that let an apparently single-maintainer project appear under a brand-heavy org without a clear support model.

    Do not rely on README disclaimers to undo official-looking placement. Public repo ownership, org naming, and maintainer signals shape user trust more than boilerplate text does.

      Attribution:
    • dwroberts #1
    • dekhn #1
    • donatj #1
    • fg137 #1
  4. 04

    AI speed changed the risk profile

    One practical wrinkle is that AI tools now let one engineer produce something polished enough to look like a full product, not just a rough DevRel script. Older assumptions about harmless individual demos break when a single person can ship enough surface area to confuse customers, collide with internal roadmaps, or preempt launches. The governance problem is not just stricter companies. The output of one motivated employee now reaches product-like scale much faster.

    Update release policies for AI-assisted prototyping. Reviews that were once reserved for product teams may now need to trigger based on external appearance and likely user interpretation, not team size.

      Attribution:
    • Aurornis #1
    • frollogaston #1
    • sanderjd #1
    • bonsai_bar #1
  5. 05

    Evasiveness did more damage than the repo

    The author’s refusal to answer the simple question of whether the release process was followed changed how people interpreted the entire episode. In a case where a clean approval trail would have been exculpatory, silence reads like absence. That made speculation about hidden context feel more credible than the stated narrative about threatened leaders and disruption.

    In any public dispute over policy enforcement, a missing yes-or-no on process becomes the story. If you want outside sympathy, publish the narrow facts that establish compliance or say plainly that you took the risk.

      Attribution:
    • anon84873628 #1
    • echoangle #1
    • AOsborn #1
    • khazhoux #1

Against the grain

  1. 01

    Firing still looks disproportionate

    Even commenters who accepted that process may have been violated argued that termination is a very aggressive response for a long-tenured engineer who built something useful and fixable. In orgs where open source publishing had been normalized, the expected remedy would have been rebranding, moving the repo, or bringing the project into an official lane. That view does not excuse the action. It says the punishment signals a company with little appetite to redirect initiative once it becomes politically inconvenient.

    If you want employees to keep taking initiative, reserve termination for fraud, refusal, or repeated violations and use remediation for first-time launch mistakes. Otherwise people learn that initiative is career risk and stop shipping.

      Attribution:
    • bonsai_bar #1
    • cdata #1 #2 #3
  2. 02

    Customer value may have threatened product control

    A smaller but pointed line of argument was that the tool exposed an uncomfortable truth about Google Workspace. Users clearly wanted a practical CLI, and an employee delivered one quickly. That makes the firing easy to read as protection of roadmap control or preferred AI surfaces rather than just trademark hygiene. The case is unproven, but it resonated because the product need was obvious and the tool apparently remained available rather than being immediately erased.

    Watch for moments when compliance language masks a strategy choice about distribution, platform control, or feature gating. Customers notice when a company punishes the person who proved demand faster than the company met it.

      Attribution:
    • jauntywundrkind #1
    • jrochkind1 #1
    • solid_fuel #1

In plain english

AI ↩
Artificial intelligence, a broad term for systems that perform tasks associated with decision-making, reasoning, or pattern recognition.
CLI ↩
Command-Line Interface, a text-based way to interact with software by typing commands.
DevRel ↩
Developer Relations, a function that helps external developers use a company’s products through documentation, examples, demos, and community support.
GitHub org ↩
A shared GitHub organization account used by a company or team to host repositories under a common brand and access model.
Google Workspace ↩
Google’s business productivity suite, including tools like Gmail, Calendar, Docs, and related admin features.
IARC ↩
An internal Google review and approval process mentioned in the comments for external releases and related compliance checks.

Reference links

Google policy and process references

Background reporting on Google open source

Tools and competing references

  • GAM wiki
    Referenced as an existing third-party tool for Google Workspace administration and as a comparison point for feature parity.
  • googleworkspace/cli repository
    Direct repository cited to show the disclaimer that the project was not an officially supported Google product.

Original post and access mirror

  • Original X post
    The original social post where the former employee described being fired after creating the CLI.
  • xcancel mirror of the X post
    Alternative mirror shared so readers without an X account could read the original post.

Books and essays mentioned