The Person Who Built It Is the Wrong Person to Teach It

Part 1: They Built It, So They Can Train It

It is three weeks before go-live, and the project meeting has finally reached the line on the plan that says "training". The build is nearly finished. The data migration has been rehearsed twice. The integration that caused so much trouble in the summer is finally behaving. Everyone is tired, and everyone can see the finish line. Then someone asks the question that has been sitting quietly at the bottom of the plan for months: who is going to train the users?

There is a short pause, and then the answer arrives, as it almost always does. "Sarah can do it. She knows the system better than anyone." Or, in the other version I hear just as often: "We'll get one of the developers to record a walkthrough. People can watch it in their own time." Heads nod. Somebody writes a name next to the line. The meeting moves on to cutover weekend, and a decision that will shape how hundreds of people experience Salesforce for years has been made in about forty seconds.

I've sat in that meeting more times than I can count, and I want to be fair to the people in it, because nobody is being careless. The logic feels completely sound. Sarah is the admin. She configured most of what users are about to see. She knows why every field exists, which validation rule will trip people up and where the automation sends things once a record is saved. The developer who built the flows knows them better than anyone alive. If you need someone who understands the system, they are the obvious choice. Who else would you ask?

And there are practical reasons stacked on top of the logical one. By this stage of a project the budget is usually stretched. The training line was estimated optimistically at the start, long before anyone knew how complex the build would become, and it has been quietly squeezed every time something else overran. The admin is already on the payroll. The developer is already on the project. Asking them costs nothing extra, at least on paper. And a recorded video feels wonderfully efficient: make it once, share it with everyone, never deliver a session again.

There is also a belief underneath all of this that rarely gets said out loud. It is the belief that training is mostly a matter of transferring information. If the information lives in the head of the person who built the system, then the most direct route is to have that person explain it. Get the knowledge out of the builder and into the users, and the job is done.

So nobody actually decides to make the admin the trainer. It simply happens, by default, because every individual reason points the same way. And because it happens by default, nobody stops to ask whether knowing a system and being able to teach people to use it are the same skill.

They are not, and the second and third parts of this episode are about why that matters and what to do about it. But before we get there, I want to look at what has changed in the last year, because the default I've just described is about to become much more tempting.

AI has made the shortcut look even cheaper. A year or two ago, if the admin was going to train, at least someone had to sit down and write the user guide, build the session and prepare the exercises. That took time, and the time was visible. Now an admin can ask an AI assistant to produce a step-by-step guide for every process in the org, and have it in an afternoon. A developer can record a screen walkthrough and have AI generate the script, the captions and a neat summary at the end. The materials appear almost instantly, they look professional, and the training line on the plan gets ticked off faster than ever.

Then there is the bigger argument, the one I'm starting to hear in leadership conversations. Salesforce is changing how people use it. More and more of the work is moving into conversation: asking Claude, working in Slack, typing a question to an assistant rather than clicking through screens. Some people call it going headless, where the interface you were trained on matters less because you simply ask for what you need. And if users can just ask, the reasoning goes, why train them at all? The system will explain itself. The AI will guide them. Surely training has become a smaller job, one the admin can easily absorb alongside everything else.

I understand why that argument is attractive. It promises to make one of the most awkward, most underfunded parts of any Salesforce programme quietly disappear. If you are a leader under pressure to cut cost and speed up delivery, it is exactly what you want to hear.

But I think it is exactly backwards. Every one of those changes makes the work of teaching people harder, not easier, and it makes the gap between the person who builds the system and the person who can teach it wider than it has ever been.

Think about what has actually got cheaper. Producing content has got cheaper. Building has got cheaper. Generating a guide, configuring a flow, recording a walkthrough: all of those now take a fraction of the effort they used to. What has not got cheaper is the part that happens inside people. The moment a user understands why a process works the way it does. The confidence to try something on a live customer record without worrying about breaking it. The judgement to know when an answer from an assistant is wrong. None of that is produced by content, however polished. It is built by teaching, and teaching is a different craft from building.

That is the uncomfortable truth sitting underneath that forty-second decision in the project meeting. When we hand training to the person who built the system, we are not choosing the most knowledgeable option. We are choosing the most convenient one, and hoping that knowledge will do the work that teaching should do.

So here is the question I'd like you to sit with. In your organisation, who decided who would train your users? And did anyone actually decide, or did it just land on the person who happened to know the system best?

Part 2: Building Is Getting Cheaper. Teaching Is Getting Harder.

My own first day with Salesforce, back in 2012, was eight hours with an American developer talking about page layouts. He was clearly brilliant. He knew that org inside out, he could answer any technical question I could think of, and he talked with real enthusiasm about how everything fitted together. At the end of the day I went home exhausted, and I could not have told you how to do a single thing my job actually required. There was no Trailhead then, no community to turn to and almost no training. I spent the following months making every classic mistake there is, and paying for them.

I don't tell that story to criticise him. He did exactly what builders do. He taught me the build.

That is the heart of the problem, and it has a name. Psychologists call it the curse of knowledge: once you know something deeply, it becomes almost impossible to remember what it was like not to know it. The person who configured the system can't un-see the architecture. When they explain it, they explain it the way they understand it, which is from the inside out. Objects, fields, page layouts, record types, the automation that fires when a record is saved. Every word is accurate. Very little of it is useful to someone who needs to know what to do when a customer rings with a complaint.

Users don't think in objects. A sales rep doesn't start the day by creating an account. She starts by wondering which deals need attention and what she promised to send yesterday. A service agent doesn't think about case assignment rules. He thinks about the customer on the line and how to find their history before they lose patience. The builder speaks system language. The user lives in working language. Somebody has to translate between the two, and translation is a skill that has very little to do with knowing how the system was built.

The developer's recorded walkthrough shows this perfectly. I've watched a lot of them. They are usually recorded in a clean sandbox, with tidy test data and a cursor that moves faster than anyone new could follow. The developer clicks confidently through the happy path, because they designed the happy path. They explain why the flow behaves the way it does, which is fascinating to them and irrelevant to the viewer. They never pause on the field that will confuse half the team, because it doesn't confuse them. And the recording rarely shows what to do when something goes wrong, because nothing goes wrong for the person who built it. The video gets shared, people watch the first few minutes, and the organisation records that training has been delivered.

Teaching is a craft, and it is worth naming what that craft involves. It means designing learning around the situations people actually face rather than the screens they will see. It means reading a room, noticing the person who has quietly stopped following and won't say so. It means letting people be slow before you expect them to be fast, building their confidence through practice, and checking that they can actually do the job rather than assuming it because they sat through a session. None of that appears in an admin's job description, and none of it appears in a developer's. It is not a criticism of either role to say so. It is an unfair load to put on them, usually on top of a build that is already running late.

Now consider what is happening to Salesforce itself, because this is where the problem moves from inconvenient to serious.

For most of the platform's history, end-user training was, at heart, a guided tour of the screen. Here is the opportunity. Here is the stage. Click here, then here, then save. It was never the whole story, but the screen gave everyone something to hold on to, including the admin who had to teach it. If you knew the clicks, you could at least show the clicks.

That anchor is disappearing. As more of the work moves into conversation, through Claude, through Slack, through an assistant that sits on top of the data, there is no longer a single screen to walk through. A user can ask a question in plain language and get an answer, update a record in a sentence, or ask for a summary of an account without ever opening it. The admin's natural method, the click path, simply stops working, because there is no path to click.

What replaces it is far harder to teach. Users now need to know what to ask, and how to ask it well. They need to know what a good answer looks like for their role, so they can recognise a poor one. They need to understand the process well enough to notice when the assistant has done something that is technically possible and completely wrong for your business. They need the confidence to question something that sounds authoritative. That is not knowledge of the system. It is judgement about the work. And judgement is the hardest thing there is to teach, because it can only be built through situations, practice and conversation.

Here is the irony. The builder is the person least well placed to teach it, because the builder already knows what the right answer looks like. They will never be uncertain in the way your users will be uncertain, so they can't easily design for it.

So this is how I'd put it. Building is getting cheaper. Teaching is getting harder.

AI is making it faster and cheaper than ever to configure flows, generate documentation and stand up new capability. The cost of building is falling every year. But the cost of helping people work confidently with what has been built is rising, because what they need to learn is shifting from where to click to how to think. Organisations that keep handing training to the builder will find themselves with more capability than ever and users who trust it less than ever.

The question for now is a simple one. When Salesforce stops being something your people click through and becomes something they talk to, who in your organisation is going to teach them how to have that conversation well?

Part 3: Who Should Teach Your Salesforce Users?

Every Salesforce project has a role it forgets to plan for. There is always a project manager, a solution architect, admins, developers, testers and usually a change lead somewhere in the mix. What there rarely is, at least until go-live is close enough to cause panic, is someone whose job is to help people learn. The specialist trainer is the forgotten role on most Salesforce projects, and the gap they leave gets filled by whoever happens to know the system best.

In the first two parts of this podcast I've argued that this default is understandable and wrong: that the person who built the system is usually the wrong person to teach it, and that the shift towards AI and conversation makes teaching harder, not easier. Building is getting cheaper. Teaching is getting harder. So what should organisations actually do? I want to highlight five practical changes, none of which needs a large budget, and all of which start with a decision rather than a purchase.

The first is to separate knowing from teaching, out loud. Put two roles on the plan instead of one: the person who knows how the system works, and the person responsible for helping people learn to use it. They might occasionally be the same person, but naming them separately forces the question that the project meeting skipped. It also takes pressure off your admin, who is no longer expected to be an architect, a support desk and a classroom trainer all at once.

The second is timing. Bring the person who owns learning in, when the plan is written, not when go-live looms. A trainer who joins three weeks before launch can only wrap content around a system that is already finished. A trainer who joins at the start can sit in discovery, hear how people describe their work, notice which processes will be hard to explain and raise it while it can still be fixed. Some of the most useful design feedback I've ever given came from asking a simple question early: how would I teach this to someone on their first week? If the answer is that I couldn't, the design probably needs another look.

The third is to give the builder a different job in training rather than no job. Your admin and your developers are enormously valuable here, just not as presenters. Make them the people who check accuracy, review scenarios, explain the edge cases to the trainer and sit in the room to answer the technical question that inevitably comes up. The builder owns whether the content is right. The trainer owns whether people can actually do it. That partnership produces far better training than either could produce alone.

The fourth applies when the admin genuinely has to train, because in smaller organisations there may simply be nobody else. If that's your situation, give them structure rather than leaving them to improvise. Write the training around jobs, not objects: real situations such as "you've just come off a call with a new prospect" or "a customer has rung back about an unresolved case", rather than a tour of the opportunity record. Keep the sessions small and practical, with people doing the work themselves rather than watching it being done. And end every session by watching each person complete a real task on their own, because that is the only reliable evidence that the session worked.

The fifth is about AI and recordings, and it's the one I'd most like leaders to hear. Use AI for what it is genuinely good at, which is drafting. Let it produce the first version of a guide, summarise a process or turn a recording into a quick reference. Then have someone who understands how people learn shape it into something that builds confidence. And never let a recording stand in for training. A developer's walkthrough can be a useful reference for someone who has already learned the process. It is not how they learn it. As Salesforce moves further into conversation, your training also needs to cover what no recording can: what to ask, what good looks like, and when to doubt the answer. That is judgement, and it is built through practice, discussion and real situations with someone guiding the way.

Let me go back to the meeting from the start of this episode. Three weeks before go-live, the plan reaches the line marked "training", and someone says, "Sarah can do it. She knows the system better than anyone."

Here is what I would have liked someone in that room to say instead. "Sarah knows the system better than anyone, and that's exactly why we need her checking the training rather than delivering all of it. Who owns helping people learn this? And why are we only asking now?" It is a slightly uncomfortable question, and it costs a little more than forty seconds. But it is the difference between a go-live where people have watched the system and one where people can confidently use it.

Because the real cost of the shortcut never shows up in the project budget. It shows up months later as quiet workarounds, as an admin who has become a permanent help desk, as users who know the system exists and don't trust themselves to use it. It shows up in the gap between what the platform can do and what people actually do with it, and that gap is about to grow, because the platform is changing faster than ever.

So here is a practical takeaway for this week. Look at your current or next Salesforce change, however small, and find the line in the plan that says "training". Next to it, write two names: who knows the system, and who owns how people learn it. If you can only write one name, or if the second space is blank, you've found the most important conversation to have before go-live.

Building is getting cheaper. Teaching is getting harder. The organisations that recognise the difference will be the ones whose people actually use what they've built.

Learn more about building success Salesforce Training Solution here https://trainsalesforce.com/train-to-win/