Here is structure to talk with A clear point, and using directly term when communicate with stakeholders such as PMs, designers, and senior engineers to improve your people skills.

Good communication sounds like:

“Here are the trade-offs and my reasoning.”

Not:

“Your idea is wrong.”

1. Align on the Shared Goal

Start with common objectives to reduce friction.

Examples

• “I think we both want faster onboarding and lower support cost.”
• “The goal here is reliability without slowing delivery too much.”

2. Present Your Argument

Use this structure:

• Observation
• Reasoning
• Impact
• Proposal

Template

Currently X happens. This creates Y problem because Z. The impact is A. I suggest B.

Example

Currently the API retries are handled in the frontend. This can create inconsistent behavior across clients. The impact is harder debugging and duplicated logic. I suggest moving retry handling to the gateway layer.

3. Acknowledge Counter-Arguments

Show that you understand trade-offs.

Templates

The trade-off is… One concern with this approach is… I understand why we might prefer…

Example

One concern with centralizing retries is increased gateway complexity.

This signals maturity and reduces defensiveness.

4. Compare Trade-offs Explicitly

Stakeholders usually care more about trade-offs than “being right.”

Template

Option A optimizes for X but increases Y. Option B reduces Y but costs more in Z.

Example

Shipping now gives faster feedback, but increases operational risk. Delaying one sprint improves testing coverage but slows validation.

5. Communication by Stakeholder Type

PM Communication

PMs Usually Care About

• user impact
• business value
• delivery speed
• prioritization
• operational risk

Templates

From a user/business perspective… The risk of not doing this is… The engineering cost is approximately…

Example

We can ship faster by skipping audit logging, but if customer issues happen later, debugging will become expensive.

Avoid

• deep technical rabbit holes
• perfectionism without business impact
• over-engineering arguments

Designer Communication

Designers Usually Care About

• UX consistency
• usability
• accessibility
• cognitive load
• user flow

Templates

The current flow may confuse users because… This interaction creates extra cognitive steps… Can we simplify while keeping the visual intent?

Example

The modal looks visually clean, but requiring 3 confirmations may interrupt user flow.

Avoid

• “users don’t care”
• purely technical rejection
• dismissing UX concerns

Senior Engineer Communication

Senior Engineers Usually Care About

• scalability
• maintainability
• operational reliability
• architecture consistency
• long-term complexity

Templates

My assumption is… Failure cases I considered are… The trade-off is complexity vs flexibility…

Example

This abstraction reduces duplication now, but I’m worried it introduces hidden coupling between services.

Avoid

• vague opinions without reasoning
• arguing from authority
• emotional attachment to solutions

6. Strong Communication Pattern

A highly effective structure:

Claim → Evidence → Trade-off → Recommendation

Example

I think we should use async processing here. The current synchronous flow increases latency under load. The downside is eventual consistency complexity. But I think the reliability gain is worth it.

7. Advanced Technique: Steelman Before Critique

Before disagreeing:

1. explain their position fairly
2. acknowledge its strengths
3. then critique the trade-offs

Example

I understand why we want a shared component here — it improves consistency and reduces duplication.

My concern is that the requirements between teams are already diverging.

This dramatically reduces defensiveness.

8. Short Practical Templates

Neutral Disagreement

I agree with the goal, but I see a different trade-off.

Soft Challenge

What assumption are we optimizing for here?

Risk Framing

This works well in the happy path. I’m more concerned about failure scenarios.

PM Discussion

The technical cost is small, but the operational risk later may be high.

Senior Engineer Discussion

I think this simplifies implementation short-term, but increases coupling long-term.

9. Communication Anti-Patterns

Avoid These

Emotional Positioning

“This is obviously wrong.”

Winning Instead of Evaluating

“You’re overthinking.”

Ignoring Constraints

• PM constraints
• delivery timelines
• UX concerns
• operational realities

Excessive Certainty

“This is the only correct way.”

10. Final Principle

Good stakeholder communication is not:

“How do I prove I’m right?”

It is:

“How do we evaluate trade-offs together?”