The Change Programme the Board Never Sees

In almost every large Salesforce transformation I have worked on, there have been two change programmes running at the same time. The board has only ever seen one of them.

The first is the official programme. It has a name, a launch event and a framework presented to the executive team in a deck that took weeks to perfect. It has a vision statement, a set of principles and a vocabulary of its own, and it reports progress monthly in colours that are almost always green.

The second programme has no name. It happens late in the evening, when a trainer rewrites a module because the process described in the framework doesn't exist in the system that was actually built. It happens in corridor conversations with regional managers, negotiating for ninety minutes of their team's time in the middle of a sales quarter. It happens in training rooms, where users ask what their new job title actually means and the person at the front is the first to admit that nobody has told them either. This second programme is where the change really happens, if it happens at all, and it appears in no status report anywhere.

I have spent a good part of my career working in that second programme. This piece is about why it exists, and why the board rarely knows it's there.

Transformation almost never starts with technology. It starts with a frustration at the top of the organisation.

"We can't get proper reporting." "We have no idea what's really in the pipeline." "Every region does things differently." "We need to move faster, serve customers better, and do it with fewer people." These are real problems, felt keenly by leadership teams who are asked every quarter to explain numbers they can't fully see. There's nothing wrong with where the story begins.

At some point in the conversation, technology enters as the answer. Salesforce is selected, a business case is built, and something interesting happens to the ambition. A new platform feels like a rare moment when everything can be reset. If the system is changing anyway, why not change the structure at the same time? Regions are reorganised, and job titles are rewritten to reflect a new way of working. Sales roles are split, merged or renamed, service teams are reimagined, and new operating models are drawn. The programme expands from implementing a system to transforming the organisation, and it is expected to do all of this quickly and at scale, because a board that has committed to transformation doesn't want to wait for it.

This is usually the point where a large consultancy is brought in to shape the change.

I want to be fair to the firms that do this work, because the people involved are often bright, articulate and genuinely skilled at what they have been asked to do. The problem is what they are asked to do, and who they are asked to do it for.

The typical engagement begins with interviews, mostly with senior leaders. It moves through workshops, again largely with senior leaders, and a period of high-level analysis. It produces a change framework that is, in fairness, often beautiful. There are principles about putting the customer at the centre, and behaviours describing the kind of seller or service professional the organisation wants to become. There are slogans that fit neatly on a slide and a launch video, and a language of transformation that makes the board feel the organisation is about to become something new.

The board recognises itself in that framework, and that is exactly the point. It was built from the board's own words, played back with more polish and more confidence than the board had when it started. Of course it is well received.

What the framework almost never contains is any real understanding of what a working day looks like for the people at the other end of the organisation. I have rarely seen these programmes include anyone sitting beside a call centre agent for a full shift. I have rarely seen anyone ride along with a field service manager, or spend an afternoon watching how a sales rep actually moves between calls, emails, customer visits and the system that is supposed to hold it all together. The people who will spend most of their working lives inside Salesforce are described in the framework, but they were rarely consulted in building it.

The same distance applies to the platform itself. These firms often understand Salesforce at the level of capability: what it can integrate with, what the architecture could look like, what the roadmap might enable. They design impressive integrations and ambitious process changes. What they understand far less well is what it means to put that system in front of several thousand people who didn't ask for it, many of whom are not particularly confident with technology, and then expect them to change how they work on day one. That is a different discipline entirely. It is the discipline of enablement, and the people who practise it are very rarely in the room when the framework is written.

In my experience, the trainer is usually invited in much later, once the framework has been approved, the build is under way and the training budget has already been fixed. The brief is to deliver the training. Nobody asks whether the plan can actually be trained.

Once the programme reaches the people it was designed for, the disconnect becomes visible very quickly, at least to anyone standing on the floor.

A rep is told they are now a "customer growth partner". They open Salesforce and find the same opportunities, a longer list of mandatory fields and no explanation of what their new title means for the way they record a deal. A service agent hears that every interaction is a chance to build a lifelong relationship, then finds it takes several screens to see a customer's case history while that customer waits on the line. A field service manager is told the new operating model will give them more time with their teams, and discovers that the scheduling process now requires three steps that used to take one.

None of these people are against change. Most of them would welcome something that made their day easier. But the change they were promised in the launch event and the change they meet in the system bear very little resemblance to each other, and they notice. People are far quicker to spot a gap between words and reality than most leadership teams give them credit for. Once they spot it, the framework loses its authority, and everything that follows is quietly discounted.

The board, meanwhile, is looking at a very different picture. Communications have been issued, the launch was well attended, and training sessions are being delivered on schedule. From the top of the organisation, everything looks exactly as the plan said it would.

The disconnect has a direct consequence for budget, and this is where the damage becomes structural.

By the time the programme reaches the question of how people will actually learn to work in the new world, most of the money has already been committed. It has gone into the framework, the build, the integrations and the launch. Training sits near the end of the plan, and it is usually sized as a line item rather than designed as a programme. It is treated as a delivery activity to be scheduled, not as the moment when the whole transformation either takes hold or doesn't.

Last week I wrote about what that can look like in practice. One organisation needed to train a large, not especially tech-confident workforce across many countries, quickly. The answer was to hand the materials to local colleagues and ask them to deliver the training, without anyone first preparing them to teach a complex system they had only just met themselves. On paper, it was efficient. In the room, it meant people learning from trainers who were still learning.

The pattern repeats in different forms. There are two hours of demonstration for a system that changes someone's entire working day. Training happens on a version of the system that is still being finished, so what people learn in the session no longer matches what they see at go-live. Nothing is planned for the weeks after launch, which is precisely when people need help most, because that is when real work collides with new habits. Real opportunities to build confidence are missed simply because nobody budgeted for them.

The result is predictable to anyone who has worked on the floor: unhappy users, a slow drift back to old ways of working, and adoption that never reaches what the business case assumed.

This is the part of the story the board almost never hears. For the people responsible for enablement, it takes up most of the programme.

When the plan approved at the top doesn't fit the reality at the bottom, someone has to close the gap. In my experience, that someone is very often the trainer, working with whoever else on the ground cares enough to help. The work of closing that gap is rarely comfortable.

It means rewriting training materials because the processes described in the framework don't match the screens users will see. It means arguing for training built on real scenarios from people's actual jobs, rather than the generic demonstration script the programme has already signed off, and making that argument to people who consider the script finished. It means negotiating with sales directors who, understandably, don't want their teams pulled away from customers at the end of a quarter, and trying to secure even half a day when the plan allowed an hour. It means translating new job titles into practical responsibilities, because nobody told users what their renamed role is supposed to do differently in the system. It means quietly building the quick guides, the floor support and the follow-up sessions that were never commissioned, because it is obvious they will be needed.

It also means standing in front of a room of experienced professionals who can see the gap as clearly as you can, and choosing your words carefully. They ask the questions the framework cannot answer, and you are the person they ask. You are also often the first person they tell the truth to about what is and isn't working.

Then there is the politics. Raising the mismatch between the board's plan and the floor's reality is rarely welcomed. You risk being seen as negative, as not aligned with the vision, or as someone who doesn't understand the bigger picture. So much of this work is done diplomatically, and a great deal of it is done invisibly. You weave the official language into training that actually works. You bend the plan just enough to make it deliverable without appearing to challenge it. You protect the programme's reputation while repairing its foundations.

When it works, the framework receives the credit. When it doesn't, the users receive the blame.

When adoption falls short, and in these programmes it usually does, the conversation at the top turns to diagnosis. The diagnosis is almost always the same: the users are resisting, the data isn't good enough, people aren't following the process.

The remedy is almost always the same too. More technology is added. Fields become mandatory, validation rules are added to force the behaviour the framework assumed would happen naturally, and dashboards are built to monitor compliance. Another tool is purchased to simplify the experience of the first one. Increasingly, an AI capability is proposed to compensate for the fact that people aren't using the system as intended.

Each of these decisions is understandable on its own. Together they add complexity to a system people already found difficult, which lowers their confidence further and pushes adoption down again. Every new layer becomes technical debt the organisation will carry for years. The original problem, a change plan that never connected with how people work, sits untouched underneath all of it.

It is worth asking why the framework itself is so rarely questioned.

Part of the answer is simple. It was endorsed at the highest level of the organisation. It reflected the board's own ambitions back at it, and it was presented with great confidence by a respected firm. Questioning it means questioning the judgement of the people who approved it, and by the time adoption problems surface, the firm that wrote it has often moved on to the next engagement.

The other part is that the framework was never measured against what happened on the floor. It was measured against its own milestones, and it met them. Launch happened, communications went out, training was delivered. On its own terms, it succeeded. The fact that those terms had very little to do with whether people's work changed is not something the reporting was ever designed to reveal.

So the organisation concludes that the vision was right and the execution was difficult. The next transformation begins the same way.

None of this is an argument against ambition at board level. Organisations are right to want better visibility, faster decisions and more capable teams, and they are right to see a platform like Salesforce as a chance to rethink how they work. The problem is not the ambition. It is the distance between the people who shape the change and the people who have to live it.

Closing that distance doesn't require a larger framework. It requires a different starting point. Before the principles are written, someone should understand a genuine day in the life of the people who will use the system, and not a persona on a slide but an actual day, observed and understood. The people responsible for enablement belong in the room while the change is being designed, not invited in afterwards to deliver whatever has been decided. Adoption deserves a budget as serious as the build, because it is the only part of the programme that turns the investment into anything at all. And the board should ask a question it rarely asks: not whether the plan is on track, but what the people on the ground are having to fix in order to keep it that way.

That last question matters more than it might appear. Somewhere in almost every transformation, someone is quietly making the change programme work. They are rewriting, negotiating, translating and absorbing the friction between what was promised and what was built. They are doing it because they care about the people in front of them and they want the platform to succeed.

So here is the question I would put to any leadership team in the middle of a transformation. Who in your organisation is running the change programme you have never seen, and what is it costing them to hold the two together?