Google shipped power, not process

A developer inside Google built a command-line tool that wrapped Workspace APIs, used it to automate parts of his own job, and lost that job over it. The tool worked. Access was legitimate. The APIs were public, documented, and shipped by Google itself. That is the part most takes skip past on their way to a headline about corporate pettiness. The firing was real, but the CLI was the trigger, not the cause.

The cause was an organization that shipped raw capability and never built the layer that decides what happens when someone uses that capability at full strength. Google is not short on capability. It is short on the operational process that turns one person’s automation into something sanctioned, repeatable, and owned. When that process is missing, the person who moves first stops being a signal and becomes a threat. Not because they broke a rule, but because they exposed the absence of one.

Strip the story down and it is not about an engineer or a tool at all. It is about the distance between “we made this possible” and “we know what to do when someone actually does it.” That distance is where careers get ended and useful work gets punished. The CLI is interesting for about five minutes. The gap it revealed is the thing worth understanding, because every company handing out powerful internal tooling is sitting on the same gap and most of them do not know it yet.

Workspace exposes APIs. A CLI over those APIs is a thin, deterministic wrapper - no models, no autonomy, no magic. It takes actions a human could already take through a browser and makes them scriptable, fast, and repeatable. The capability was never the innovation. Google built the surface, documented it, and invited developers to use it. What Google never built was the absorption layer: the part of the organization that takes a working automation and makes a decision about it. Promote it. Standardize it. Retire the manual process it just made redundant. Retrain the people whose role was that manual process. None of that infrastructure existed, so the automation had nowhere to go but into conflict.

This is the failure mode I’d call build it and they will break. Capability without an operational path does not produce controlled improvement. It produces disruption that lands on individuals instead of being managed at the system level. The CLI did not break anything technically. It broke an assumption - that the manual workflow it replaced was load-bearing and permanent. When one person’s pipeline makes a team’s manual process visibly unnecessary, that is a real disruption, and it is a disruption no one at Google owned. Unowned disruption always gets resolved the cheapest way available, which is removing the source.

There are three layers in play here, and they are worth separating cleanly. First, capability: the APIs exist and work. Second, usage: someone builds on top and automates. Third, governance: someone decides what that automation means for the workflow, the team, and the roles around it. Google is strong at the first layer, loose to the point of reckless at the second, and effectively absent at the third. Tolerance at the usage layer without anything at the governance layer is not freedom. It is exposure. The organization gets the appearance of an open, experimental culture while quietly offloading all the risk of that culture onto whichever employee actually acts on it.

The easy read is that Google is anti-innovation, afraid of autonomy, allergic to anyone who colors outside the lines. That read is wrong, and it is lazy. Google ships autonomy-adjacent tooling constantly and employs people whose entire job is pushing internal systems past their intended limits. The company is not scared of autonomy as an abstract idea. What it lacks is a path to operationalize a specific act of autonomy once that act appears in the wild. The fear does not show up at the level of policy or values. It shows up at the exact point where working capability meets an ungoverned workflow, and at that point the org has no move except to treat the person as the problem.

The second bad read is the mirror image: a rogue employee who overstepped and got what was coming. That framing collapses the moment you look at what actually happened. Calling a documented, sanctioned API through a thin CLI is not going rogue. If that is a firing offense, then the boundary was never defined in the first place - and undefined boundaries are always enforced after the fact, against the individual, never against the process that failed to draw them. “You should have known” is what organizations say when they never decided, and then needed someone to carry the cost of not deciding.

The read that actually holds is structural, and it is less satisfying because there is no villain in it. This was an orchestration failure, not a cultural one and not a personal one. The missing component was the operational layer that manages the disruption capability inevitably creates. Every company that distributes powerful tools without a process for absorbing what those tools make redundant is running the same unpatched defect. Most have not hit it yet only because no one has pushed hard enough to expose it. Google did, one of its own people pushed, and the defect surfaced the way defects always do - expensively, publicly, and at the expense of the person who found it.

Build the third layer before you need it

The fix is not tighter control at the usage layer. Locking down internal APIs to prevent the next CLI kills the exact experimentation that makes a capable engineering org worth joining, and it treats a symptom while the real defect sits untouched. What you build instead is the governance layer Phase 1 named: the part of the organization that takes a working automation and makes a decision about it. You build it as standing infrastructure, staffed and owned, before anyone ships the tool that forces the question. An absorption layer assembled after the complaint arrives is not an absorption layer. It is a disciplinary process wearing a nicer label.

That layer has four working parts, and none of them require a model or an agent. Start with intake. Give anyone who builds a tool a low-friction way to register it: a short entry that says what it does, which APIs it touches, and how much manual work it removes per week. This is a registry, not an approval gate. Registration takes ten minutes and buys you the one thing Google never had, which is visibility before scale instead of discovery through conflict. A tool the org can see is a tool the org can direct. A tool it learns about from an angry team is already a personnel problem.

The second part is triage with named owners, and it resolves to four outcomes. Promote: adopt the tool as supported infrastructure, assign it a maintainer and a budget. Standardize: extract the pattern and roll it across every team doing the same manual work by hand. Contain: keep the tool but scope it, sandbox the blast radius, add a dry-run flag, rate-limit the destructive calls, and log every action to an audit trail. Retire: shut down the manual process the tool made redundant, on a date, with an owner. Every registered tool leaves triage carrying one of those four labels and a human attached to it. That single rule is what converts a loose act of autonomy into something the org has chosen rather than tolerated.

The third part is the one every company skips, and it is where Google’s failure actually lived: workflow and role reconciliation. When an engineer’s script makes six hours of weekly manual work disappear, that redundancy is a fact the moment the script runs, whether or not a manager touches it. Someone has to own the sentence “this work no longer needs a human, and here is what the three people who did it are doing next week.” That is a management decision, not an engineering one. Leave it unassigned and the redundancy resolves itself the cheapest way available, which is firing the person who exposed it. The fourth part closes the loop: for anything labeled promote or contain, wire in the deterministic controls a scriptable tool demands, because a wrapper that does in four seconds what a human does in an hour also makes mistakes at that speed. Reversibility, logging, and a kill switch are the price of running the tool in production instead of pretending it does not exist.

The same CLI at a company that planned for it

Run the identical events through an org that built the absorption layer. Day one, the engineer writes the Workspace CLI and registers it: wraps the admin and directory APIs, saves the provisioning team roughly eight hours a week, code linked. Day three, triage looks at it. The manual onboarding checklist that team has run by hand for two years is now visibly slower than a script anyone can call. Nobody treats that as a threat, because a named owner already exists for exactly this moment. The decision takes one meeting: promote the CLI to supported tooling, assign a staff engineer to harden it, add audit logging and a dry-run mode, and set a retirement date for the manual checklist.

The reconciliation happens in the same week, not six months later through attrition. The provisioning lead reassigns the two people who ran the checklist to access reviews and exception handling, work the script cannot do and the company was neglecting. The engineer who built the tool gets credited on the internal changelog and pulled into the group that owns internal automation. Same capability, same act, same disruption to the same manual process. The result inverts, because the org had a place to put the disruption instead of a person to pin it on.

Now hold that against what Google actually ran. No registry, so the tool stayed invisible until it started replacing work people were measured on. No triage, so the four outcomes never got considered and the default outcome, doing nothing, quietly became the outcome of removing the source. No reconciliation, so the redundancy the CLI created had no owner and defaulted to the engineer’s manager, who owned a headcount line and a workflow the tool had just embarrassed. The distance between promoted and fired was not talent, intent, or how clean the code was. It was one missing layer, and the engineer paid the full cost of its absence.

The trap is the missing layer, not the tool

This reads like a firing story, so most people file it under corporate pettiness and move on. Read as a system, it is a preview. Every company handing engineers powerful internal tooling and documented APIs is running the same architecture Google ran, minus the incident that exposes it. The capability layer works. The usage layer is tolerated, sometimes celebrated in an all-hands. The governance layer that decides what a working automation means for the workflow and the roles around it does not exist. That configuration is stable right up until one competent person uses the tools at full strength, and then it fails the way it failed here: expensively, publicly, and against the individual.

Tolerating experimentation without owning its consequences is not an open culture. It is unpriced risk sitting on the person who acts. The org collects the upside of looking innovative and hands the entire downside to whichever employee moves first, then calls the resulting firing a matter of judgment. If calling a sanctioned API through a thin wrapper can end a career, the boundary was never drawn, and undrawn boundaries always get enforced after the fact, against a person, never against the process that failed to draw them. “You should have known” is the sentence an organization uses when it never decided and then needed someone to carry the cost of not deciding.

So build the third layer before someone forces you to. It is cheaper than the alternative and it is not complicated: a registry, a four-outcome triage with owners, a reconciliation step that treats redundant work as a management decision, and deterministic controls on anything you promote. Do that and the next internal tool becomes an asset you route, harden, and standardize. Skip it and you keep the trap armed, waiting for your most capable engineer to be the one who trips it. The tool was never the risk. The missing layer is, and it is missing in more places than Google.