Many engineers (me included) I met have a drawer full of proposals that never went anywhere. Technically airtight. Benchmarked. Diagrammed. Presented to a room of intelligent people who nodded politely and went a different direction.

You walk away muttering the same thing every technically correct person has muttered since the beginning of organized work: “They just don’t get it”.

They got it. They just weren’t moved.

Perelman spent decades dismantling this blind spot. In his The new rhetoric: a treatise on argumentation, he drew a line that most of the intellectual tradition had been smudging since Descartes: the line between convincing and persuading.

Convincing is an operation on logic. You assemble premises, you chain them together with valid inferences, and you arrive at a conclusion that any rational agent should accept. The target is what he called the “universal audience”, an idealized audience of every reasonable mind that ever existed or could exist. If your argument is valid, it should work on all of them. A mathematical proof convinces. A benchmark convinces. A failing test suite convinces.

Persuading is a different animal entirely. Persuading targets a particular audience: these people, in this room, with these fears, these incentives, these memories of the last migration that went sideways. Persuading doesn’t ask “is this logically sound?”. It asks “will this move them to act?”.

Convincing addresses reason. Persuading addresses the full human. And the gap between the two is where most technical proposals go to die.

You can convince every person in the room that your microservices architecture is superior to the monolith. You can lay the evidence flat on the table like a surgeon displaying X-rays. And they will still vote for the monolith, because the last team that attempted a migration was disbanded, because the VP of Engineering ships their bonus on a Q3 deadline, because the tech lead built the monolith and his pride is load-bearing infrastructure.

Pascal used to distinguish between geometric and subtle minds (sensibilities). The geometric mind works through axioms and deductions, step by step, like a compiler. The subtle mind grasps a situation holistically, reading context, feeling the weight of unspoken constraints, sensing what a room will and won’t tolerate.

This is clearly a simplification, but engineers are usually trained almost exclusively in the geometric mind. The entire discipline is built on the assumption that correctness is sufficient, that if you can prove something works better, the proof carries its own momentum. Unfortunately in reality it doesn’t. Correctness is necessary but it is not sufficient. It should be the foundation, not the building.

This is why the best technical decision-makers I’ve ever worked with aren’t necessarily the smartest or most technically proficient people in the room. They’re the ones who learned, often painfully, that an argument aimed at “every rational person” lands on no one in particular. They stopped presenting to the universal audience and started reading the particular one.

Think about the last RFC/ADR/One-Pager you wrote.

You laid out the problem statement, described the current architecture and its failure modes, proposed a solution, backed by evidence. You anticipated objections and addressed them. In your opinion it was clean, thorough, well-reasoned.

Once presented you probably had some of the following people in your audience. The SRE guy who’s drowning in incidents and sees any architectural change as another surface area for things to break. The product manager who translates every engineering proposal into “how many sprints does this cost me”. The junior engineer who doesn’t understand the current system well enough to evaluate a replacement.

Probably your RFC even convinced them. But it didn’t persuade them. And you confused the two, so when the proposal stalled, you assumed the problem was comprehension. You added more diagrams. You wrote a longer appendix. You scheduled another meeting to walk through it again.

You were just polishing a handle of a door no one wanted to open.

This terrain was mapped millennia ago. The three dimensions of rhetoric are since then well-known: the logical structure of the argument, the credibility and character of the speaker, and the emotional state of the audience.

Convincing lives almost entirely in the logical structure.
Persuading requires all three mixed together and calibrated to context.

In software engineering, we worship logic and treat the other two as contamination. We act as though caring about who is making the argument, or how the audience feels about it, is a form of intellectual corruption. It’s not. It’s the recognition that human beings are not compilers. They don’t parse your argument in isolation from everything else they’re carrying that day.

What drives decision-making has little to do with logical validity. Not because logic doesn’t matter, but because logic operates on a different layer of the stack. You need the logic underneath if you want to bring a solid proposal: that is your job.
But it’s not the interface. The interface is trust, timing, and the careful art of making someone feel that acting on your proposal serves what they already care about. This is not manipulation, which would require you not actually having the honest conviction underneath. The two must work together: you need a sound argument and the skill to land it.

Conviction without persuasion is impotence. Persuasion without conviction is fraud.

This doesn’t only cut one way. A VP of Engineering who decrees a change has the authority to make it happen. The org chart says so. The decision is made, communicated, documented.

Then nothing moves or results are way worse than expected.

Engineers complied without committing. They did the minimum the process demands and none of what the change actually requires.
Authority without credibility is just a mandate with no engine behind it. The VP convinced no one, they didn’t need to: they have the title. But they also didn’t persuade, because persuasion requires much more than the reporting line alone can provide.

Positional power gets compliance. Persuasion gets commitment. The gap between those two is where rewrites stall, migrations rot, and strategic initiatives quietly become shelfware.

Engineers and leaders who actually move things aren’t the ones who are right the most often. They’re the ones who learned that being right is the starting line, not the finish.

If you liked this post, consider subscribing to receive new posts, or sharing it on Hacker News.