There's a quote that floats around, usually misattributed to George Bernard Shaw: "The single biggest problem with communication is the illusion that it has taken place." I think about this line constantly. You walk out of a meeting thinking alignment was reached. Two sprints later, two teams are building different things. Everyone was in the room. Everyone nodded. Nobody understood the same thing.
Over the years I've come to accept an uncomfortable truth: when I present a design and people nod, there's a good chance most of them heard something different from what I said. Not because they weren't paying attention, but because interpretation is personal. Experience, context, values, what happened to them on their last project, it all filters what lands. Seniority doesn't predict it either. I've seen senior engineers walk out of the same review with opposite understandings of what was decided.
Once you accept this, it changes how you communicate. You stop assuming the nod means agreement. You start recapping, restating, asking people to play it back.
Nobody ever made a decision because of a number
Early in my career I thought the way to win an architecture argument was to bring better data. Lower latency, fewer failure modes, cleaner separation of concerns. I'd show benchmarks. I'd show diagrams.
It rarely worked the way I expected. The proposals that actually moved people were the ones that told a story. Not a manufactured narrative, a real one, from a real project, with a real outcome.
"We should use event sourcing" is an assertion. "Last quarter, our order service needed to reconstruct state after a failover, and because we had no event log, the team spent three weeks manually reconciling, that cost us a product launch" is a story. The same technical recommendation, but one speaks to intuition and the other speaks to a spreadsheet. People decide with intuition first and justify with data later.
I used to think this was a flaw in how organizations make decisions. Now I think it's just how humans work. If you want your architecture to get built, you need to make people feel why it matters before you show them how it works.
What I learned is that when someone raises an emotional objection to a technical proposal, responding with technical facts creates disconnect. You have to meet them where they are first. Acknowledge the feeling, understand the history, then redirect to the practical discussion. Skip that step and you'll win the argument on paper while losing the room.
The RFC is a persuasion instrument
I used to think of RFCs and ADRs as documentation. A record of what was decided and why. That's the least interesting thing they do.
The real value of writing a proposal down is that it forces you to anticipate objections before the meeting happens. Every time I write an RFC, I discover gaps in my own thinking, edge cases I glossed over, alternatives I dismissed too quickly, assumptions I didn't realize I was making. The document makes those visible before a stakeholder does.
But the bigger thing is that the review process gives people a voice before the decision is finalized. That's the mechanism for buy-in. When someone leaves a comment on your RFC and you incorporate their feedback, they become a co-author of the decision. They're no longer being sold to your proposal, they're part of the thing being built.
One pattern I've noticed is that the more people involved in an architecture decision, the more disagreement you get. Solo decisions are clean and fast. Group decisions are messy and slow. And group decisions produce better outcomes almost every time, because the friction surfaces problems that a single perspective would miss.
What I actually do now
I'm an engineer. My instinct is to let the technical merits speak for themselves. But they don't, so I've built habits:
I structure proposals as stories, not specs. Situation, problem, what we tried, what happened. The technical details come after the narrative context. When people understand why before what, they engage differently.
I recap constantly. After every significant discussion point, I pause and restate what I think was agreed. It feels redundant. It catches misunderstandings about half the time.
I write before I present. The RFC draft is where I do my real thinking. By the time I'm in the room, I've already stress-tested my own arguments and I know where the weak points are.
I listen for the type of conversation. Is this person raising a technical concern, an emotional one, or a political one? They require completely different responses. Treating them all as technical is the fastest way to lose trust.
I invite disagreement explicitly. "What am I missing?" is the most productive question in an architect's toolkit. It gives people permission to push back without framing it as conflict.
The best architecture I've shipped wasn't the most technically elegant. It was the stuff I managed to get an entire team genuinely behind, where people understood the tradeoffs, felt heard in the process, and defended the decisions when I wasn't in the room.
You're not just designing systems. You're selling them. And the sooner you get comfortable with that, the better your systems will get.