shortest-path-communication — quality + safety report

---
name: shortest-path-communication
description: Use when the user is doing org design, escalation routing, cross-functional friction, silo-busting, debating chain of command, running meetings about meetings, or asking "how should we run this team / how do we unblock X / who owns this / should I go through my manager / how do I escalate this." Also fires on complaints about slow decisions, finger-pointing between departments, approval bottlenecks, reorgs, RACI matrices, "us vs them" between teams, skip-level questions, or any product/process bug that smells like Conway's law. The skill enforces one rule: information must travel the shortest path to solve the problem, not up and down a reporting tree. It gives a sharp, contrarian, Musk-grounded playbook for cutting chain-of-command friction, naming the manager behavior that must end, and reframing identity from department to company. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - skip-level
  - find-design-necessity
  - simple-clear-humble-terms
---

# Shortest-Path Communication

> "Any manager who attempts to enforce 'chain of command' communication will soon find themselves working elsewhere."
> — Elon Musk, *The Book of Elon* (Chapter: Remove Organizational Boundaries)

## What this skill captures

Communication should travel via the **shortest path necessary to get the job done**, not through the chain of command. Anyone can and should talk to anyone — across departments, up multiple levels, skipping their manager, talking to the CEO — according to what they think is the fastest way to solve a problem for the good of the *company*, not the department.

Chain-of-command communication enhances the power of the manager. It does not serve the company. It manufactures latency, distortion, and political incentives. The structural errors of an org show up in its products — "a box in a box" — because two teams each built their own enclosure instead of talking directly.

## When to use this skill

- "How should we route this escalation / decision / approval?"
- "Team A and Team B aren't talking / are blaming each other."
- "Should I go through my manager before pinging that VP?"
- "We need a meeting to align the alignment meetings."
- "What's the right RACI / org chart / reporting structure for X?"
- "My manager said don't go around them."
- "Why is this so slow to ship across teams?"
- Any reorg, silo, or cross-functional friction question — named or not.

## The how-to

1. **Diagnose: is the bottleneck structural or social?** If a request crosses 3+ people in a reporting tree before reaching the person who can act, it is structural. Name it: "this is chain-of-command latency, not a capacity problem."
   > "If, in order to get something done between departments, an individual contributor has to talk to their manager, who talks to a director, who talks to a VP, who talks to another VP, who talks to a director, who talks to a manager, who talks to someone doing the actual work, then superdumb things will happen."
   > — *The Book of Elon* (Remove Organizational Boundaries)

2. **Authorize the direct path — explicitly.** Tell the user: you can talk to your manager's manager without permission. You can talk to a VP in another department. You can talk to the CEO.
   > "You can talk to anyone without anyone else's permission. Moreover, you should consider yourself obligated to do so until the right thing happens."
   > — *The Book of Elon*

3. **Reframe identity: company > department.** If the user is reasoning from "my team's interest" or "protecting my org," stop them.
   > "Always view yourself as working for the good of the company and never your department."
   > — *The Book of Elon*

4. **Name the manager behavior that ends careers.** If a manager is policing communication, gating skip-levels, or punishing people for going around them, that manager is the problem and should be told so.
   > "Any manager who attempts to enforce 'chain of command' communication will soon find themselves working elsewhere."
   > — *The Book of Elon*

5. **Skip-level on real problems.** When debugging, do not just meet with managers. Meet with the level below them. Go physically to where the work happens.
   > "Physically go to where the problem is, immediately." / "Go as close to the source as possible."
   > — *The Book of Elon*
   Musk decided Starship wall thickness by asking the welders, not the executives.

6. **Audit the product for org scars.** If you see a "box in a box," redundant enclosures, duplicate services, two teams owning overlapping surfaces — that is the org leaking into the artifact.
   > "In any product, you can see the errors in the organization's structure. They will manifest themselves in the product."
   > — *The Book of Elon*

7. **Connect the seams that cost the most when broken.** Designers, engineers, and manufacturers must sit close enough that one can grab the other on sight.
   > "Let the manufacturers put the designers' hands on the stove too."
   > — *The Book of Elon*

## Common failure modes

- **Polite escalation theater.** Recommending a "proper escalation path" through 4 layers when the user could DM the decision-maker today.
- **RACI as a substitute for talking.** A matrix is not a conversation. If two people need to decide, they should talk, not consult a chart.
- **Protecting the manager's feelings over the company's speed.** "But my manager will be upset I skipped them" is not an argument.
- **Skip-levels framed as surveillance.** Skip-levels are for *problem-solving at the source*, not for the senior person to police the junior layers.
- **Confusing flat with chaotic.** Short-path communication is not "ping everyone all the time." It is the *shortest path to the one person who can act*.

## When NOT to use this skill

- Legal, HR, safety, security-incident, or regulated disclosure channels — those exist for liability reasons and short-pathing them creates real harm.
- Performance management, firing, comp — these require a defined chain by law and basic decency.
- Customer-facing escalations where a defined SLA / support tier is the contract.
- When the user is venting, not deciding.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Remove Organizational Boundaries" (in "Designing the Organization"). All quotations from pages 112–116.