Centralized vs. Decentralized Decision Making
This gets debated as a philosophy — are we a company that trusts people, or a company that maintains standards — and framed that way it is unresolvable, because both sides are describing something real. The framing is the problem. Centralisation is not a company-wide value; it is a setting you choose per class of decision, and there are three variables that determine the right setting. A company that gets this right is highly decentralised on most things and tightly centralised on a few, and can explain exactly why for each.
What’s inside
It is per-decision, not per-company
The three variables
What each mode costs you
The standard mistake in each direction
Prerequisites for decentralising
How to change the setting
Where Blomma fits
It is per-decision, not per-company
The philosophical version of this debate produces slogans and no decisions. “We push decisions to the edges” is a good sentence and it does not tell anyone whether a support lead can issue a refund above a threshold, or whether a team can pick its own database.
The useful version is a list. For each class of decision, where does it get made? Pricing exceptions under ten percent: the account owner. Above ten percent: the commercial lead. Database choice: the team, within an approved set. Adding a new language to the stack: central. Hiring within an approved headcount: the manager. Above it: the exec team.
Once framed that way, the question stops being ideological and becomes analytical, which means it can be settled and written down. It also stops producing the specific dysfunction where a company describes itself as decentralised while everyone knows the founder decides everything that matters — which costs more credibility than honest centralisation would.
The three variables
Three inputs determine where a decision belongs. Run them on any decision class and the answer is usually obvious.
Reversibility.How hard is it to undo? A pricing experiment on one segment is reversible in a month. A platform migration, a market entry, or a senior hire is not. Reversible decisions should be decentralised almost regardless of the other variables, because the cost of a wrong call is bounded and the cost of the delay is not.
Information locality.Where does the information needed to decide well actually live? If it lives with the team — customer context, technical detail, what was tried last quarter — centralising means deciding with worse information, which is the most common and least discussed cost of centralisation. If the information is company-level — cash position, strategic sequencing, what the board has been told — it must be central, or the decision is made blind.
Consistency requirement.Does it matter that this is decided the same way everywhere? Pricing, brand voice, security standards, employment terms, and metric definitions usually do. Tooling choices, meeting formats, and most technical decisions inside a boundary usually do not. Where consistency matters, central wins even if the other two variables argue otherwise.
Most decisions score clearly. Where they conflict — reversible but consistency-sensitive, for instance — the resolution is usually a bounded delegation: the team decides within a framework someone central sets.
What each mode costs you
Both modes have real costs, and pretending otherwise is why these debates go badly.
Centralisation costs speed and information quality.Every centralised decision adds a queue and a context transfer. It also means the decision is made by someone further from the facts, which is a quality cost that founders systematically underestimate because they do not see the decisions they got wrong from a distance. And it degrades the people below: a manager who does not decide does not develop judgment, so you get a layer of coordinators rather than leaders — and then conclude that your managers are not strategic.
Decentralisation costs consistency and occasionally produces bad calls.Six teams will make six different choices, some worse than a central call would have been. Standards drift. Duplicated effort appears. And you will personally see the failures, vividly, while the successes look like nothing happening — which is the asymmetry that pulls companies back toward centralisation after any visible mistake.
The honest position: you are choosing which failure mode you prefer for each class of decision. Say that out loud when you set the rules, because a company that thinks it can have speed, information quality, and perfect consistency will keep oscillating.
The standard mistake in each direction
Over-centralising in response to one bad decision.Something goes wrong at the edge, and the response is to require approval for that whole class of decision going forward. It feels prudent, and the cost is permanent while the incident was one-off. Worse, the message received is broader than intended: people learn that autonomy is conditional on nothing going wrong, so they stop exercising it generally. One over-correction can centralise a company more than a policy would.
Decentralising without the prerequisites.Announcing autonomy without giving people the context, the framework, or the tolerance for mistakes. What follows is either paralysis — nobody uses the authority because they cannot tell what good looks like — or a set of poor decisions that get used as evidence against decentralisation. The autonomy was nominal, and the failure gets attributed to the people.
Both mistakes come from treating this as a stance rather than a design. A stance flips in response to the last thing that happened. A design changes when the variables change.
Prerequisites for decentralising
Autonomy is not free to grant. Four things have to be in place or the delegation is nominal.
Context.People cannot make good company-level trade-offs on functional information. Decentralising requires sharing the real numbers, the strategy and its reasoning, and the constraints. Founders who withhold context and then complain their teams make parochial decisions have described a situation they created.
A framework, not just permission.“You decide” is insufficient. “You decide, within these bounds, optimising for this” is actionable. The bounds are what make real autonomy inside them possible.
Demonstrated tolerance for reversible mistakes.This one is behavioural and it takes months to establish. If a reversible decision that went badly resulted in the authority being withdrawn, you have taught the organisation that speed is punished. People go by evidence, not announcements.
Someone with the judgment to decide.If the person you are delegating to has never made this class of call, they need support — pairing, a review of the reasoning, coaching. Delegating to an unprepared person and calling the result evidence about decentralisation is a common and unfair pattern.
How to change the setting
Changing where decisions live is a real change and it deserves the same care as a restructure.
Do it explicitly, one class of decision at a time, in writing. “From now on, refunds up to X are decided by the account owner, no approval” is a change people can act on. A general exhortation to move faster is not.
Name what you are accepting. If you are decentralising pricing exceptions, you are accepting some inconsistency and occasional bad calls in exchange for speed. Saying so protects the change from the first mistake.
Then hold it through the first failure. That moment is the entire test. The first time a decentralised call goes visibly wrong and you respond by asking what they learned rather than reclaiming the authority, you have changed how your company operates more than any policy document would.
And review the settings at each stage change. A decision that belonged central at forty people frequently belongs at the edge at a hundred and fifty, because the information has moved.
Where Blomma fits
The difficult part of this is not the framework. It is that two of the prerequisites depend on your own behaviour — sharing context you may be inclined to hold, and tolerating a reversible mistake without reclaiming authority. Both are hard to assess in yourself, and the people best placed to tell you how you actually behave in those moments report to you.
Blomma is an always-on AI career coach with no stake in your company. Use it to run the three-variable test on the decisions currently sitting with you, and find the two or three that are reversible, information-local, and not consistency-sensitive — those are your immediate wins. Use it to write the framework rather than just the permission. And use it in the moment that decides whether any of this holds: the first time a decision you pushed down comes back worse than yours would have been, and every instinct says take it back. Where the situation warrants a human who has designed at your stage, bring one in.
The second application: the people you are handing decisions to are building judgment they have not needed before. Coaching that does not depend on their manager’s calendar having room is how that judgment develops fast enough to justify the delegation..
Centralised or decentralised is not who you are as a company. It is a setting, per decision, with three inputs — and the companies that are genuinely fast have simply been explicit about it.