Skip to main content
Organizational Systems

Decision Flow vs Org Charts: Why Formal Structure Rarely Predicts How Decisions Actually Get Made

The org chart is a map of a country that doesn't exist.

Why don't org charts reflect how decisions get made? The gap between formal reporting lines and actual decision flow reveals where organizational dysfunction hides.

Decision Flow vs Org Charts: Why Formal Structure Rarely Predicts How Decisions Actually Get Made

The org chart says the VP of Engineering owns technical direction.

In practice, teams wait to hear what the principal engineer thinks. The VP asks for their view. Directors avoid contradicting them in public. Product managers route architecture-sensitive proposals through them before formal review because everyone knows an objection from that person can stop the work.

The org chart is accurate about reporting lines. It is less accurate about decisions.

Decision flow is the path decisions actually take: who gets consulted, whose objections matter, who controls information, who can allocate resources in practice, and whose priorities change what teams do tomorrow. Formal authority is part of that system. It is rarely the whole system.

Organizations get into trouble when they redesign the document and expect the system to change with it.

Consultation Is Often the Real Approval

Formal approval usually happens late. The influential work happens before the request reaches the approver.

A product manager may formally own prioritization. Before they finalize a roadmap, they ask engineering about feasibility, sales about revenue exposure, support about operational cost, customer success about account risk, and leadership about strategic fit. Any of those conversations can move the priority.

If engineering says the feature is too expensive, it drops. If sales ties it to a renewal, it rises. If the CEO expresses doubt, it quietly disappears. The product manager remains the formal owner, but the decision has been shaped by people whose approval may never appear in the workflow.

Mapping decision flow means watching these consultation patterns. Who must be asked before a decision feels safe? Whose silence creates risk? Whose objection changes the agenda even without formal veto power?

That network often explains execution better than the org chart.

Informal Veto Power Is Real Power

Some people can stop work because proceeding without them is politically or practically too expensive.

A principal engineer outside the approval chain raises concerns about a platform migration. The formal approvers have signed off. The team still pauses because leadership trusts the engineer’s judgment, other teams follow their technical guidance, and ignoring them would make any later failure indefensible.

That influence may be healthy. Expertise should matter. The problem starts when informal veto power is invisible and unaccountable. The person can stop initiatives without owning the delay, the trade-off, or the consequences of inaction.

Decision flow reveals these hidden vetoes. The org chart may show one approver. The actual system may require satisfying three informal authorities before the formal approver is willing to act.

Expertise, Relationships, and Information Reshape Authority

Expertise creates authority because people defer to the person who understands the system. A senior engineer who built the billing platform may influence every billing decision regardless of title. Reorganizing their reporting line does not remove the knowledge that gives them power.

Relationships create channels the org chart does not show. An engineer who knows someone on another team can get an answer in an hour that the formal manager-to-manager path would take a week to produce. Most cross-team execution runs on these informal paths because formal paths are slower than the work can tolerate.

Information access creates subtler influence. The analyst who prepares the executive report chooses what is highlighted. The assistant who manages access to the CEO knows which topics are urgent. The customer-facing team that controls account context can frame a problem before product ever sees it.

None of these are necessarily dysfunctional. They become risky when the organization pretends they do not exist.

Crises Show the Actual System

Routine work can perform the formal process. Crises reveal decision flow.

During an incident, people stop asking who has the correct box on the org chart. They follow whoever has competence, credibility, and enough nerve to make the next call. A senior engineer starts directing rollback. An operations lead controls communication. A support manager decides which customers need direct contact.

Afterward, the postmortem may return to formal language. The incident commander approved this. The director was informed. The process was followed. Everyone who was present knows the real authority flowed through capability and trust.

Organizations should pay attention to that pattern. Crisis decision flow often identifies the people and channels that already carry operational authority. Sometimes the structure should be adjusted to match them. Sometimes the organization needs to ask why formal authority disappears when stakes rise.

Mismatch Creates Ambiguous Accountability

When formal responsibility and actual influence diverge, failure becomes hard to assign.

A launch misses. The product manager owned the roadmap on paper. Engineering constrained scope. Sales moved a customer request upward. Leadership set the date. Support shaped readiness requirements. The product manager coordinated the decision but did not fully control it.

If the launch succeeds, credit spreads easily. If it fails, the formal owner is exposed while the informal decision-makers can describe themselves as advisors.

This is how accountability disappears. The person responsible did not decide alone. The people who shaped the decision were not accountable alone. The process becomes the owner, which means the outcome has no real owner.

Large gaps between org chart and decision flow also reward political navigation. People who know the informal network succeed. New hires and straightforward executors follow the formal process and discover too late that the decision happened elsewhere.

Reorganizations Often Move the Wrong Thing

Organizations reorganize to change behavior. They move teams, rename functions, create new roles, and redraw reporting lines.

Decision flow may continue almost unchanged.

Engineers still consult the same technical experts. Product still reacts to the same executive attention. Customer escalations still bypass roadmap governance. Work still moves through the same relationship network because trust, expertise, and information access did not change when the boxes moved.

This is why reorganizations can produce new meetings without new behavior. The formal structure changed. The influence system did not.

A reorganization can work when it changes the actual decision paths: who has authority, who owns resources, who gets consulted, which vetoes are removed, and which informal powers are formalized or intentionally broken. Moving reporting lines alone mostly changes where status flows.

When Org Charts Matter

Formal structure still matters in specific places.

Budget authority, headcount approval, capital expenditure, performance review, promotion, legal accountability, compliance responsibility, and board governance usually follow the org chart. These decisions have formal consequences attached to role and title.

That creates tension. A person may take day-to-day direction from an informal expert while their career depends on a formal manager. A team may rely on relationship networks to ship while legal accountability sits with a named executive. A product decision may be shaped by customer escalation while budget approval remains with a director.

The org chart matters most where the organization, regulator, auditor, or employment system requires formal ownership. Decision flow matters most where work is actually discovered, shaped, and executed. Healthy organizations understand both maps.

How to Map Decision Flow

Do not start with the approval process. Start with decisions that actually happened.

Ask who was consulted before the decision felt safe. Ask whose objection would have stopped it. Ask who saw the relevant information first. Ask who controlled resources in practice. Ask which metric, customer, executive, or incident moved the decision more than the documented priority.

Look at crises. Look at exceptions. Look at the projects that moved unusually fast and the ones that got stuck. The real structure appears where the formal process bends.

Then compare the pattern with the org chart. Some informal authority should be formalized, especially when expertise is already determining outcomes. Some formal authority should be removed because it is ceremonial. Some consultation networks should be documented. Some shadow organizations should be disbanded because they make consequential decisions without accountability.

Perfect alignment is neither likely nor desirable. Expertise and relationships will always shape work. The question is whether the gap is visible enough to manage.

An org chart is a useful administrative artifact. Decision flow is the operating system. Treating the artifact as the system is how organizations redesign structure and leave the real decision machinery untouched.