Your job is to create better decision-makers

The more senior you become, the easier it is to confuse being needed with being effective. Experience gives you pattern recognition, so you can often see the trade-off faster, recognise where the risk is hiding, or spot the decision a team is avoiding. When somebody brings you a problem, giving them the answer can feel like the most useful thing you can do, and in the moment it often is. The problem appears when that behaviour becomes the system.

If important decisions repeatedly travel to the most senior person in the room, the organisation may still make good decisions, but it has not necessarily built good decision-making capability. Teams learn to bring ambiguity upwards, leaders accumulate context that nobody else has, and work slows whenever the right person is unavailable. Eventually, the organisation becomes dependent on exactly the leadership behaviour it describes as a bottleneck.

I explored the consequence of that in Why organisations stay broken. When every meaningful decision still needs permission, scaling starts to become an illusion because the org chart gets bigger while authority remains concentrated in roughly the same place.

Series 3 is about the alternative. Article 1 argued that strong Engineering, Product and Design functions are not enough on their own because better product organisations also need a stronger system between them. The same principle applies inside teams. It is not enough to hire capable people and tell them they are empowered. Leaders have to design the conditions that allow good judgement to spread.

For me, that changes the leadership job. The goal is not to make every important decision well yourself. It is to increase the number of people in the organisation who are capable of making good decisions without you.

Better decisions start with better context

We talk a lot about autonomy, but I think we often start at the wrong end of the problem. Teams cannot make strong decisions with context they do not have.

A team may know what it has been asked to deliver, the date it needs to hit and the metric attached to the work, while still knowing surprisingly little about why the initiative matters. They may not understand the commercial pressure behind it, what customers are actually struggling with, what evidence changed the organisation’s mind, which constraints are genuinely fixed, or which assumptions are still open to challenge. We then ask them to take ownership of the outcome.

That is not really autonomy. It is often just decentralised execution.

A better organisation treats context as something that needs to be deliberately distributed. Teams should understand the customer problem, the business intent, the evidence available, the strategic connection and the constraints surrounding the work. They also need to understand which parts are unresolved, because being given a polished brief that hides all uncertainty is another way of removing judgement from the team.

This is where leadership can unintentionally make teams weaker. Senior leaders absorb enormous amounts of context through planning meetings, customer conversations, commercial discussions and decisions that happened months earlier. By the time work reaches a team, much of that context has been compressed into a roadmap item or a sentence explaining what needs to ship. The team inherits the decision without inheriting the reasoning.

A better approach is to transfer the reasoning as well.

What this looks like:A team starting a payroll onboarding initiative receives the customer problem, business outcome, known research, support signals, regulatory constraints and the assumptions that are still unresolved. It is not handed a predetermined flow to execute. The team has enough context to challenge the proposed approach while still understanding what must remain true.

The value is not more documentation. The value is giving people enough information to exercise judgement.

Principles scale better than approvals

One of the easiest ways for an organisation to become dependent on senior people is to keep solving the same type of problem as though it were new.

A quality compromise appears and the Design leader is asked whether it is acceptable. A technical trade-off appears and Engineering leadership is pulled in. A roadmap decision changes and a Product leader needs to approve it. Each intervention may be sensible, but if the same class of decision keeps returning to the same people, the organisation has learned very little from the previous one.

This is where principles become useful. Good principles are not slogans. They capture judgement that would otherwise remain trapped in individual leaders.

If the organisation repeatedly debates when experience debt is acceptable, it should develop a shared view of what makes that debt tolerable and what makes it dangerous. If teams repeatedly ask whether research is necessary before shipping, there should be some shared logic for the level of evidence required depending on risk and reversibility. If every project debates what can be sacrificed when a deadline tightens, the organisation should already have principles for how those trade-offs are made.

The aim is not to replace judgement with rules. It is to give judgement something reusable to work from.

That matters because most organisations cannot scale by adding an approval layer every time complexity increases. At some point, the decision needs to become easier to make without the person who previously made it.

What this looks like:Instead of asking a Design leader to approve every experience compromise, the team has a shared principle that allows reversible simplification when the core task remains clear, but requires broader review when the compromise affects trust, compliance or a repeated pattern across the product. The team still exercises judgement, but it is no longer starting from zero.

A principle is useful when it reduces the number of decisions that need to travel upwards without pretending that every situation is identical.

Decision rights need boundaries, not slogans

“Empower the team” is one of those phrases almost everyone agrees with and very few organisations define.

The problem is that authority is not binary. Teams should not make every decision independently, and leaders should not make every important decision centrally. The useful question is where the boundary sits, and that boundary needs to be designed.

A team should know which decisions it owns, which ones require alignment because they affect another team or shared system, and which ones genuinely need escalation because the consequences extend beyond the group. When those boundaries are unclear, escalation becomes a form of self-protection. People ask for approval because they do not know whether they have permission to act, or because they have learned that a decision can be reopened later by someone with more authority.

That ambiguity also shows up at the organisational level. When I asked who owns the experience across teams, the responses split between Product at 41%, Design at 29% and “everyone” at 29%. The sample was small, but the lack of a clear answer was more interesting to me than the percentages themselves. If ownership is ambiguous across the organisation, it is not surprising that decision rights become ambiguous underneath it. Teams compensate by aligning more widely or escalating upwards because nobody is quite sure where authority sits.

That is expensive in ways that do not always show up on a delivery plan. Decisions slow down, people become cautious, meetings accumulate and senior leaders are pulled into increasingly detailed work.

A better system makes the boundaries explicit enough that people can move confidently within them.

What this looks like:A team can change content, flows, prioritisation and implementation choices without leadership approval. Materially changing the intended customer outcome requires EPD alignment because the consequences cross functions, while regulatory risk or a significant commercial commitment is escalated because it exceeds the team’s authority. The team does not need approval for everything because it understands where its authority begins and ends.

That kind of clarity is more useful than telling people to act like owners while retaining an invisible veto above them.

Stop solving the problem too early

This is probably one of the harder shifts for experienced leaders because being able to see the answer is part of what made many of us successful.

A team describes a problem and you recognise it immediately. You have seen something similar before, you know which option is likely to work, you can see which stakeholder needs to be involved, and you can often predict which mistake the team is about to make. Saying the answer is efficient, and there are moments when that is exactly the right thing to do.

Leadership is not a coaching exercise at all costs. There are situations where risk is high, time matters and experience should be used directly. The difficulty is recognising when speed in the immediate decision is creating dependence in the longer term.

If the leader repeatedly supplies the answer, teams learn a different skill. They learn when to ask the leader. Over time, the organisation can end up with capable people who become increasingly cautious around ambiguity because judgement has been centralised above them.

A better leadership response is often to add the missing context, expose the trade-off or ask the question that improves the team’s reasoning without taking the decision away. That might mean asking what evidence differentiates two options, what assumption is driving the recommendation, which risk is reversible, or what the team would choose if the leader were unavailable.

Those questions are useful because they reveal whether the team lacks capability, context or simply confidence. Those are different problems and they should not all be solved by providing an answer.

What this looks like:A team brings two onboarding options to a senior leader and asks which one to choose. Instead of selecting one immediately, the leader asks which option better addresses the customer problem, what evidence supports that view, which downside would be hardest to reverse and what the team recommends. The team keeps ownership of the decision, but its reasoning gets stronger.

The point is not to withhold expertise. It is to use expertise in a way that leaves more capability behind.

Feedback is how judgement compounds

Authority on its own does not create better decision-makers. People improve when they can connect the decisions they made to what happened afterwards.

That sounds obvious, but product organisations are often surprisingly bad at it. A project ships, the team moves to the next roadmap item, and the trade-offs that were made disappear into history. The organisation may measure adoption or revenue at a portfolio level, but the people who made the original decisions do not always see how those decisions performed.

That breaks the learning loop.

If a team simplified an experience to meet a deadline, did customers struggle with it? If an Engineering team took on technical debt to move faster, did that debt actually become expensive later? If Product decided not to solve an edge case, did support contacts increase or did nothing meaningful happen? Without that feedback, the next decision is still mostly opinion.

A better organisation makes decision outcomes visible enough that judgement can improve over time. Research, analytics, quality measures, support data and retrospectives become part of the learning system rather than separate activities owned by individual functions.

What this looks like:A team deliberately simplifies onboarding to meet a fixed launch date. Four weeks later it reviews activation, SEQ, abandonment and support contacts alongside the debt it knowingly introduced. If the compromise performed well, that becomes useful evidence for future decisions. If it failed, the organisation learns something more valuable than simply recording that the launch was on time.

The important part is that the feedback returns to the people making the next trade-off, because that is how judgement compounds.

Escalation should transfer context, not ownership

I do not think a healthy organisation is one where nothing gets escalated. Some problems genuinely extend beyond the context or authority of a team. Two areas may have competing priorities, a commercial commitment may have consequences the team cannot see, or a technical decision might affect a platform used across the company.

Leadership exists partly because those wider trade-offs need somewhere to go.

The problem is when escalation becomes the moment where ownership permanently moves upwards. A team raises a cross-organisational constraint, leadership enters the problem, and eventually the detailed product decision itself is being made several levels away from the people closest to the work.

A better escalation solves the part of the problem that requires wider authority, then returns the rest. Leaders can resolve the organisational priority, expose context the team did not have, or clarify which constraint matters most. Once that is done, the detailed decision should usually move back to the people with the most relevant context.

What this looks like:Two teams disagree because both roadmaps depend on the same platform capability. Leadership resolves which business priority takes precedence and makes the trade-off visible, but it does not redesign the solution for them. Once the constraint is clear, the teams take the product decision back.

This distinction matters because escalation should increase the context available to a team rather than teaching the team that difficult problems belong to somebody more senior.

Better leadership changes what happens when you are not there

There is a simple test I increasingly like for leadership: what happens when you are unavailable?

The useful question is not what happens when you are in the meeting, reviewing the work, asking the right question or unblocking the team. It is what happens when the organisation has to operate without your immediate judgement.

If decisions wait, work stalls or people delay difficult conversations until a particular leader returns, the organisation may value that leader highly, but their leadership has not fully scaled. That is not necessarily a criticism of the individual. Sometimes organisations deliberately concentrate authority because they trust a small number of people more than the system around them. The consequence is still dependence.

The better outcome is not that teams never need leadership. It is that they can make reasonable decisions inside understood boundaries, recognise when something genuinely exceeds those boundaries and bring back the right risks rather than every uncertainty.

What this looks like:Review the significant decisions made while you were unavailable over the last quarter. If teams waited for your return, ask what they believed only you could provide. If they moved confidently and escalated only the risks that genuinely required your authority, the system is becoming less dependent on your presence.

This changes the leadership metric. Your value is no longer only visible in the decisions you improve personally. It is also visible in the quality of decisions the organisation can make without you.

Better decision-makers create a faster organisation

A lot of organisations try to create speed by shortening planning cycles, removing meetings or increasing delivery pressure. Those things can help, but one of the biggest sources of drag is more fundamental. Too many decisions travel upwards, sideways and repeatedly across functions before anyone feels confident enough to act.

One of the polls I ran alongside the earlier series reinforces the other side of this problem. When I asked what most turns a product team into a feature factory, delivery-based metrics was the strongest response at 50%. It was a small, directional sample, but the pattern matters here because decision-making does not happen in isolation. If teams know that shipping is what gets recognised, they will naturally make decisions that optimise toward shipping. Giving them more authority without changing the signals around them simply decentralises the same behaviour.

A better organisation moves judgement closer to the work. It gives teams context instead of just requirements, principles instead of recurring approvals, clear authority instead of vague empowerment, and feedback instead of assuming the decision was good because the project shipped.

This does not mean decentralising everything. Some decisions should remain central because the consequences are genuinely organisational. The goal is to put each decision at the lowest level that has enough context and authority to make it well.

That is a much more useful definition of empowerment than simply telling teams they own the outcome. It is also one of the ways organisations become genuinely faster rather than simply demanding that people move faster.

Building something better

Series 1 looked at the symptoms of organisations that optimise for shipping. Series 2 explored the systems that keep those behaviours in place, including the way authority becomes concentrated and permission starts to replace ownership. Series 3 is about what I think we should build instead.

For me, better leadership does not mean withdrawing from decisions. It means being more deliberate about what you are adding when you enter them. Sometimes that is an answer, but more often at senior levels it should be context, principles, boundaries, feedback or the removal of an organisational constraint that the team cannot resolve itself.

The aim is to leave behind more judgement than you started with.

A useful place to begin is with the decisions that keep coming back to you. Look for the ones you have made more than once and ask why they are still yours. It may be that the team needs more capability, but it may also be that context is trapped above them, authority is unclear, or the organisation has never converted repeated judgement into something reusable.

Start with one recurring decision:Choose something that has been escalated to you more than once. Instead of asking how you can make it faster next time, ask what context, principle or boundary would allow the team to make the next version of that decision well without you.

The more senior you become, the goal should not be to become indispensable to every important decision. It should be to build an organisation that keeps making better ones.

Your job is to create better decision-makers was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.