Influence Without Authority

Senior engineers rarely get to decide anything unilaterally outside their own code. Migrating off the ORM, adopting a design system, spending three weeks on the flaky test suite — all of these need other people to agree, and none of them come with a lever you can pull.

The mechanics that actually work:

Translate into the listener's currency. An engineer cares that the abstraction leaks; a founder cares that shipping a new surface takes three weeks instead of three days. Same argument, different sentence. Making a PM justify your refactor to themselves — because you framed it as roadmap velocity — is a different outcome from asking permission for it.

Do the work before the argument. A prototype, a benchmark, a one-page doc with the three options and a recommendation, a spiked branch showing the migration is two days not two months. Opinions get debated; artefacts get reviewed. Most decisions are won by the person who did the reading.

Pre-socialise. Meetings are for confirming decisions, not making them. Talk to the two people who'll object beforehand, understand their objection properly, and either fix it or name it in your proposal. Being surprised in the room by an objection you could have predicted is the common failure.

Trade credibility carefully. You get a limited number of "trust me on this" cards, and they're replenished by being right, and by publicly conceding when you weren't. The engineer who fights every battle loses the ones that matter.

Give the credit away. Adoption goes up when the idea belongs to the group.

Behavioural rounds probe this with "tell me about a time you convinced someone" and "a time you couldn't" — and the second is more revealing. At a small company you'll be the most experienced person on some surface, arguing for work that costs the roadmap something. If the only tool you have is being right, most of your good ideas will die in Slack.

• Influence comes from artefacts — prototypes, benchmarks, a one-page options doc — more than from argument quality.
• Frame the proposal in the listener's units: roadmap time, churn, incident count, hiring, not internal elegance.
• Pre-socialise with likely objectors; a meeting is where a decision is confirmed, not made.
• Understand the objection well enough to state it better than the objector can, then address it directly.
• Credibility is finite and spendable — pick the two fights that matter and concede the rest visibly.
• "A time you failed to convince someone" is the sharper question; a good answer includes what you'd do differently and whether they turned out to be right.
• Letting the decision become the team's idea rather than yours is a feature, not a loss.