Change Management Was Built for Projects. Your Organization Is Not a Project.

Witnessed Trust — Everyday Futurism

For ten years, I cancelled duplicate forms.

Not because anyone thought it was a good use of my time. I was among the most highly paid, most specialized people in the department. And a meaningful portion of my week went to cleaning up administrative errors because people are bad at filling out forms. One transaction could generate five or six versions. We would wait until one was in good order, then cancel the rest.

We said, repeatedly, that this was wrong. That the risk was minimal. That the answer was automation, not us. The response was a shame report.

Every period, leadership would run the numbers. How many duplicates still logged. Who had not cleared their queue. Then distribute the results. There were always two or three of us making the same argument. The organization heard it as resistance.

I cleared my queue within 24 hours of every report. Not before. I was not going to be proactive about work I had told them for years was a structural waste. Full compliance. No concession.

It took ten years. Then new technology automated the entire process. The whole system was eliminated as soon as the automation was live.

The frontline concern was right the whole time. And for a decade, the response was a metric that converted "why does this work exist" into "why haven't you cleared your queue." The shame report was not a solution. It was a way of managing dissent dressed up as performance management.

That is what I mean when I talk about the gap between due diligence and interrogation.

Why change management keeps failing

There is an assumption buried inside every change management engagement. Rarely stated, but it structures everything: that change has a beginning, a middle, and an end. That once you reach the destination, the work is done.

This assumption made sense when it was built. It does not describe the environment most organizations are operating in now.

Change is no longer a project. It is a permanent condition. AI adoption, workforce restructuring, market volatility, regulatory shifts. These are not discrete initiatives with completion dates. They are overlapping, ongoing, and they do not wait for the previous change to finish before arriving. Organizations trying to navigate this with a project mindset are using the wrong tool. And the cost is not just operational. It is cultural.

Who change management is actually for

Here is the part nobody says out loud. Change management arrives after the decision. It is deployed on the people who have to live with the outcome. Even when it is done well and humanely, the structure is the same: leadership decided, change management delivers. The frontline role is to receive and adopt.

That is not a flaw in the execution. It is the design. Change management is a tool of the decision-makers, not the people affected by the decision. And frontline staff know this. They have seen it before. They file their concern under resistance before anyone even labels it that way, because they already understand what the process is for.

Many of the most widely used models, including ADKAR, are built specifically to help decisions land. That is not a criticism. It is the job description. The issue is not competence. It is that helping a decision land and asking whether the decision should be reconsidered are structurally incompatible goals. You cannot do both at once. And most change management frameworks do not try.

Which means that when frontline staff raise concerns, and they always do because they are closest to where plans meet reality, those concerns get categorized as resistance to manage rather than intelligence worth taking seriously. The concern gets a listening session. A FAQ. A town hall. None of which is designed to ask whether the concern is right.

By the time the project fails, the change management firm has moved on. The investigation finds execution failure, market conditions, bad timing. Not the fact that the warning signs were there from the beginning and the process was designed to smooth them over.

A $2 million lesson in building for the wrong audience

A contact and knowledge management system — software that tracks client relationships, documents staff interactions, and surfaces how work is actually happening — was built to do something genuinely useful.

The consultation to design it was cherry-picked. The people in the room were the people who knew what leadership wanted to hear. No one challenged the direction. No one asked whether it could be built differently. No one was paid to find out what would actually make frontline staff want to use it.

It could not sort by broker. It could not sort by third-party vendor. The people who would live in it daily were not asked how they worked. The people who commissioned it got exactly what they wanted: something impressive. Something that demonstrated the scale of their vision.

Two million dollars.

Adoption was then mandated through shame. We spent $2 million on this, therefore you have to use it. People used it when it finally contained information they could not get anywhere else. Not a day before.

The suppression happened in the consultation, before a single line of code was written. The wrong people were in the room, and the right people knew better than to say so.

What the Assumption-Ground Audit actually is

The Assumption-Ground Audit is a way of finding whose concern was overlooked before a decision was finalized, and understanding exactly how that happened.

Not: what did we decide, and how do we get people on board?

But: whose concern would have changed this decision if it had been heard? What made it possible to not hear it? And who benefited from the silence?

The audit looks at the documents organizations do not think to protect. The training materials built for managers before a rollout. The FAQ and what questions it pointedly does not answer. The town hall recordings and which questions got deflected. The working folders that contain the actual deliberation rather than the polished announcement.

It looks for what is missing as much as what is there. And it talks to frontline staff last, after the official record has been mapped, because by then you know what you are holding.

They are almost never surprised it failed.

When what you suppress stops being a project problem and becomes a culture problem

In a project model, suppressing a frontline concern has a bounded cost. The project fails or succeeds. The investigation runs. The organization moves on.

When change is ongoing, and there is no completion date and no future state that signals you have arrived, the suppression does not stay bounded. The frontline staff who raised the concern and watched it get translated into a FAQ and a listening session do not file it under "that one project." They file it under how things work here. The concern that did not land becomes the staff who learned not to raise concerns. The lesson the organization takes is not "we missed something." It is "this is the kind of place where certain things do not get said."

And then the next initiative begins. And you hire the change management firm into that culture.

The problem that started as a project risk has become the way the organization operates. You cannot run another engagement over the top of it and expect different results. You have to go underneath it, back to where the assumption first hardened, back to whose concern first did not land, and surface what got buried before it gets carried forward again.

How the cycle breaks

The organizations that navigate ongoing change without accumulating this kind of damage share something. Their leaders do not outsource the interrogation.

Not to the change management firm. Not to the communications team. Not to the engagement survey. They go directly to where the assumption meets reality. They ask frontline staff not "are you on board" but "what do you know that this decision does not account for." They treat the answer as intelligence rather than resistance. And when it is load-bearing, when it actually changes the calculus, they say so publicly. They slow things down. They absorb the friction that creates.

That is what generates witnessed trust. Nobody had to be told that leader listens. They watched it happen. In a meeting, in a decision that got revisited because someone three levels down said something that turned out to be true.

Witnessing is not about being in the building. It is about the quality of attention you bring to what is happening versus what is being reported as happening. That is what separates the leaders who find the problem before it becomes a culture from the ones who inherit it.

What the Assumption-Ground Audit is not

It is not a listening tour. It is not a way to make people feel heard while the decision proceeds unchanged. It is not a kinder version of change management.

It is a forensic process for finding what did not get held. The concern that was real. The voice that was structurally prevented from registering. The assumption that was never tested because testing it would have slowed something down or complicated the narrative.

Organizations resist giving it the access it requires because the honest record of how a decision was made is also the record of what got suppressed and who did the suppressing.

Which is precisely why it matters. And why change management, however well-executed, cannot do this work. It was never built to.

The Assumption-Ground Audit is a methodology developed through Everyday Futurism. If your organization is navigating the gap between a decision that has been made and the concerns that have not been resolved — book an intro consultation.