Skip to content
Published on

Communication for Engineers: How to Get Technical Decisions Made

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction — The Code Was Right, But Nobody Listened

If you have been at this a while, you have lived some version of this. You clearly saw the better architecture, but the meeting decided otherwise. Months later, another team stumbles onto the same conclusion and gets praised for it. It stings. You knew all along.

Here is where most engineers draw the wrong lesson: "It's politics." But the real problem is usually simpler, and mercifully, fixable. What they missed is that having a good idea and getting others to adopt it are two completely different skills.

The line that separates senior and staff engineers is not coding ability. By that level, most people write good code. The real differentiator is the ability to get decisions made — not just knowing the right answer, but getting the organization to choose it. This post is about that skill. It's not a story about politics; it's a story about clarity.

Design Docs and RFCs — Why Writing Beats Talking

The most powerful tool for driving a technical decision is not a slide deck or a passionate speech in a meeting. It is a single well-written document, usually called a design doc or an RFC (Request for Comments). There is a reason Google treats design docs as a cornerstone of its engineering culture.

Writing beats talking for concrete reasons.

  • Writing gets reviewed. A proposal thrown out verbally in a meeting is at the mercy of the room's mood and whoever talks loudest. A document lets people read at their own pace, coolly, and leave objections in the margins. Good ideas survive that scrutiny; bad ones get caught by it.
  • Writing forces thought. Some ideas look perfect in your head and only spring leaks when you put them into sentences. The question "how do we handle this case?" surfaces on its own as you write. The act of writing is itself an act of design.
  • Writing scales and persists. A meeting is known only to the people in the room. A document reaches a colleague in another time zone, a new hire who joins six months later, and the future version of you who wants to know why a decision was made.

A good design doc tends to share a common skeleton.

  Title / Author / Status (draft, in review, approved, deprecated) / Date

  1. Context and Problem
     - What is broken and why. Why you are reading this.

  2. Goals and Non-Goals
     - What we are solving, and explicitly what we are not.
     - Non-goals are the fence that keeps discussion from wandering.

  3. Proposed Design
     - The core approach. Diagrams, data flow, key interfaces.

  4. Alternatives Considered
     - Other options, and why they were not chosen.

  5. Trade-offs / Risks
     - What this choice gives up. Where it can go wrong.

  6. Rollout / Migration (optional)

The two sections most people skip are actually the most important: Alternatives Considered and Trade-offs. A doc without them is an argument that says "accept my answer." A doc with them is an invitation that says "let's judge this together." Reviewers trust the latter far more. When they see the very alternative they were about to raise already considered and rejected in the doc, they relax: "this person did the thinking."

Lead With the Problem, Not the Solution

The most common persuasion mistake engineers make is leading with the solution they have already fallen in love with. "Let's move this to Kafka." At that moment, half the room mentally takes the other side. They don't even know why the change is needed and they are already being handed a conclusion.

People buy the problem before they buy the solution. Flip the order.

  • First, paint the problem sharply. "Order processing is backing up at peak. Over the last month, inventory updates after payment lagged by an average of 40 seconds, and in that window we oversold 217 times."
  • At this point, the whole room is on the same side. Nobody wants to oversell. You now have people looking at the problem with you.
  • Only then do you bring out the solution, together with its alternatives. Because people already feel the problem, they now evaluate the solution by "how well does it fit" rather than "friend or foe."

It's easy to argue against a solution, but hard to argue against a well-defined problem.

Turn this around and it becomes a diagnostic. When someone pushes back hard on your proposal, they usually don't dislike the solution — they don't agree it's a problem worth solving in the first place. Defending the solution harder is wasted effort there. You have to step back to the problem. The question "are we even looking at the same problem?" moves the discussion forward more than ten feature comparisons.

Tailor the Message to the Audience

The same decision has to be packaged completely differently depending on who you're explaining it to. The most common failure is dumping implementation detail on an executive the way you would on a peer. They lose interest in five minutes, and you walk away thinking "they don't get the tech."

The key is knowing what each audience worries about.

AxisExecutive / LeaderPeer Engineer
What they want mostCost, risk, timelineTrade-offs, implementation
Desired takeaway"What does it cost, what's risky, when's it done""Why this design, where's it weak"
Favored evidenceBusiness impact, opportunity cost, competitive riskBenchmarks, failure modes, code structure
Level of detailConclusion first, summary-heavyDeep, down to the reasoning
Time budgetShort. Get to the point in three sentencesLong. Ready to dig in

For an executive, lead with the conclusion. "This migration takes six weeks, has a rollback plan mid-flight, and if we skip it we risk an outage under next quarter's traffic." A leader doesn't want an elegant algorithm; they want the inputs to a decision — cost, risk, timeline. They have to weigh your proposal against ten other priorities using exactly those three levers.

For a peer engineer, do the opposite and go deep on trade-offs and implementation. They want to know "why B and not A," "how does this design fall apart under concurrency," and the more diligently you answer, the more trust you earn.

Telling the same truth, but handed over in a form the other person can carry — that isn't manipulation. It's consideration, and it's translation.

Make the Trade-offs Explicit

If I had to name a single signal that separates an immature proposal from a mature one, I would watch for whether it surfaces its own trade-offs. Every technical decision costs something. There is no free lunch. Yet a novice's proposal lists only upsides: "This is faster, cleaner, more scalable." Such a proposal actually buys distrust. A seasoned reviewer knows that if the cost isn't visible, it just means the cost hasn't been found yet.

So a strong proposal names its own weaknesses first.

  • "This cache layer makes reads much faster, but it introduces a whole new class of bugs: cache invalidation complexity."
  • "Splitting into microservices lets teams deploy independently, but the price is distributed transactions and operational overhead."
  • "Using this library saves us two months, but it chains us to their release cycle."

Naming the cost up front does three things at once. First, it earns trust: "this person sees the whole picture." Second, it seizes control of the discussion — you put the weakness on stage before an opponent could point at it and shout "gotcha." Third, it raises the quality of the decision, because the whole team now judges against a visible cost instead of a hidden one.

Every decision costs something. If you don't name the price, the invoice arrives later — with interest.

Async vs. Sync — When a Doc Wins, When a Meeting Wins

"Should I write a doc or book a meeting?" This choice trips people up every time, but it actually has fairly clear criteria. There are two axes: the complexity of the information and how converged the opinions already are.

Async (docs, threads) wins when:

  • The information is complex and precision matters. Architecture proposals, incident postmortems, API design — things where people need to chew at their own pace and object precisely.
  • The team spans time zones. A document keeps the discussion moving without waking anyone who's asleep.
  • A record must remain. Any decision where, six months later, someone needs the answer to "why did we decide this?"

Sync (meetings, calls) wins when:

  • Opinions diverge and emotions are running. A standoff that won't narrow after five round-trips in a thread often dissolves in a fifteen-minute call. Text tends to amplify misreadings and defensiveness.
  • Even the problem definition is still fuzzy. Brainstorming what to solve is overwhelmingly faster as real-time catch than as prose.
  • It's urgent and the relationship is at stake. Building trust or patching a conflict needs a face, or at least a voice.

In practice, the most powerful move is to combine the two. Circulate a doc before the meeting so everyone stands on the same context ("read before the meeting"), then use the meeting only to close the disagreements the doc already surfaced, in real time. And write the meeting's decision back into the doc as the async record. Amazon's famous ritual of reading a six-page narrative in silence for the first twenty minutes of a meeting is exactly this combination — capturing both the precision of a document and the immediacy of a meeting.

Beware one anti-pattern: the endless argument in a thread. When comments on the same topic pass twenty and each person turns a little more defensive, that is the signal to book a meeting. Conversely, dragging matters that don't need an immediate answer into a meeting is also waste. Reserving thirty minutes on someone else's calendar should always carry a reason worth that much.

Disagree and Commit

However well you argue, a day will come when your proposal isn't the one chosen. Maybe your data was thin, maybe the leader saw a constraint you didn't, maybe the organization simply picked a different direction. What you do next determines your maturity as a senior engineer.

There are two worst responses. One is sulking behind the scenes — staying quiet in the meeting, then muttering "I told you it would fail" afterward. The other is quiet sabotage — since you never agreed in your heart, you drag your feet on execution too. Both corrode the team and, decisively, destroy trust in you.

The mature alternative is the principle Amazon codifies as "disagree and commit." It means this.

  1. In the moment of debate, object with everything you have. Staying quiet is not a virtue. Putting the risks you know clearly and forcefully on the table is your duty. Holding back here is actually a failure of diligence.
  2. Once the decision is made, execute it fully. Once the organization sets a direction, you sprint to make that decision succeed as if it had been yours. You don't bury your lingering resentment inside the execution.

Separating these two is the key. The "phase of persuasion" and the "phase of execution" are different. In the former you argue fiercely; in the latter you commit cleanly. Paradoxically, people who can do this earn greater trust next time. Few assets are as valuable as the reputation that "when they disagree, they disagree hard, but once it's decided, they never stab you in the back."

One addition: committing does not mean swallowing being wrong forever. If the decision genuinely produces bad outcomes, you can return to the table with that data. But your grounds then must be newly observed facts, not "I told you so." Commit and re-litigation are not contradictory. Commit is a promise not to be lazy in execution, not a vow of eternal silence.

The "Strong Opinions, Loosely Held" Trap

Our industry has an old slogan: "strong opinions, loosely held." Originally proposed by the futurist Paul Saffo as a stance toward forecasting — form a strong hypothesis about an uncertain future, but drop it without regret when new evidence arrives — it is, in itself, healthy advice.

The problem is that in the wild, this phrase is often used to mean the exact opposite. What actually happens:

  • The person who asserts most confidently, in the loudest voice, dominates the room. Only the "strong opinions" half got practiced.
  • But the "loosely held" half evaporates. When challenged, they don't change their mind; they just assert something else, equally strongly, on the next topic.
  • As a result, the slogan becomes a license to disguise confidence as evidence. In practice, volume wins, not data.

There is a quiet but serious side effect. The most careful person in the room — usually the one honest enough to say "I'm not sure," the junior still gathering data — gets automatically drowned out. In a culture where speaking strongly is mistaken for being right, the loud person's mistake beats the quiet person's insight. This slowly erodes the team's decision quality.

So what should you do? Not abandon the phrase, but practice it for real.

  • When you give an opinion, state your degree of confidence with it. Simply distinguishing "I'm nearly certain of this" from "this is a hunch" changes the quality of the discussion.
  • Say in advance what would change your mind. "If the benchmark shows X, I'll drop my position." That one sentence turns "loosely held" from words into action.
  • And when you actually get refuted, change your mind visibly. A senior who says out loud "ah, I missed that point — you're right" sends the team a powerful signal: that here, being right sits above ego.

Having a strong opinion is cheap. Putting it down honestly is the whole point of the phrase.

Wrapping Up

The ability to get technical decisions made is not a gift of eloquence. It is the sum of a few learnable habits: proposing through writing that gets reviewed (design docs and RFCs) rather than talk; getting people onto your side with the problem before the solution; handing executives cost, risk, and timeline while handing peers trade-offs and implementation; naming the price of every decision yourself; choosing docs versus meetings by the situation; committing cleanly after you lose an argument; and treating "strong opinions" as an honest hypothesis rather than a license for confidence.

If a single attitude runs through all of it, it's taking responsibility for clarity. Not what you know, but making others understand it, trust it, and decide alongside you — that's where the senior job begins. If writing good code is half the work, making the organization believe together that the code is right is the other half. And usually, the second half is harder and worth more.

References

Discuss on Twitter • View on GitHub