Drawing Your Real Org Chart

Idea one

A department is not a decision owner

A decision owner is the person who has the authority and obligation to bring a particular decision to a conclusion. They may seek advice, require information, and work within financial, legal, technical or safety limits. They may not perform every action that follows. But they are the person who must decide, or make sure that a decision is made through the agreed route.

This sounds obvious until a manager tries to name decision owners in a real organization. People describe responsibilities in broad terms — Finance owns financial control, Sales owns customer relationships, Operations owns service delivery. These statements are useful, but they do not identify who owns the decision when responsibilities collide.

Who decides whether a critical repair can proceed when the account is on credit hold? Who decides whether a repeated portal defect deserves priority over planned development? Who decides whether an account executive can offer a service recovery? Who decides what happens when the normal decision-maker is unavailable?

If the answer to these questions is "Finance," "the leadership team," "the business," or "we discuss it," the decision probably has no clear owner.

A department is not a decision owner. Neither is a meeting.

A meeting can be a place where information is brought together and a decision is made. A department can provide expertise, control or execution. But one named person, or a clearly defined decision forum with stated authority, must be accountable for reaching a conclusion. Without that clarity, work drifts.

An urgent repair may be visible to several people at once, and all of them matter. Yet they do not all own the same decision. The service manager may own classifying the repair as critical. The account executive may own providing accurate commercial context. The warehouse supervisor may own preparing the part safely once conditions are met. A Finance manager may own approving an exception within a defined exposure limit.

The important point is not that one person controls the entire case. It is that each decision within the case has an owner.

Idea two

A short list, in practical language

Begin with decisions that repeatedly affect customers, money, risk, capacity or employee confidence. Do not attempt to map every decision in the organization at once. That creates an impressive document that nobody will maintain or use.

Instead, select the decisions that cause waiting, repeated escalation, confusion, or private workarounds. Approval of urgent credit-hold exceptions. Prioritization of critical repairs when capacity is limited. Approval of customer recovery offers. Release of stock for urgent service cases. Allocation of Technology capacity between planned work and operational problems.

Then write each decision in practical language. Avoid broad phrases such as "customer experience" or "commercial performance." Those are outcomes, not decisions.

"Decide whether to release a part for a critical customer with an account on hold" is a decision. "Decide whether the portal defect should move ahead of a planned roadmap item" is a decision. "Decide whether a service manager can offer a customer a defined recovery within agreed limits" is a decision.

The wording matters because it forces people to confront the actual choice. It becomes harder to hide behind general responsibility when the question is specific.

Idea three

The formal owner, and the real one

Identify the formal owner first: who is supposed to make the decision according to stated authority, policy or management structure. Then identify the real owner by reviewing recent cases.

Who made the final call? Whose agreement was treated as necessary? Who could stop the decision? Who acted as though they had authority, even if the role description did not say so? Who was contacted privately before the formal discussion began?

The difference between the formal and real owner is one of the most important things the map can reveal.

Sometimes the difference is sensible. A Finance manager may formally own routine urgent exceptions while the director becomes involved only above a stated threshold. That is delegation working as intended.

Sometimes the difference reveals a lack of confidence. The manager may have authority on paper but send every uncomfortable case upward because they fear being overruled. The decision owner has been named, but the authority has not become credible.

Sometimes the difference reveals an informal veto. A divisional leader may be accountable for customer recovery, but nobody will commit until the sales director has expressed a view. He may not intend to hold that power. Employees may simply have learned, from past experience, that his opinion determines what is safe to promise.

In each case, the chart needs to show what is actually happening before anyone decides what should change.

Idea four

Owner, contributor, approver — and the limit

The owner makes the decision and carries responsibility for it. A contributor supplies information, expertise, or a necessary perspective. An approver has authority to confirm a decision because of a defined control, limit, or risk.

These roles can overlap in a small organization — a founder may be owner, contributor and approver for many decisions. As the organization grows, combining them everywhere becomes dangerous. It creates bottlenecks and encourages employees to escalate rather than use judgment.

Take the portal defect. Product may own the priority decision. Technology contributes estimates, options, dependencies and technical risk. Support contributes evidence of manual workload. Sales contributes renewal and relationship risk. Finance may contribute the cost of continued manual handling. A senior technology leader may need to approve an option that creates material technical or security risk.

If these roles are confused, the discussion becomes circular. Product waits for Technology to decide. Technology says it is a Product priority. Support reports customer pain without knowing whether anyone must act. Sales escalates individual complaints because that seems more effective than the formal route.

That clarity does not guarantee that people will like the decision. It does ensure that disagreement does not become indefinite waiting.

The most useful maps also show decision limits. Authority without limits is vague. Limits without named authority are restrictive. Employees need both. A Finance manager may approve an urgent exception up to a stated level provided the account history, part value, recovery plan and commercial context are complete. A service manager may reprioritize engineers within their area for a verified critical failure, but must escalate when doing so would affect another critical customer.

These limits should not be designed as a test of whether employees can catch one another making mistakes. They should help capable people act quickly while ensuring that significant risk receives the right level of attention.

Idea five

Absence is the test, and the map must be usable

When drawing decision ownership, absence is a critical test. For every important decision owner, ask, "What happens if this person is unavailable?"

If the answer is that work waits, the organization has not fully identified an owner. It has identified a person on whom the work depends.

A credible decision route includes a deputy, a defined escalation point, or a temporary transfer of authority. The deputy must be known, trusted, and willing to use the authority. Naming someone in a document is not enough if employees still say, "We should wait for Priya," or "Daniel will be back tomorrow."

The same test applies to decision forums. If a weekly meeting is the only place a portal priority can be decided, what happens when the customer problem becomes urgent on a Thursday afternoon? If the answer is that everyone waits until next week, the forum may be useful for ordinary prioritization but inadequate for exceptions. The real org chart should show both the normal route and the route when time matters.

Finally, decision ownership should be visible to the people who need to use it. A manager may create a careful map and keep it in a leadership folder. That will not change how work moves. Service managers, Support advisers, account executives, Finance analysts, warehouse staff and technical leads need to know what they can decide, what they must provide, who decides the next question, and how quickly they should expect an answer.

If they can answer, the organization has begun to replace personal guesswork with usable authority. If they cannot, the published chart may still be neat, but the real org chart remains hidden in memory, influence, and private messages.