Most organizational information flow is accidental — it happens because people default to sharing what they know, not because anyone designed what needs to travel where, to whom, how often, and in what format.

The result is predictable: too much information moves vertically (up and down the hierarchy) and not enough moves horizontally (across teams, across functions). Leaders get informed late because escalation paths are unclear. Teams duplicate work because nobody knows what's being built elsewhere. Problems surface in all-hands meetings because they couldn't get into the weekly review.

This is usually treated as a communication problem. The more useful frame is architecture: what needs to travel where, through which path, and with what expectation of action?

The Map You Need to Draw

Before you can fix information flow, you need to know what it currently is. Draw the information map:

For each significant decision or situation in your organization, trace: who has the information first? Who needs it? How does it currently travel from the first person to the person who needs it? What are the stops in between?

Most organizations have never done this. When they do, the gaps are stark.

A useful simplification: think about three types of information flow and design each separately:

Operational information: status, progress, blockers — flows upward from teams to management. Designed to answer: does management need to act, and if so, on what?

Strategic information: context, direction, priorities — flows downward from management to teams. Designed to answer: are we aligned on what we're doing and why?

Cross-functional information: dependencies, changes, risks — flows horizontally across teams and functions. Designed to answer: does someone outside my immediate team need to know this, and do I need to know something they're working on?

Most organizations have the first two reasonably designed. The third is almost always broken.

Designing the Three Flows

For vertical upward flow (operational):

Define what needs to escalate. Not everything. A useful heuristic: if this continues unchanged for another week without the manager knowing, does it become significantly harder to fix? If yes, escalate. If no, it can wait for the regular cadence.

Define the escalation path. Who tells whom, and how quickly? For operational blockers, the expectation should be: surface it within one business day, through the weekly review if it can wait that long, through a direct message if it can't.

Separate information from solutions. When something escalates, the first question is: what is the information the manager needs to decide whether and how to act? Not: here is the problem and here is my proposed solution (though that can follow). The manager needs the information first.

For vertical downward flow (strategic):

Communicate decisions, not discussions. When a decision is made, communicate the decision and the reasoning — not the history of the discussion that led to it. People who need context can ask. Most people need the conclusion.

Name the implications. When priorities change, say what it means in concrete terms: what gets deprioritized, what shifts timeline, what the team should stop doing. Not communicating implications is the most common reason downward communication fails to change behavior.

For horizontal flow (cross-functional):

Define the coordination forums. Which decisions or changes need to be communicated to which teams before they affect those teams? Not after — before. This is usually a named meeting with a defined agenda: any decision or change that affects another team's work gets announced in this forum before implementation.

Define the handoff protocol. When work moves from one team to another, what information needs to travel with it? Not just the work itself — the context, the constraints, the assumptions. A technical spec is not a handoff. A spec with a walkthrough conversation is.