The practical question is not whether legibility is good or bad.

The practical question is: what should become clearer now, what should remain protected for now, and what needs translation before the organization makes a bad decision?

That is the legibility audit.

Use it when a team feels foggy, a leadership layer demands more visibility, a dashboard creates suspicious confidence, a project keeps slipping, an experiment is being strangled by process, or a sensitive issue is hiding inside polite updates.

The audit is not a documentation checklist. It is a power-and-judgment check: what will this new visibility let the organization do, and what might it quietly destroy?

1. Name the work type

Different work needs different legibility.

Is this execution, discovery, conflict resolution, craft development, strategic exploration, incident response, accountability, or resource allocation?

Execution needs more legible commitments. Discovery needs bounded protection. Conflict needs privacy plus escalation discipline. Craft needs examples and apprenticeship, not only documentation. Strategy needs protected exploration before broad translation. Accountability needs visible ownership and consequence.

If you apply the wrong legibility mode, the work distorts.

2. Name the reader

Legible to whom?

The CEO, VP, manager, team lead, peer team, board, customer, support rep, and individual contributor do not need the same view. One view for everyone usually means the wrong view for most people.

For each reader, ask:

  • what decision do they need to make;
  • what action do they need to take;
  • what context is enough;
  • what detail would mislead or distract;
  • what uncertainty must be preserved.

Legibility without audience design is just exposure.

3. Name the decision

If no decision or coordination need exists, ask why the system wants visibility.

Sometimes visibility is requested because leaders are anxious. Sometimes because trust is low. Sometimes because ownership is unclear. Sometimes because the reporting habit has outlived its purpose.

A useful artifact should change a decision, improve coordination, clarify ownership, surface risk, or strengthen accountability.

If it does none of those, it may be proof-of-work.

4. Identify what compression will lose

Every summary loses something.

What local nuance disappears? What caveat matters? What tacit judgment is being converted into a field? What conflict is being sanitized? What customer signal becomes invisible when averaged? What uncertainty becomes falsely crisp?

You may still compress. Organizations require compression. But name the loss so you do not mistake the artifact for reality.

5. Check the incentive created

Any legibility mechanism changes behavior.

A metric invites optimization. A dashboard invites comparison. A tracker invites status management. A public commitment invites performance. A decision log invites rationale discipline. A private escalation path invites earlier truth.

Ask what people will do differently once this becomes visible. If the likely behavior is gaming, defensive updates, or premature certainty, redesign the mechanism.

Also ask who gains leverage. Does the artifact help a team coordinate, or does it let a distant reader intervene at a grain they do not understand? Does it create accountability, or only auditability? Does it improve truth flow, or teach people which truth is unsafe to write down?

6. Separate privacy from opacity

Some things should remain private. Fewer things should remain unaccountable.

Healthy privacy has:

  • a reason;
  • an owner;
  • a boundary;
  • a review point;
  • a translation path.

Unhealthy opacity has none of those. It hides who decided, who benefits, who is blocked, or what consequence is being avoided.

The audit should protect privacy and attack opacity.

7. Choose the artifact

Do not default to a dashboard.

The right artifact might be:

  • a decision memo;
  • a dependency map;
  • an escalation note;
  • an exception report;
  • a learning brief;
  • a private conflict readout;
  • a metric with interpretation;
  • a standards document;
  • a case review;
  • a simple owner/date/action list.

Artifacts are tools. Pick the one that matches the operating job.

8. Set the review point

Legibility changes over time.

Exploration should become clearer as signal accumulates. Sensitive conflict should translate once the operating implication is known. A private strategic option should become a resource decision if it needs company commitment. A dashboard should be retired if it no longer changes behavior.

Every protected illegibility should have a moment when someone asks: should this now become legible?

The operator standard

A good operating system is neither fully transparent nor comfortably opaque.

It makes commitments, decisions, dependencies, risks, and ownership legible enough for coordination and accountability. It protects craft, trust, local intelligence, experimentation, sensitive conflict, and emerging strategy long enough for judgment to work. It exposes hidden power, shadow priorities, and blockers before they damage the system.

Great operators do not worship clarity. They practice translation.

They know what to reveal, what to protect, what to compress, what to preserve, and when the organization is mistaking visibility for understanding.