Category Archives: Project Management

The Most Dangerous Status Report Is the One Everyone Is Comfortable With

Posted on by

 

The governance is running. The reports are flowing. The steering committee met on time, every question got a confident answer, and the pack looked clean.

And the programme is in more trouble than anyone in that room is prepared to say.

This is not an unusual situation. It is not a sign of dysfunction or dishonesty. It is, in my experience, the most common information environment in large-scale programme delivery. The data supports that reading. Research by Milliken, Morrison and Hewlin, published in the Journal of Management Studies, found that 85% of employees have withheld important information from their manager because they feared the consequences of speaking up. The fear is not of formal punishment. It is relational: the fear of being seen negatively, of damaging a relationship, of being labelled someone who creates problems rather than solves them.

This is not a minority behaviour. It is the default.

The question is not whether a filter exists on your programme. The question is how thick it has become, and whether you would know.

 

Nobody Decides to Build the Filter

The pattern I have watched play out more times than I can count begins with a capable, experienced leader who genuinely means what they say. They have told the team, in kick-offs and town halls and one-to-ones, that they want to hear the bad news early. They are not performing openness. They believe it.

But then someone raises a concern in a steering committee and the leader’s body language shifts before the words are out. A risk gets flagged and the first question is why it was not caught earlier rather than what needs to happen now. A project manager delivers a difficult update and spends the following week under a level of scrutiny that has nothing to do with fixing the problem.

Nobody announces a new policy. Nobody says: do not bring me bad news.

But the room notices. Every single time.

And slowly, without anyone deciding to do it, the filter gets built. The team learns which concerns land well and which ones create friction. They learn how to frame things to reduce the emotional temperature in the room. They learn the difference between the truth and the version of the truth that keeps the meeting moving and their professional standing intact.

The updates keep arriving. The reports keep flowing. The governance keeps running.

But the signal has been stripped out. What remains is noise dressed up as information.

 

You Do Not Build This Through Negligence

This is the part that most leadership development will not tell you directly. You do not build a closed information environment through negligence. You build it through a series of entirely human, entirely understandable responses to difficult moments.

A flash of impatience when a problem arrived at the wrong time. A habit of moving to solutions before the problem is fully understood. A preference, however subtle, for the reassuring narrative over the complicated one.

These are not character flaws. They are instincts under pressure.

But at leadership level they are not private. The CIPD’s 2024 evidence review on psychological safety identifies leader and manager behaviour as the most critical driver of whether people feel safe to speak up, and specifically notes that what matters is not what leaders say about wanting honesty, but what they demonstrate through their actions when honesty arrives. The research is unambiguous: psychological safety is fragile. A single punitive response to good-faith feedback can damage trust that took months to build.

Every reaction is observed, interpreted, and factored into how safe it feels to tell you the truth next time. The leader who says they want honesty but visibly struggles to receive it is not running an open culture. They are running an organisation that has learned to give them what they can handle rather than what they need.

The most dangerous status report is not the one with red items on it.

It is the one everyone is comfortable with.

 

Four Practical Moves

The filter is not permanent. It is a learned behaviour, and learned behaviours can be unlearned. But reversing it requires something more specific than an open-door policy.

Stop asking questions that invite the managed answer. “How are things going?” will get you the curated version every time. Try instead: what is the one thing you would not put in a status report but think I should know? If this programme were going to fail, what would the early sign look like? What are we not talking about that we probably should be? Those questions signal that you are interested in the reality, not the performance of it.

Go to where the real work is happening. Not to inspect. To listen. The people closest to delivery carry an understanding of programme health that rarely makes it into formal reporting. A single honest conversation with a delivery lead or a technical team that has been carrying a quiet problem for weeks will tell you more than three months of steering committee updates.

Create a visible moment where surfacing difficulty is rewarded rather than merely tolerated. When someone raises something uncomfortable and your public response is genuine appreciation followed by a real conversation about what to do next, the entire room recalibrates what is safe to say. One moment like that shifts the culture more than any open-door policy ever will. The inverse is equally true: one moment where the messenger suffers sets the filter back months.

Learn to read silence as data. The steering committee where every question gets a confident answer. The risk log that has not changed in three weeks. The team that delivers polished updates but never raises anything unexpected. These things can mean a programme is running well. They can also mean the filter is fully operational and the real conversation is happening somewhere else entirely. If nobody is telling you anything that surprises you, that is not necessarily a sign that everything is on track. It may be a sign that you have stopped being the kind of leader people bring hard news to.

 

The One Question That Cuts Through

There is a question I now use when a programme looks clean but feels wrong.

I find someone close to the real work. Someone who has been there long enough to know where the bodies are buried. And I ask them one thing.

What does everyone here know that nobody is saying out loud?

The answer to that question is almost always where the programme actually is. The gap between that answer and what appears in the formal reporting is almost always where the real leadership work needs to happen.

 

Comfortable Information Is Borrowed Time

PMI’s research on complex programme delivery is consistent on this point: early warning signals are frequently present and frequently ignored, causing problems to compound in severity before they are addressed. The pattern is not exceptional. It is systematic.

Every week a real problem stays hidden is a week where the options for addressing it narrow. Manageable risks become serious ones. Recoverable situations become critical ones. And the longer the filter operates, the more the team’s trust erodes, because people who know the truth and watch it go unacknowledged eventually stop believing that leadership is operating in good faith.

When the programme finally tells you the truth, and it always does eventually, the question is rarely how to get back on track.

It is whether getting back on track is still possible.

 

The Leaders Who Get This Right

The leaders who consistently deliver in high-stakes environments are not always the most experienced or the most technically skilled.

But they share something that is harder to develop than either of those things. They have learned to want the truth more than they want to be comfortable. They have built the self-awareness to notice when they are receiving a managed version of reality, and the discipline to go looking for the unmanaged one. They have created environments where people bring problems early because they have learned, through consistent experience, that doing so leads somewhere useful.

That is not a natural state for most leaders. It requires sustained effort, genuine self-awareness, and a willingness to sit with difficult information and resist every instinct to make it someone else’s problem.

But the alternative is a programme that looks healthy until it does not. A team that has learned to give you what you can handle. A steering committee that runs on time and misses everything that matters.

When your team tells you how things are going, are they telling you what is happening?

Or are they telling you what they have learned you can live with?

The gap between those two answers is where most programmes are won or lost.

Why Western Delivery Frameworks Stall in the Middle East (and What to Do Instead)

Posted on by

 

I remember sitting across from a senior government official in the Gulf, about six weeks into a major transformation programme. On paper, everything was moving. The governance framework was in place. The workstream leads had been assigned. The project plan had been reviewed and signed off. The first steering committee had gone smoothly.

And yet nothing was actually happening.

Not because of incompetence. Not because of a lack of resources. Not because the methodology was flawed. The team I was working with was experienced, capable, and well-intentioned. But they had arrived with a delivery model built for a different context, and they were applying it with the confidence of people who had never had reason to question it.

That pattern is playing out at an extraordinary scale right now. Saudi Arabia’s ICT market surpassed $48 billion in 2024, the largest technology market in the Middle East. McKinsey’s 2025 State of AI in GCC Countries report, drawing on surveys of senior GCC executives, found that 84% of GCC organisations have adopted AI in at least one business function, and only 31% have successfully scaled or fully deployed across the organisation. That is a 53-percentage-point gap between starting and delivering, across some of the best-funded, most ambitious transformation programmes in the world.

The question is not why organisations in the region are investing. The question is why so much of that investment stalls between intention and outcome.

After more than a decade delivering in the Middle East, I think I know the answer. And it is not the one most people reach for.

 

The Assumption That Travels Badly

Western delivery frameworks, whether PRINCE2, PMI, SAFe, or the various proprietary methodologies that large consulting firms carry from engagement to engagement, are not neutral tools. They are cultural artefacts. They were built in specific organisational contexts, shaped by particular assumptions about how decisions get made, how accountability flows, how disagreement is handled, and what progress looks like.

Those assumptions are rarely stated explicitly. They do not need to be, in the environments where these frameworks were designed. Everyone in the room already shares them. But the moment you move those frameworks into a fundamentally different cultural context, the unstated assumptions become the problem.

Hofstede’s cultural dimensions research (now maintained by The Culture Factor Group) offers a useful lens here. Arab countries consistently score high on two dimensions that bear directly on programme delivery. The first is power distance: the degree to which authority is respected rather than openly challenged, and the degree to which the most senior voice shapes the room rather than the most technically accurate one. The second is uncertainty avoidance: a preference for predictability, a resistance to ambiguity, and a reluctance to surface risk that might destabilise a process already formally endorsed. These are not character flaws or cultural limitations. They are consistent patterns that predict specific delivery behaviours imported frameworks are simply not designed to manage.

The typical Western delivery model assumes a relatively flat decision-making structure where the person with the most relevant expertise speaks most loudly. It assumes that challenge and disagreement in a meeting are signs of healthy engagement rather than disrespect. It assumes that formal sign-off is the meaningful moment of commitment and that what is agreed in the room will be actioned after it. It assumes that timelines create accountability and that accountability creates action.

In the Middle East, several of those assumptions do not hold. And the teams that arrive without understanding this do not fail because they lack capability. They fail because they are solving the wrong problem.

 

What Actually Drives Delivery in This Region

Execution in this region is not primarily operational. It is relational.

This is not a cultural curiosity or a soft consideration to be acknowledged in a pre-departure briefing and then set aside. It is a delivery requirement. Understanding it, genuinely understanding it rather than paying lip service to it, is the difference between a programme that moves and one that generates activity without progress.

Decisions in many Middle Eastern organisations, particularly in government and quasi-government entities which dominate the regional landscape, do not flow through the formal governance structure in the way a Western framework assumes. The steering committee may ratify decisions, but the real alignment happens elsewhere. In relationships that have been built over time, in conversations that take place outside the formal meeting structure, in the space between hierarchy and trust that no project plan captures.

Hierarchy here is not an obstacle to navigate around. It is the delivery infrastructure. Understanding who the real decision-makers are, what they care about, how they receive information, and what kind of relationship needs to exist before they will move is not supplementary to the delivery approach. It is the delivery approach.

Equally, the pace at which genuine commitment forms is different. A Western programme manager reads a signed-off plan as a committed baseline. In many regional contexts, that same sign-off is closer to the beginning of a conversation than the end of one. Real commitment, the kind that produces action, is built through repeated engagement, demonstrated respect, and a track record of following through. It cannot be manufactured by a governance process, however well designed.

 

The Meeting That Agrees to Everything and Changes Nothing

One of the most consistent patterns I encounter when stepping into stalled programmes in the region is what I have come to think of as performative alignment. The meetings happen. The presentations are well received. The heads nod. The action items are recorded. And then the follow-through does not come, not because anyone has decided not to cooperate, but because the alignment that appeared to exist in the room was not the deep kind that produces action.

In high-context cultures, of which many in the Middle East are clear examples, direct disagreement in a formal meeting setting carries a social cost that most Western delivery professionals underestimate. Saying no to a proposal in front of a room of peers and seniors is not simply a professional difference of opinion. It can feel like a breach of the respect and harmony that the meeting is partly there to maintain.

The result is that concerns, reservations, and genuine blockers often do not surface in formal governance forums. They emerge later, in quieter conversations, or they do not emerge at all. The experienced regional delivery leader learns to read what is not being said in a meeting as carefully as what is. The silence after a proposal is not always agreement. The smooth meeting is not always a sign of progress.

Teams that do not understand this dynamic spend months wondering why a programme that looked aligned keeps stalling. The answer is usually that the alignment they measured was the visible kind, and what drives delivery here is the invisible kind.

 

Where International Teams Get It Wrong

The failure mode I see most consistently is not incompetence or arrogance, although both exist. It is the application of a known model to an unknown context, with too much confidence and too little curiosity.

The international team arrives. They bring the framework, the templates, the governance structure, the reporting cadence. They run the kickoff. They establish the workstreams. They hold the first set of meetings. Everything looks like it is moving. The client counterparts are polite, engaged, and apparently aligned.

Then the programme slows. Decisions that should take days take weeks. Approvals that seemed close keep getting deferred. Stakeholders who appeared committed become harder to reach. The team escalates. They add more governance. More reporting. More pressure. The programme slows further.

What they are experiencing is the consequence of building delivery infrastructure without first building relational foundations. They have a governance model without trust underneath it, and governance without trust is just paperwork.

The other common failure is treating local counterparts as recipients of the methodology rather than as partners in understanding the context. The best people in any regional organisation carry an understanding of how things actually work, who the real influencers are, where the genuine blockers sit, and what has been tried before and why it did not land. Engaging that knowledge seriously, rather than as a courtesy, would transform the delivery approach. Most international teams access about ten percent of it.

 

What to Do Instead

The answer is not to abandon rigour or to conclude that structured delivery does not work in the region. It does. But it works differently, and the sequence matters enormously.

The first investment, before the governance framework, before the project plan, before the first steering committee, is in relationships. Not networking in the transactional sense. Genuine relationship-building, rooted in curiosity and respect, that creates the conditions under which honest conversation becomes possible. In a region where trust precedes transaction rather than following it, the time spent on this is not a delay to delivery. It is the foundation of it.

The second shift is in how decisions are understood and pursued. Rather than designing a governance structure and expecting decisions to flow through it, the experienced regional programme leader maps the real decision-making landscape. Who are the individuals whose genuine endorsement will move things? What do they need to see, hear, or feel before that endorsement becomes real? What informal conversations need to happen before the formal ones? Answering those questions honestly, and building a relationship strategy around them, is more valuable than any governance framework.

The third adjustment is in how alignment is tested. Rather than reading smooth meetings and nodding heads as confirmation of commitment, effective regional delivery leaders build in deliberate mechanisms for surfacing the real picture. Private conversations with key counterparts after formal sessions. Trusted intermediaries who can carry honest feedback in both directions. An explicit understanding that the formal meeting is often where positions are displayed rather than where they are formed.

Fourth, the pace of delivery needs to be calibrated to the pace at which genuine alignment forms, not the pace that the project plan demands. This is uncomfortable for Western programme managers trained to treat a timeline as a commitment. But the cost of false pace, the appearance of movement without the substance of it, is far higher than the cost of taking the time to build the real thing.

Finally, and perhaps most importantly, local knowledge must be treated as a strategic asset rather than a logistical courtesy. The people who understand the organisation, the culture, the history of what has been attempted before, and the unwritten rules that govern how things actually get done are the most valuable resource on the programme. Structuring the delivery approach around that knowledge, rather than around the imported framework, is the shift that most changes outcomes.

 

The Deeper Lesson

Delivering in the Middle East has taught me something that has made me a better programme leader everywhere, not just in the region.

Context is not a complicating factor. It is the medium through which all delivery happens. Every organisation has its own version of the unwritten rules, the informal power structures, the historical sensitivities, and the cultural patterns that shape how work actually gets done. The Middle East makes these visible in ways that Western environments sometimes obscure, because the gap between the imported model and the local reality is large enough that you cannot ignore it.

But the principle is universal. The best delivery professionals I have worked with anywhere in the world are the ones who arrive with curiosity before they arrive with answers. Who treat understanding the environment as the first act of delivery, not a preliminary to it. Who know that a framework is a starting point, not a solution.

The frameworks that travel well are not the ones with the most sophisticated methodology. They are the ones held lightly enough to be adapted, by people self-aware enough to know when adaptation is what the moment requires.

 

A Final Thought

If you are leading a programme in the Middle East and it has the shape of movement without the substance of it, the instinct will be to add more structure, more governance, more reporting, more pressure. That instinct is usually wrong.

The question to ask instead is simpler and harder. Do the people who need to move this programme forward trust you enough to tell you what is actually in the way? Have you built the relationships that make honest conversation possible? Do you understand not just the governance landscape but the human one?

If the answer to any of those questions is uncertain, that is where the work is. Not in the framework. Not in the plan.

 

Pre-Mortem: Anthropic’s Wall Street Agentic AI Suite

Posted on by

 

Thirteen of the world’s largest financial institutions just deployed ten autonomous AI agents into the most regulated workflows in finance. None of them has publicly named who is accountable when the agents are wrong. Not the banks. Not the vendor. Not the regulators. The launch on 5 May reads like a milestone. Read closer and it reads like a stress test of every governance assumption the financial services industry operates on.

A post-mortem tells you why something failed once it already has. A pre-mortem asks the same questions before failure is possible. Same five questions, every time, applied to a current programme, announcement, or initiative. This is the first in the series, and the subject is not chosen by accident. The Anthropic Wall Street launch is the clearest example I have seen this year of capability racing ahead of the architecture meant to hold it to account. If you are a CIO, a CRO, or a transformation lead in a regulated industry, the lessons here apply to you whether you are deploying Claude or not.

 

The Bet

Anthropic and the deploying banks are betting that ten autonomous agents can land in the most regulated workflows in finance, underwriting, KYC, credit memos, statement audits, faster than the regulatory architecture can constrain them. The technical bet rides on Claude Opus 4.7’s 64.37% on the Vals AI Finance Agent benchmark and AIG’s quoted 88% accuracy on insurance claims out of the box. The strategic bet is that being first at this footprint, including JPMorgan Chase, Goldman Sachs, Citi, AIG, BNY, Carlyle, Mizuho, and Visa, outweighs whatever comes back from regulators in the next twelve months. Reasoned bets, made by an extraordinarily capable vendor and the most sophisticated buyers in the world. But they are bets, not certainties, and the launch reads as certainty. The CIO of any one of those banks is taking on operational, regulatory, and reputational risk for which the vendor has accepted no published share. That is the bet they should be examining most carefully.

 

The Assumption

One belief is doing all the work: that bank operating models can absorb ten simultaneously deployed agents without the human-in-the-loop quietly thinning where the agents prove reliable. Anthropic’s own commitment depends on it, from the primary announcement: “Users stay firmly in the loop, reviewing, iterating on, and approving Claude’s work before it goes to a client, gets filed, or is acted on.” The history of automation in regulated environments tells a different story. Algorithmic trading kill switches were not triggered because the system was performing. Automated underwriting reviews became rubber stamps once approval rates looked normal. Every automation failure in regulated finance follows the same arc: human oversight erodes invisibly as the system proves itself, and the erosion is only visible after the failure. JPMorgan CIO Lori Beer said it directly at the launch: “The technology can do so much. It’s the actual organization’s ability to digest and absorb it.” That ability is the load-bearing assumption. If it holds, the launch is a milestone. If it does not, the launch is a slow-moving incident.

 

The Sequence

Capability shipped. Ten named agents, Microsoft 365 generally available, Moody’s embedded, more than a dozen banks in production. What was committed before the operational governance for vendor-supplied agentic decisioning was published: all of it. Three weeks earlier, the Fed and the OCC revised Model Risk Management guidance and explicitly excluded agentic AI as “novel and rapidly evolving.” A Request for Information is planned, with no committed timeline. The EU AI Act’s high-risk financial-sector requirements take effect 2 August, twelve weeks after launch. The FCA and PRA decided against creating a dedicated AI Senior Management Function and instead mapped accountability onto existing SMFs that were never designed with autonomous agents in mind. Three jurisdictions. Three different gaps. One vendor launch landing in all of them at once. This is not a regulator being slow. This is a regulator explicitly stating that the rules do not yet apply, while the systems the rules are meant to govern are already in production.

 

The Pager

The banks have named regulatory accountability at the firm level. SMF24 (Chief Operations), SMF4 (Chief Risk Officer), SMF16 (Compliance Oversight) at FCA and PRA-regulated firms hold statutory responsibility for technology, risk, and compliance. Model risk owners at US firm level cover the same ground. Real, senior, public. That deserves credit. However, none of them have been publicly named for the deployment of these specific agents. Inheriting accountability through a job description is not the same as being named as the accountable owner of a programme. The first is the regulatory default. The second is what serious AI governance actually requires. Anthropic has no published vendor accountability commitment for autonomous regulated decisioning. The asymmetry is the entire story. When a Claude-built agent denies a loan that should have been approved, or approves a KYC file that should have been escalated, the pager rings at the bank, with consequences for the bank, while the vendor’s exposure is contractual and capped. The clearest demonstration came six days before the launch itself. On 29 April, Goldman Sachs removed Claude access for its Hong Kong bankers over contractual, regulatory, and geopolitical factors. The bank pulled the product. The vendor did not pull itself out. Whoever absorbs the cost when regulatory fit fails, absorbs it alone. Until vendor accountability is publicly framed, every bank deploying these agents is underwriting risk the vendor will not.

 

The Proof

Two outcome measures have been published. 64.37% on Vals AI. 88% on AIG insurance claims out of the box. Both are useful. Neither measures regulated-decision accuracy at scale. There is no committed measure for customer-detriment rate, near-miss frequency, incident reporting cadence to regulators, or the rate at which human reviewers actually amend agent outputs versus rubber-stamp them. The banks deploying these agents do not yet have public outcome commitments either, and that absence is its own answer. Former CFO Alyona Mysko captured what is at stake: “In finance, 99% correct is still wrong.” In eighteen months, the question “did this work?” will be answered by whoever owns the platform to define what work means. Right now, that platform is the vendor’s marketing. The banks need to claim that platform back, in their own outcome language, before the metric is set by a third party with no skin in their game.

 

Verdict

The launch is genuinely significant. More than a dozen named banks in production, industry-leading benchmark performance, audit logs in the Claude Console, the deepest Microsoft and Moody’s integrations any AI vendor has shipped. None of that is in dispute.

What is in dispute is whether the deploying banks have done the work to fill the accountability gap that the vendor has not closed and the regulators have not yet defined. The lesson generalises beyond Anthropic and beyond banking. Any CIO buying agentic AI in a regulated industry, healthcare, insurance, energy, the public sector, is operating in the same gap, and most have not yet noticed.

The action is concrete. Name the human in your organisation who carries the pager when the agent is wrong. Demand a vendor accountability schedule before you sign, not after. Define your own regulated-decision outcome measure and publish it, so the standard your performance is judged against is one you helped set.

If Anthropic publishes a vendor accountability commitment in the next six months, and a major bank commits to a public regulated-decision outcome measure tied to a named owner, this becomes a case study other industries will study for years. Without both, it becomes the most expensive procurement lesson the industry buys this decade.

The UAE Leads the World in AI Adoption. That Is the Easy Part

Posted on by

 

The UAE’s 70% AI adoption figure is everywhere. Conference keynotes open with it. Board papers cite it. Technology leaders in the region are being measured against it.

It is an impressive number. The UAE leads the world, ahead of a global average of just 17.8%. Government entities are reporting 97% AI tool adoption. Investment in AI infrastructure exceeded AED 543 billion across 2024 and 2025. The commitment is real, it is visible, and it is serious.

But a figure that measures how many people are using AI tools does not tell you whether those tools are being used well, safely, or in ways that will actually compound into competitive advantage. Right now, across the region, adoption has outpaced governance, capability, and leadership readiness by a significant margin.

That is the conversation worth having.

 

The Gap Between Using and Doing Well

A Fast Company Middle East report found that skills gaps, governance issues, and resource shortages are actively hindering AI projects across the UAE and Saudi Arabia. McKinsey found 88% of organisations globally now use AI in at least one business function. In a separate McKinsey study, only 1% of leaders called their own AI deployment mature.

Read that again. 88% usage. 1% maturity.

Most of the adoption conversation is measuring the first number. Almost nobody, anywhere, is meaningfully achieving the second.

This is not a reason for pessimism. It is a reason for precision. Because the organisations that close that gap are the ones that will extract genuine long-term value from the investments being made. The ones that do not will have impressive statistics and quietly disappointing outcomes.

 

What the 70% Figure Actually Measures

Adoption, in most surveys, means someone in the organisation is using an AI tool. It does not mean:

  • Those tools are connected to meaningful business outcomes
  • There is a governance framework determining how AI agents operate, with what access, and under what oversight
  • Leaders understand the capability well enough to ask the right questions of it
  • The organisation has redesigned workflows around AI rather than simply layered it on top of existing ones
  • There is a plan for what happens when something goes wrong

“Adoption measures presence, not performance. A Copilot licence in every seat is not a transformation. It is a starting point.”

 

 

What Sits Underneath the Headline Number

The organisations that will genuinely lead in this environment are not the ones chasing the adoption number. They are the ones building what sits underneath it.

Three things separate the organisations that will compound this investment from the ones that will stall.

  • Governance before scale. As AI agents take on more autonomous tasks, the permission architecture, oversight mechanisms, and human confirmation requirements need to be established before deployment at scale, not retrofitted after something goes wrong. Look at the incidents of the last eighteen months. Production databases deleted. Cloud environments wiped in seconds. All of it the consequence of deploying capability ahead of governance.
  • Leadership readiness, not just technology literacy. Most AI adoption programs focus on upskilling employees to use tools. Far fewer focus on equipping leaders to make good decisions about AI: what to deploy, what oversight to maintain, what risks to accept, and what questions to ask the vendors selling them the infrastructure. “Technology literacy and leadership readiness are not the same thing.” Confusing the two is one of the most common and costly mistakes being made right now.
  • Workflow redesign, not workflow overlay. The organisations getting lasting value are not the ones that added AI to existing processes. They are the ones that redesigned the process around what AI can actually do. That requires change management discipline, not just technology deployment.

 

The Region Has the Ambition. Now It Needs the Architecture.

The UAE’s strategic commitment to AI is not in question. A 543AED billion investment, a world-first framework to deploy agentic AI across government, a national curriculum introducing AI literacy from school level. These are not the moves of an economy dabbling. This is a serious long-term play.

That is exactly why the governance and capability conversation matters so much right now. The investment is in place. The infrastructure is being built. The adoption numbers are world-leading.

The question is not whether the UAE is committed to AI leadership. It clearly is. The question is whether the organisations operating within that environment are building the internal foundations to convert the headline numbers into durable, compounding advantage.

A 70% adoption rate is the beginning of the story, not the destination.

 

The Organisations That Will Lead Are Already Asking Different Questions

They are not asking how to get their adoption rate up.

They are asking what good looks like once they get there. Who is accountable for how their AI agents behave. What their governance architecture looks like for the autonomous systems they are deploying. What they are actually measuring to know this is working.

Those organisations will not be the loudest voices at the next conference. They will be the ones with something real to show for it in three years.

The UAE’s 70% AI adoption figure is everywhere right now. It is genuinely world-leading, and it is not the number that should be keeping leaders awake at night.

Globally, 88% of organisations use AI. 1% have reached actual maturity. That is the gap worth talking about, and the organisations closing it are not the ones chasing higher adoption rates.

The question I keep coming back to: if your organisation is sitting in that 70%, who is actually accountable for how your AI agents behave once they are deployed?

The Architecture Is the Problem, Not the Agent

Posted on by

 

Every time an AI agent causes a catastrophe, the conversation goes to the same place. What did the AI do wrong? Can these systems be trusted? How do we stop it happening again?

Those are the wrong questions. And the wrong questions lead to the wrong fixes.

The better question, the one that actually leads somewhere useful, is this: who built the environment where it could happen?

 

Three Incidents. The Same Root Cause.

PocketOS, April 2026. An AI coding agent found an unscoped API token sitting in an unrelated file. It used that token to delete a storage volume on Railway, their infrastructure provider. It did not check whether the volume was shared across environments. It was. Production database and every backup, gone in nine seconds.

Replit, July 2025. An AI agent deleted over a thousand executive records during an explicit code freeze. Nothing stopped it because nothing had been configured to stop it.

Amazon Kiro, December 2025. An AI agent inherited a senior engineer’s elevated permissions, the kind that would normally require two people to sign off on a destructive action. It deleted and recreated an entire cloud environment. Thirteen-hour outage.

In every case, the agent did something it was technically permitted to do. Not something it was asked to do. Something it could do, because the architecture said it could.

That is not an AI failure. That is a design failure.

 

We Are Asking Questions About the Wrong Moment

The instinct to interrogate the AI is understandable. These systems are new, they are powerful, and when they cause damage the natural response is to look at the machine.

But that framing lets the actual problem off the hook. In each of these incidents, someone made decisions about credential storage, access scopes, permission inheritance, and whether destructive actions should require human confirmation before execution. Those decisions created the conditions. The agent had the speed and autonomy to find the gap before anyone noticed it was there.

“The incident is never the origin.” Every one of these failures has a human design decision sitting upstream of it.

 

CIOs and CTOs Own This

This is where the conversation needs to land, and where it rarely does.

CIOs and CTOs set access models. They decide, or delegate the decision about, what credentials AI agents can reach, what permissions they inherit, and whether irreversible actions require a human confirmation step. These are not AI product decisions. They are infrastructure and governance decisions of the kind that technology leadership has been making for years.

The least-privilege principle has been a security standard since the 1970s. Every process should have only the access it needs and nothing more. We have applied it carefully to service accounts, automated pipelines, and human users for decades. We are not applying it with the same rigour to AI agents. The gap is showing up in production.

 

Three Questions That Determine Your Exposure

If you are deploying AI agents and cannot answer these clearly, you have a governance problem. It is a matter of when, not if.

  • Are your AI agents operating on minimum permissions? Or are they inheriting ambient credentials that happen to be accessible in the environment? Unscoped tokens stored in accessible files are a credential hygiene problem. AI agents now have the speed to exploit them in ways a human operator simply would not.
  • Do irreversible actions require human confirmation before execution? Not a log entry after the fact. A genuine gate, before the command runs. Deletion, overwrites, production deployments. These should not be single-step autonomous operations regardless of how capable the agent is.
  • What is the blast radius? Before any AI agent is deployed, you should be able to answer: what is the worst thing this agent could do with the access it currently has? If that question gives you pause, the deployment is not ready.

These are not new questions. They are the questions we have always asked about automated systems. The difference is that AI agents are faster, more capable of creative problem-solving, and more likely to find an unintended path that nobody anticipated during design.

 

Governance Does Not Require a New Platform

Much of the current enterprise AI governance conversation focuses on model behaviour: hallucination, bias, output quality. Those are real concerns. They are not the ones that will delete your production database.

The vendors now selling AI governance infrastructure are not wrong about the problem. But executives should make their own assessment of what their environment actually needs. “Governance does not require a new platform. It requires applying principles you already know to systems you are now deploying.” When vendors know the renewal depends on value delivered rather than fear managed, the conversation changes quickly.

 

The Agent Did Not Design the Environment

The uncomfortable fact sitting underneath every one of these incidents is that the AI agents involved were, in a narrow technical sense, doing their jobs. They identified a problem and attempted to fix it. They used the access they had. They executed what was permitted.

The humans who made the architectural decisions upstream of those moments are the ones who need to answer for the outcomes.

You cannot fix an architecture problem by retraining the model.

Your Project Isn’t Behind Schedule….Your Culture Is

Posted on by

Every project has two timelines.

The first one lives in the plan. It has milestones, dependencies, resource allocations, and a go-live date that everyone has committed to in the presence of leadership. It is colour-coded, regularly updated, and presented with confidence at every steering committee.

The second one is invisible. It is being negotiated silently, every day, by the culture surrounding the project. It moves at the speed of trust. It stalls at the friction points of unresolved conflict, political caution, and the gap between what people say in a workshop and what they actually do when they return to their desks.

The first timeline is managed with precision. The second one is almost never managed at all.

And yet, in almost every failing project I have witnessed across 20 years of complex programme delivery, it was the second timeline that determined the outcome.

“The project was a symptom. The culture was the condition. And we spent the entire time treating the symptom.”

The Invisible Force Shaping Every Project

Culture is not a soft concept. It is not the values statement on the intranet or the tone of the all-hands presentation. It is the accumulated weight of how decisions actually get made, how conflict actually gets handled, and how safe people actually feel when they need to say something that the room does not want to hear.

When that culture is aligned, transparent, and psychologically safe, the effect on project velocity is extraordinary. Decisions happen faster because people trust the process. Problems surface earlier because raising them feels safer than absorbing them. Teams move with a coherence that no methodology can engineer, because the invisible conditions that enable collaboration have been built into the environment.

When the culture is misaligned, fragmented, or fear-driven, the opposite is true. And the destruction is systematic. It operates in every layer of the project simultaneously, and it is almost impossible to diagnose from a status report.

How Culture Creates the Ebbs and Flows

If you have delivered a complex project, you will recognise the pattern even if you have never named it in cultural terms.

The project starts well. There is energy in the kick-off. Stakeholders attend. Leadership is visible. The novelty of the initiative creates a temporary social cohesion that feels like alignment but is actually closer to politeness. People show up. The culture cooperates, at least on the surface.

Then comes the middle phase. The novelty fades. The real work begins to create friction with existing priorities, existing reporting lines, and the existing distribution of power within the organisation. This is where the culture stops pretending and starts expressing itself.

  • The stakeholder who supported the project in principle begins finding reasons why each individual decision needs further review.
  • The team that attended every workshop begins quietly reverting to the processes the project was designed to replace.
  • The escalation that should have reached the steering committee disappears somewhere in the middle management layer, because the culture has an unspoken norm that problems travel upward only when they are already solved.
  • The two departments that were supposed to collaborate begin protecting their own interests, because the project has started to expose a territorial conflict that existed long before any of this began.

None of these dynamics appear on a risk register. They do not generate a red status in the weekly report. They show up instead as decisions that take longer than expected, deliverables that require more rework than they should, and a general sense that the project is moving through something viscous, that progress requires more energy than the plan anticipated.

This is not a project management problem. It is a cultural one. And the distinction matters enormously, because the tools you use to fix a project management problem will not address a cultural one. More governance does not resolve a territorial conflict. More reporting frequency does not create psychological safety. A revised timeline does not fix a leadership vacuum.

“Culture doesn’t self-correct. It calcifies. And it takes your project with it.”

The Myth of Self-Correction

One of the most expensive assumptions in organisational life is that cultural problems, if managed carefully and given enough time, will eventually resolve themselves. That the tension between two departments will settle once both sides see the project delivering results. That the resistant stakeholder will come around once the early wins become visible. That the team will find its rhythm.

I have never seen this happen. Not once, across 20 years and dozens of complex programmes.

What I have seen, repeatedly, is this: cultural dynamics are self-reinforcing. The silo that existed before the project started will be deeper after it ends, unless a leader has actively and deliberately intervened. The resistance that began as scepticism will harden into obstruction unless someone with sufficient authority named it, engaged with it, and changed the conditions around it.

Choosing to wait and see on a cultural problem is not a neutral decision. It is an active choice to allow the problem to compound. And at some point in every project timeline,  often somewhere in that difficult middle phase, a compounding cultural problem crosses a threshold beyond which recovery becomes genuinely unlikely, regardless of what the project plan says.

Why Top Leadership Cannot Afford to Delegate This

This is where the responsibility conversation becomes uncomfortable.

Most senior leaders understand, intellectually, that culture matters. They have read the research. They can quote the statistics. They believe, in principle, that cultural alignment is a prerequisite for successful delivery.

And then they appoint a capable programme manager, approve the governance framework, set the reporting cadence, and quietly exit from the environment that will determine whether the project succeeds.

They remain present for the milestone reviews. They sign off on phase completions. But the cultural conditions that are either enabling or strangling delivery, the political dynamics, the unresolved departmental conflicts, the leadership behaviours creating drag at every level, those remain unaddressed. Because they are harder to put on a slide than a RAG status.

The problem is that no programme manager in the world has the authority to fix what only senior leadership can. A project manager can flag a cultural risk. They cannot resolve a conflict between two executive stakeholders. They can surface a pattern of passive resistance. They cannot change the norm that makes resistance feel safer than engagement. They can manage the process. They cannot change the environment.

“The culture of a project is a direct reflection of the culture of the organisation. And the culture of the organisation is set, every day, by the behaviours of its most senior leaders.”

When leadership is genuinely present in a project, not just at steering committees, but in the informal conversations, the moments of ambiguity, the points where the culture is deciding how to respond to a challenge, the trajectory changes. Not because of any specific intervention, but because the culture takes its signal from what leadership pays attention to, tolerates, and rewards.

When leadership is absent from those moments, the culture fills the vacuum with its own defaults. And the defaults are almost always conservative, territorial, and risk-averse. Exactly the opposite of what a complex change project requires.

What Active Cultural Leadership Looks Like in Practice

This is not an argument for leaders to become project managers. It is an argument for leaders to understand that sponsoring a project and leading its cultural environment are two different responsibilities, and that only one of them can be delegated.

Active cultural leadership in a project context looks like this:

  • Naming the cultural dynamics that are creating drag,  not as project risks, but as organisational behaviours that leadership is choosing to address.
  • Creating visible and consistent accountability for the behaviours the project requires, not just the deliverables it produces.
  • Being present at the moments when the culture is deciding how to respond to difficulty, and modelling the response you need it to make.
  • Making it safe for the people closest to the work to surface the real picture, not the managed version of it.
  • Understanding that alignment at the top does not automatically produce alignment throughout, and actively working to close that gap.

None of this is comfortable. It requires a kind of candour about the organisation’s own cultural health that many leadership teams find easier to defer than to confront. It requires treating the cultural environment of a project as a leadership responsibility rather than an HR consideration. And it requires accepting that the most powerful variable in project delivery is not the methodology, the technology, or the talent. It is the environment in which all three are being asked to operate.

The Question Worth Asking

The next time a project in your organisation begins to slow, when the milestones start slipping, when the energy in the team shifts, when the steering committee updates start sounding more optimistic than the reality on the ground, resist the instinct to look first at the plan.

Ask instead: what is the culture around this project telling us?

Is it telling you that people feel safe enough to surface the real problems? Or that the real problems are being managed privately, because surfacing them carries too high a risk?

Is it telling you that the organisation is genuinely aligned behind this change? Or that the alignment is a performance, present in the steering committee and absent in the daily decisions of the people who actually have to deliver it?

Is it telling you that the conditions for this project to succeed have been built into the environment? Or that the project has been launched into a culture that was never prepared for what it requires?

The answers will tell you more about where your project is actually heading than any Gantt chart you have ever reviewed. And they will tell you something else, something harder to hear but more important to act on:

“The project is not behind. The culture is. And that is a leadership problem, not a project management one.”

If this resonated, explore more at scottz.com or connect with me on LinkedIn.

What 20 Years of High-Stakes Delivery Taught Me About Execution, and the Difference Between Programme Management and Programme Leadership

Posted on by

 

I have stepped into programmes where every governance box was ticked, every RAG status was green, and delivery was quietly failing. The plan looked solid. The reporting was clean. The steering committee meetings ran on time. And yet nothing was really moving.

That pattern, visible control with invisible dysfunction, is what two decades of high-stakes delivery teaches you to recognise. And it almost always comes back to the same root cause. We confuse programme management with programme leadership.

 

Programme Management Keeps Things Moving. Programme Leadership Makes Them Work.

Most organisations lean heavily into programme management, and it is easy to see why. Detailed plans, governance frameworks, status reports, risk logs, and steering committees all create a sense of order and control. On paper, everything looks under control.

The problem is that I have stepped into too many programmes where all of that existed and delivery was still failing. Because structure creates visibility, not outcomes. Programme management is fundamentally about control, while programme leadership is about direction, alignment, and energy. One tracks progress while the other makes progress possible. That distinction is where most organisations fall short, not because they lack process, but because they mistake process for leadership.

 

Context Shapes Execution

Here is something that even experienced delivery professionals often underestimate. Execution does not happen in a vacuum. It happens inside a specific organisation, a specific culture, and a specific set of relationships and unwritten rules that no governance framework will ever fully capture.

I have watched highly capable teams arrive with world-class frameworks and strong delivery disciplines and still struggle to get real traction, not because their methodology was wrong, but because the environment was not properly understood. They received agreement in meetings but silence where there should have been challenge. Risks that everyone privately knew about went unsurfaced because the conditions for honest conversation had not been established.

Delivering across the Middle East over the past decade has made this especially clear to me. Execution here is not just operational, it is relational. How trust is built, how decisions are really made, the importance of respect and hierarchy, and the pace at which genuine alignment actually happens are not soft considerations. They are delivery requirements. When you get them right, conversations become honest, decisions become clearer, and alignment becomes real. When you ignore them, execution becomes performative, with activity replacing progress.

The same principle applies in any environment where you are leading in unfamiliar territory. Understanding context is not optional at this level. It is the difference between a programme that moves and one that stalls.

 

The Biggest Mistake: Managing Metrics Instead of People

When delivery starts slipping, most organisations respond in a predictable way. More reporting, more tracking, and more pressure. It feels like a logical response, but it is usually the wrong one, because metrics do not deliver programmes. People do.

I have seen programmes sitting on green dashboards right up until the moment they fail, not because the data was falsified, but because what was not being measured was what actually mattered. Team fatigue, misalignment between stakeholders, lack of psychological safety, and quiet disengagement do not show up in a status report. When people are treated like a line item, engagement drops, ownership fades, and quality begins to slip long before the timeline does. Burn a team out and you do not just lose pace. You lose the judgment, initiative, and honesty that high-stakes delivery fundamentally depends on. No dashboard captures that, but every experienced programme leader eventually learns to recognise it.

 

The Gap Between Manager and Leader Is Where Execution Breaks

This is the gap that most organisations do not even realise they have. They promote strong managers and expect leadership to follow, but the two are not the same thing and they do not produce the same results.

Managers tend to focus on tasks, deadlines, and maintaining control over the plan. Leaders focus on clarity, alignment, and removing the obstacles that prevent capable people from doing their best work. A manager’s primary question is whether the programme is on track. A leader’s primary question is what is getting in the way. That difference sounds subtle, but in practice it determines whether a programme survives pressure or collapses under it.

The best delivery environments I have worked in were not the most heavily governed. They were the most honest. When people feel clear about what success looks like, trusted to make decisions, safe enough to surface problems early, and genuinely supported when things get difficult, they perform at a level that no governance framework can manufacture. When those conditions are absent, no amount of process or reporting will compensate for it.

 

Execution Is a Human System, Not a Delivery Framework

After 20 years, this is the conclusion that becomes impossible to argue against, even if it takes time to fully accept. Execution is not primarily a technical problem. It is a human one.

You can have the right tools, the right frameworks, and the right governance model in place and still fail to deliver if you do not have trust, alignment, cultural awareness, and a team that still has the energy and conviction to push through difficulty. The principles that have held true across every programme I have led, recovered, or stepped into under pressure are consistent. Clarity beats complexity, because people cannot deliver what they do not fully understand. Context and culture are not optional, because they shape how work actually gets done regardless of what the plan says. Sustainable pace matters more than most organisations are willing to admit, because the cost of burning people out shows up in quality long before it shows up in a timeline. And leadership has to be visible not just at the top, but across the programme at every level where real decisions are made and real obstacles are felt.

 

Closing Thought

You can manage a programme perfectly and still fail to deliver it. Execution is not about control. It is about people, and the environment you create around them. The organisations that understand this tend to deliver. The ones that do not keep searching for a better framework when the answer was never in the framework to begin with.

Process Mining in Healthcare: Turning Complexity into Clarity

Posted on by

Healthcare is perhaps the most complex ecosystem on the planet. Unlike banking or retail, where processes are mostly transactional and predictable, healthcare is built on human lives, high-stakes clinical decisions, and layers of regulation.

Every patient journey generates a massive trail of data across admissions, diagnostics, treatment, and billing.

The problem is that most healthcare organizations are drowning in that data but starving for actual visibility. They know the data exists, but they lack a cohesive view of how work actually happens on the ground. This leads to bottlenecks and delays that do more than just drive up costs. They undermine the patient experience.

This is where process mining, comes in. It is a discipline that takes raw data and turns it into a living map of your operations, showing you the reality of your workflows rather than the idealized versions found in your policy manuals.

 

The Traffic Control Problem
Think of a large hospital as a city. Every department is a different neighborhood: pharmacy, radiology, surgery, finance. The patients are the citizens moving through the intersections. If the traffic signals do not sync or if shortcuts are hidden, the result is total chaos.

Process mining acts as the traffic control system for this “city.” It uncovers the hidden routes and signals exactly where the blockages are happening. Unlike a manual audit or a staff survey, process mining relies on the actual digital footprints left in your systems. It moves you away from assumptions and toward a factual, end-to-end view of the patient journey.

 

The Structural Barriers to Change
Digital transformation in healthcare is never just a technology play. It is a cultural and structural battle. You are often dealing with legacy systems that do not talk to each other, creating silos where information goes to die.

You also have to consider the human element. Clinicians are already stretched to their limit. If you ask them to adopt a new tool without showing them how it actually makes their lives easier, you will face immediate resistance. Then there are the stakes. Patient data is incredibly sensitive, making security and compliance a constant, necessary drag on speed. These are the reasons why so many expensive digital projects fail. They layer new technology over broken processes.

 

Where the Real Value Hidden When you apply process mining thoughtfully, you start to see opportunities where there was previously only frustration.

  • Fixing Patient Flow: You can identify exactly why a discharge is delayed or why a lab result is sitting in a queue. If there is a bottleneck, process mining tells you if it is a staffing issue, a system lag, or a procedural flaw.
  • Optimizing the High-Cost Areas: Operating theatres are some of the most expensive hospital assets. In radiation oncology, process mining revealed planning delays that, when fixed, significantly improved throughput and reduced time-to-treatment for patients.
  • Safety and Compliance: In clinical pathways, deviations can be a matter of life or death. Process mining allows for real-time monitoring of treatment protocols, reducing risks for both the patient and the organization.
  • Cutting Administrative Bloat: Claims and procurement processes are often riddled with waste. Research combining Kaizen with process mining has shown how these inefficiencies can be wiped out to create sustainable improvements.
  • Better Outcomes for Patients: Every efficiency gain translates to faster, safer care. Work done on older adult patient journeys shows how identifying systemic choke points can free up capacity across the entire system.

The Foundation for the Future Many leaders see process mining as a “fix-it” tool for inefficiencies. It is actually much more than that. It creates a digital twin of your operations. This provides a foundation for everything that comes next, including AI-driven analytics and automation. You cannot automate a process that you do not fully understand.

The Bottom Line Healthcare is at a crossroads. Costs are rising and resources are thinner than ever. Digital transformation is no longer a luxury, but without clear visibility, your technology investments are just expensive guesswork.

Process mining does not just show you where the cracks are. It gives you the data you need to repair them and the ability to monitor the progress in real time. The result is a hospital that runs like a coordinated ecosystem, giving clinicians more time to do what they do best: care for patients.

How to Ensure Product and Project Teams Work Well Together

Posted on by

Product vs. Project Teams: How to Stop the Friction and Start Delivering

In many organizations, there is a quiet but constant tension between product and project teams.

It is a classic tug-of-war. Product managers are focused on the “what” and the “why,” obsessing over user value and long-term vision. Project managers are focused on the “how” and the “when,” managing timelines, resources, and the reality of deadlines.

When these two forces are out of sync, the results are predictable: missed milestones, feature creep, and a team that is burnt out from trying to serve two different masters. But when they work in harmony, they create a high-velocity engine for innovation.

If you want to move beyond the friction, you have to stop treating these as competing functions and start treating them as two sides of the same coin. Here is how to align your product and project teams for maximum impact.

 

1. Define the Boundaries of Responsibility
The biggest source of conflict is overlapping territory. If the product manager is trying to manage the sprint schedule and the project manager is trying to prioritize the backlog, everyone gets frustrated.

You need clear roles. Product is the guardian of the strategy and the customer voice. Project is the guardian of the execution and the operational flow. When leadership sets the tone for these roles, it removes the guesswork and allows each professional to focus on what they do best.

2. Align on the “North Star” Metric
Friction often happens because teams are being measured by different metrics. Project teams might be rewarded for hitting a specific date, while product teams are rewarded for adoption rates.

To bridge the gap, you need a shared definition of success. Both teams should be anchored in the broader business strategy. If a deadline must be missed to ensure a feature actually solves a customer problem, that should be a collaborative decision based on value, not a battle between “delivery” and “discovery.”

3. Build a Culture of Continuous Communication
Silos are where transformation goes to die. If your product and project leads only talk during formal status meetings, you have already lost.

Effective teams build “radical transparency” into their daily rhythm. This means project managers are involved in discovery sessions to understand the “why” behind a feature, and product managers are involved in resource planning to understand the constraints of the “how.” This shared context prevents the “vision gap” that derails so many digital projects.

4. Manage the “Dependency Dragon” Together
Technical debt and complex system dependencies are not just IT problems. They are the primary obstacles to both product innovation and project delivery.

When product and project teams ignore these hidden issues, they end up with a roadmap that is impossible to execute. By treating technical debt as a shared priority, you can allocate time for “foundational” work that makes future delivery faster and more reliable. This is where augmentation, using tools to simplify these complexities, becomes a strategic advantage.

5. Focus on Outcome, Not Output
A project is “done” when the code is shipped. A product is never really “done.”

Shifting the mindset from output (shipping features) to outcome (solving problems) changes the dynamic between the teams. It moves the conversation away from “Did we hit the date?” to “Did we achieve the impact?” This shift requires leadership to value adaptability over rigid adherence to a plan.

 

The Bottom Line The most successful organizations do not have “product vs. project” cultures. They have “delivery” cultures.

When you stop fighting over who owns the roadmap and start focusing on how to serve the customer better, the friction disappears. You stop being a collection of silos and start being a unified team that is capable of building things that actually matter.

Why Deadlines Aren’t Enough: The Case for Purpose-Driven Project Goals

Posted on by

Why Deadlines are the Wrong Scoreboard for Project Success

For decades, the corporate world has worshipped at the altar of the deadline. Success has been reduced to a single, binary question: did you ship on the date you promised? This obsession with the calendar has created a generation of project managers who are experts at checking boxes but often fail to deliver actual business value.

While timelines are necessary, they are not a guarantee of success. A project delivered exactly on time that fails to solve a customer problem or align with the company’s mission is, by definition, a failure. Worse yet, a deadline-first culture breeds burnout and kills creativity. When the only goal is speed, teams stop thinking about impact and start thinking about survival.

True success is measured by the value you create, not by the date you finished.

 

The Trap of the “Done” List
In many organizations, teams move in a constant state of pressure. They rush through deliverables and overlook user experience just to hit a milestone. This “output over outcome” mindset is exactly how companies end up with digital transformation projects that fail to achieve their intended results.

When you prioritize the date over the purpose, you incentivize people to cut corners. You might get the software out the door by Friday, but if no one uses it because it doesn’t fit the workflow, you have wasted your most valuable resources.

 

The Power of Purpose-Driven Goals
Shifting to a purpose-driven approach means anchoring every task in a clear vision. When a team understands the “why” behind their work, their entire perspective changes. They move from being order-takers to being problem-solvers.

Take a digital transformation initiative as an example. If the goal is simply to “launch the system by Q3,” the team will focus on technical checkboxes. But if the goal is to “reduce patient wait times by twenty percent,” the team will make better strategic decisions about user interface and data flow. They will prioritize what actually moves the needle.

In this model, deadlines do not disappear. Instead, they become milestones that guide progress rather than rigid constraints that stifle innovation.

 

How to Lead with Purpose
Transitioning away from a clock-watching culture requires a deliberate shift in leadership. It involves moving from managing tasks to managing impact.

  1. Define the Problem First: Before you set a date, define the impact. What is the one thing this project must achieve to be considered a success? If the team understands the problem, they will find the most efficient way to solve it.
  2. Align Every Stakeholder: A purpose-driven project requires radical transparency between product and project teams. Everyone from the executive level to the front-line staff needs to be bought into the “why.”
  3. Measure Value, Not Velocity: Tracking points or dates is easy, but it is often misleading. Measure success by tangible improvements. Are users more engaged? Is the workflow smoother? Is the chaos turning into clarity?
  4. Reward Adaptability: Markets move faster than project plans. If a project needs to pivot to stay aligned with its purpose, that should be celebrated as a win, not punished as a delay.
  5. Celebrate the “So What”: When you reach a milestone, don’t just celebrate the completion. Celebrate the result. Show the team how their work actually changed the business.

 

The Bottom Line
The most impactful projects are not just completed on time. They are completed with a purpose that survives long after the launch date.

Ask yourself: is your team racing toward a date on a calendar, or are they moving toward something that actually matters? If you want to build a high-performance culture, you have to stop managing the clock and start managing the mission.