Leadership: Remove Delivery Blockers

One of the most important responsibilities of an executive leader is to remove obstacles that prevent teams from delivering meaningful outcomes.

Strategies, roadmaps and investment plans are valuable, but they create little impact when delivery teams cannot access data, secure funding, obtain decisions, recruit the right people or gain approval from risk and governance functions.

In many organisations, teams do not fail because they lack effort or technical ability. They fail because the organisational environment makes progress unnecessarily difficult.

Common blockers include:

• Unclear decision-making authority.
• Conflicting priorities.
• Slow governance processes.
• Limited funding.
• Delayed access to data or infrastructure.
• Weak business sponsorship.
• Procurement and vendor delays.
• Shortages of specialist skills.
• Architecture disagreements.
• Poor coordination between regional and global teams.
• Resistance to adoption.

The executive leader’s role is not simply to ask why delivery is late. The leader must identify what is preventing progress, determine why the issue cannot be resolved at the current level and intervene with the appropriate authority.

A strong executive leader creates movement.

They make decisions, clarify accountability, secure resources, resolve conflicts and establish a path forward.

A weak executive leader repeatedly asks for status updates while leaving the underlying obstacle unchanged.

The difference is significant.

Asking for progress creates pressure.

Removing the blocker creates progress.

---

1. What is a delivery blocker?​

A delivery blocker is any unresolved issue that prevents a team from progressing at the required speed, quality or level of confidence.

A blocker may stop delivery completely, but it can also create repeated delays, rework, uncertainty or inefficient workarounds.

For example, a team may technically continue working while waiting for production data access. However, it may be forced to build against incomplete sample data. This creates hidden rework later when the production data contains different formats, quality issues or sensitivity requirements.

The team appears active, but meaningful delivery is blocked.

Delivery blockers generally fall into four categories.

1.1 Operational blockers​

These affect the team’s ability to perform day-to-day work.

Examples include:

• Missing system access.
• Delayed environment provisioning.
• Incomplete requirements.
• Unavailable subject-matter experts.
• Dependency on another team.
• Unresolved technical defects.
• Lack of testing capacity.
• Delayed security credentials.

These blockers can often be resolved by project, programme or engineering leadership.

However, they become executive issues when they persist across teams, require policy exceptions or involve competing organisational priorities.

1.2 Organisational blockers​

These arise from unclear structures, responsibilities or relationships.

Examples include:

• No clear business owner.
• Overlapping accountability.
• Conflicting instructions from multiple leaders.
• Regional and global operating-model disputes.
• Unclear product ownership.
• Tension between innovation and control functions.
• Lack of authority to make cross-functional decisions.
• Internal political disagreement.

These blockers often require senior intervention because the delivery team does not have the authority to resolve them.

1.3 Commercial and resource blockers​

These relate to money, people, suppliers and capacity.

Examples include:

• Funding has not been approved.
• Budget ownership is unclear.
• The required specialists are unavailable.
• Procurement has not completed vendor onboarding.
• Commercial terms remain unresolved.
• Cloud or model consumption limits are too restrictive.
• External partners are not meeting commitments.
• Delivery capacity has been allocated elsewhere.

These issues require prioritisation and trade-offs.

The executive leader must decide what matters most and ensure that resources reflect those priorities.

1.4 Governance and risk blockers​

These arise when teams cannot obtain the confidence or approval required to proceed.

Examples include:

• Privacy concerns.
• Cybersecurity approval delays.
• Unclear legal interpretation.
• Model-risk concerns.
• Third-party risk assessments.
• Responsible AI requirements.
• Data-retention questions.
• Regulatory uncertainty.
• Audit or assurance evidence gaps.
• Unresolved client-confidentiality concerns.

These blockers cannot be solved by simply pressuring control teams to approve something faster.

The executive leader must bring the right people together, clarify the decision required, ensure that the correct evidence exists and determine whether the remaining risk is acceptable.

---

2. Why blocker removal is an executive responsibility​

Not every delivery problem requires executive intervention.

High-performing teams should be empowered to solve normal operational issues independently. Programme managers, product owners, architects and delivery leads should resolve problems within their authority.

Executive intervention becomes necessary when the blocker exceeds the team’s decision rights.

This usually occurs when the problem involves:

• Multiple business units.
• Significant funding.
• Competing executive priorities.
• Policy interpretation.
• Risk acceptance.
• Strategic vendors.
• Organisational design.
• Senior stakeholder disagreement.
• Global and regional conflicts.
• Material client or regulatory exposure.

The executive leader has something the delivery team does not have: organisational authority.

That authority should be used carefully, but it should be used decisively when progress depends on it.

A leader who refuses to intervene may unintentionally leave teams trapped between functions.

For example:

• Technology says the business must define the requirement.
• The business says technology must propose the solution.
• Risk says it cannot approve the use case without architecture details.
• Architecture says it cannot complete the design without data access.
• Data owners say access cannot be granted without risk approval.

Every function may be acting rationally from its own perspective, yet the initiative remains stuck.

The executive leader must break the cycle.

They must define the sequence, assign ownership and create a decision path.

---

3. The difference between monitoring and leadership​

Many leaders spend considerable time reviewing dashboards, attending programme meetings and requesting updates.

Monitoring is useful, but monitoring alone is not leadership.

A leader may ask:

• Why is this milestone late?
• When will the issue be resolved?
• Who is responsible?
• Why has approval not been received?
• Can the team work harder?
• Can the deadline still be met?

These questions may reveal the problem, but they do not necessarily remove it.

Executive leadership begins when the leader asks:

• What exact decision is preventing progress?
• Why can the team not resolve this itself?
• Who has the authority to make the decision?
• What evidence does that person need?
• What trade-off must be accepted?
• What can I decide now?
• What should be escalated?
• What can be simplified or removed?
• What commitment will each owner make?
• By when will the blocker be closed?

A status-focused leader collects information.

An outcome-focused leader converts information into action.

---

4. A practical executive blocker-removal process​

A disciplined blocker-removal process helps leaders avoid two common problems.

The first is intervening too early and undermining team ownership.

The second is intervening too late, after weeks of delay.

A practical process contains seven steps.

Step 1: Define the blocker precisely​

Teams often describe blockers too broadly.

For example:

• “Risk is blocking us.”
• “The business is not engaged.”
• “We have a data problem.”
• “Procurement is slow.”
• “Architecture has not agreed.”
• “We do not have enough people.”

These descriptions are not specific enough to support executive action.

The leader should require a precise blocker statement.

A good blocker statement explains:

• What cannot proceed.
• What decision or input is missing.
• Who currently owns that decision.
• What has already been attempted.
• What impact the delay is creating.
• When the decision is required.
• What options are available.

For example:

The team cannot begin controlled user testing because the privacy review has not approved the use of customer-service transcripts. The review requires confirmation of the retention period and whether personal data will be used for model improvement. Without a decision by Friday, the pilot will move by three weeks.

This is actionable.

It identifies the affected activity, the missing decision, the owner, the deadline and the impact.

Step 2: Determine whether it is genuinely an executive blocker​

Not every issue should be escalated.

Some teams escalate problems because escalation is easier than resolving conflict directly.

The executive should ask:

• Has the team spoken directly to the decision owner?
• Have the options been documented?
• Has the delivery lead proposed a recommendation?
• Is the issue within the team’s existing authority?
• Is this a real blocker or simply an inconvenience?
• Has the team allowed reasonable time for the dependency?
• Is the escalation based on evidence or frustration?

Executives should not become the default resolution mechanism for routine disagreements.

Their role is to remove obstacles that genuinely require senior authority, not to replace delivery management.

Step 3: Understand the root cause​

The visible issue may not be the real blocker.

For example, a risk approval may appear delayed because the risk function is slow. The actual cause may be that the delivery team submitted incomplete evidence.

A funding request may appear blocked by finance. The real issue may be that the business case does not clearly demonstrate value.

A data-access delay may appear to be caused by the data owner. The real concern may be that the requested access is broader than necessary.

The leader should distinguish between the symptom and the cause.

A useful technique is to ask repeatedly:

• What is preventing the decision?
• Why is that information unavailable?
• Why has ownership remained unclear?
• Why was this dependency not identified earlier?
• What concern is the stakeholder trying to manage?
• What would need to be true for them to approve?

This helps the leader solve the actual problem rather than applying temporary pressure.

Step 4: Identify the decision owner​

Every blocker should have a named decision owner.

Committees can advise, review and challenge, but accountability should remain with an individual.

The owner may be:

• A business sponsor.
• A product owner.
• A risk executive.
• A data owner.
• A technology leader.
• A procurement leader.
• A finance leader.
• A regional executive.
• A global capability owner.
• The executive Data and AI leader.

The leader should avoid vague ownership statements such as:

• “Technology will resolve it.”
• “The programme team is looking at it.”
• “Risk needs to approve it.”
• “The business needs to decide.”

Instead, the leader should ask:

Which named person has the authority and accountability to make this decision?

When ownership is unclear, the executive must assign it.

Step 5: Present clear options and trade-offs​

Executive decisions are easier when the issue is presented as a set of realistic options.

For each option, teams should explain:

• The expected benefit.
• The cost.
• The delivery impact.
• The risk.
• The dependencies.
• The reversibility of the decision.
• The recommended option.

For example:

Option 1: Wait for the strategic data platform

• Lower long-term duplication.
• Six-month delay.
• Stronger alignment with global architecture.
• Risk of losing business sponsorship.

Option 2: Build a temporary regional data pipeline

• Enables delivery in six weeks.
• Creates additional technical debt.
• Requires a retirement plan.
• Higher short-term cost.

Option 3: Reduce the initial scope

• Enables a smaller pilot using currently available data.
• Limits business value.
• Preserves learning while strategic access is resolved.

The executive can then make an informed trade-off.

Without options, escalation becomes an open-ended discussion.

Step 6: Make the decision and assign actions​

Once the issue is sufficiently understood, the leader should act.

The outcome should include:

• The decision.
• The rationale.
• The owner.
• The immediate action.
• The deadline.
• Any conditions or controls.
• The escalation path if the action is not completed.

For example:

We will proceed with a limited pilot using anonymised data. The Data Protection Officer will confirm the anonymisation standard by Wednesday. The product team will update the scope and delivery plan by Thursday. The full-data pilot will remain dependent on the completed privacy assessment.

This creates clarity and momentum.

Step 7: Confirm that the blocker is actually closed​

A blocker is not resolved because a meeting took place.

It is resolved when the team can proceed.

Executives should ask:

• Has the decision been communicated?
• Has the required access been granted?
• Has funding been released?
• Has the owner completed the action?
• Has the team updated the delivery plan?
• Has the risk been recorded?
• Has the dependency been removed?
• Has a new blocker been created elsewhere?

Closing the loop is essential.

Otherwise, organisations accumulate repeated discussions without practical resolution.

---

5. Common delivery blockers and how leaders should respond​

5.1 Lack of funding​

Funding problems are common because Data and AI initiatives frequently cross cost centres, service lines and financial periods.

The team may need funding for:

• Cloud infrastructure.
• Model consumption.
• Data engineering.
• External vendors.
• Specialist resources.
• Licensing.
• Security tooling.
• User training.
• Change management.
• Assurance activities.

Funding becomes blocked when:

• No single function owns the budget.
• The business case is unclear.
• Costs are distributed but benefits are concentrated.
• The initiative competes with established priorities.
• The total cost of ownership is underestimated.
• The project is treated as experimentation without a scale plan.
• Leadership has not agreed whether the capability is strategic.

The executive leader should not simply request “more budget.”

They should clarify:

• What outcome the investment will create.
• What minimum funding is required.
• Which costs are one-off and recurring.
• Which service line or function benefits.
• Whether the initiative should be centrally or locally funded.
• What will be stopped or delayed to release capacity.
• What decision is needed from finance or the executive committee.

Good executive intervention may include:

• Reallocating funding from lower-value initiatives.
• Approving a staged investment.
• Requiring a stronger business case.
• Creating a central innovation fund.
• Establishing co-funding between functions.
• Stopping the initiative if the economics are weak.

Removing a funding blocker does not always mean approving the money.

Sometimes the correct leadership decision is to stop or reduce the initiative.

5.2 Unclear ownership​

Unclear ownership creates delay because no one feels accountable for the outcome.

This commonly occurs when an initiative crosses:

• Business and technology.
• Regional and global teams.
• Data owners and product teams.
• Risk and innovation functions.
• Multiple service lines.
• Internal and client-facing teams.

Warning signs include:

• Decisions repeatedly return to committees.
• Stakeholders attend meetings but avoid commitments.
• Multiple people believe someone else is accountable.
• The delivery team receives conflicting instructions.
• Risks are identified but not owned.
• Benefits are claimed by one function while costs sit elsewhere.

The executive should define:

• The executive sponsor.
• The business outcome owner.
• The product owner.
• The delivery owner.
• The technology owner.
• The data owner.
• The risk owner.
• The adoption owner.

These roles may be held by different people, but their responsibilities must be explicit.

A useful question is:

Who will be accountable if this initiative does not achieve the intended outcome?

That person should have sufficient authority to influence priorities, resolve conflicts and make decisions.

5.3 Delayed access to data​

Data access is one of the most common blockers in Data and AI delivery.

Access may be delayed because of:

• Privacy concerns.
• Data classification.
• Unclear ownership.
• Poor data quality.
• Technical integration difficulties.
• Cross-border restrictions.
• Client confidentiality.
• Lack of legal basis.
• Security controls.
• Retention requirements.
• Consent limitations.
• Competition or independence concerns.

The executive should avoid treating data access as an administrative task.

It is often a complex risk and ownership decision.

The leader should ask:

• What specific data is needed?
• Is all requested data genuinely necessary?
• Can the scope be reduced?
• Can data be anonymised, masked or aggregated?
• Can synthetic data support early development?
• Who is the legal and operational data owner?
• What control evidence is missing?
• Is the proposed access time-limited?
• Can access be granted in a controlled environment?
• What is the intended use and retention period?

Possible executive actions include:

• Reducing the data scope.
• Requiring privacy-enhancing controls.
• Assigning a named data owner.
• Creating a time-limited approval.
• Establishing a secure development environment.
• Approving a phased access model.
• Escalating legal interpretation.
• Stopping the use case if the data risk is disproportionate.

The objective is not maximum access.

The objective is sufficient, appropriate and controlled access.

5.4 Architecture disagreements​

Architecture disagreements can consume significant delivery time.

Different stakeholders may disagree about:

• Cloud providers.
• Model providers.
• Central versus federated platforms.
• Build versus buy.
• Open-source versus proprietary technology.
• Regional versus global hosting.
• Integration patterns.
• Security architecture.
• Data storage.
• Model orchestration.
• Reuse of existing platforms.
• Long-term scalability.

Some disagreement is healthy. It improves the quality of technical decisions.

However, disagreement becomes a blocker when:

• Criteria are unclear.
• Participants defend preferred technologies rather than business outcomes.
• No one has final decision authority.
• The perfect future architecture delays practical delivery.
• Strategic standards conflict with immediate business needs.
• Decisions are repeatedly reopened.

The executive leader should ensure that architectural decisions are based on explicit criteria, such as:

• Business value.
• Security.
• Compliance.
• Scalability.
• Cost.
• Maintainability.
• Time to market.
• Reusability.
• Vendor dependency.
• Integration complexity.
• Data residency.
• Exit options.

The leader does not need to make every technical decision personally.

However, they should establish who makes the decision, what principles apply and when the decision must be final.

Where appropriate, the leader may approve a controlled exception.

For example:

The regional team may use the interim platform for the pilot, provided it meets the minimum security controls and includes a migration plan to the strategic global platform.

This balances speed with architectural discipline.

5.5 Risk approval delays​

Risk approval delays often create tension between delivery and control functions.

Delivery teams may believe that risk teams are too cautious.

Risk teams may believe that delivery teams provide incomplete information, involve them too late or underestimate potential harm.

The executive leader should avoid framing the issue as innovation versus governance.

Both functions are trying to protect organisational value.

The leader should ask:

• What specific risk is preventing approval?
• Is the risk clearly described?
• What evidence is required?
• Is the evidence available?
• Which controls could reduce the risk?
• Who has authority to accept the residual risk?
• Is the review proportionate to the use case?
• Has the initiative been correctly classified?
• Are multiple control functions reviewing the same evidence separately?
• Is the approval process itself well designed?

Possible interventions include:

• Bringing risk, legal, security and delivery leaders into one decision session.
• Requiring a single consolidated evidence pack.
• Defining risk-based approval pathways.
• Establishing service-level expectations.
• Assigning an accountable risk decision owner.
• Introducing standard control patterns.
• Creating pre-approved technical architectures.
• Escalating genuine policy exceptions.
• Rejecting the initiative where residual risk remains unacceptable.

A strong executive does not bypass governance.

They make governance clearer, faster and more proportionate.

5.6 Shortage of skilled people​

Data and AI programmes often depend on scarce capabilities.

These may include:

• Data engineering.
• Machine learning engineering.
• AI architecture.
• Cybersecurity.
• Responsible AI.
• Product management.
• Cloud engineering.
• Change management.
• Model evaluation.
• Legal and regulatory expertise.
• Industry-specific knowledge.

Skill shortages become blockers when organisations launch too many initiatives without understanding specialist capacity.

The leader should ask:

• Which capability is genuinely scarce?
• Is the requirement temporary or long term?
• Can the work be simplified?
• Can an existing component be reused?
• Can internal people be upskilled?
• Can resources be shared across programmes?
• Should external specialists be used?
• Is the initiative important enough to justify priority?
• Which lower-priority work should be paused?

Possible responses include:

• Reallocating scarce specialists.
• Creating shared expert pools.
• Hiring strategically.
• Using external partners for short-term acceleration.
• Training internal teams.
• Standardising repeatable patterns.
• Reducing the number of concurrent initiatives.
• Creating succession and capability-development plans.

The worst response is to spread the same specialist across too many programmes.

This creates the appearance of coverage while reducing actual delivery capacity.

5.7 Conflicts between regional and global teams​

Regional and global teams often have legitimate but different priorities.

Global teams may prioritise:

• Standardisation.
• Security.
• Reusability.
• Economies of scale.
• Consistent vendor relationships.
• Global governance.
• Enterprise architecture.

Regional teams may prioritise:

• Local client needs.
• Regulatory requirements.
• Market speed.
• Revenue opportunities.
• Local language or data requirements.
• Regional autonomy.
• Immediate delivery.

Conflict arises when:

• Global standards are not ready.
• Regional teams create duplicate capabilities.
• Decision rights are unclear.
• Funding responsibilities are disputed.
• Local regulation requires variation.
• Global governance is perceived as slow.
• Regional teams make commitments without global alignment.

The executive leader should clarify:

• Which decisions are global.
• Which decisions are regional.
• Which standards are mandatory.
• Where local variation is permitted.
• How exceptions will be approved.
• Who funds shared components.
• How reusable assets will be contributed back.
• How conflicts will be escalated.

A useful operating principle is:

Standardise where scale and risk matter; localise where regulation, clients or market speed require it.

The leader should aim for governed federation rather than uncontrolled independence or excessive centralisation.

5.8 Vendor and procurement delays​

Vendor onboarding can delay delivery because of:

• Contract negotiations.
• Security assessments.
• Data-processing agreements.
• Financial approvals.
• Independence checks.
• Insurance requirements.
• Intellectual-property terms.
• Service-level agreements.
• Third-party risk reviews.
• Legal negotiations.
• Procurement capacity.

The executive should first determine whether the vendor is genuinely necessary.

Questions include:

• Can an approved supplier provide the capability?
• Can the organisation build or reuse the component?
• Is the vendor needed for the pilot or only for scale?
• What data will the vendor access?
• What is the exit strategy?
• What happens if the vendor fails?
• Are commercial terms proportionate?
• Does the organisation understand long-term dependency and cost?

Possible interventions include:

• Prioritising the procurement review.
• Using a controlled pilot agreement.
• Selecting an already-approved vendor.
• Reducing the initial vendor scope.
• Escalating critical contractual issues.
• Negotiating enterprise terms.
• Approving an alternative solution.
• Stopping the dependency entirely.

The executive should not force procurement to ignore due diligence.

They should ensure that effort is focused on the most material issues and that the process has clear ownership and deadlines.

5.9 Weak business sponsorship​

Some initiatives have technical enthusiasm but limited business commitment.

Signs of weak sponsorship include:

• The sponsor rarely attends decision meetings.
• Business users do not participate in design or testing.
• Benefits are described vaguely.
• No business process owner has been assigned.
• The initiative is viewed as a technology experiment.
• Adoption planning is deferred.
• No one is accountable for changing the operating model.
• The business expects technology to deliver value independently.

The executive should challenge whether the initiative should continue.

Questions include:

• Which business outcome is being improved?
• Who owns that outcome?
• Who will change the process?
• Who will drive adoption?
• Which users have committed to the pilot?
• What will happen if the solution succeeds?
• Is funding linked to expected benefits?
• Is the sponsor willing to make operational changes?

Possible decisions include:

• Assigning a stronger sponsor.
• Pausing the initiative until sponsorship improves.
• Reducing the scope.
• Moving the initiative to a more committed business area.
• Stopping the project.

AI cannot create value if the business is unwilling to change how work is performed.

5.10 Poor adoption​

A system may be technically successful but commercially unsuccessful because users do not adopt it.

Poor adoption may result from:

• Weak communication.
• Poor user experience.
• Lack of trust.
• Insufficient training.
• Fear of job displacement.
• Misalignment with workflows.
• Low-quality outputs.
• Missing incentives.
• Leadership inconsistency.
• Lack of user involvement.
• No clear benefit to the user.

Executives should treat adoption as part of delivery, not as a post-launch activity.

They should ask:

• Who is expected to use the solution?
• What behaviour must change?
• Why would users choose to adopt it?
• What concerns do they have?
• Have users participated in design?
• Are managers reinforcing the change?
• Is the system easier than the existing process?
• Are performance measures aligned?
• Is trust being measured?
• What support exists after launch?

Possible interventions include:

• Assigning an adoption owner.
• Improving product usability.
• Increasing user involvement.
• Changing incentives.
• Introducing targeted training.
• Addressing workforce concerns openly.
• Requiring senior leaders to model usage.
• Redesigning the workflow.
• Stopping features that do not create user value.

Adoption is not achieved through communication alone.

The solution, process, incentives and leadership behaviour must all support the intended change.

---

6. The executive blocker-removal meeting​

Organisations often benefit from a short, disciplined forum for resolving significant blockers.

This should not become another general status meeting.

Its purpose is decision-making.

A useful agenda includes:

6.1 Outcome at risk​

What business, client or delivery outcome is being affected?

6.2 Precise blocker​

What specifically cannot proceed?

6.3 Impact​

What happens if the blocker is not resolved?

This may include:

• Revenue delay.
• Cost increase.
• Client dissatisfaction.
• Regulatory exposure.
• Missed milestone.
• Resource waste.
• Loss of sponsorship.
• Increased technical debt.

6.4 Actions already attempted​

What has the team done to resolve the issue?

6.5 Decision required​

What decision must be made, and by whom?

6.6 Options​

What realistic options exist?

6.7 Recommendation​

What does the accountable delivery leader recommend?

6.8 Decision and ownership​

What has been agreed, who owns the next action and when will it be completed?

The meeting should focus only on blockers that require executive authority.

A well-run session may last 30 minutes and resolve several important issues.

A poorly run session may last two hours and produce no decisions.

---

7. Principles for effective blocker removal​

7.1 Create clarity before urgency​

Executives often respond to delay by increasing pressure.

However, urgency without clarity creates confusion, defensive behaviour and rushed decisions.

The leader should first clarify:

• The objective.
• The blocker.
• The owner.
• The decision.
• The deadline.
• The trade-off.

Then urgency becomes productive.

7.2 Escalate decisions, not frustration​

Escalations should be evidence-based.

A useful escalation states:

• What is blocked.
• Why it matters.
• What has been attempted.
• What decision is required.
• What the options are.
• What the team recommends.

An unhelpful escalation states:

• “They are not supporting us.”
• “This has taken too long.”
• “Risk is being difficult.”
• “The global team is blocking innovation.”

The executive should challenge emotionally framed escalations and redirect them toward decisions.

7.3 Preserve accountability at the lowest effective level​

Executive leaders should remove blockers without creating dependency.

If teams learn that every disagreement will be resolved by a senior leader, they may stop developing their own judgement and conflict-resolution capability.

The executive should ask:

• Could the team resolve this with clearer authority?
• Does the team need a decision, or does it need coaching?
• Can the decision right be delegated permanently?
• Is the issue recurring because the operating model is unclear?

The objective is not to become the organisation’s chief problem solver.

The objective is to create an organisation that solves problems effectively.

7.4 Make reversible decisions quickly​

Not every decision requires perfect certainty.

Where a decision is low risk and reversible, the leader should encourage speed.

Examples include:

• Running a limited pilot.
• Testing with synthetic data.
• Selecting a temporary tool.
• Restricting the initial user group.
• Using a time-limited exception.
• Trialling one workflow before scaling.

High-risk, irreversible decisions require greater evidence.

The level of governance should reflect the consequence of being wrong.

7.5 Challenge unnecessary complexity​

Many blockers exist because the proposed solution is too broad.

The executive should ask:

• Can the scope be reduced?
• Can we solve one workflow first?
• Can we use fewer data sources?
• Can we remove a non-essential integration?
• Can we use an existing platform?
• Can we avoid custom development?
• Can we reduce the number of stakeholders required for the first release?

Simplification is one of the most powerful forms of blocker removal.

7.6 Protect teams from conflicting priorities​

Teams cannot deliver effectively when several executives assign urgent but incompatible priorities.

The leader must make trade-offs visible.

This may involve saying:

• This initiative is more important than the other one.
• This deadline will move.
• This resource will be reassigned.
• This feature will not be included.
• This regional request will wait.
• This pilot will stop.

Avoiding prioritisation does not preserve flexibility.

It transfers the conflict to delivery teams, where it becomes overload and delay.

7.7 Resolve recurring blockers structurally​

A blocker that occurs once may require a specific intervention.

A blocker that occurs repeatedly indicates a system problem.

For example:

• Repeated privacy delays may require a standard privacy-assessment process.
• Repeated architecture disputes may require clearer design authority.
• Repeated data-access problems may require a governed data-sharing model.
• Repeated procurement delays may require strategic vendor agreements.
• Repeated skill shortages may require workforce planning.
• Repeated adoption failures may require stronger product and change-management capability.

Executives should track patterns, not only individual incidents.

The best blocker removal prevents the same obstacle from returning.

---

8. What poor blocker removal looks like​

Executive intervention can become harmful when it is inconsistent or poorly disciplined.

8.1 Asking for updates without decisions​

The same issue appears in multiple meetings, but no one makes the required decision.

This creates reporting activity without delivery movement.

8.2 Escalating everything​

When every problem is treated as urgent, senior attention becomes diluted and teams lose ownership.

8.3 Bypassing governance​

A leader may pressure risk, legal or security teams to approve an initiative without sufficient evidence.

This may accelerate one milestone while creating unacceptable exposure.

8.4 Making decisions without understanding the impact​

Fast decisions are not always good decisions.

Executives should understand material consequences, especially where client data, regulation, security or professional obligations are involved.

8.5 Publicly blaming individuals​

Public blame encourages stakeholders to hide problems until they become severe.

Leaders should challenge performance directly while preserving psychological safety for early escalation.

8.6 Changing direction repeatedly​

Frequent executive intervention can create instability if priorities change every time a new stakeholder raises a concern.

Decisions should remain stable unless new evidence materially changes the situation.

8.7 Solving symptoms instead of systems​

Repeatedly expediting individual approvals does not fix a broken approval process.

The leader should solve the immediate issue and improve the system that created it.

8.8 Accepting vague ownership​

When everyone is involved but no one is accountable, blockers remain open.

8.9 Protecting low-value initiatives​

Leaders sometimes remove obstacles from projects that should instead be stopped.

Blocker removal should not become unconditional project rescue.

The initiative must still demonstrate sufficient value, strategic relevance and manageable risk.

---

9. Building a blocker-removal culture​

Effective blocker removal should not depend entirely on one executive.

It should become part of the organisation’s operating model.

9.1 Encourage early escalation​

Teams should raise blockers before deadlines are missed.

A healthy escalation culture distinguishes between:

• Escalating responsibility.
• Escalating a decision.

The team should remain responsible for delivery while requesting help with an issue beyond its authority.

9.2 Define escalation thresholds​

Teams should understand which issues require escalation.

Examples may include:

• A critical dependency delayed beyond an agreed period.
• A material risk without an owner.
• A decision affecting multiple business units.
• A funding gap above a defined threshold.
• A milestone at risk.
• A regulatory or client-confidentiality concern.
• A disagreement that cannot be resolved within the programme.
• A vendor issue affecting critical delivery.

9.3 Maintain a blocker register​

A blocker register should include:

• Blocker description.
• Category.
• Date identified.
• Business impact.
• Owner.
• Decision required.
• Target resolution date.
• Current status.
• Escalation level.
• Resolution.
• Preventive action.

The register should focus on unresolved obstacles, not become a general issue log containing hundreds of minor tasks.

9.4 Measure resolution effectiveness​

Useful measures include:

• Average blocker age.
• Number of critical blockers.
• Time from escalation to decision.
• Percentage resolved by the target date.
• Number of recurring blockers.
• Delivery days lost.
• Blockers by function.
• Blockers requiring executive intervention.
• Decisions reopened after closure.

These measures help identify systemic weaknesses.

9.5 Reward constructive challenge​

People should be able to raise concerns without being labelled as obstructive.

Risk, architecture and delivery stakeholders should be encouraged to challenge assumptions early.

The desired behaviour is:

• Raise the issue.
• Explain the impact.
• Propose options.
• Recommend a path.
• Accept accountability for the next action.

9.6 Improve decision rights​

Many blockers are symptoms of unclear decision authority.

The organisation should define:

• Which decisions belong to product teams.
• Which decisions belong to architecture.
• Which decisions belong to risk.
• Which decisions belong to regional leadership.
• Which decisions require global approval.
• Which decisions can be delegated.
• Which exceptions require executive approval.

Clear decision rights reduce unnecessary escalation.

---

10. Removing blockers in a Data and AI context​

Data and AI delivery introduces additional forms of uncertainty.

Teams may be working with:

• Probabilistic model behaviour.
• Sensitive data.
• Emerging regulation.
• Rapidly changing technology.
• Third-party foundation models.
• Uncertain operating costs.
• New security threats.
• Limited organisational experience.
• Difficult-to-measure benefits.
• Human oversight requirements.

Executives should therefore ensure that blocker removal does not reduce necessary safeguards.

For example, the leader should not respond to an evaluation delay by approving production deployment without adequate testing.

Instead, the leader may remove the blocker by:

• Prioritising evaluation specialists.
• Reducing the initial use-case scope.
• Establishing acceptance thresholds.
• Approving a limited user group.
• Requiring human review.
• Using a lower-risk data set.
• Creating a temporary manual control.
• Defining a monitored pilot period.

The objective is responsible acceleration.

This means increasing the speed of decision-making while maintaining appropriate protection for clients, employees, regulators and the organisation.

---

11. Executive questions for removing blockers​

A strong executive can use a consistent set of questions.

Questions to understand the blocker​

• What exactly cannot proceed?
• When did the issue first become known?
• What is the root cause?
• Who currently owns the issue?
• What has already been attempted?
• Why can the team not resolve it?
• What happens if no decision is made?

Questions to test importance​

• Which business outcome is at risk?
• What is the financial or client impact?
• Is this on the critical path?
• Is the deadline genuinely important?
• Is this initiative still worth protecting?
• What other work would be affected by intervention?

Questions to identify options​

• What are the realistic options?
• Which option does the team recommend?
• Can the scope be reduced?
• Can we use a temporary solution?
• Can an existing capability be reused?
• Is there a safe, reversible decision?
• What control would make the risk acceptable?

Questions to assign accountability​

• Who has authority to decide?
• Who owns the next action?
• By when will it be complete?
• What evidence will confirm closure?
• What will happen if the deadline is missed?

Questions to prevent recurrence​

• Why did this issue arise so late?
• Has this happened elsewhere?
• Does the operating model need to change?
• Should a standard process or pattern be created?
• Can decision authority be delegated?
• What lesson should be applied to future initiatives?

---

12. Example: removing a data-access blocker​

Consider a regional AI team developing a document-review assistant for a professional-services business.

The team needs access to historic client documents for testing.

The data owner refuses access because of confidentiality and retention concerns.

The programme team escalates the issue and states that “data governance is blocking delivery.”

A weak executive response would be:

Please accelerate the approval. This programme is strategically important.

This increases pressure but does not address the concern.

A stronger executive response would be:

1. Define the minimum data required.
2. Confirm whether client documents can be anonymised.
3. Determine whether synthetic or internally generated documents can support early testing.
4. Clarify the legal basis and retention period.
5. Restrict access to an approved environment.
6. Assign the confidentiality decision to a named accountable owner.
7. Approve a limited pilot using lower-risk documents.
8. Require deletion after the evaluation period.
9. Record the decision and controls.
10. Establish a reusable data-access pattern for similar use cases.

The executive has not ignored governance.

They have converted a broad conflict into a controlled delivery path.

---

13. Example: removing an architecture blocker​

A regional team wants to build a client-facing generative AI solution using a cloud platform that is already available locally.

The global architecture team requires the use of a strategic enterprise platform that will not be available for six months.

The client expects a pilot in eight weeks.

The disagreement has continued for a month.

A weak response would be:

Both teams need to align and come back with a solution.

A stronger executive response would define decision criteria:

• Client deadline.
• Security.
• Data residency.
• Integration requirements.
• Long-term scalability.
• Migration complexity.
• Strategic alignment.
• Cost.

The leader might decide:

The regional team may deliver the eight-week pilot on the approved local platform. The pilot must use standard identity, logging and security controls. No long-term client contract may depend on the temporary architecture. The team must document a migration path to the global platform before production scale.

This decision preserves delivery momentum while managing long-term architecture risk.

---

14. Example: removing a weak-sponsorship blocker​

A technical team has built an AI assistant intended to improve an internal finance process.

The solution performs well in testing, but finance teams are not participating in rollout planning.

The project lead requests additional funding for production deployment.

A weak executive may approve the funding because the technology appears promising.

A stronger executive asks:

• Who owns the finance process?
• Which metric will improve?
• Who will require teams to use the solution?
• What process changes are needed?
• Who is accountable for benefit realisation?
• What adoption commitment has finance made?

If these questions cannot be answered, the leader may pause the investment.

The blocker is not technology.

It is the absence of a committed business owner.

Removing the blocker may mean assigning a sponsor, redesigning the use case or stopping the project.

---

15. The executive leader’s personal operating discipline​

Effective blocker removal requires consistent personal habits.

Review critical blockers regularly

The leader should review a small number of material blockers, not every operational issue.

Require recommendations

Teams should not escalate problems without proposing a path forward.

Make decisions visibly

Decisions should be recorded and communicated to affected stakeholders.

Protect decision stability

Do not reopen decisions without material new evidence.

Follow through

Check that the action occurred and delivery resumed.

Recognise patterns

Look for recurring blockers across programmes.

Improve the system

Use repeated issues to improve governance, funding, architecture and resource models.

Remain calm under pressure

Blockers often create tension between strong stakeholders.

The executive must create clarity without increasing conflict.

Separate challenge from blame

Leaders should challenge assumptions, quality and accountability without creating a culture where people hide bad news.

Know when to stop

Some initiatives remain blocked because they lack sufficient value, ownership or feasibility.

Executive leadership includes the courage to end them.

---

Conclusion​

Removing delivery blockers is one of the clearest expressions of executive leadership.

Teams do not need senior leaders merely to observe their progress. They need leaders who create the conditions in which progress is possible.

This means:

• Clarifying the obstacle.
• Identifying the root cause.
• Determining the correct decision owner.
• Presenting realistic options.
• Making timely trade-offs.
• Assigning clear accountability.
• Confirming that the team can proceed.
• Fixing the organisational system that created the blockage.

A strong executive does not confuse activity with momentum.

They do not allow the same unresolved issue to appear in meeting after meeting.

They do not solve every problem personally, but they ensure that important problems have an owner, a decision path and a deadline.

Most importantly, they understand that leadership is not demonstrated by how often they ask for progress.

It is demonstrated by how effectively they make progress possible.