What happens when cooperation stops correcting problems and starts protecting them — and how to know when it is time to escalate
Most serious professional crises will not begin with something that looks like a crisis. They begin with a perfectly reasonable request.
Could you move this deadline forward? Could you approve this version for now and we will fix it later? Could we leave that objection out of the minutes because we have already spent too much time discussing it? Could you be a little more flexible? Could we call this activity a pilot because the reporting deadline is approaching? Could we avoid making the risk sound so dramatic? Could everyone please focus on solutions?
None of these sentences is inherently sinister. Complex projects survive through compromise, improvisation and a considerable amount of people repairing things that were not supposed to break. Anyone who has worked in a complex project knows that the beautifully ordered Gantt chart created at proposal stage tends to develop a rather imaginative relationship with reality approximately fifteen minutes after implementation begins.
The difficulty is recognising when normal project friction has become something fundamentally different.
There is a large grey territory between a badly managed project and a project that requires formal escalation. That territory is unsettling because competent people are usually trained to solve problems rather than formalise them. We negotiate. We explain. We rewrite. We offer another meeting. We absorb somebody else’s delay because the overall result matters more than proving who caused it. We avoid escalating because escalation sounds adversarial, and most of us would rather be known as the person who rescued the work than the person who wrote the complaint about it.
For a long time, this instinct is healthy. Projects would become impossible if every missed deadline, irritating colleague or questionable decision triggered a governance process. A difficult personality is not automatically an institutional problem. A badly chaired meeting is not always misconduct. An inaccurate sentence in a draft report is not necessarily cheating. If those were the thresholds, cooperation would require a small tribunal permanently attached to every Zoom link.
But there is a point at which continuing to be “collaborative” can become a way of helping a serious problem survive.
The moment the problem changes
A project crosses an important threshold when disagreement is no longer about how to do the work, but about whether the organisation can truthfully, safely or professionally stand behind what is being done.
One of the clearest warning signs is a growing distance between the official record and observable reality. Perhaps a deliverable is described as complete when substantial work is still missing. Perhaps a pilot is reported before the conditions for meaningful testing exist. Perhaps a revised timetable removes months of delay, creating the impression that downstream partners simply became inexplicably slow. Perhaps minutes record consensus where there was substantial objection.
One isolated error can be corrected. A pattern is different.
The second warning sign appears when normal correction mechanisms stop functioning. You raise a factual problem and receive no answer. You provide evidence and the conversation moves to your tone. You ask for a decision in writing and are told that everyone already understands what was agreed. You propose a technical safeguard and are told that the process is becoming too complicated. You request realistic time and are reminded of the budget. Slowly, the discussion moves away from the substance of the objection and toward the inconvenience of the person making it.
This is often where organisations make a mistake. They assume escalation is justified when somebody behaves badly. Usually it is not. The more important question is whether the behaviour is beginning to interfere with professional judgement, safety, financial integrity, compliance or the accuracy of the institutional record.
A rude email is unpleasant. Pressure to certify work you believe is incomplete is different. A hostile meeting is exhausting. Pressure to release something you believe could harm users is different. Being ignored is frustrating. Discovering that an official record no longer reflects what happened is different.
The distinction matters because formal escalation should never become a sophisticated version of an argument between colleagues. It exists because some problems eventually become larger than the interpersonal relationship in which they first appeared.
AI makes the threshold much easier to see
Artificial intelligence makes this problem unusually visible because AI systems can look convincing long before they are ready.
In a recent project, we were responsible for technical work on a conversational AI system intended to interact with vulnerable users around emotionally sensitive and mental-health-related material. The system depended on a substantial body of content that arrived almost a year later than the technical sequence had assumed. By the time that material was finally available in usable form, the project calendar had not somehow acquired an extra year out of sympathy. The same work still had to happen; it had simply been compressed into a much smaller space.
Internal testing made the problem more concrete. At one stage, the system was performing satisfactorily in roughly six interactions out of ten. That figure was never presented as a universal legal threshold for AI safety, because no such magical percentage exists. What mattered was what could be sitting inside the remaining four interactions: hallucinated information, inappropriate reassurance, failure to recognise a crisis signal, unsafe handling of emotionally sensitive content, inconsistent behaviour across languages, or a response that sounded calm and competent while being clinically or contextually wrong.
A calm-sounding answer from an AI is not automatically a safe answer.
That is where the ordinary language of project delivery begins to break down. A completed interface can be demonstrated. A chatbot can produce several impressive answers in front of a room. A launch event can be photographed. None of these things proves that the system has been adequately validated for vulnerable users.
Responsible AI work involves less photogenic activities: stabilising the source material, mapping its boundaries, validating languages, testing high-risk scenarios, establishing human escalation routes, checking privacy controls, red-teaming the system and exposing it gradually under controlled conditions. Much of the output of that work is evidence that the system should not yet be released.
Under deadline pressure, that can make safety look suspiciously like delay.
And once safety begins being treated as the obstacle rather than the condition of responsible delivery, project management has become a governance problem.
Four conditions that should make you pay attention
We now think of the escalation threshold as the point where several conditions begin converging rather than as one dramatic incident.
The first is material risk. The problem affects users, safety, money, contractual obligations, compliance, professional responsibility, reporting integrity or another area where “we will sort it out later” is no longer a harmless management preference.
The second is documentary instability. The official record begins moving away from the implementation history you can actually evidence. What people later read in reports, minutes, plans or timelines is no longer simply an imperfect summary of reality; it is becoming a materially different version of it.
The third is failure of ordinary correction. The issue has been raised clearly. Evidence has been supplied. A reasonable route to correction has been offered. The people responsible have had an opportunity to fix it. Yet the same problem continues, is minimised, is reframed as a personality issue or reappears in another document.
The fourth is transferred responsibility. You are being asked, explicitly or implicitly, to sign, certify, approve, release or remain associated with something that you cannot professionally defend.
One of these conditions may still be manageable through ordinary project work. When all four begin appearing together, it is worth becoming much more deliberate about what happens next.
Do not confuse conflict with misconduct
This distinction deserves emphasis because difficult projects generate a great deal of ordinary human unpleasantness.
People become impatient. They defend their work. They communicate badly. They misunderstand each other across languages and professional cultures. They occasionally write emails that would have benefited from being left in drafts overnight. None of this automatically requires formal escalation.
Ego also exists in organisations in quantities currently unregulated by the European Union.
The threshold is not that people have become irritating. It is that the conflict is beginning to change what can safely or truthfully be delivered, approved, reported or released.
That is why a professional disagreement about whether an AI feature is elegant enough belongs in normal implementation, while pressure to expose an inadequately validated system to vulnerable users may not. A disagreement about meeting style is interpersonal. A pattern in which material objections repeatedly disappear from the formal record is institutional. An argument over who caused a delay may be tedious but ordinary; a timeline that removes the delay while preserving its downstream consequences can become a reporting issue.
The important question is therefore not, “Has this project become unpleasant?”
It is, “What would continuing without escalation now require us to accept?”
Would you need to sign something you do not believe is accurate? Would you need to release something you consider unsafe? Would your organisation’s name remain attached to a statement you cannot defend? Would you be assuming responsibility for consequences created by decisions you explicitly advised against?
When the answer becomes yes, preserving harmony is no longer a neutral choice.
Do not escalate your anger. Escalate the problem.
There is another distinction worth making. The strongest escalation is rarely the most emotional one.
When people have spent months being ignored, blamed or pressured, the natural impulse is to explain everything. Every contradictory email. Every insulting comment. Every missed deadline. Every meeting where somebody said something outrageous. By the time a formal complaint becomes necessary, the person writing it may possess enough accumulated frustration to produce a document roughly the length of a minor Russian novel.
Unfortunately, institutions cannot act on indignation nearly as easily as they can act on evidence.
The useful first move is to strip the problem down. What was required? What actually happened? What evidence establishes that? Why does the discrepancy matter? What correction was requested? What happened after that request?
This sounds almost offensively calm when the underlying situation is anything but calm. That is precisely the point.
If an official document says one thing and contemporaneous records show another, the strongest sentence is often not “they lied.” It is: “The official record states X. The contemporaneous record shows Y. Please reconcile the two.”
If a technical team believes a system is unsafe, the useful question is not whether management “cares about safety.” It is: What validation has been completed? Which required tests remain outstanding? Who has authority to waive them? On what basis? Who assumes responsibility for the consequences?
If a decision is disputed, the question is not who behaved worst in the meeting. It is whether informed approval exists and where it is documented.
The more serious the problem becomes, the less theatrical the evidence should become.
The strangest stage: when the problem becomes you
There is a recognisable moment in many failing governance systems when the organisation stops discussing the inconvenient information and starts discussing the inconvenient person.
Why are they making everything so complicated? Why can they not just cooperate? Why are they always sending formal emails? Why do they keep asking for things in writing? Why are they slowing the project down?
This psychological shift is understandable. A person who keeps reintroducing reality into a convenient narrative is exhausting. Unfortunately, reality retains a surprisingly stubborn veto.
The danger is that social pressure can start performing an operational function. If raising a technical objection repeatedly leads to public criticism, threats to reallocate tasks, impossible deadlines or accusations of disloyalty, the professional cost of saying “no” increases. Eventually people begin adjusting their judgement not because the evidence has changed, but because resistance has become expensive.
That is why hostility matters in a project crisis even when no single hostile remark appears catastrophic. The important question is not whether someone was rude. It is whether the environment is making independent professional judgement harder to exercise.
What to do before the formal escalation
The first response should usually be quieter than people expect.
Preserve the record. Separate facts from interpretations. Keep fulfilling the obligations you can fulfil. Correct inaccurate statements promptly and without embellishment. Where an important verbal instruction affects safety, money, reporting or responsibility, confirm it in writing. When a deadline is impossible, explain why in operational terms rather than simply refusing it. When somebody asks you to remove a safeguard, ask which safeguard they are asking you to remove and who authorises that decision.
Most importantly, stop trying to win every meeting.
Meetings are useful for solving problems between people who broadly agree that reality is binding. When that assumption weakens, the objective changes. Your task is no longer to produce the perfect argument that finally makes everyone understand. Your task is to ensure that an accurate, contemporaneous institutional record exists from which a competent third party could later understand what happened.
That is a very different form of work.
And it is the point at which a difficult project begins becoming a governance case.
Why we are writing this now
This is not theoretical for us.
During the past year, REDefine crossed this threshold inside a live international project. What began as ordinary implementation difficulty gradually became a collision between almost a year of delayed inputs, disputed reporting, an AI system working around sensitive mental-health content, vulnerable users, pressure to accelerate closure, contested project records and an increasingly hostile working environment.
We tried ordinary correction first. Then stronger internal correction. Then institutional escalation. Eventually, the matter reached the funding authority.
The project is still active, and we have deliberately removed its name, programme, institutions, countries and individuals from this essay. That is not because the details are unimportant. It is because the lesson is considerably more useful than the identities.
For Inner Circle readers, however, we want to show what actually happened: where we realised the project had crossed the line, what evidence changed our strategy, how we separated implementation from the dispute, how we dealt with disputed reporting and an unsafe technology timeline, why we stopped arguing in meetings, how we structured the escalation, what we asked the funding authority to do, what we deliberately refused to do, and what happened afterwards.
More importantly, we want to explain the practical part that rarely appears in project-management guidance: how to behave when you suspect something genuinely serious has happened, how to preserve your own credibility, what evidence is actually useful, how to refuse without becoming the obstruction, how to recognise when informal communication itself has become a risk, and how to ask an institution for remedies it can realistically provide.
Because there is a substantial difference between knowing that you should escalate and knowing how to do it without destroying yourself, and if possible, the project you are trying to save.
The difficult part begins after you decide to escalate
Knowing that a project has crossed the line is only the beginning. The harder question is what to do next without weakening your own position, damaging the project, or becoming the person everyone conveniently labels “the problem.”
In the full Inner Circle edition, we open the case completely: the AI safety conflict, the reporting contradictions, the pressure to accelerate an unready system, the evidence architecture we built, the communication strategy we used, the escalation path we followed, the mistakes we deliberately avoided, and what the funding authority ultimately did.
It is a practical case study in how to navigate a project crisis when ordinary cooperation is no longer enough.
Subscribe to REDefine’s Inner Circle to unlock the full article and the complete escalation playbook.
