The Decision Hierarchy Problem

Writing Note

The Decision Hierarchy Problem

Most organizational friction is not a communication problem. It is a decision authority problem that has been relabeled as a communication problem.

Most organizational friction is not a communication problem.

It is a decision authority problem that has been relabeled as a communication problem.

When engineers do not know whether they can choose a library, that is not a communication gap. It is an unresolved question about who owns the technical surface. When PMs escalate feature decisions to leadership instead of resolving them with engineering leads, that is not a collaboration failure. It is the absence of a clear decision frame.

The symptom presents as information flow breakdown. But the root is almost always the same: nobody made the map of who can decide what, at what level, with what evidence.

What a decision hierarchy actually does

A decision hierarchy answers three questions:

  1. What decisions exist at this level of the organization?
  2. Who owns them, and what does ownership mean in practice?
  3. What does escalation look like, and when is it appropriate versus a failure of the system?

Without those answers, people fill the vacuum in predictable ways. Some over-escalate — because being wrong alone feels worse than waiting for permission. Some under-escalate — because they optimized for speed and built something that cannot be unmade. Most do both at different times, which looks like inconsistency and feels like unreliable judgment.

Neither group is wrong. The system is wrong.

The signal that surfaces it

The clearest signal that a team lacks a functioning decision hierarchy: people ask “who decides this?” in more than one meeting per week.

That question is useful once — when a new area opens up and ownership genuinely has not been established. After that, the question is a symptom. It means the first time the question arose, the answer was given verbally and not written down anywhere durable.

Verbal-only decisions are not decisions. They are precedents waiting to be forgotten or disputed.

The simplest repair

Write the map. Not in a policy document. In a short living file that the team can amend when circumstances change.

The file needs three columns: decision category, decision owner, escalation path. That is all. If the team cannot produce this file, that is already useful information — it means the hierarchy does not exist yet, and what exists instead is informal power that the formal org chart does not reflect.

The best time to build the map is before you need it. The second best time is the week after a decision went sideways and everyone learned what ambiguity costs.

Filed under engineering leadership , org design and decision making .

If this connects with something you are building or untangling, reply by email — the subject line is already written.