The delay is in the shape of the organization

A one-field change to an internal order view can expose an entire decision path. The team that owns the view knows the field, the users and the rollback path. Yet the request waits in three separate queues because three departments each own a slice of the application. This is an illustrative case, not a report from a company.

Where is the work? The implementation might take an hour. The decision path might take a week.

A conversation about organizational bureaucracy makes a sharper point than “meetings are bad”: the arrangement of an organization can produce the bureaucracy its people then try to remove. That is a claim about structure, not a proven cure for every slow team. It gives us a useful question: which waiting time exists because of how authority is split?

Trace a decision, not an org chart

Pick one recurring class of decision. A schema change, a support-policy exception, or a new field in an export will do. Start when somebody has enough information to ask for a change. Stop when the change is accepted or rejected. Record who owns each step, what they need to decide, and when they can act.

The distinction is between a handoff and a check. A handoff moves a request to another owner. A check tests a real constraint. They often appear together, but they need not.

In the illustrative order-view change, one team might check whether the field exposes personal data. That is a check with a reason. A second group might only repeat the same priority discussion because the implementation team cannot set its own queue. That is an ownership boundary. Remove the meeting and the boundary remains.

Crossing	Question it answers	Keep it if…
Product to implementation	Is the change worth making now?	The receiving team has a different, needed view of priorities
Implementation to security	Does access change?	The change crosses a permission or data boundary
Implementation to operations	Can the change run and recover?	The operator owns a real deployment or recovery consequence
Team to team for visibility	Who should know?	Awareness changes action; notification need not be a veto

This table is a conceptual diagnostic. It reports no measured effect from changing any particular organization. Our guide to team productivity addresses tools; this diagnostic asks whether a handoff needs to exist at all.

Decision distance is the useful unit

A box on an org chart says who reports to whom. It does not say how far a decision travels before someone can take responsibility for it. Decision distance is the sequence of context transfers, queues and vetoes between a problem and an accountable action.

1. Change request

   problem is known
   waits
2. Queue

   ownership boundary
   reconstructs
3. Context transfer

   reason restated
   authorizes
4. Decision

   accountable owner

Distance matters because context decays. Each transfer requires someone to restate why the field matters, what could go wrong and what was already ruled out. A recipient can ask for a cleaner specification. The sender can write one. Neither has removed the need to reconstruct the situation.

This is why “communicate more” often disappoints. Better notes can make a necessary boundary work. They cannot turn an unnecessary boundary into useful work. If the same facts are explained in three rooms, the missing artifact is often a decision right, not a slide deck.

For a sync between a store and an email system, the cost is concrete. The person who knows the business meaning of “active customer” may sit outside the team that owns field mapping. If every correction waits for a general platform review, the mapping queue becomes a substitute for shared ownership. The teams may need a clear contract: local business rules belong with the workflow owner; transport, authentication and recovery belong with the platform owner.

When an approval protects the work

“An extra approval catches mistakes.” Sometimes it does. Security, consent, financial controls and changes to shared interfaces can create consequences beyond the team making the request. Cutting those checks to improve a chart is reckless.

The better test asks what each crossing catches. If a reviewer routinely finds permission errors, keep the control and make its input sharper. If a reviewer receives the same request for visibility and never changes the decision, replace the veto with a record or notice. If two teams independently own the same outcome, resolve the ownership conflict before shortening the calendar.

A bounded experiment can make this visible. Choose one low-risk decision class. Name the accountable team, the constraints it may not cross, the evidence it must retain and the way to reverse a mistake. Compare a small sample of similar requests before and after: elapsed time, waiting time, rework and reversals. These are measurements to collect, not numbers the source supplies.

Reorganization is expensive. People learn new roles, lose familiar routes to help and may uncover constraints the old chart hid. Start with the decision path. A change in reporting lines may follow, but it should not be the first artifact.

The shortest path is sometimes a missing permission to decide.