Keeping Decision Authority Clear as a Company Grows

By Mark Bold | leadership | 8 min read

An org chart shows reporting lines. A decision system shows who can commit what resources, when they must escalate, and what triggers a review. Growing companies need the second, not just the first.

Why Reporting Lines Are Not a Decision System

Most growing companies produce an org chart within their first fifty employees. Boxes connect to boxes, titles sit beneath titles, and leadership points to the diagram as evidence that structure exists. The chart answers a narrow question: who reports to whom for performance management and career development. It does not answer the questions that actually slow a company down.

Who can sign a contract that commits the company for three years. Who can hire outside an approved plan. Who can approve an exception to the discount policy. Who must be told before a product change affects an enterprise customer. Who decides when two functions disagree about priority. None of these are visible on the chart. In the absence of explicit answers, people guess. The most common guess, especially in companies founded by strong operators, is that the founder will weigh in. That guess erodes the delegation the founder believes already happened.

A decision system is the layer that sits above or beside the org chart. It specifies authority, escalation, and review in a form that someone can read and apply without asking anyone. Building it is unglamorous work. Not building it is one of the most common reasons scaling companies feel slow despite having added capable people.

Delegation Thresholds That Mean Something

Delegation is often described as a mindset. It is more useful to treat it as a set of thresholds. A threshold is a specific statement of what a role can commit without further approval. It names the resource, the ceiling, and the conditions.

Consider a hypothetical director of marketing in a company of two hundred people. A real delegation threshold for that role might state that the director can commit up to a defined annual spend across approved vendor categories, can sign agreements under a defined term length using the standard template, can hire within an approved headcount plan at bands already set by compensation, and can approve campaigns that do not make claims regulated by the company's compliance review. Everything else requires a named approver.

The discipline is in the specificity. Vague delegation, such as telling a leader to use their judgment on spend, produces one of two outcomes. Either the leader treats every meaningful decision as needing a check in, which slows the company and signals to the organization that the delegation was performative, or the leader interprets authority broadly, and the founder discovers commitments they would not have made. Both outcomes damage trust. Threshold language, by contrast, is testable. A controller can audit it. A new hire can read it in a week.

Thresholds should cover at minimum: spending commitments by category and duration, hiring and compensation decisions, contractual terms that affect the balance sheet or create long tail obligations, pricing exceptions, public communications, and anything touching the product roadmap for named strategic accounts. The right ceilings depend on company size, cash position, and risk tolerance. There is no universal number. What matters is that the numbers exist and that leaders know them.

Escalation Paths and the Problem of Shadow Approval

Escalation is the companion to delegation. If a decision exceeds a threshold, the escalation path says exactly where it goes. A good path names a single primary approver and a backup, specifies the information required to decide, and sets an expected response window. A bad path routes everything to the founder because that feels safe.

Shadow approval is the pattern where the written system says a leader has authority but the practical system requires informal sign off from the founder or another senior figure. It appears in small signals. A leader checks in before making a call they are formally empowered to make. A founder reverses a decision after the fact and the organization notices. A deputy learns to run choices past the chief of staff to avoid friction. Each instance teaches the company that the real decision rights sit somewhere other than where the document says.

Shadow approval is costly in three ways. It slows throughput because every decision carries hidden steps. It demoralizes capable executives who understood they were accountable for outcomes but discover they are accountable for predicting the founder's preferences. And it prevents the company from learning whether its delegation thresholds are set correctly, because the real decisions never test the thresholds.

The counterargument deserves a hearing. Founders often shadow approve because they have context no one else has, particularly about investors, strategic relationships, or founding commitments. That context is real. The right response is not to resume approval. It is to transfer context, which is slower and harder, and to narrow the categories where founder involvement remains explicit rather than ambient.

Authority to Commit Resources

Resource commitment is where authority becomes concrete. The relevant resources are cash, headcount, time of other teams, the company's name in public, and legal obligations that extend beyond the current period. Each should have an owner at each level of the organization and a documented ceiling.

Two failure modes are common. The first is concentrating commitment authority too high, so that routine operational choices move slowly and senior leaders spend their attention on decisions that could have been made two levels down. The second is distributing it too broadly without the accompanying financial literacy, so that leaders commit the company to obligations they do not fully understand, particularly in multi year contracts, indemnification language, or auto renewing arrangements. The remedy for the first is honest delegation with real ceilings. The remedy for the second is training and tooling, including standard templates, a contracts review process scaled to risk, and a finance partner embedded with each function.

Legal implications of commitment authority vary significantly by jurisdiction, entity type, and the specific documents a company uses. A delegation policy is a business instrument. Whether a particular signature binds the company in a dispute depends on corporate authority documents, apparent authority doctrines, and the terms of the agreement itself. Treat the internal policy and the external legal position as related but distinct questions, and have counsel review both.

Review Triggers That Catch Drift Early

Authority without review degrades. People stretch thresholds, categories blur, and the environment changes. A decision system needs explicit review triggers, which are events that cause a specific authority to be reexamined.

Useful triggers are both calendar based and event based. Calendar based reviews happen at known intervals, typically tied to planning cycles. Event based triggers include crossing a revenue or headcount threshold, a material change in cash position, a leadership transition in a function, a significant incident such as a customer loss or a compliance finding, and the introduction of a new business line with a different risk profile. When a trigger fires, the review asks a narrow set of questions. Are the thresholds still appropriate. Are the escalation paths being used or bypassed. Are there categories of decisions where exceptions have become routine, suggesting the policy no longer matches operations.

Reviews should produce changes or a documented decision not to change. A review that always confirms the existing policy is not functioning as a check.

Making the System Visible and Teachable

A decision system only works if people can find it, understand it, and apply it under pressure. That means it should be written in plain language, available in a known location, taught during onboarding for any role with meaningful authority, and referenced when decisions are made. New executives should be briefed on their thresholds in their first week, not left to infer them.

The system also needs a mechanism for proposed exceptions. Policies that cannot be challenged are either ignored or treated as ceremonial. A simple exception process, where a leader can propose a one time deviation with a stated rationale and a named approver, keeps the policy credible and surfaces the cases where the underlying thresholds should be revised.

Executive Imperatives

Executive Imperative: Audit your current state honestly. Ask three or four leaders two levels below you to describe, in writing, the exact authority they believe they hold over spend, hiring, contracts, and customer commitments. Compare their answers to what you believe you delegated. The gap is your starting point.

Executive Imperative: Write delegation thresholds as specific numbers and categories, not as principles. If you cannot state a ceiling, a term limit, or a named approver, the delegation is not real and will produce shadow approval under stress.

Executive Imperative: Identify and dismantle your own shadow approvals. For each category where you still weigh in despite having delegated it, decide whether to formally reclaim the authority, transfer the missing context so delegation can stand, or accept that your involvement is undermining the leader who owns the decision.

Executive Imperative: Install review triggers tied to both the planning calendar and specific events. Treat a review that never changes anything as a signal the review itself needs redesign, not as evidence the system is healthy.