Change saturation is not a communication problem

On a major S/4HANA transformation, the first signs of trouble did not look like resistance. They looked like missed stand-ups. Then deliverables started slipping, readiness checkpoints came back with gaps and the same functional leads kept surfacing on the list of competing priorities.

The people behind those signals were not disengaged. They were functional resources supporting the implementation while still doing their day jobs. At the same time, the organization was adopting Agile ways of working, so they were also learning new project roles, Agile ceremonies, Jira, new testing expectations and new processes. Many of them held real authority in their day jobs that did not carry over into their transformation roles, which meant they were learning to operate without the standing they normally relied on.

When teams fell behind, the response from leadership was reasonable on its face: more meetings, more follow-ups, more frequent status updates. The intent was to get the program back on track. What I watched happen instead was that the same people responsible for completing the work spent more of their week explaining why the work was behind.

That is the pattern most organizations miss. Change saturation gets diagnosed as a communication gap, and the treatment consumes the capacity the team needs to recover.

What misdiagnosed saturation looks like on the ground

Saturation rarely announces itself in an engagement survey. It shows up first in delivery mechanics, and those signals are easy to read as a discipline or messaging problem.

The first signal is erosion in attendance, not pushback. Stand-ups get missed, ceremonies get shorter and the same names drop off invitations. Nobody is objecting to the transformation. They are triaging their calendars.

The second signal is status work crowding out delivery. When a growing share of a team’s week goes to preparing updates, attending check-ins and answering follow-ups, the program has started paying for visibility with the capacity it needs for execution.

The third is readiness gaps that get labeled as training issues. People who attended the sessions still are not ready, because the sessions competed with everything else on their plate and landed at the wrong moment.

The fourth is easy to overlook on global programs: capacity assumptions that do not match the actual calendar. On more than one program, the roadmap accounted for U.S. holidays and overlooked holidays affecting large portions of the teams in India, South America and other locations. The plan was built on capacity that was never there, and the gap surfaced weeks later as slipped dates.

Taken together, these signals point to the same root cause. The work did not get harder. The load did. Yet each signal is usually treated as a separate performance issue and handled with more oversight.

None of this is unusual. In Prosci’s research on change saturation, 78 percent of respondents said their organizations were nearing, at or past the point of saturation, and people managers and front-line employees carry the heaviest load. Those are the same people a transformation depends on to adopt and operate what it delivers.

Why more communication makes it worse

When a program falls behind, the executive instinct is to increase pressure around the existing dates. Add a working session. Increase the cadence of status reporting. Ask for more frequent communication so leadership can see what is happening.

Every one of those moves is made with good intent, and every one of them draws from the same limited pool of time. The people being asked for more updates are the people who were already stretched. On a program adopting Agile at the same time, the added forums sat on top of stand-ups, planning sessions and retrospectives the teams were still learning to run. Visibility goes up, capacity goes down and the program slips further. It also changes how the team experiences the program. Instead of support, they experience scrutiny, and people already carrying two jobs start to feel that the program mostly adds questions.

There is a line I use with leadership teams when this starts to happen:

When a team is behind, the instinct is often to add oversight. But every additional status meeting takes time away from the work you’re trying to accelerate.

Communication and visibility matter. They do not solve an underlying capacity problem, and sometimes they deepen it. Gartner found that only 32 percent of business leaders said the last change they led achieved healthy adoption by employees, and Gartner has argued that leaders get further by making change routine than by trying to inspire people through it. Saturation is a load problem. Louder or more frequent messages to an overloaded team do not reduce the load.

What actually relieves saturation

The moves that worked on my programs were less about new frameworks and more about giving capacity back.

Adjust the operating model as teams mature. Early go-lives needed frequent stand-ups, heavy training and hands-on support. After teams had been through multiple S/4HANA go-lives and understood the process, we deliberately reduced the cadence. Daily meetings became four days a week and eventually two. Holding on to the early-phase cadence after teams had outgrown it would have been another quiet drain. Reducing meetings on a program that has just slipped feels counterintuitive. It requires leadership to trust the dashboards and the team more than the meeting count.

Protect time when the team is on track. On one program, we kept Mondays and Fridays free of meetings when the work was on schedule. It signaled that the time belonged to the work, and teams used it.

Make upcoming work visible instead of asking for more reporting. Readiness dashboards showed what was coming, and we gave advance notice when phases were changing so people could plan around the shift rather than react to it. The dashboards did the job the extra status meetings were trying to do, without taking anyone out of the work.

Make support available without requiring attendance. Recorded training, multiple sessions and office hours let people get targeted help when they needed it without adding another meeting to everyone’s week.

Understand the change landscape before launching the next initiative. That means surveying employees and listening beyond the executive level to the functional teams who will do the work. Executives tend to see initiatives one at a time. Employees experience their cumulative impact alongside their day jobs. Research highlighted in MIT Sloan Management Review found that employees can realistically absorb one or two major changes a year, while leaders are planning for three or four. A short survey of the functional teams will usually surface collisions a portfolio view misses, because those teams feel every initiative that lands in the same week.

The principle behind all of this is one I come back to on every program: “You can’t ask people to absorb more change without giving them something back.”

For CIOs, change saturation is a portfolio decision, not a communications task. CIOs sit where multiple initiatives converge on the same functional teams, and they are often positioned to see the cumulative load before anyone else does. The decisions that relieve saturation are theirs to shape: what gets sequenced first, what waits, what cadence a mature team actually needs and whether the capacity assumptions behind a roadmap match the real calendar.

One practical test helps. Before approving the next initiative or the next status forum, ask which work the affected teams will stop doing to make room for it. If nobody can answer, the capacity is being borrowed.

The organizations that sustain transformation across multiple waves are not the ones with the best change campaigns. They are the ones that treat capacity as a constraint to be managed with the same discipline they apply to budget and scope.

You can’t communicate people into having more capacity. You can only decide, deliberately, how much change you ask them to carry at once.