Founder Dependency: Fix the Decisions Before the Org Chart

Arjun and Kiran start a design-build firm out of a rented room in 2014. They are not a real company; they are every second business I meet. They win their first clients on velocity. A drawing is queried at nine at night and redrawn by morning. A site problem appears on Thursday and is solved on Thursday, usually by Kiran driving there. When a supplier sends the wrong finish, Arjun eats the cost and replaces it before the client has finished noticing. Nobody writes any of this down, because it isn't a process. It is just what the two of them do.

The work grows. They hire, sensibly, against the gaps in their own week: a draughtsman so Arjun stops drawing, a site engineer so Kiran stops travelling, a project coordinator so neither of them chases. Each hire is given a clear remit and each one performs it. Twenty people, then forty, then more. Revenue climbs. They finally stop working every Sunday.

Then Meera, a client of six years, says the sentence that starts every one of these conversations: "It was different when you were handling it, Arjun."

Nothing was late. Nothing was defective. The drawings were correct, the site was supervised, the handover was completed. Something was missing anyway, and nobody inside the company can name what it was.

This is founder dependency, and it almost never announces itself as a structural problem. It arrives as a quality complaint you cannot reproduce.

The instinct at this point is to fix the organisation: draw the chart, define the departments, write job descriptions for everyone, cascade some KRAs. I want to argue that doing this first is what deepens the problem. Founder dependency is a decision-rights problem wearing an org-structure costume. Your team stops at the edge of their role because every consequential decision still belongs to you. Writing down everyone's role before you redistribute those decisions formalises the exact passivity you are complaining about.

What the client noticed that your dashboard didn't

Start with what actually degraded, because it wasn't output.

What Meera bought from Arjun was never the drawing. It was judgement applied without being asked. Arjun saw a specification that would look wrong in that particular room and changed it before anyone raised a query. He heard her tone on a call and rang back the next morning. He absorbed two days of rework rather than open a conversation about scope. None of that appeared on an invoice or a schedule, and none of it survived the move to a team, because none of it was ever written down as a requirement.

The team delivers the contract. Arjun used to deliver the contract plus his judgement. From Meera's chair, that difference is enormous and completely unspecific, which is why it comes out as "it was different."

Now look at the same gap from inside. Five tells, and most founder-led businesses past twenty people have at least three.

Approvals queue on one desk, and that queue is the real production constraint. Decisions get reversed when the founder returns from travel, which teaches everyone that a decision taken in his absence is provisional. People escalate rather than decide, and the arithmetic is on their side: a good call belongs to the company, a bad one belongs to them personally. Nobody owns the space between functions, so design-to-production and production-to-site are where work quietly drops. And the tell founders misread most often: the best people ask permission most, because they care about the outcome and have learnt the outcome is not theirs to determine.

There is a clean test that separates founder dependency from ordinary founder involvement. Leave for two weeks with your phone off. Involvement means the business runs slower. Dependency means it runs differently, and clients can tell.

Diagnose with RACI, but map decisions, not tasks

Before using the tool, a plain description of it, because the acronym does more to confuse founders than to help them.

RACI is a way of writing down, for any piece of work, who plays which of four roles. R is Responsible: the person who does the work. A is Accountable: the one person who owns the outcome and whose answer settles the matter. C is Consulted: people whose input is genuinely sought before the call is made. I is Informed: people who need to know afterwards but have no say. You build it as a simple grid with the items down the left and the names across the top, and you put one letter in each box.

Two rules make it useful instead of decorative. There can only ever be one A per row; the moment there are two, nobody owns it. And R and A can sit on the same person, but they usually shouldn't, because that is how a founder ends up doing the work and carrying every decision.

Now the important part. Most founders run this on activities. They build a grid with rows like "prepare quotation" and "conduct site inspection", assign letters, print it, and nothing changes. The exercise fails because activities were never the problem. Nobody in your company is confused about who prepares the quotation. They are waiting to hear what price is acceptable.

Run it on decisions instead. That single change turns a filing-cabinet document into an operating tool, and it is the core of the decision rights and execution work that actually reduces dependency.

Four steps.

• list the decisions that move money, risk or the client. Not tasks. Decisions. Aim for twelve to twenty, no more. In a design-build or manufacturing business the list usually looks like this: what price we quote, what discount we concede, what a design finally looks like before it releases, which vendor we use and at what rate, whether material is accepted or rejected on arrival, whether production reworks or ships, what we do when the site hits an unforeseen condition, whether we absorb a cost to protect a relationship, when a project is declared complete, and who we hire.

• mark who is Accountable today, honestly. Not the person whose title suggests it. The person whose answer actually ends the discussion. Arjun, filling this in, wrote his operations head as Accountable for vendor selection, then admitted that the operations head has never once placed an order above two lakh rupees without messaging him first. The honest letter was A on Arjun's row, not the operations head's.

• count. How many of those decisions have you as Accountable? That number, over the total, is your founder-dependency ratio, and it is the only metric in this article. Above two-thirds, the organisation is an extension of your calendar whatever the org chart claims. Then draw a second column beside it: who should be Accountable in a business of your size.

• map the handoffs.. List the transitions in your value chain. Sales to design, design to costing, costing to production, production to site, site to handover. For each one, name the single person accountable for that transition being clean. Most businesses cannot fill this column at all, which is the finding. Work rarely fails inside a function where someone owns it. It fails in the gaps between functions where nobody does.

One caution about the tool itself. RACI is blunt for approvals, because "Accountable" says who owns the decision and says nothing about how far their authority runs. For anything involving money or risk, replace the single letter with three columns: the owner, the limit, and the escalation trigger. Procurement head approves vendor rates within five per cent of budgeted cost; above that, or for any new vendor, it comes to me. That sentence does more to reduce founder dependency than an entire org chart, because it is unambiguous, it is testable, and it survives your absence.

Your standard was never a specification

The decision map explains why the team doesn't decide. It doesn't yet explain why they don't go the extra bit, and that is a separate failure needing a separate fix.

Founders describe this as a character shortfall. They don't have ownership. They don't care the way we do. Sometimes that is true. Much more often, the extra mile the founder is asking for is a set of unwritten judgement calls, and judgement that has never been articulated cannot be delegated, only re-hired.

Break it into three things that can actually be written.

What good looks like at each handoff. Not a quality policy. A specific, boring definition of the output. What a design must include before production is allowed to accept it. What production must confirm before the site team signs for it. What the site must verify before handover is called. Ambiguity at a handoff always resolves in favour of the person passing the work along, which is how defects travel downstream and surface at the client.

Which client signals require action without being asked. Arjun does this instinctively. A client who replies in one word after previously writing paragraphs. A site visit where the client's spouse asks a question that isn't about the site. A payment that is on time but processed late in the day. He reads these and acts. His project manager reads nothing, because nobody has told him these are readable. Write down the six signals you respond to and what you do about each, and intuition becomes a capability the company owns.

What the team is authorised to spend to protect a relationship. This is the one that unlocks the rest. Your people cannot go the extra mile because nobody has told them they are allowed to incur the cost of one. The extra mile has a price: rework hours, a replaced material, a discount, a Sunday. Every one of those costs money the founder owns, and every employee knows it. So they don't spend it, they raise it with you, and by the time you answer, the moment that would have impressed the client has passed.

Fix it with a number. Any project manager can authorise up to fifty thousand rupees of rework or goodwill spend to resolve a client issue on the spot, and reports it at the weekly review. You will lose some money to poor calls in the first quarter. You will also be running a company where somebody other than you can protect a relationship in real time, which is precisely what Meera was missing.

Ownership is granted before it is shown

The bigger question founders ask is how to make a team think like entrepreneurs. Right ambition, wrong sequence. Ownership behaviour has three preconditions, and founder-led businesses typically supply none of them.

Authority. A real decision the person can take without asking. Not input into a decision. Not a recommendation you approve. One consequential call that is theirs, with a stated limit. If everything a person does is subject to your review, they are executing your judgement, and no amount of encouragement converts that into ownership.

Information. Ownership requires knowing the score. Most employees in founder-led businesses have never seen the margin on a project they ran. They know the revenue, because the client told them, and they know the effort, because they lived it. The gap between those two numbers is where every commercial judgement lives, and it is routinely withheld. A project manager who sees project margin weekly starts arguing with the site about wastage. The same person, kept blind, treats wastage as somebody else's problem.

Consequence. They carry the outcome, and you do not rescue them. This is the hardest, and it is where most attempts collapse. A founder delegates a decision, watches it heading somewhere he wouldn't have gone, and steps in. Rationally, the cost of that mistake was real and avoidable. Cumulatively, the organisation has learnt that delegation is provisional, and the next person checks with you first.

Why "mistakes are fine, just don't repeat it" doesn't work on its own

Most founders believe they have already granted permission. They have said, in a meeting, some version of take the call, if it goes wrong that's fine, just don't repeat the mistake. Then nothing changes, and they conclude the team lacks appetite.

Two reasons it fails. The instruction is unbounded, so the employee is being asked to guess where your tolerance ends. A fifty thousand rupee call and a five lakh one are both "a call", and guessing wrong is the precise outcome he is trying to avoid. And employees weight what you do far above what you say. One reversal, one visible flash of irritation, one why didn't you check with me first delivered in a bad week, and the policy is dead while you still believe it is in force. That is why founders so often cannot understand the silence: from where they sit, permission was granted months ago.

The version that works is narrower and sounds less generous. A named decision, a stated limit, in writing, and a debrief rather than a rescue when it goes wrong. "You can decide anything up to X" is believable. "Feel free to take calls" is not.

The discipline that backs it is to let reversible decisions go badly. Sort your decision map into calls that can be unwound and calls that cannot. On the reversible ones, hold your tongue and debrief afterwards. Andy Grove's argument in High Output Management is that a manager's output is the output of the organisation beneath him, not his own work. A founder who out-executes his own team every time is optimising his personal output and shrinking everyone else's. The team that hands Arjun problems was trained to do so by Arjun, who kept solving them faster than anyone else could.

Now design the organisation, around the value chain

Only now does structure become a real question, and by now it is much easier to answer, because the decisions have already told you where the roles are.

Design around the flow of work and its handoffs, not around departments borrowed from a bigger company. A fifty-person design-build firm does not need the org structure of a five-hundred-person one, but it does need a named owner at each transition in its value chain. Start there: one accountable person for each handoff you mapped, with the authority attached.

Then identify the small number of senior roles that must exist for you to leave the approval path. In most businesses at this size it is three to five: someone who can release a design without you, someone who owns cost and procurement within defined limits, someone who owns delivery on site, and eventually someone who owns the client relationship. That is your real hiring plan. It is far narrower and far more expensive than a company-wide role definition project, and it is the one that changes your calendar.

Two things founders resist here, both worth naming. Some of your current people will not fill those roles, and the decision map makes that visible without a formal evaluation exercise. You usually already know who; what you have been avoiding is the conversation, not the diagnosis. And spans of control should stay honest. A structure where nine people report to Kiran because each was hired for a distinct task is not an organisation, it is a hub.

Writing job descriptions that create ownership instead of ceilings

Now, finally, job descriptions, and the reason they come this late.

A job description written as a task list is a fence. It tells a person precisely where they are entitled to stop. Hand a fence to somebody who is already waiting for permission and you have documented their passivity and given it official standing. This is why the founder complaining that nobody goes beyond their role should be the last person on earth writing role definitions first.

A job description built on the map you have just made does something different. Five parts:

Purpose, one sentence: what this role exists to make happen. Outcomes, four to six with measures attached, replacing the list of activities. Decisions owned, lifted straight from the decision map, each with its limit and escalation trigger. Handoffs, given and received, with the definition of "good" for each. Escalation triggers: the specific situations where this person must involve you, stated positively so everything else is theirs by default.

That last line is the whole design. A conventional job description lists what you may do, and everything unlisted belongs to somebody else. This one lists what you must escalate, and everything else is yours. Same document, opposite behaviour.

The rule that makes it stick: no job description is written for a role whose decisions have not been placed first. Otherwise you are back to building fences.

Execution: the rhythm is the system

These projects die in the rollout, not the design. Ninety days, in this order.

Weeks one to two: announce decision rights before roles. Circulate the decision map with limits, in writing. Do not wait for the full structure. The decisions are what people can act on immediately, and the early wins buy credibility for everything after.

Weeks two to twelve: install the rhythm. Three meetings, protected. A weekly project review that looks at status and margin together. A weekly handoff exception review, fifteen minutes, covering only what got stuck between functions and who owns unsticking it. A monthly pipeline and margin review. Visibility on a schedule replaces you chasing, and non-performance surfaces on its own, which is worth more than any evaluation framework you could buy.

Throughout: founder discipline. Two habits. When someone brings you a decision that is now theirs, answer with a question rather than an instruction: what would you do? Then let them do it. And keep a visible log of the decisions you have refused to take back. Your team is watching for the first reversal, and they will read one reversal as permission to stop.

Day ninety: rerun the map. Your first version was wrong somewhere. Some limits were too tight and created new queues; some were too loose and cost you money. Recount the ratio. This is also where OKRs and accountability structures start to earn their place, because goals only work when the people holding them can actually decide. Installed before ownership is real, an OKR cascade is a more elaborate way of reporting to the founder.

"My business isn't ready for this"

Two serious objections, both deserving a straight answer.

"At our size we genuinely need formal HR architecture." If you are at eighty to two hundred people, correct, and I am not arguing otherwise. Compensation bands, review cycles, a competency framework and a proper people function all become necessary at that scale, and running without them creates real problems in retention and fairness. The argument here is about sequence. Build the HR layer on top of a decision map and it encodes how the business actually runs. Build it first and you have documented a founder-dependent organisation in considerable detail, which is why so many of these exercises are completed, filed and never opened again.

"My team genuinely can't take these decisions." Sometimes true. The point of the diagnosis is that it proves this rather than assuming it. Run the map, hand over the decisions with limits, watch for two quarters. You will usually find that most people handle authority within stated boundaries better than expected, and that two or three genuinely cannot. That is a targeted hiring problem in a handful of roles, not a case for keeping every decision, and it is a much cheaper answer than a company-wide competency project.

Where the argument weakens: in a regulated environment, or a business where one bad call is unrecoverable, such as a compliance breach, a structural failure or a safety incident, the answer is tighter authority limits and stronger verification, not looser. Distribute the decisions that can be unwound. Keep the ones that cannot, and be explicit about which is which so nobody has to guess.

The document that actually describes your company

An org chart is a picture of who talks to whom. A decision map is a picture of who the business is when you are not in the room. Founders build the first, admire it, and wonder why the second didn't change.

Meera's complaint was never about the chart. She was telling Arjun that the thing she had been buying for six years, attention and judgement and someone willing to spend something to make her problem disappear, used to be available from one person and is now available from nobody. That is a fixable design fault, but only once you stop treating it as an attitude problem in your team and start treating it as an authority problem you created.

There is a simple place to start, and it needs no consultant, no framework and no budget. Open your calendar for the last fortnight and mark every meeting that existed because a decision needed you. That list is your founder dependency, in your own handwriting. It is also the only document in the company you can edit tomorrow morning.

About Premraj Menon

Premraj Menon is the founder of Simpleworks Consulting, working with MSME founders and growth-stage businesses across India to turn strategy into execution. With experience spanning manufacturing, SaaS, retail, and professional services, Prem brings a practitioner's eye to the problems most consultants only theorise about.

Ready to get the decisions off your desk?

Book a free first conversation with Premraj Menon →