The Decision Architecture That Scales

Two years into building Majhi Group, I had a team and a problem. The team was capable. The problem was that nothing moved without me. Not because people weren't empowered — I had told them they were empowered. But because the authority structure was entirely implicit, the criteria for decisions were in my head rather than written down, and the accountability for outcomes was diffuse in the way that most early-stage companies are diffuse.

I was the decision architecture. And I was the bottleneck.

The fix required understanding something that most founders learn slowly and often painfully: the transition from founder-as-operator to organisation-as-system is not a mindset shift. It is an engineering problem. You are designing a system that produces good decisions without requiring you at every node.

Why delegation alone doesn't solve it

The standard advice when a founder becomes a bottleneck is to delegate. Tell people they are empowered. Step back. Trust the team.

This advice is well-meaning and mostly ineffective, because it treats decision authority as a mindset rather than an architecture.

When authority is delegated without clarity — when "you're empowered" is the full instruction — people are left to infer what they can actually decide. And the rational response to ambiguous authority in most organisations is to escalate. The cost of making a decision you weren't authorised to make is higher than the cost of asking. So people ask. They ask up. And the founder who has nominally delegated finds that nothing has changed because the architecture hasn't changed.

Research by McKinsey on organisational decision-making found that 72% of senior executives reported that bad decisions were as common as good ones in their organisations — and that unclear roles and responsibilities for decisions was the most frequently cited cause. The problem is not a shortage of decision-making ability in organisations. It is a shortage of decision architecture.

The three components

Decision architecture that scales has three components. They need to be designed explicitly, not assumed.

Authority clarity. The first component is knowing, for each class of decision, who actually has the authority to make it. Not who has authority in theory — in theory most organisations have authority charts. Who has authority in practice: who decides when there is disagreement, whose sign-off is required for what, and who is not required in the room for a decision to be valid.

This sounds simple and is rarely done. Most companies have job descriptions that describe responsibilities, not decision authorities. The result is that authority is inferred from title, relationship, and seniority — which produces inconsistency, escalation, and the founder-as-bottleneck problem.

The tool that makes this explicit is a decision rights framework: for each major class of decision in the organisation, who recommends, who approves, who must be consulted, and who must be informed. Amazon implemented a version of this through "two-pizza teams" — small units with genuine authority over their domain, not requiring approval from adjacent teams for decisions within their scope. The architecture was the empowerment, not the speech about empowerment.

Decision criteria. The second component is the criteria by which decisions in each class should be made — written down rather than carried in the founder's head. This is where most delegation fails. The founder delegates the decision but not the criteria for the decision. The person who receives authority makes a different call than the founder would have made, not because they are wrong but because they are using different criteria. The founder overrides it. The delegation collapses.

When I built the quality framework for Majhi Group's search process — the criteria by which a candidate advances to shortlist, the standards a search must meet before an offer is recommended — I was not writing a checklist for its own sake. I was externalising the decision criteria from my head into a system. Anyone running a search can now make the same quality decision I would make, not because I've told them to trust their instincts, but because the criteria are written down and shared.

Accountability for outcomes. The third component is the hardest: genuine accountability attached to the authority. Authority without accountability is permission without consequence. It produces the worst of both worlds — decisions get made without the founder, but nobody owns the outcome, so the learning doesn't compound and the quality doesn't improve.

Accountability means the person who made the decision is the person who is evaluated on the outcome. Not who was in the room. Not who was technically responsible. Who decided, and what happened as a result.

The transition from founder-as-operator to organisation-as-system is not a mindset shift. It is an engineering problem. You are designing a system that produces good decisions without requiring you at every node.

The Majhi OS version of this problem

Building Majhi OS required solving this problem in software before I had to solve it in the human organisation.

The observability layer of Majhi OS monitors mandate health in real time. When a mandate starts degrading — response rates falling, pipeline slowing, recruiter load increasing — the system fires an alert. The question that then determines whether the system is useful or just noisy is: who acts on this alert, under what authority, and with what decision criteria?

If the answer is "whoever happens to see it" — no decision architecture. Alerts become background noise. Nothing recovers.

If the answer is "the alert surfaces to the recruiter, who has authority to adjust sourcing strategy within defined parameters; to the search lead, who has authority to change the search brief; to the client, who has authority to adjust the mandate scope" — decision architecture. The alert reaches the person with the right authority to take the right action.

The system is only as good as the decision architecture it operates within. This is true of every AI system and every management system. The technology surfaces the right information. The architecture determines whether the right person acts on it.

Reversible versus irreversible decisions

One of the most useful frameworks for distributing decision authority is the distinction between reversible and irreversible decisions.

Jeff Bezos articulated this as Type 1 and Type 2 decisions. Type 1 decisions are doors you can't walk back through — consequential, slow-moving, hard to reverse. They deserve careful process, senior involvement, and deliberate authority. Type 2 decisions are two-way doors — reversible, lower-stakes, fast to correct if wrong. They should be made as low in the organisation as possible, as fast as possible, with minimal escalation.

Most organisations have the decision architecture inverted: they apply slow, high-escalation processes to reversible decisions and make irreversible ones too quickly because nobody wants to own them. The result is an organisation that is simultaneously slow and reckless — slow on the small decisions that shouldn't need approval, reckless on the large ones that deserve it.

The framework for distributing authority should be built around this distinction. Reversible decisions should be pushed to the lowest level that has the relevant context. Irreversible decisions should have explicit authority assignment, written criteria, and real accountability. The two categories need different architectures.

Building it before you need it

The time to design decision architecture is not when the founder has become an obvious bottleneck. By then, the organisation has grown around the implicit architecture — roles have been shaped by it, relationships have compensated for it, and the structural redesign is disruptive rather than clean.

The time to design it is early, when the organisation is small enough that the design is simple and the cost of getting it wrong is low. The specific tools: a decision rights framework for major classes of decisions, written criteria for the classes of decisions that repeat, accountability assignment that makes the decision and the outcome visible to the same person.

Building both Majhi Group and Majhi OS from Odisha, without access to the management infrastructure that comes with being in a dense ecosystem of experienced operators, required making these things explicit earlier than most founders have to. There was no informal culture of distributed authority to absorb me into. I had to design it.

The result is not a bureaucracy. It is an organisation where the people in it know what they can decide, know how to decide it, and know they will be accountable for the outcome. That combination is what allows the organisation to move without the founder at every node.

That is what scaling actually requires. Not more delegation. A better architecture.

Sources

McKinsey — Decision-Making in the Age of Urgency

Harvard Business Review — Who Has the D? How Clear Decision Roles Enhance Organisational Performance

Jeff Bezos — 2016 Amazon Shareholder Letter: Type 1 and Type 2 Decisions