dilbert-test — quality + safety report

---
name: dilbert-test
description: Force a "common sense over company rule" audit whenever a policy, process step, or org rule produces an obviously absurd result in a specific situation. Use this skill aggressively when the user is doing policy debates, process audits, rule-writing, compliance reviews, onboarding-doc cleanup, or saying "this rule is ridiculous", "the policy says X but it makes no sense here", "two teams each think the other team owns this", "nobody knows why we do this", "the form requires it but no one reads it", "we have to ask three approvers for a $20 expense", "the SOP contradicts itself", "an intern wrote this rule years ago", or any moment where a smart person is about to comply with something they cannot defend. Also fires on rules whose owner cannot be named, requirements inherited from departed employees, and any contradiction surfaced when you ask two teams the same question and get opposite answers. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - best-part-is-no-part
---

# Dilbert Test

> "In general, always pick common sense as your guide. If following a 'company rule' is obviously ridiculous in a particular situation, such that it would make for a great Dilbert cartoon, then the rule should change."
> — Elon Musk, *The Book of Elon* (Chapter: Simplicity Wins)

## What this skill captures

Most "company rules" survive not because they are correct, but because nobody is allowed to ask whether they are stupid. Musk's Dilbert test is a forcing function: if explaining the rule out loud — in this specific situation — would sound like a punchline in a Dilbert cartoon, the rule is the problem, not the situation. The test is deliberately low-brow because the failure mode is high-brow: smart, conscientious people complying with absurdity because it has a policy number attached.

Musk's own anecdote is the canonical example. Tesla had robots gluing fiberglass mats onto battery packs. He asked the battery team what the mats were for — they said noise and vibration. He asked the vibration team — they said fire safety. Nobody owned it. The mats came out, two million dollars of robotics came out, and the cars sounded identical. The value: you stop optimizing, accelerating, and automating processes that should not exist at all.

## When to use this skill

- A policy debate where someone is defending a rule with "it's the policy" instead of a reason.
- A process audit where a step exists but no current employee can explain or owns it.
- Two teams give opposite answers about who owns a requirement (the fiberglass-mat tell).
- Onboarding, compliance, or SOP cleanup where rules accumulate but never get deleted.
- A smart engineer or operator is about to comply with something they cannot defend.
- A "just in case" justification is the only thing keeping a rule, form, or approval alive.

## The how-to

1. State the rule out loud in the specific situation, then ask: would this be a Dilbert cartoon?
   > "If following a 'company rule' is obviously ridiculous in a particular situation, such that it would make for a great Dilbert cartoon, then the rule should change."
   > — *The Book of Elon*
   The test is the cartoon, not the abstract policy. Many rules pass in general and fail spectacularly in the specific case in front of you.

2. Name the person who owns the rule. Not the department — the person.
   > "Whatever requirements or constraints you do have must come from a person, not a department. You can't actually ask a department. You have to be able to ask a person, and the person putting forth the requirement must take responsibility for that requirement."
   > — *The Book of Elon*
   If you cannot name a living, currently-employed human who will defend the rule, that is your answer. Intern-from-two-years-ago is not an owner.

3. Ask two teams the same question separately. Watch for contradiction.
   > "I asked the battery safety team, 'What the hell are these mats for? Fire protection?' They said, 'No, they're for noise and vibration.' So I asked the noise vibration analysis team, 'What's the mat for?' They said fire safety. It was like being in a Dilbert cartoon."
   > — *The Book of Elon*
   When each team thinks the OTHER team owns the requirement, the requirement owns nothing. Delete it.

4. Default to deleting the rule, not patching it. Accept you will reinstate some.
   > "If you're not adding deleted things back in 10 percent of the time, you're clearly not deleting enough."
   > — *The Book of Elon*
   A 0% reinstatement rate is not virtue — it's evidence you were too timid. Plan to overshoot deletion and put a fraction back.

5. Do not automate, accelerate, or optimize a rule that fails the Dilbert test.
   > "The most common mistake of smart engineers is to optimize a thing that should not exist."
   > — *The Book of Elon*
   Musk burned years automating fiberglass-mat installation before deleting it. Run the Dilbert test before any process improvement, or you will polish nonsense.

6. Change the rule, then write down who changed it and why. Make the new rule defensible by the same standard.
   > "Simplicity is our mantra. It creates both reliability and low cost."
   > — *The Book of Elon*
   The replacement must have a named owner and survive its own future Dilbert test. Otherwise you have just swapped one cartoon for another.

## Common failure modes

- Defending the rule because "compliance / legal / safety said so" without a named human who will sign their name to it today.
- Treating the rule as sacred because it is old. Age is not justification — it is suspicion.
- Optimizing or automating the absurd process instead of deleting it. ("We made the mat-gluing robot 100% faster.")
- "Just in case" reasoning. Musk: "you can make 'just in case' arguments for many, many, many things." Almost all of them lose to the Dilbert test.
- Asking only one team and accepting their answer. The contradiction only surfaces when you ask the second team.

## When NOT to use this skill

- Catastrophic / irreversible domains where the rule encodes a hard-won safety lesson (aviation checklists, medical dosing, nuclear). Apply the test, but the bar for deletion is much higher — get the named owner and run the experiment carefully.
- External regulation you do not control (tax, export, GDPR). The rule may still be dumb, but the cartoon is being drawn by a government, not your company.
- Cultural or interpersonal norms where "ridiculous" is a matter of taste, not logic. The Dilbert test is for absurd process, not for taste disputes.
- When you have not yet talked to a frontline operator who actually executes the rule. Run the test with them present, not from a conference room.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Simplicity Wins" (in "Designing the Organization"). Supporting anecdote drawn from the fiberglass-mat example in the adjacent "The Algorithm" chapter.