Communication Skills for Salesforce Architects

Part 99: Communication Skills for Salesforce Architects

Here is an uncomfortable truth that nobody tells you when you start chasing Salesforce certifications: the thing that will make or break your career as an architect has nothing to do with Apex, Flows, or data modeling. It is communication. Full stop.

I have watched brilliant technical architects fail projects because they could not explain a platform limitation to a VP without drowning them in jargon. I have also seen architects with average technical chops absolutely crush it because they knew how to listen, translate, and align a room full of people who all wanted different things.

If you only take one thing from this post, let it be this — your job as a Salesforce Architect is not to build things. It is to make sure the right things get built. And you cannot do that without exceptional communication skills.

Why Communication Is the Most Important Skill You Have

Think about what an architect actually does day to day. You sit in meetings. You review requirements. You whiteboard solutions. You write design documents. You present options to leadership. You negotiate trade-offs with developers. You explain timelines to project managers who want everything yesterday.

Every single one of those activities is a communication exercise. The actual “architecture” — drawing boxes and arrows, selecting patterns, writing technical specs — is maybe 20% of the job. The other 80% is making sure everyone involved understands what is being built, why, and what it will cost them.

I once worked with an architect who designed a genuinely elegant integration pattern for a client’s ERP system. Multi-org, event-driven, beautifully decoupled. The problem? He presented it to the business stakeholders using a 40-slide deck full of sequence diagrams and middleware terminology. Their eyes glazed over by slide 5. They rejected the proposal — not because it was bad, but because they did not understand it. The project ended up with a fragile point-to-point integration that caused headaches for years.

That is the cost of poor communication. It is not hypothetical. It shows up in bad architecture decisions, blown budgets, frustrated teams, and lost trust.

How to Communicate With Stakeholders

The single biggest mistake architects make is treating every audience the same way. You would not explain governor limits to your CFO. You would not show your Apex developer a slide about ROI projections. Different audiences need different languages.

Talking to Non-Technical Stakeholders

Non-technical stakeholders — executives, business analysts, department heads — care about outcomes. They want to know: Will this solve my problem? How long will it take? What will it cost? What are the risks?

What bad communication looks like:

“We’ll implement a Platform Event-driven architecture with a pub/sub model that decouples the order management system from the fulfillment engine. We’ll need a custom Apex subscriber and a change data capture listener on the Order object.”

Nobody outside your dev team cares about any of that.

What good communication looks like:

“When a sales rep closes an order, the fulfillment team will automatically get notified in real time — no manual handoff, no delays. If the fulfillment system is temporarily down, the notification queues up and delivers when it is back online. This eliminates the 2-hour gap your team currently deals with.”

Same solution. Completely different framing. The second version talks about the problem being solved, not the technology solving it.

A practical framework — the “So What?” test: After every sentence in your stakeholder communication, ask yourself “so what?” If you say “We are implementing Platform Events,” the stakeholder is thinking “so what?” If you say “Your fulfillment team will never miss an order notification again,” they are thinking “tell me more.”

Talking to Technical Stakeholders

With developers, tech leads, and other architects, flip the script. They want precision. They want to know the pattern, the trade-offs, the limitations, and the edge cases. Do not oversimplify — it comes across as condescending.

Be specific about constraints: “We are using Platform Events instead of CDC here because we need custom payloads, and the 24-hour retention window is acceptable for this use case. If we need replay beyond that, we will need to evaluate an external message broker.”

That single sentence tells a developer exactly what pattern you chose, why, and when the decision would need revisiting. That is good technical communication.

How to Ask Questions That Get Real Answers

Discovery is where projects are won or lost, and discovery is fundamentally an exercise in asking the right questions. Most architects make two mistakes: they ask too many closed-ended questions, and they accept the first answer they get.

The Problem With “What Do You Need?”

When you ask a stakeholder “What do you need?” they will almost always describe a solution, not a problem. “I need a dashboard.” “I need a field on the Account object.” “I need an integration with our ERP.”

Your job is to dig past the stated solution and find the actual problem. The technique is simple — keep asking “why” until you hit the real need.

Example conversation:

Stakeholder: “I need a new report that shows all opportunities closing this quarter.”
You: “Help me understand — what decision will this report help you make?”
Stakeholder: “I need to know which deals are at risk so I can intervene.”
You: “How do you currently identify at-risk deals?”
Stakeholder: “I check in with each rep individually, but I’m missing things.”
You: “So the core problem is visibility into pipeline risk without having to chase people down?”
Stakeholder: “Exactly.”

Now you are solving the right problem. Maybe the answer is a report. Maybe it is a dashboard with exception-based alerts. Maybe it is a Flow that flags stalled opportunities automatically. But you would never have gotten there if you just built “a report.”

A Discovery Question Framework

Here are questions I come back to on virtually every project. Adapt them to your context:

“Walk me through what happens today from start to finish.” — This reveals the current process, pain points, and workarounds people have built.
“What happens when something goes wrong?” — This uncovers exception handling needs that stakeholders rarely think to mention.
“Who else does this affect?” — This identifies downstream dependencies and additional stakeholders you should be talking to.
“If you could only change one thing, what would it be?” — This forces prioritization and reveals what truly matters.
“What have you tried before that did not work?” — This prevents you from repeating past mistakes and builds credibility.
“How will you know this project was successful?” — This establishes measurable success criteria before a single line of configuration is touched.

Write these down. Print them out. Tattoo them on your arm. I do not care — just use them.

How to Set Realistic Expectations

Nothing destroys a project faster than misaligned expectations. And nothing destroys an architect’s credibility faster than promising something you cannot deliver.

The “Yes, But” Trap

Architects who want to be liked say yes to everything. “Can we integrate with 15 external systems in Phase 1?” Yes. “Can we go live in six weeks?” Yes. “Can we build a custom portal with real-time inventory and AI-powered recommendations?” Yes.

Then reality hits. Timelines slip. Features get cut. Stakeholders feel deceived. You have now lost the one thing you cannot buy back — trust.

How to Say No Without Saying No

The trick is to reframe limitations as choices. Nobody likes hearing “no.” Everyone understands trade-offs.

Instead of: “No, we can’t do that in six weeks.”

Try: “We can deliver the core order management workflow in six weeks. The reporting layer and the mobile experience would add another four weeks. Would you like to phase it, or should we adjust the timeline?”

You have said the same thing — six weeks is not enough — but you have given the stakeholder agency. They get to choose. People who feel in control of decisions are dramatically more satisfied with outcomes, even when those outcomes involve compromise.

The Expectation-Setting Checklist

At the start of every project or major phase, explicitly align on:

Scope — What is in, what is out, and what is “Phase 2.” Write it down. Get sign-off.
Timeline — Provide ranges, not single dates. “We expect this to take 8-10 weeks” is honest. “This will be done on March 15th” is a promise you probably cannot keep.
Assumptions — State what has to be true for your plan to work. “This timeline assumes the API documentation is accurate and the third-party vendor provides test credentials by Week 2.”
Risks — Name the things that could go wrong and what you will do about them. Stakeholders respect architects who are upfront about risk.
What success looks like — Revisit those success criteria from discovery. Make sure everyone still agrees.

If you skip this step, every person in the room walks away with a different picture of what “done” looks like. That is a guaranteed conflict later.

How to Build Trust With Your Stakeholders

Trust is the currency that makes everything else possible. When stakeholders trust you, they give you room to make decisions. They back you up in meetings. They come to you early when problems arise instead of hiding them until it is too late.

Trust is not built through grand gestures. It is built through small, consistent actions over time.

Show Up Prepared

Read the pre-meeting materials. Know the stakeholder’s domain. Understand their KPIs. When you walk into a room and reference something specific about their business — “I noticed your team processes about 3,000 cases per month, with a spike in Q4” — you signal that you have done your homework. That is respect, and people reciprocate it.

Follow Through on the Small Things

If you say you will send a follow-up email by end of day, send it by end of day. If you say you will look into a question, look into it and circle back — even if the answer is “I don’t know yet, but here’s what I’ve found so far.” The fastest way to lose trust is to let small commitments slip. People notice.

Admit What You Do Not Know

This one is counterintuitive. Many architects think admitting ignorance undermines their authority. It is the opposite. When you say “I’m not sure about that, but I’ll find out and get back to you by Thursday,” you are being honest. When you bluff your way through an answer and get caught later, you are done. Stakeholders can forgive not knowing. They cannot forgive being misled.

Give Credit Generously

When the project succeeds, name the people who made it happen. “The integration went smoothly because Priya on the dev team anticipated the timeout issue and built in retry logic.” When you make others look good, they want to work with you again. Architecture is a team sport — act like it.

Be Consistent

Stakeholders should know what they are getting when they work with you. Consistent communication cadence. Consistent honesty about status. Consistent follow-through. Unpredictability, even well-intentioned, erodes trust over time.

Section Notes

Communication is not a “nice to have” for architects — it is the primary skill that determines project success or failure.
Always adapt your language to your audience. Technical depth for developers, business outcomes for executives. The “So What?” test is your best friend.
Discovery is about finding the real problem, not the stated solution. Keep asking “why” until you get there. Use the question framework above as your starting point.
Set expectations early and explicitly. Scope, timeline, assumptions, risks, and success criteria — if any of these are ambiguous, you are setting yourself up for conflict.
Trust is built through preparation, follow-through, honesty, generosity, and consistency. There are no shortcuts.
The best architects I have worked with are not the ones who know the most about Salesforce. They are the ones who can walk into a room, understand what people actually need, and make everyone feel confident that the right thing is being built.

In the next post, we will shift gears and talk about documentation — what to write, how much is enough, and how to make sure your design documents actually get read.