The ceremonies of a scaling framework are a trust-manufacturing machine. Run them as theater, and they manufacture only the appearance of trust while the real thing drains away.

The most quietly devastating moment in a transformation program is rarely about budget or architecture or scope. It is a senior business leader concluding, without drama, that engaging with the transformation is no longer a good use of their time — and simply stopping. Not being difficult. Being honest. Deciding to re-engage only once the delivery side has sorted out its own priorities, rules, and responsibilities, and quietly withdrawing until then.

When the people a transformation is supposed to serve disengage from it, the program has lost, regardless of how the delivery metrics look. This business–digital divide follows a recognizable arc: skepticism hardens into fatigue, fatigue into distrust, distrust into withdrawal. By the time it shows up as a disengaged stakeholder, it has usually been building for a long time.

What makes this especially worth understanding is that modern scaling frameworks are, underneath the mechanics, built precisely to prevent it. Alignment and transparency are among the core values of the Scaled Agile Framework, and almost every ritual it prescribes — bringing business and delivery into the same planning room, demonstrating working software on a fixed cadence, having business leaders assign value to what teams commit to — exists to keep the two sides in a trusting, reciprocal relationship. The divide opens anyway, and it opens through a specific failure: running the ceremonies as form while starving them of the substance that was supposed to make them work.

Credibility debt: the promises that came before you

Most business–digital divides do not start with the current program. They start with the last one, and the one before that.

Enterprise transformation is rarely anyone’s first attempt. By the time a given initiative kicks off, the business stakeholders have usually been promised similar things before and watched those promises go unmet. This creates what might be called credibility debt — a running balance of skepticism that every new program inherits whether it earned it or not. A leader who was promised a basic reporting view a year earlier and is still doing the work by hand in a spreadsheet is not describing a feature request. She is describing why she no longer believes the next promise.

Credibility debt is brutal because it is invisible on the project plan and fully present in the room. A team walks in believing it has a fresh start; its audience is carrying a year of unmet commitments the team had nothing to do with. Here the framework is clear about the only thing that pays the debt down. Working software is the primary measure of progress, and the recurring System Demo — the ritual of showing real, integrated, working capability on a fixed cadence rather than talking about it — exists precisely to convert promises into evidence at regular intervals. Credibility debt is repaid one demonstrated increment at a time, or it is not repaid at all. Roadmaps do not touch it.

Fatigue: when the collaboration stops being reciprocal

The second stage is fatigue, and it has a specific cause. Business stakeholders are asked to invest real time — workshops, interviews, reviews, definitions — and what they get back is uncertainty: shifting priorities, unclear ownership, more meetings. The exchange stops feeling reciprocal.

A leader who quietly halves their involvement in a collaboration because it has stopped feeling reciprocal captures the mechanism exactly. She is still willing to contribute; she is not willing to contribute at full intensity to a program that keeps returning ambiguity for effort. Her half-time is not laziness. It is a rational reallocation of a scarce resource — her attention — away from something that has stopped paying her back.

This is precisely the reciprocity that a well-run planning cadence is designed to protect. In a healthy program increment planning event, the business shows up to give context and priorities, and the teams give back a concrete, committed plan and a confidence vote in the same session — effort in, a real answer out, on a predictable rhythm. Cadence exists to make the exchange feel reliable and mutual. When the ceremonies run but the reciprocity is missing — when the business invests the time and still leaves without clarity — the ritual becomes one more meeting that takes and does not give, and fatigue is the entirely rational result. A lot of programs misread this signal as the business being uncooperative or resistant to change. Almost always it is the opposite: the business was cooperative, invested, and got too little back, and is now protecting itself.

Withdrawal: the retreat to the workaround

The third stage is withdrawal, and it is often disguised as pragmatism, because that is exactly what it is. When the transformation is not delivering, the business does not sit and wait. It goes back to what works: the manual process, the personal spreadsheet, the local workaround. At least those produce something today.

The tragedy is that this retreat is individually sensible and collectively fatal. Each leader who returns to a spreadsheet is making a reasonable decision. But every one of those decisions further hollows out the transformation’s mandate, because the program was justified on the premise that the business needed it. When the business demonstrates, through its behavior, that it can limp along without it, the case for the whole endeavor quietly weakens. In framework terms, this is the Business Owner — the very role meant to steer value and accept outcomes — voting with their feet. A program can survive a lot, but it cannot survive its own Business Owners deciding it is optional.

Withdrawal is not limited to the obvious stakeholders. The functions whose buy-in is most essential — often the upstream ones, engineering or product or operations, whose data and standards everything else depends on — are frequently the first to disengage and the hardest to notice, because they were never loudly in the room to begin with. When a critical upstream function “takes a backseat” for a year while workshops define backlogs it never engages with, the whole value stream is incomplete, and everything downstream is quietly blocked by a group that has opted out. Organizing around value, rather than around functional silos, is supposed to pull those functions in; when it is not actually done, the silo simply stops participating and no ceremony compensates for the hole.

The behaviors that widen the divide

Alongside this arc, specific behaviors on the delivery side reliably make the divide worse. Each is, notably, a place where a framework’s discipline has been dropped.

The first is presenting instead of delivering. When a program is under pressure and behind, it often produces more artifacts about the work — slides, plans, frameworks, roadmaps — as a substitute for the work itself. To the delivery team this feels like progress. To a fatigued business audience it reads as evidence that nothing real is coming. This is exactly the failure the System Demo was invented to prevent: the discipline of showing working software every iteration exists so that presentations can never quietly substitute for tangible output. When a program has to be told, as a corrective, to “come with a working prototype, not a PowerPoint,” what has really happened is that the System Demo stopped being enforced and slideware rushed into the vacuum. Every slide-only review widens the divide, because it asks the business to spend more belief without giving them anything to believe in.

The second is re-litigating settled decisions. In a low-trust environment, decisions do not stay decided. A definition agreed in a working session gets reopened weeks later, often by someone who was not in the room, and the group re-derives the same conclusion at great cost. Teams return, again and again, to the same first-principles arguments — what is a customer, what counts as an account, what does the metric mean — not because the questions are genuinely unresolved, but because no one trusts the previous resolution enough to build on it. Two framework disciplines exist to stop this: getting the right people into the planning event so conclusions are not later overturned by absentees, and the Inspect and Adapt workshop, where problems are solved once, structurally, rather than re-argued endlessly in the margins. Re-litigation is what fills the gap when both are neglected.

The third is territoriality, and it is the most structural. In a multi-unit enterprise, standardization asks each unit to give up something it controls — its own system, its own definitions, its own customer master — in service of a shared outcome. That feels like loss, and units resist it, sometimes by guarding their turf and sometimes by quietly standing up their own parallel version of whatever the program is building. It is not rare for two groups to be building essentially the same capability without knowing about each other, or for one department to begin constructing a second copy of a shared process it will eventually have to consolidate. Territoriality is not pettiness. It is what happens when people are asked to sacrifice control without enough trust in the shared thing to make the sacrifice feel safe — which is why organizing genuinely around value, with the affected units actually in the room, is a precondition and not an afterthought.

Closing the divide

The divide is not closed with communication plans or stakeholder-management slides. It is closed by changing the actual experience the business has of working with the delivery organization — which, not coincidentally, is what the framework’s rituals are for when they are run in substance rather than form.

The first move is to deliver something small and real before asking for more belief. Because the business is carrying credibility debt, the only currency that spends is demonstrated reality. One genuinely useful thing, shown working, does more to rebuild trust than any number of roadmaps. This is the whole point of “working software over comprehensive documentation” and of the System Demo: give a fatigued audience evidence, on a cadence, and let the evidence do the arguing.

The second move is to protect the reciprocity of the exchange. Every time the program asks the business for time, it owes them something visible back within a reasonable horizon. Cadence is the mechanism — a reliable rhythm where investment reliably produces a concrete answer. If that loop cannot be closed, it should not be opened. Nothing produces fatigue faster than repeatedly asking busy people to invest in a process that returns ambiguity.

The third move is to make decisions stick. Re-litigation is a trust problem wearing a process costume. When a decision is made, capture who made it and who was in the room, treat reopening it as an exception that requires new information, and route recurring problems through a real Inspect and Adapt rather than the hallway. An organization that can make a decision stay decided gives the business solid ground to build on instead of sand.

The fourth move is to make the shared thing safe enough to be worth the sacrifice. Territoriality recedes when units trust that the shared platform will serve their objectives and not quietly serve someone else’s at their expense. That trust is built by involving them in the decisions that affect them — organizing around their value, not around the program’s convenience — and by demonstrating, again through delivered reality, that standardization gives them something better than what they gave up. You cannot argue a unit out of protecting its turf. You can only make the shared alternative trustworthy enough that protecting the turf stops being the smarter move.

The people are the transformation

The lesson worth keeping is that a transformation is not, at its core, a technology program or a process program. It is a change in how a large number of people work, and those people get a vote — not a formal one, but the most powerful one there is. They vote with their attention and their belief. When they withdraw both, the program can keep running for a long time on momentum and budget, but it has already lost the thing it needed.

This is where the framework and the wisdom finally meet. Every ritual a scaling framework prescribes is, in the end, a machine for manufacturing trust between the business and the people building for it: planning together, demonstrating working software, assigning value out loud, inspecting and adapting in the open. But the machine only produces trust if it is fed substance. Run PI Planning without the business truly present, hold a System Demo with slides instead of software, let decisions be reopened at will, and the ceremonies produce a convincing appearance of alignment while the actual relationship keeps draining. The House of Lean puts respect for people and culture at its foundation for exactly this reason: the ceremonies sit on top of a culture, and no cadence of meetings can manufacture a respect that the organization does not actually extend.

The signals are never hidden. They are people quietly halving their involvement, people going back to their spreadsheets, people saying they will care once the delivery side sorts itself out, whole functions quietly taking a backseat. It is tempting to read these as resistance to be managed, or as ceremonies to be scheduled more rigorously. They are almost always feedback to be heeded — an accurate report on whether the transformation has been worth the people’s time. The programs that recover stop trying to manage the disengagement and start earning back the engagement, one delivered, reciprocal, decision-that-stuck at a time. The people were never the obstacle. They were the point.

• Gravatar