Centralize or Delegate

Idea one

The question is not which, but for what

Centralization is the decision to retain authority in one place rather than distribute it across the organization. It is usually spoken about as though it is either sensible discipline or needless bureaucracy. In reality, it can be both, depending on the decision.

It is useful when consistency matters, when the risk of a poor decision is high, when specialist knowledge is scarce, or when separate teams would otherwise make choices that damage the whole. It becomes damaging when decisions that could be made safely near the work are pulled upward simply because leaders are uncomfortable letting go.

So the central question is not "Should we centralize or delegate?" It is "Which decisions need central control, and which decisions are being slowed down without sufficient benefit?"

At Northstar, credit control is centralized for good reason. If every service manager could independently release goods to customers with overdue debt, the company could expose itself to serious losses. A manager facing an angry customer and a downed site might understandably prioritise restoring service. Finance sees a wider picture: payment history, total exposure, disputed invoices, patterns across accounts, cash-flow risk, and the precedent created by each exception.

Finance is therefore not merely being difficult when it controls credit holds. It is protecting a legitimate organizational interest that may be invisible from the customer site.

The same holds for safety standards, and for fairness — if every manager sets pay or handles discipline with no shared framework, employees receive very different treatment depending on whom they report to. The advantage of centralization is therefore not control for its own sake. It is coordinated judgement. A central team sees patterns individual teams cannot: several small exceptions creating a larger exposure, local requests that would produce incompatible systems, teams buying similar services at different prices. The centre adds value by connecting decisions that would otherwise appear separate.

Idea two

Not centralization. Centralization without a route.

Problems begin when the centre retains authority without providing the speed, clarity, or capacity that the work requires.

Northstar's urgent case showed it exactly. The site was down. The part was in the warehouse. The obstacle was the credit hold. Finance had a valid reason to control the release — but if the only route was a shared mailbox reviewed within one business day, then the control was badly designed for an urgent operational situation. The service manager was responsible for restoring the equipment. The account executive was managing the relationship. The warehouse supervisor was ready to act. Yet all of them had to wait because the authority to make one decision was held at a point too distant from the event.

The issue was not centralization alone. It was centralization without a workable service level, threshold, or emergency route.

And that distinction matters, because organizations usually respond to bottlenecks in one of two wrong ways. They see a central function slowing work and conclude that all decisions should be delegated — which creates inconsistency and uncontrolled risk. Or they see one poor local decision and conclude authority should be pulled back to the centre — which turns a single error into an approval process that burdens everyone. Neither response asks what actually happened.

A better review asks: what risk was the central control designed to manage? How often does this decision occur? What information is needed to make it well? How urgent is it in practice? Could a manager closer to the work decide safely within a defined boundary? What truly requires central approval? And what happens when the central decision-maker is unavailable?

These questions turn an argument about trust into a practical question of design.

Idea three

The right to know is not the right to decide

Centralization often becomes excessive because leaders confuse visibility with approval.

Priya, the Finance Director, may reasonably want to know when goods are released to customers carrying significant debt — whether exceptions are becoming more frequent, whether Sales is making promises that create credit risk, whether certain customers repeatedly rely on informal concessions. But she does not need to personally approve every urgent release in order to have that visibility.

If the finance manager can approve exceptions below a defined exposure threshold, with Sales accepting responsibility for commercial follow-up, Priya can receive a summary of those decisions. She can review the pattern, challenge weak practice, and change the policy. The operational decision moves in hours rather than waiting for a director who may be travelling or in another meeting.

This is one of the simplest ways to reduce bottlenecks: separate the right to know from the right to decide.

The same problem appears everywhere in senior management. A chief executive asks to be copied on an important customer issue. A director wants to see all proposed hires. A department head wants to approve every change in priorities. Each request may sound reasonable. Together, they teach managers that no meaningful action is complete until someone more senior has seen it.

Then a protective habit forms. People copy leaders in "for awareness." Leaders reply with a question or a suggestion. Others read the reply as an instruction. The decision is suspended until the leader confirms it. Nobody has formally changed the authority structure, but usable authority has moved upward.

Managers then wait for approvals senior leaders do not realise they are being asked to give. Leaders complain their inboxes are full of detail. Employees complain nothing can be decided without escalation. This is not a sign that the organization lacks talented people. It is a sign that it has made senior attention the scarce resource through which too much work must pass.

A bottleneck is not always a person who refuses to act. Often, it is a person who has become the required participant in too many decisions. And it repeats at every level — the service manager waits for Finance, engineers wait for the service manager, new starters wait for colleagues who know the informal rules, the customer waits for all of them. The published org chart may show a sensible reporting structure. The real org chart shows a chain of waiting.

Idea four

Distance, and the manager who becomes a messenger

Centralization has another cost: distance from the information needed to make a good decision. The person at the centre may have wider perspective and lack local context. A central scheduling team may optimise engineer utilisation and not know that a site requires a specific qualification, has limited access hours, or is already frustrated by missed appointments. A central product team may set priorities from aggregate data, while support advisers hear the practical consequences of a portal failure every day. Neither view is sufficient on its own.

The danger arises when central authority treats local knowledge as anecdotal or inconvenient. People closest to the work then stop contributing their judgement. They send requests upward, wait for the answer, and follow it even when they can see that it does not fit the situation. That creates the appearance of compliance while weakening the organization's ability to respond intelligently.

Good centralization does not silence local knowledge. It creates a route for that knowledge to shape the decision. A central call on the portal fix may be right — the fix affects a shared system and competes with other work — but the decision will be poor if Product and Technology treat Support merely as a source of complaints rather than a source of operational evidence. The centre should gather the wider picture, not replace it.

There is a human cost too. Managers repeatedly denied the ability to make reasonable decisions begin to behave like messengers. They carry requests upward and answers downward. Their teams still call them managers, and much of the role becomes administrative transmission.

It is worst for someone promoted from an operational role. They are told they own customer delivery or service quality, then discover that every meaningful lever sits elsewhere. They become responsible for explaining delays they did not create. Over time this makes managers cautious and dependent — and makes senior leaders believe those managers lack initiative, when in fact they have learned the organization's real rule: independent decisions are more likely to be questioned than escalated decisions.

Idea five

Deliberate, limited, reliable

Centralization works best when it is deliberate, limited, and reliable. Deliberate means authority is held centrally for a stated reason: risk, consistency, scarce expertise, legal obligation, or an enterprise-wide trade-off. Limited means the centre does not retain decisions simply because it always has, or because leaders prefer to be involved. Reliable means that when a central decision is needed, people know where to take it, what information is required, how quickly an answer will come, and who can act when the usual decision-maker is unavailable.

Delegation is the other side of it — placing a decision with someone who has the information and proximity to act without waiting. Done well it shortens the path between noticing a problem and responding to it. Done badly it creates inconsistency, unmanaged risk, and a different kind of delay: work moves quickly at first, then returns later as rework, dispute, customer harm, or a senior intervention. Delegation is therefore not the opposite of control. It is a choice about where control should sit.

And the boundary is what makes delegation safe. A weak form sounds like "use your judgement." That helps when a manager has already established the purpose, standards, limits and escalation route. On its own it leaves people exposed. What judgement? What cost is acceptable? Which promise can they make? When should they stop and ask?

Without answers, people go to one of two extremes. Some become overly cautious, escalating decisions they could probably make because they do not want to be blamed — the organization believes it has delegated and nothing has changed. Others act too freely, reading broad language as permission, making an exception without understanding the precedent it creates. Neither outcome is a failure of character. It is a failure to define the decision properly.

Useful delegation states the outcome, the decision, the limits, and the point of return. The engineer may extend a repair visit by up to two hours where necessary to restore equipment safely, within existing technical standards, provided it needs no credit-hold exception, non-standard spend or change to a contractual commitment — recording the reason, updating the customer, and notifying the team lead if it affects another appointment.

Then test the whole design against one question. What would happen if the usual experienced person were absent? An experienced service manager knows to call the finance manager directly, knows what evidence Finance needs, knows how to reach Daniel. That knowledge is valuable. It should not be the operating model. If a newly promoted manager cannot follow the same route without relying on personal favours, the organization has not found a balance — it has created an exception process that works only for insiders. A good design allows people to use judgement without requiring them to discover the organization's hidden network under pressure.