Stakeholder Management Is Not a Soft Skill — It's the Whole Job
Nobody puts this in any Salesforce training or job spec. But the technical part of the role — the flows, the Apex, the data model — is maybe 40% of what determines whether you succeed on a project. The other 60% is this: your ability to manage the people around you well enough that the technical work gets a fair chance to land.
This is not a soft skill. Calling it that is how it gets dismissed. Stakeholder management is applied intelligence about how organisations actually work — who decides what, what people are really worried about, and what it takes to move something from agreed-in-principle to actually-deployed. It is learnable, it is specific, and most technical people never develop it because nobody told them it was part of the job.
Why requirements are never just requirements
Every requirement that reaches you has a history. Someone asked for it. Someone approved it. Someone else quietly opposed it in a meeting two weeks ago and lost. The document in front of you is the official version. The political version is different, and if you only work from the official version, you will build the right thing for the wrong outcome.
The question "what do you need?" rarely gets you what you actually need to know. The better questions are: who else cares about this? Who pushed back when it was proposed? What does success look like to the person signing this off — not the technical success, but the political one? A VP of Sales who asked for a dashboard is not asking for a dashboard. They are asking to look competent in the next leadership review. Build the thing that makes them look competent.
Managing up vs managing across
Managing up is what most people think of when they hear stakeholder management — keeping leadership informed, presenting well, managing expectations. This matters, but it is the easier half.
Managing across — laterally, with peers and parallel teams — is where most projects actually live or die. The business analyst who controls the requirements. The data team whose sign-off you need. The IT security team who will review your integration. The sales ops lead who has strong opinions about how the pipeline should work. None of these people report to you. None of them have to cooperate. Keeping them on side, informed, and bought in is not a box-ticking exercise — it is an ongoing negotiation, and most technical people lose it by default because they stop engaging once the requirements are signed.
What "managing expectations" actually means
It does not mean making people feel good about bad news. It means ensuring that nobody is surprised by anything at go-live. Surprises at go-live are stakeholder management failures, and they are almost always traceable to a moment earlier in the project where the truth was available but not communicated.
The truth is often inconvenient: this will take longer than planned, this requirement as written cannot be built, this integration will break if the other team does not change their data structure. Most technical people sit on these truths for too long because delivering them feels like failing. The opposite is true. Delivering them early, clearly, with a proposed path forward, is what earns trust. Delivering them at go-live is what ends careers.
The specific skills worth building
Reading a room. Before you speak in a meeting, know who the decision-maker is, what they are worried about, and what they need to hear. Not what they want to hear — what they need to hear in order to make a good decision. These are sometimes the same thing and often not.
Writing that moves things forward. Most project emails inform. The useful ones decide. A good update email ends with a clear action, owner, and date. A good escalation email frames the choice, names the consequence of inaction, and makes it easy to say yes. If you write emails that require people to figure out what you want from them, you will wait a long time.
Knowing when to escalate and when not to. Escalating too often makes you look unable to handle normal problems. Not escalating when you should makes you complicit in a predictable failure. The line is roughly this: if the issue will cause a project outcome to change and the people affected do not yet know, escalate. If you can resolve it without changing outcomes, resolve it.
Where to start
If you have never treated stakeholder management as a skill to actively develop, start with the simplest possible habit: after every significant conversation with a stakeholder, write down three things — what they actually care about (not what they said), what they are worried about, and what a good outcome looks like for them personally. Do this consistently for a month and you will start seeing patterns that were previously invisible to you.
Two habits that change project outcomes fastest:
- Never deliver bad news without a proposed next step. "This will take longer than planned" is a problem dump. "This will take longer than planned — here is what we can cut to hit the original date, and here is what it costs to keep full scope" is a decision frame. Stakeholders can act on a decision frame. They cannot act on a problem dump.
- Map your stakeholders before every delivery phase. Fifteen minutes at the start of each sprint: who is affected by what we are building? Who needs to know? Who can block it? If anyone on that list has not heard from you recently, fix that before the delivery lands on them.
The deeper skill — reading what people mean in meetings, knowing when consensus is real versus polite — takes longer. But it is built from the same raw material: paying close attention to people, not just to the work in front of you.
The real competitive advantage
In a world where AI can generate the Apex, build the flow, and produce the documentation, the scarce skill is not technical output. It is judgment about what to build, why, and for whom — and the ability to navigate the human system around the build well enough that the output actually lands.
That is stakeholder management. It was always the whole job. Now it is the only part of the job that AI cannot do for you.
Frequently Asked Questions
How do you figure out the political version of a requirement when nobody will tell you directly?
Look at who is absent from the meeting, who defers to whom when questions arise, and who asks clarifying questions that seem designed to slow things down rather than move them forward. Side conversations before and after formal meetings often reveal more than the meetings themselves — people say in a corridor what they won't say on a call. Asking 'who else should we loop in on this?' is a low-threat way to surface stakeholders who haven't declared themselves yet.
What's the most common reason technical people lose the lateral stakeholder game?
They treat sign-off as a finish line rather than a relationship. Once the data team or IT security team has approved something, most technical people stop engaging — and those teams feel deprioritised and become unresponsive or obstructive the next time they're needed. Keeping parallel stakeholders informed even when you don't need anything from them is what builds the credit that makes future cooperation faster and easier.
How do you manage a VP or senior leader who keeps changing requirements late in a project?
Late requirement changes from senior stakeholders usually signal that their underlying concern — the political or personal success metric — was never properly surfaced at the start. Going back to ask what a successful outcome looks like for them specifically, beyond the technical deliverable, often reveals a simpler fix than re-scoping the entire build. If change is unavoidable, frame the conversation around impact to timeline and risk rather than resistance to the change itself.
What does good expectation management actually look like in practice during a Salesforce project?
It means creating deliberate touchpoints — demo checkpoints, written summaries after key decisions, and explicit confirmation when something is descoped — so that nothing materialises at go-live that a stakeholder hasn't already seen in some form. A short written update after every significant decision, sent to the relevant people even when no response is needed, creates a paper trail that prevents 'I didn't know about that' conversations later. The goal is that go-live feels like a formality, not a reveal.