Interest-Based Negotiation

A position is what someone says they want: "we will only provide a nightly batch file", "the launch must be in six weeks", "it must be built on the paved road".

An interest is why they want it: protecting a fragile system, avoiding operational burden, meeting a customer commitment, keeping the estate supportable.

Positions frequently conflict when interests do not, and the negotiation is unresolvable at the level of positions while being straightforward at the level of interests.

Why it matters to architects

A large part of architectural work is reconciling parties with different objectives — product and security, platform and stream teams, a company and its integration partners. An architect who negotiates positions either picks a winner or produces a compromise nobody wanted.

An architect who surfaces interests can usually find a third option: satisfying the underlying needs rather than the stated demands. That is frequently where the most value is added in the entire role.

Implementation patterns

• Ask why, twice. The first answer is usually a restated position; the second is often the interest.
• Look for asymmetric value. Something cheap for you and valuable to them — running the integration yourself, absorbing a rate limit, taking on the operational burden — changes the shape of the deal at low cost.
• Separate constraints from preferences. A requirement from a regulator or a customer contract is a constraint; a preference for a particular approach is negotiable. Naming which is which collapses much of most conflicts immediately.
• Generate options before evaluating them, so the conversation does not narrow to two positions prematurely.
• Use objective criteria — measured data, an industry norm, a cost model — so the outcome rests on something other than relative authority.

Industry example

The recurring internal case is a feature with a committed date, a security control with a longer lead time, and a platform team wanting a paved road that does not yet support it. The positions are irreconcilable in six weeks; the interests — meet the customer commitment, keep the risk acceptable, keep the estate supportable — admit a compensating control: something cheaper that reduces the risk enough to ship, with the full control committed and dated, and migration debt owned with a date.

The external case is a partner offering only a nightly batch. If their interest is load protection, a rate-limited incremental interface may be acceptable. If it is operational burden, offering to run the integration changes the conversation entirely. Neither option is visible while the discussion is about batch files.

Failure scenarios

• Assuming the position is the interest, and negotiating a compromise on the wrong axis.
• Treating every requirement as negotiable, including genuine constraints, which destroys credibility.
• Winning the negotiation and losing the relationship, which matters when the counterparty is a partner you depend on or a team you work with every week.
• An agreement that requires the counterparty to behave well, with no specified behaviour when they do not. That is a hope, not an agreement.

Trade-offs

Surfacing interests takes time and a degree of trust, and some counterparties will not disclose them — particularly in a commercial negotiation where the interest is leverage. In those cases positional bargaining is what is available, and recognising that quickly is better than persisting with an approach the other side is not participating in.

The approach also risks over-accommodation: an architect who always finds a way to satisfy everyone may be absorbing costs that should have been pushed back. Some conflicts should be escalated rather than solved.

Interview question

"A partner insists they can only provide data as a nightly file, and your product needs updates within minutes. Walk me through the conversation you would have — and tell me what you would build regardless of how it goes."