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.
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 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.
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.
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.
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:
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.
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.