Architecture Test for Growing Organisations
- Amrita Mazumdar
- Jul 9
- 9 min read
~ before you add another layer
There is a moment that repeats itself in almost every growing organisation. Something isn't working. A handoff is slipping, a decision is stuck, a function feels overwhelmed. And in that moment, a familiar instinct takes over: someone needs to own this.
In a hiring boom, this instinct shows up as a role. In the present environment, where almost no one is in a hurry to hire, it shows up in different ways:
A title gets upgraded without any real change in what the person is resourced to do.
A sign-off gets added to a process that was already complex.
A decision that one person used to make now needs three people to nod at it, including a 5 mins with Finance.
The organisation chart doesn't necessarily grow a new box — but it grows heavier all the same. And everyone moves on, relieved that the problem has been "addressed."
Three months later, a similar problem shows up somewhere else.
This is not a story about bad decisions. The leaders making these calls are usually experienced, thoughtful and genuinely trying to solve something real. The instinct to add structure when something breaks is commonsensical — it is often the fastest available response, and in the middle of a growth phase, speed matters. But fast is not the same as accurate. And an organisation that keeps adding layers without asking what those layers are actually for eventually finds itself with more structure but less clarity.
What Counts as a Layer
Before going further, it's worth being precise about what "layer" means here, because the word does a lot of work in this article.
A layer is any addition of structure made in response to a problem — a new role, a new manager, a new sign-off or approval step, a new committee, a requirement that a decision now be made jointly rather than by one clear owner, or a title change that alters who reports to whom. It is not only a new box on the org chart. A layer can be as small as one extra person needing to nod before a decision moves forward.
The distinction that matters is not size, or form but origin: structure that was designed deliberately, in advance, as the organisation scaled, is simply good architecture. Structure that gets bolted on reactively, the moment something breaks, without anyone asking why the current organisation couldn't handle it — that is the layer this article is concerned with.
The Question Underneath the Question
When a new organisational challenge appears, most leaders instinctively ask:
"Who should own this?"
It's a reasonable question. It's also the wrong first question, because it assumes the answer is structural before the problem has been understood. "Who should own this" almost always resolves into some version of another role, another manager, another approval point, another meeting, another reporting line. The organisation absorbs complexity by adding more organisation.
A better first question is:
"Why can't the organisation handle this today?"
This question doesn't assume the answer is a new layer. It asks the leader to sit with the problem long enough to understand its actual shape before reaching for a structural fix. Sometimes that diagnosis will still lead to a new role — and when it does, the role will be built on a real understanding of what it needs to do, rather than a general sense that "someone" should be watching this. Often, the diagnosis leads somewhere else entirely.
This is not a new philosophy so much as a discipline. It is the difference between an organisation that reacts to complexity and one that reads it.
Structure Should Support Capability, Not Compensate for Its Absence
This is not a case against hierarchy. It is not a case against management, governance or accountability. Growing organisations need all of these — arguably need them more, not less, as they scale past the point where informal coordination and personal relationships can hold everything together. An organisation of 200 people cannot run the way an organisation of 25 people did, and pretending otherwise is its own kind of failure.
The question was never should organisations have layers. Of course they should. The question is narrower and more useful: is this particular layer solving the real problem, or is it standing in for a problem that hasn't been named yet?
Structure exists to support capability that already exists, or capability that is being deliberately built. It is not a substitute for capability that is missing. The org chart may look more mature, but the underlying constraint remains exactly where it was.
How Layers Accumulate
For a large number of Indian MSMEs, this instinct rarely takes the form of a hiring decision at all. Hiring is expensive, funding is tight, and every headcount is weighed against a corpus that doesn't stretch as far as it used to. So the layer-adding reflex finds other outlets.
Much of the day-to-day in these organisations runs on jugaad — people moving fluidly between whatever needs doing between 9:00 am and 7:00 pm, picking things up because they're capable and present, not because a document says it's theirs. This isn't a character flaw. It's what resourcefulness looks like when it has to substitute for structure.
But over time, that same fluidity has a cost. When ownership is a matter of who happened to be free rather than who is accountable, confidence erodes quietly. A founder or leader stops fully trusting that any one person owns a function cleanly — because, in practice, no one ever fully has. And the response to that discomfort is rarely "let's hire someone to own this properly." It's smaller and more familiar: add a review step, loop the founder in, make it a joint call. Accountability gets diluted across more people, or matrixed across more sign-offs, in the hope that more eyes will catch what one clear owner should have caught in the first place.
This is still the same instinct the rest of this article is describing. It's just wearing a different, more budget-conscious costume. A new sign-off is a layer. A joint decision where one owner would do is a layer. And it deserves the same diagnostic scrutiny as a new managerial hire would.
The Architecture Test for Growing Organisations
When a new challenge surfaces, before concluding that the answer is a new layer, it helps to ask four questions in sequence. Together, they form what we call the Architecture Test.
1. Is this a Capacity problem?
The test: would more of the same people, doing the same work in the same way, clear this?
If yes, it's Capacity.
Has demand genuinely outgrown the people currently doing the work? Not "does this team feel busy" — busyness is a poor diagnostic on its own — but has the volume of work crossed a real threshold that existing people cannot absorb regardless of how well they are organised.
In the current climate, few leaders reach for this answer casually — cash is watched too closely for that. Which is, in its own way, useful discipline: it means capacity claims tend to be tested rather than assumed.
If the answer genuinely is yes, more hands may be warranted. But it's worth confirming that the constraint is really volume of work, and not one of the three questions that follow.
--------
2. Is this a Capability problem?
The test: if we added more people with the same skill level, would the problem persist? I
f yes, it's not Capacity — it's Capability.
Do the people already doing this work have the skill, experience or confidence the challenge now requires?
Growth often changes the nature of a role faster than the person in it has had time to grow.
A team that managed fine at one scale may simply not yet have the judgment the next scale demands. This is not solved by adding more people with the same gaps, and it is not solved by a new layer of oversight either.
It is solved by building capability directly: training, mentoring, or in some cases, bringing in someone whose expertise fills the gap, rather than someone who supervises the gap from above.
--------
3. Is this a Clarity problem?
The test: if we asked five people who owns this, would we get five different answers?
If yes, it's Clarity.
Are roles, ownership and decision rights actually unclear?
A great deal of what looks like an organisational failure is, on closer inspection, an ambiguity failure:
Two people believe a decision belongs to the other. A process has no clearly designated owner, so it drifts until something breaks and someone finally steps in. This is often the truest diagnosis in organisations where the job description was written once and never revisited, or never written at all — ownership exists in practice, not on paper, and it shifts depending on who was available that week. In these cases, the fix is not a new sign-off or a joint decision sitting above the confusion — it's naming the confusion and resolving it directly.
Adding a layer here, whether that's a manager, a review step or a second approver, often makes things worse.
It gives the organisation a new place to defer ownership, and it lets low confidence in any single owner harden into a permanent habit of diluted or matrixed accountability, rather than forcing one person to actually claim the decision.
--------
4. Is this a Coordination problem?
The test: does the problem live at the boundary between functions, rather than inside any one of them?
If yes, it's Coordination.
Are the processes and interactions between functions creating friction that has nothing to do with any individual's skill or clarity of role?
Sometimes every person involved is capable and clear on their remit, and the problem still persists because the handoffs between them were never designed.
This is often mistaken for a people problem when it is, in fact, a process and governance problem — better addressed through clearer workflows, forums or decision protocols than through adding a person whose job is to sit between two functions and translate.
--------
Only once these four questions have genuinely been explored — not rushed through, but sat with — does it make sense to ask whether a new layer is warranted. Sometimes it still is. An organisation that has outgrown its span of control, or crossed into genuinely new complexity, may need a new managerial layer, and there is nothing wrong with building one deliberately. The difference is that this layer will be built with a clear brief, because the leader knows exactly what problem it exists to solve.
Reading the Signal, Not Just Responding to It
This connects to something we've touched on before in other writings. Growth creates complexity. That complexity often shows up as decision bottlenecks — the wrong things escalating, the right things stalling. And not every decision that reaches a leader's desk actually deserves to be there.
The Architecture Test extends that thinking one step further. It's not only about which decisions should be escalated and which shouldn't — it's about what an organisation does when a new kind of problem appears that its current structure wasn't built to handle. The instinct to add a layer is, in a sense, an escalation instinct at the structural level. It says: this is bigger than us, so let's build something above it. Sometimes that's right. Often, the organisation already has what it needs — it just hasn't been asked to use it clearly.
Organisational architecture, in the end, is what determines how much complexity a business can absorb before it starts to buckle. A well-designed structure doesn't eliminate complexity — no structure does. It determines whether that complexity gets processed intelligently, at the right level, by people equipped to handle it — or whether it simply gets pushed upward, layer by layer, until the organisation is heavy with structure and still short on clarity.
The Difference That Shows Up Later
Every founder running a growing organisation meets this moment repeatedly — a new challenge, and underneath it, an unspoken choice: build something, or understand something first. Most founders feel it the moment a problem lands on their desk, often before they've consciously named what they're deciding.
What separates organisations isn't whether the founder has a framework for this moment. It's what they were already reaching for before the framework mattered. Some reach for the fast fix — a sign-off, a joint call, a bigger title — and it looks entirely reasonable in the moment, because it usually is a reasonable response to the immediate problem. The cost doesn't show up right away. It shows up later, when someone new tries to work out who actually owns what, or when the org chart is finally audited and turns out to be answering questions nobody's asking anymore.
Others keep returning to the same quieter question — "Why can't the organisation handle this today?" — and are willing to sit with an answer that isn't the fast one. Not because they're more disciplined by nature, but because they've noticed what the shortcut costs them further down the line, and have decided the pause is worth it.
That's really the whole distinction this piece is making. Not a rule. Not a checklist. Just the difference between a layer that answers a question someone actually asked, and one standing in for a question nobody stopped to ask at all.
Comments