Planned in Pieces, Delivered in a Heap.

Part 1: The pile nobody sees

Picture an ordinary month in the working life of a service agent. Nothing dramatic happens in it. There is no go-live, no new system, no project with a launch date and an executive sponsor. It is just a month.

In the first week, Salesforce updates itself. A couple of screens load in a slightly different order, and a button she uses dozens of times a day has moved. In the second week, the admin team adds a new field to the case record, because the operations director wants to report on a new category of complaint. Her manager, separately, asks the team to keep a particular list view up to date ahead of a quarterly review. In the third week, an email arrives inviting her to try an AI assistant that has been switched on as a pilot. And at the end of the month, following a reorganisation two floors up, the way escalations are handed over changes, so a step she used to do is now done by somebody else. Except when it isn't.

Every one of those changes is small. Every one of them is reasonable. Every one of them has an owner who could stand up in a meeting and explain exactly why it was necessary. And by the end of the month, she is slower than she was at the start. She has stopped trying things she isn't sure about, and she checks with the colleague beside her before she does anything unfamiliar.

At some point, someone senior will look at the usage figures for that AI pilot, or at the gaps in that new field, and conclude that the team is resistant to change.

Resistance is the most convenient diagnosis in transformation. It is convenient because it places the problem inside the people rather than inside the organisation. And it asks nothing of leadership except more persuasion: another communication, another reminder, another session to explain the benefits. In more than ten years of working with Salesforce users across a dozen countries, I have met genuine resistance, but far less often than the word gets used. Most people want to do their job well. What I see far more often is people coping.

Here is what is really going on. In most organisations, change is planned in pieces and delivered in a heap.

Each piece has an owner. The vendor owns the release. IT owns its backlog. The project team owns its rollout. The operations director owns the new field, and the manager owns the request for the list view. Each owner looks at their own change, judges its size, decides it is manageable, and in isolation they are right. What nobody looks at is the total. There is no single place where every change landing on one role in one month is added together. There is no meeting where anyone asks the question that matters most: what else is this team absorbing right now?

The only person who experiences the total is the user. And she doesn't experience it as a programme. She experiences it as a string of interruptions to a working day that already had enough in it. She doesn't get a change plan. She gets a Tuesday.

This is why change management so often seems to work in the project room and fail on the floor. Every individual change passes its own test. It was communicated, it was approved, perhaps it was even trained. But adoption isn't decided one change at a time. It is decided by how much capacity people have left once everything else has been absorbed. When the pile gets high enough, people do what any sensible person does under pressure. They protect the core of their job and let everything else wait. The new field gets a placeholder. The AI pilot gets ignored. The list view gets updated when someone chases. From the top, that looks like resistance. From the floor, it is triage.

I would go further. When leaders mistake triage for resistance, they almost always respond by adding more. More communications, more reminders, more mandatory sessions, more fields to track whether people have done what was asked. Each of those is well intended, and each of them lands on the same pile it was meant to clear. The cure becomes part of the condition.

None of this is an argument for organisations to stop changing. Salesforce will keep evolving, businesses will keep reorganising, and AI is not going away. The point is that change has a cumulative cost, and that cost is paid almost entirely by the people who had the least say in it. Somebody needs to see the total.

There is a simple way to start. Pick one role in your organisation. List every change that has reached the people in that role over the last three months: platform updates, new fields, new reports, new tools, process tweaks, structural changes. Not just the programmes with a name and a budget, but the small requests as well. Most leaders who try this aren't surprised by any single item on the list. They are surprised by how long the list is.

And here is the uncomfortable part. If the pile is too high for the people doing the job, you might reasonably assume that the people whose job it is to keep up, the admins, consultants and specialists, at least have it under control. Increasingly, they don't either. And that tells us something important about what we are really asking of everyone else.

Part 2: If the experts can't keep up, what chance has the rep?

Spend time with Salesforce professionals at the moment and you will hear something that would have been almost unthinkable a few years ago. Admins, consultants and architects, people whose entire job is to understand this platform, will admit, usually quietly, that they can't keep up. Announcements arrive faster than anyone can absorb them. Products are renamed, repositioned and merged. Capabilities that were the highlight of one keynote are reworked by the next. People who built careers on knowing Salesforce inside out now describe a constant feeling of being slightly behind.

I recognise that feeling. I have been in this ecosystem for more than ten years, and a meaningful part of my working week goes on understanding what has changed. There are still weeks when I feel the ground shift under me.

Now think about who we expect to absorb those same changes with no time set aside at all. The sales rep, between calls. The service agent, with a queue building in front of her. The field engineer, in a van between jobs. We give the specialists release notes, preview environments, communities and whole days to work through what is new. We give the user a surprise on a Monday morning.

If the people paid to keep up are struggling, the people paid to do something else entirely never stood a chance. Not because they are less capable, but because keeping up was never their job, and nobody made it anybody else's.

That gap produces one of the strangest patterns I see in organisations that have used Salesforce for a while. The longer people use it, the less of it they explore.

You would expect the opposite. Experience should build confidence, and confidence should build curiosity. A rep in her fourth year should be using more of the platform than she did in her first month, not less. But in organisation after organisation, experienced users have narrowed their use to a handful of things they know will work, and they stay there.

The reason is not laziness and it is not age. It is something people learn from experience. When the system changes around them often enough, without warning or explanation, they conclude that it is unpredictable. And people use unpredictable systems defensively. They stop clicking on things they aren't sure about, because the unfamiliar is where the surprises live. They don't try the new feature, because the last new thing they tried left them with a problem they had to explain to a customer. They lean on the one colleague who seems to know. They do the minimum, and they do it safely.

So the platform gets more capable every year, and the people using it get more cautious. Each change adds a little capability to the system and, in many organisations, takes a little confidence away from the user. Over time, the gap between what the organisation pays for and what its people actually use doesn't stay still. It widens.

That leads to a conclusion that sounds backwards, but which I'm increasingly sure is true. The more change you push at people, the less of the platform they use.

It sounds wrong because every individual change is supposed to make things better, and many of them genuinely would. But adoption doesn't respond to the quality of each change. It responds to how people experience change as a whole. When that experience is relentless, unexplained and impossible to keep up with, the rational response is to retreat to safe ground. Every improvement that arrives after that point lands on people who have already stopped looking.

This is productivity leakage of the quietest kind. Nothing breaks. Nothing gets escalated. People still log in, records still get created, and the dashboards still show plenty of activity. But the experienced rep never discovers the improvement she has been waiting years for, because it arrived in a month when she had stopped exploring. The service team keeps doing by hand something the platform could have done for them two releases ago. The organisation keeps paying for capability that never reaches the people who would benefit from it. None of this appears on a report, because nothing failed. Things simply never got better.

The usual answer is to communicate more. A release newsletter, an email listing everything that has changed, a lunchtime session demonstrating every new feature. All of it is well meant, and I understand the instinct. But it treats the problem as a shortage of information, when what people are struggling with is a surplus of change. Sending them a longer list doesn't make the load lighter. It just describes it in more detail. A comprehensive release email is the pile, written down.

So the answer can't be to send people more change, more neatly. Somebody has to make the pile smaller. Somebody has to decide what reaches people, when it reaches them, in what order, and what they can safely leave alone. That is a real job. In most organisations it doesn't exist. And I think I know who should be doing it.

Part 3: The trainer as editor

Every good editor knows that the most important decisions in a piece of writing are about what to leave out. A first draft usually contains everything the author knows. The editor's job is to cut, reorder and simplify until what remains is what the reader actually needs, in an order they can follow.

I have come to believe that enablement now works the same way. For most of Salesforce's history, training was additive. A new system arrived, so we taught it. A new feature arrived, so we taught that too. That made sense when change came in occasional, sizeable pieces with a clear beginning and end. It makes far less sense now that change arrives continuously, from every direction at once. When the platform, the business and the tools are all moving at the same time, the most valuable thing anyone can do for users is not to add to what they need to know. It is to decide, deliberately, what they don't.

That is subtraction. And trainers are the people best placed to do it.

Let me be clear about what I'm not saying. This isn't an argument for less training. It is training doing its most important job: making sure that what people learn is what they need, at a moment when they can actually absorb it.

Why trainers? Consider the alternatives. Admins see the system from the configuration side, and they are usually flat out keeping it running. Project teams see their own change, not everyone else's. Managers are on the receiving end of the pile themselves. Trainers sit in a different place, in the space between the system and the work. Our whole craft is translating system language into working language. We are the first to see confusion, in the room, in the questions afterwards, and in the look on someone's face when a screen doesn't match what they expected. We know which features people use, which ones they avoid, and why. No one in the organisation has a clearer view of the pile from the user's side.

Yet in most organisations, trainers are brought in at the very end. Here is what's changing, please train people on it. They receive change; they don't get to shape it. I think that is exactly backwards. The people who understand what users can absorb belong in the conversation when change is planned, not when it lands.

So what does editing look like in practice? In my own work it comes down to a handful of habits, and none of them needs a new budget or a new tool.

The first is to count the load per role. Before anything new goes out, look at what that role has already absorbed recently. If the service team has taken on a new escalation process, two new fields and an AI pilot this quarter, the next change either waits, or something else comes off the pile to make room. It sounds obvious. It is almost never done.

The second is to tell people what they can ignore. This is one of the most underrated things a trainer can do. Most change communication lists everything that is new, and leaves the reader to work out which parts matter to them. That is exactly the work busy people don't have time for. A clear statement that something doesn't affect them, and that they can safely leave it alone, builds more confidence than another paragraph of detail. In my experience, it is often the part of a briefing that people appreciate most.

The third is sequencing. One meaningful change per role at a time, with room to practise before the next one arrives. The platform may change on a fixed date, but that date doesn't have to be the deadline for your people. The introduction to users can follow a rhythm that suits their work rather than the developer’s calendar.

The fourth is to reintroduce before you introduce. Most teams would gain more from properly learning something they already have than from the next new thing. Before adding anything, ask what has been sitting in your org, switched on and paid for, that nobody was ever shown how to use well. Some of the quickest productivity gains I have seen came from reintroducing people to the power of the platform they already owned.

And the fifth is to make it someone's job. Editing doesn't happen by accident. Somebody has to own the user's experience of change, with the authority to say "not yet" and a seat at the table when change is being planned rather than after it has been decided. If that owner isn't named, the pile will keep growing, one reasonable request at a time.

Now go back to the service agent from the beginning of this story and picture the same month in a different organisation.

The platform still updates itself in the first week. But a short note from the trainer tells her the one thing that has changed for her, and that the rest can safely be ignored. The new field arrives with a single sentence explaining why it exists and who will use what she enters. The request for the list view is folded into her one-to-one, so it feels like part of her job rather than another thing to remember. The AI pilot waits until the new escalation process has settled, and when it does arrive, she gets time to practise with it rather than an email inviting her to try. And somewhere along the way, someone shows her a feature that has been in the org for two years, which saves her ten minutes on every case she handles.

Same platform. Same releases. Same business. A very different month. She isn't resisting anything, and she isn't behind. Nobody buried her.

Your users aren't behind. They're buried. The question isn't whether your people can keep up with change. It is whether anyone in your organisation has taken responsibility for how much of it reaches them.

If this sounded like your team, here’s how I help organisations work out what their people can really absorb and build training around it, instead of piling on more: sebapp.com