On this path · Behavioral 2. Influencing Stakeholders Under Disagreement
Influencing Stakeholders Under Disagreement
The architecture-forum dynamic, RFC-driven persuasion, and data over opinion.
Learning outcomes
The behavioral prompt “tell me about a time you influenced a stakeholder with a different opinion” is the one where the most senior candidates give the most junior answers. They describe a conversation they won, a manager they looped in, or a meeting where they talked the loudest. None of those is what an autonomy-first, RFC-driven organization measures as influence. This concept teaches influence as an engineering discipline: the data that outranks opinion, the written artifact that forces disagreement into the open, the coalition that makes the better choice obvious, and the forum where the decision gets recorded.
After studying this page, you can:
- Explain why influence at Trade Republic is an RFC-and-forum activity, not a persuasion activity.
- Structure a dissent so the opposing view is stated more accurately than its holder would state it.
- Build the evidence and the coalition before the decision meeting, not during it.
- Tie any influence story to the speed-versus-security tension the company lives every day.
- Recognize the difference between influencing an engineer, a designer, and an executive, and adapt the artifact accordingly.
Before we dive in
The naive model of influence is rhetorical. You have the right idea, someone else has the wrong idea, and your job is to talk them out of theirs. The reason this model fails inside an engineering organization that makes decisions through written artifacts is that nobody is persuaded by talk when a document is on the table. Talk is cheap, reversible, and deniable. A written comparison of options, costs, and failure modes is none of those things, and in a forum of Senior and Senior-plus engineers, the document does the persuading, not the person.
The problem that shaped this discipline at Trade Republic is the cost of uncoordinated technical choice in a domain-team organization. Roughly 280 engineers split into autonomous teams could fragment into private technology islands without a governing mechanism, so the organization balances two opposing forces: the speed of innovation a fast-moving fintech needs, and the security and compliance a regulated neobank must hold. Every significant technical decision sits on that tension, and influence is the act of moving a decision on that tension with evidence rather than authority. The architecture forum exists so that no single senior can impose a choice by rank, and the RFC exists so that the choice is defensible to peers who were not in the room.
So influence here is a process, and the process has steps. The rest of this concept walks the mechanics, then grounds them in a debate the organization has actually had, so you can tell an influence story that matches how decisions are really made.
The prompt and what it is really measuring
The prompt asks for a time you influenced a stakeholder with a different opinion. What it is measuring is not whether you won, it is whether you can move a technical decision through evidence and process under disagreement. The interviewer is listening for three things that separate a senior influence story from a junior one.
First, did you state the dissenting opinion precisely, or did you strawman it? Second, did you produce evidence that outranks opinion, or did you argue from preference? Third, did the decision land in a durable artifact like an RFC or architecture decision record, or did it live only in a conversation that could be relitigated?
A junior influence story is “I thought we should use a cache, my teammate disagreed, I explained my reasoning, and they agreed.” It has no artifact, no evidence beyond preference, and no durability. A senior influence story is “the staff engineer advocated two-phase commit for cross-service atomicity, I wrote an RFC comparing it to the transactional outbox on three axes, the forum reviewed the failure modes, and the decision was recorded as an ADR adopting the outbox.” The difference is that the second story moved a decision through the organization’s actual mechanism, which is what the signal rewards.
The mechanics of influence at an RFC-driven organization
Data over opinion, the first discipline
The first discipline is that data outranks opinion, always, and the senior’s job is to produce the data before the disagreement reaches the forum. Opinion is “I think the outbox is simpler.” Data is “the outbox adds one table written in the same transaction, while two-phase commit adds a coordinator, a prepare phase, and a blocking failure mode I can demonstrate.” The second statement ends the argument in a way the first cannot, because it is checkable.
The practical move is to convert every opinion into a measurement before the meeting. If you believe option A is faster, instrument it. If you believe option B is riskier, write the failure-mode table. If you believe option C is more expensive to operate, produce the on-call burden estimate. The discipline is that you walk into the forum with evidence your opponent would have produced if they were right, which means the only way to defeat your position is to produce better evidence, not louder opinion.
The diagram’s lesson is that the senior’s real work happens before the forum. By the time the disagreement reaches the room, the data should already have done the persuading, and the forum’s job is to ratify and record.
Writing the RFC that forces the disagreement open
The RFC is the artifact that makes influence durable and depersonalized. A well-written RFC does not advocate, it compares. It states the problem, lists the options with their costs and failure modes, recommends one with reasons, and records the decision. The discipline that makes it an influence tool rather than a polemic is that it presents the strongest version of the option it argues against.
This matters because the most common way an RFC fails to influence is that it strawmans the opposition. A reader who holds the dissenting view reads the weak version of their argument and concludes the author is either ignorant or dishonest, and the document loses credibility even if its recommendation is correct. The senior move is to write the dissenting option’s case so well that its holder signs off on the characterization, then defeat it with evidence. When the opponent agrees with how their position is stated, the only remaining dispute is the evidence, which is exactly where you want the debate to live.
At this organization, significant technical decisions are recorded as RFCs and architecture decision records, and the significant ones go through the architecture forum. So the RFC is not optional ceremony, it is the decision’s permanent home. An influence story that does not name the RFC or the ADR is missing the durability that the signal rewards.
Building the coalition before the forum
The third mechanic is coalition-building, which is the most often skipped and the most often decisive. A forum of Senior and Senior-plus engineers does not decide in a vacuum; it decides against a backdrop of who has already reviewed the evidence and what they concluded. The senior who walks into the forum cold, with a strong RFC but no prior conversations, is often surprised when a concern they never anticipated kills the proposal. The senior who walked the key stakeholders through the RFC beforehand already knows the objections, has either addressed them in the document or prepared responses, and arrives with implicit support.
Coalition-building is not lobbying in the political sense, it is the engineering practice of pre-review. You identify the two or three people whose opinion will sway the forum, you share the draft RFC, you ask what would change their mind, and you incorporate the answer. The cost is a few conversations. The benefit is that by the forum, the dissent is not a surprise, and the decision lands.
The one coalition move that fails the influence signal is escalating over the dissenter to a manager or a more senior engineer to override them. That is escalation theater, not influence. The signal grades moving a decision through evidence in a peer forum, not routing around disagreement with rank.
The speed-versus-security tension every influence story lives inside
Every significant technical decision at this organization sits on the tension between speed of innovation and the security and compliance a neobank must hold. A strong influence story names this tension explicitly, because the decision the candidate influenced almost always traded one against the other. The choice of an eventually-consistent outbox over a strongly-consistent two-phase commit is a speed-versus-correctness trade. The choice of fail-open over fail-closed on a non-critical path is a speed-versus-safety trade. The choice of a new technology on the Tech Radar’s assess ring versus an adopt-ring standard is an innovation-versus-stability trade.
Naming the tension does two things for your story. It shows you understand why the disagreement existed in the first place, because reasonable engineers hold different positions on this tension for good reasons. And it shows you can frame your influence as moving the organization to the right point on the tension for the specific decision, not as defeating a wrong opinion. A staff engineer who wanted two-phase commit was not wrong, they were optimizing for a different point on the tension, and your influence was producing the evidence that the outbox sat at the right point for this system’s latency and failure requirements.
A worked debate: transactional outbox versus two-phase commit
To make the mechanics concrete, walk through the debate the organization has actually had in substance, the choice between a transactional outbox and two-phase commit for publishing state changes reliably. This is the kind of decision that goes to the architecture forum, and it is the kind of influence story that demonstrates the signal at full depth.
The disagreement is real. A senior who has lived through distributed-transaction pain advocates two-phase commit because it gives atomicity across the database write and the message publish without application-level machinery. A senior who has operated two-phase commit at scale advocates the outbox because the coordinator’s blocking failure mode is worse than the application-level complexity it avoids. Both are reasonable; the question is which failure mode this system can tolerate.
The influence work is the comparison. The RFC lays out three axes. On latency, the outbox adds a poll or change-data-capture path but keeps the local transaction fast, while two-phase commit adds a prepare phase that holds locks across the network. On failure modes, the outbox risks at-least-once delivery and duplicate messages, solved with idempotent consumers, while two-phase commit risks a coordinator failure that blocks all participants until recovery, a harder problem. On operational complexity, the outbox adds a publisher and a deduplication concern, while two-phase commit adds a coordinator the team must operate and a recovery procedure they must rehearse.
The evidence that moves the decision is the failure-mode asymmetry. The outbox’s failure mode, duplicate messages, is bounded and handled at the consumer with idempotency keys, which the organization already patterns. Two-phase commit’s failure mode, a coordinator holding locks across participants during recovery, is unbounded in duration and blocks the write path, which at brokerage scale means blocked trades. The RFC demonstrates this with the latency budget and the recovery procedure, and the decision lands on the outbox because its failure mode is the one the business can tolerate.
The influence story, told in an interview, is not “I was right about the outbox.” It is “the staff engineer preferred two-phase commit for its atomicity guarantee, I wrote an RFC comparing both on latency, failure mode, and operational cost, demonstrated that the outbox’s duplicate risk was bounded by idempotency while two-phase commit’s blocking risk was unbounded, and the forum adopted the outbox as an ADR.” That story has a precisely stated dissent, evidence over opinion, a forum, and a durable record, which is the full signal.
Influencing different kinds of stakeholders
The prompt names three kinds of stakeholder: an engineer, a designer, and an executive. The influence discipline is the same, data over opinion, written artifact, coalition, but the artifact and the evidence differ by audience, and a senior adapts.
Influencing an engineer is the case above: an RFC, a failure-mode table, a forum of peers. The evidence is technical, the artifact is an ADR, the coalition is the architecture forum. Influencing a designer is different because the disagreement is usually about user experience, not mechanism. The data that outranks opinion here is a prototype, a usability finding, or a latency measurement tied to a user-perceived delay, and the artifact is a design doc or a spec that records the tradeoff. The 40-millisecond search experience is an example: a designer might want richer result rendering, and the influence is a measurement showing that the rendering budget eats the latency target, recorded as a design constraint. Influencing an executive is different again because the executive cares about business outcome and risk, not mechanism. The data is impact, cost, and risk in business terms, the artifact is a one-page decision memo, and the coalition is the exec’s trusted lieutenants.
The engineer reads an RFC for failure modes, the designer reads a spec for user-perceived tradeoffs, the executive reads a memo for impact and risk. Same discipline, different evidence and artifact. A senior influence story names the stakeholder type and matches the artifact to it.
Common mistakes candidates make
The first mistake is influence-as-persuasion, describing a conversation won by charisma. The signal grades data over opinion and a written artifact. The fix is to name the RFC, the evidence table, and the forum.
The second mistake is strawmanning the dissent. The candidate describes the opposing view as obviously wrong. The signal grades stating it precisely. The fix is to articulate the strongest version of the dissent and the evidence that defeated it.
The third mistake is escalation theater, going over the dissenter to a manager. The signal grades moving a decision through a peer forum. The fix is to describe the forum review and the recorded decision.
The fourth mistake is skipping the coalition, walking into the forum cold. The candidate describes a surprise objection that nearly killed the proposal. The signal grades pre-review. The fix is to describe the stakeholders walked through the draft and the concerns incorporated.
The fifth mistake is ignoring the speed-versus-security tension. The candidate frames the dissent as right-versus-wrong. The signal grades understanding why reasonable engineers held the other position. The fix is to name the tension and frame the influence as finding the right point on it for this decision.
What the interviewer asks next
After an influence story, the interviewer probes for the three measured properties and for depth.
The interviewer asks “what was the strongest argument for the option you argued against?” If you cannot state it, you strawmanned the dissent. The interviewer asks “what evidence did you produce, and what would have changed your mind?” If the answer is preference rather than measurement, the influence was rhetorical. The interviewer asks “where is the decision recorded, and who has to follow it?” If there is no artifact and no scope, the influence was a conversation, not a decision. The interviewer asks “who did you talk to before the forum, and what concern did they raise that you had not anticipated?” If you went in cold, you skipped the coalition.
The follow-up questions are designed to distinguish a lived story from a rehearsed one. Prepare each influence story by pre-answering the strongest dissent, the evidence produced, the artifact recorded, and the pre-forum conversations that shaped the proposal.
Mastery Questions
Question
The behavioral prompt asks for a time you influenced a dissenting stakeholder. What three properties does the interviewer measure, and how does a junior answer differ from a senior one?
Answer
The three properties are: did you state the dissent precisely, did you produce evidence that outranks opinion, and did the decision land in a durable artifact like an RFC or ADR. A junior answer describes a conversation won by reasoning. A senior answer names the dissenting opinion's strongest version, the evidence table produced, the architecture forum that reviewed it, and the recorded decision. Talk is deniable; a written comparison is not.
Sources & evidence4 claims · 3 cited
The influence prompt and the RFC-and-forum decision process are from the interview and Tech Radar sources; the speed-versus-security tension and the outbox failure-mode evidence are sourced. The four-mechanic influence framework is internal-reasoning and carries no claim.
- The behavioral round explicitly probes influencing a stakeholder, an engineer, designer, or executive, who holds a different opinion.verified
- Trade Republic records significant technical decisions as RFCs and architecture decision records, and the significant ones go through an architecture forum of Senior and Senior-plus engineers, making influence an RFC-and-forum activity rather than a persuasion activity.verified
- The organization balances two opposing architectural forces: the speed of innovation a fast-moving fintech needs and the security and compliance a regulated neobank must hold, which is the tension every influence story lives inside.verified
- In a transactional outbox at high insert and publish rates, partial indexes bloat and poison-pill messages stall the publish transaction, which is the concrete failure-mode evidence that informs a documented outbox-versus-two-phase-commit tradeoff.verified
Cited sources
- How to Pass the Trade Republic Software Engineer Interview (JobMentis) · JobMentis (interview outcome database)
- From Architecture to Tech Radar: How Trade Republic uses Tech Radar and Architecture processes · Trade Republic Engineering (Daniela Valero)
- PostgreSQL + Outbox Pattern Revamped Part 1: Incidents and a new design pattern · Trade Republic Engineering (Sadeq Dousti)