When Your Decision System Holds You Back
How to Move from Bottlenecks and Politics to Clear Ownership and Faster Decisions
We architect systems deliberately.
But we often let the decision-making architecture emerge by accident.
Have you ever felt that the way decisions are made in your company is slowing your work down?
Or that the tech debt you’re paying for today is really the result of yesterday’s decision-making problems?
Maybe the wrong people made the call.
Maybe not all the data and constraints were on the table.
Maybe the people closest to the problem were never asked.
One of the biggest success factors for a company is its organisational model.
And I don’t mean job titles and reporting lines. I mean the decision-making structure: who decides what, based on which input, and how those decisions flow through the organisation.
You can think of this as a system: ideas pop up from teams, leaders, customers. They flow through the organisation, and some of them eventually become decisions that are executed.
But on their way to execution, things can go wrong:
Bottlenecks – everything has to pass through one or two people.
Good ideas get blocked because they land in the wrong forum or never reach the right owner.
Bad ideas get promoted and prioritised without solid data or reasoning.
Too many ideas are accepted without structure, and the product slowly turns into a mess.
If you don’t design this decision system deliberately, it will design itself. And you probably won’t like the result.
Examples of Immature Decision Design
Let’s dive into a few classical examples that point to a low maturity of the decision making system.
Example 1 – When one person becomes the decision bottleneck
In a young company, having one strong person at the centre of decisions can work surprisingly well.
Often that person is the CEO or CTO. Sometimes it’s a highly trusted senior engineer or other “glue person” who’s been around forever and seems to know everything.
They know the product inside out. They sat with the first customers. They remember every shortcut and trade-off made along the way. At that stage, routing major decisions through them is often the fastest and safest way to move.
The problem is that many organisations keep this decision pattern long after they’ve outgrown it.
The consequences:
Decisions slow down.
Teams are ready to move, but the next available slot in this person’s calendar is in a week or two.Decisions are made too far from the details.
When every big choice is compressed into a short call or a couple of slides, a lot of nuance gets lost: edge cases, UX details, operational constraints. The decision might be directionally sensible, but misaligned with the messy reality of how the product behaves today and how the teams actually work.Teams stop feeling real ownership.
Once the pattern is established, people eitherrelax, because “someone else is carrying the load”, or
get frustrated that “someone else is making the decision for us”. They might tweak slides to “sell” their story, or quietly give up on what they believe is right and fall back on: “We just follow a given direction.”
This is a decision-making system that was never designed for scale – one that still assumes a single person can and should sit in the middle of everything.
Example 2 – When no one owns a domain end to end
Another common pattern: many people shape a critical domain, but no one owns it end to end.
This domain might be the overall product experience, the overall product architecture, or a key product capability (onboarding, billing, search, integrations, etc.).
Different parts of the organisation drive different changes:
Commercial teams push for features to close key deals.
Operations pushes for changes to reduce manual work.
Engineering pushes for refactors, performance and reliability.
Each initiative is valid. And each group has enough influence to get some of their needs into the roadmap. What’s missing is a clear owner of the domain as a whole – someone whose primary responsibility is to ask:
“How do all these changes fit together into one coherent system or experience?”
When everyone is pulling hard on their part of the rope, with no end-to-end owner for the domain, the overall direction is accidental.
Over time, you see the consequences:
Product complexity. The product gets cluttered - user experience confusing, technical complexity increased with special cases or “just this once” hacks.
Roadmap by negotiation. Priorities are set through escalation and negotiation. If you put all ongoing activities next to each other, you’d struggle to explain why some of them made it through as top priority or how they connect to company goals.
No coherent “no”. Nobody is clearly mandated to say: “This request makes sense locally, but it weakens the product or system overall”.
The result is a gradual drift away from a sharp value proposition and a clear architecture, towards a product that reflects internal politics more than user needs.
Example 3 – When roles overlap and nobody is clearly accountable
Another common pattern is when leaders have overlapping scope.
On the org chart, it looks mature and well-structured – roles like Head of Platform and Head of Architecture, or Group Lead and Head of X.
But when their responsibilities aren’t sharply defined, the day-to-day reality gets inefficient very quickly.
Alignment overhead increases. People add more syncs: 1:1s, pre-meetings, “quick catch-ups”.
Double work or no work. Two people are writing their own strategy, principles or roadmap, or proposal, and then have to merge them afterwards. Other times, each assumes the other will take the lead on a tricky decision, so nothing happens until someone escalates.
Teams get stuck in ambiguity. When roles overlap, teams are never quite sure whose call it really is. So they start to: check decisions with both leaders “just to be safe”. They spend more energy navigating opinions and less energy on moving the work forward.
This is what happens when we create titles without clear decision rights.
It doesn’t create a big chaos, but it does reduce effectiveness and slows delivery down.
Principles to Design Your Decision-Making Architecture
All these examples share the same root cause: ownership and decision rights were never deliberately designed.
Don’t let your decision system “just happen” - you probably won’t like the result.
Instead, treat decision-making as part of your architecture: something you can design, test, and improve.
Once you look at it that way, a few simple principles can help you put the right setup in place.
Principle 1 – One strategy, one owner
For every important area, there should be one clearly named person who owns the strategy and how decisions are made in that area.
But:
One owner does not mean one person decides everything.
It means one person is accountable for the decision system in that domain.
Their job is to:
Set direction and constraints.
Decide which decisions are delegated and to whom.
Step in when there’s conflict or ambiguity.
When you don’t have one owner, you get “everyone influences, nobody owns”.
When the owner decides everything, you get a bottleneck.
Principle 2 – Push decisions to the lowest level with enough context
Good decision architecture follows a simple rule:
Leaders define direction and rules.
Teams decide how to get there.
Decisions should live where:
The information is richest (close to users, systems, incidents).
The consequences are felt (by the people who build and run the product).
Leaders and domain owners should be asking:
Which decisions must stay at my level?
Which decisions can teams make on their own?
Do they have the right business information and context to make that call?
If small UX choices, tech approaches, and team-level prioritisation still routinely go to the CEO/CTO/board, you don’t have strong governance – you have a centralised anti-pattern.
Principle 3 – Clear boundaries of responsibilities
“Shared ownership” sounds healthy.
In practice, shared ownership without clear boundaries usually becomes blurred accountability.
You want statements like:
“You own this domain; I own that one.”
“You decide implementation; I decide which problem we solve first.”
“You own reliability for this surface; I own scope and timelines.”
If you ask, “Who decides when you disagree?” and people hesitate, your boundary isn’t real.
Double work, and “we thought the other person would lead this” are all symptoms of ignoring this principle.
Principle 4 – Treat important things as components with owners and metrics
Some parts of your product and organisation are critical or chronically painful.
If something is important, repeatedly painful, and measurable, consider treating it as a separate component.
That means:
Give it a clear boundary – what’s inside, what’s outside.
Assign one strategy owner.
Define a small set of success metrics.
For example, “Customer data integration” for new clients. Instead of being everyone’s problem (sales, implementation, ops, backend), you treat it as a component:
Set one owner accountable for the end-to-end integration experience.
Set metrics like time-to-first-sync or number of one-off scripts to show measurable progress.
You can apply the same thinking to other domains that you find business critical.
Principle 5 – One owner, many deciders, shared principles
You don’t want either extreme:
Centralised decision making: one person decides everything.
Chaotic decision making: everyone decides everything.
The middle ground:
One owner for the strategy and decision system.
Many people making decisions locally.
All using the same principles.
Those shared principles can be, for example:
Product principles – who we build for, how we want the product to feel, what we won’t do even if asked.
Architecture principles – how systems interact, expected uptime and reliability, how configurable or bespoke the system is allowed to become.
Over time, these principles become part of how people think – ground rules that teams follow almost intuitively when they decide what to do next.
Principle 6 – Make important decisions visible
Invisible decisions are a source of rework or blame.
You don’t need heavy process, but you do need a habit.
For meaningful decisions, capture briefly:
What we decided.
The key options we considered.
Who decided and who was consulted.
What we’re trading off.
You create a “log” for the decision thinking, so you can later see patterns and refactor how decisions are made.
5. Where to Start: Refactor Your Decision-Making System
You don’t need to fix decision-making with a big-bang reorganisation.
You fix it the same way you fix a complex system: find one painful area, change how it works, learn and repeat.
Here are some tips on how to start.
Pick one domain
Pick one domain that you find important or where you observe a continuous pain. For example:
A part of the product where development feels slow.
A new capability (onboarding, billing, integrations) that is cluttered and confusing.
A platform or architectural area where everyone has opinions and complains.
Do a quick decision audit
For the last 2–3 months in that domain, ask:
What were the 3–5 biggest decisions?
Who actually made them? How did they get there? (escalation, board meeting, data …)
Which ones went well, and which felt painful, slow or frustrating for the team?
Were there hidden, conflicting principles at play (“move fast” vs “minimise risk”) that nobody named explicitly?
Apply “one strategy, one owner”
Appoint one owner for that domain.
Make it explicit that their job is to:
Own the strategy and direction for that domain.
Design the decision system: who decides what, and where.
Define metrics that person is responsible to drive.
Write it down in one or two sentences so everyone understands it.
Decide which decisions move down
With that owner and the core team for the domain, walk through:
Which decisions genuinely belong with the owner? For example, big trade-offs, cross-team conflicts, major bets.
Which decisions should we move down to teams? For example, implementation, UX details, local prioritisation, experiments.
Check if teams have enough context and information to own those decisions.
If not, fix that: share metrics, strategy, or any business constraints.
Set a few principles as guardrails
Co-create a small set of domain principles.
For example: “We optimise for user experience. Clear, intuitive design is our differentiator, even if it costs us extra effort in implementation.”
In exceptional situations, you might need to break a principle – but that should feel exceptional: the owner is consulted, or the decision is clearly logged as a conscious deviation.
A simple test: If people can’t use these principles to make everyday decisions without asking for permission, they’re too vague.
Tighten, clarify, and iterate until teams can confidently decide and still stay inside the guardrails.
Make it visible
Create a one-pager for the domain. Summarise important points like:
Domain name
Owner
Key teams involved
Main decision boundaries (owner vs teams)
3–5 principles
Key metrics (if relevant)
Share it on Confluence. Point to it in meetings. Use it when someone asks “who should decide this?”.
Add light decision logging
Capture the key decisions in 1–2 short paragraphs each: what we decided, why, who decided, and what we traded off.
Then, every now and then, review these with the owner and the teams:
Are we escalating the right things?
Are the principles actually helping teams decide on their own?
Are we still too centralised, or drifting back into chaos?
If the logs turn out to be useful, keep the habit.
If they’re not adding value, change the format or frequency—but don’t go back to a world where important decisions leave no trace at all.
Closing Thoughts
You can’t scale your organisation on the same decision system you designed for Day 1.
If you let your decision system “just happen”, it will – but you probably won’t like the result.
Ask yourself:
Have we designed a decision-making system that matches our size, strategy, and reality?
If not, start where the pain is highest – the overloaded executive, the incohesive product area, the overlapping roles – and begin to redesign your decision-making architecture iteratively and deliberately, one step at a time.
Enjoyed this Article?
Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Insights, strategies, and actionable tips—delivered straight to your inbox.
👉 If you found this useful, you might also enjoy my other articles on leadership, product strategy, and team dynamics:
