Designing Incentives in Vendor-Customer Relationships
Contract structure is a design choice that shapes incentives, not a fixed container for engineering work.
The Belief That Contracts Sit Outside Engineering
Many engineers who move into customer-facing deployment work quietly assume that the terms of an engagement belong to a different department. Procurement negotiates the price, legal drafts the language, and the technical team builds whatever the signed document describes. On this view, the contract is a fixed container that the engineering work gets poured into. Nothing about how the terms are arranged is considered a design decision.
What do you think happens?
Before reading on: does the way a contract is arranged change what people actually do once the system is deployed?
Reveal answer
Yes, the arrangement changes behavior on both the customer side and the vendor side.
The source's position is that the contract's arrangement does change behavior on both sides of the table, and that treating it as someone else's problem is a missed opportunity rather than a neutral choice. The rest of this article tests that claim.
This belief is worth examining closely, because it is the exact belief the source argues against. The source treats contract structure as a deliberate choice that the FDE can shape, not as a fixed backdrop. Throughout this article, the term FDE refers to the role that proposes, defends, and adjusts that structure.
Where the Separate-Container View Breaks Down
The separate-container view treats the contract and the engineering work as two different objects that touch only at signing. The source argues for a different relationship: the contract is itself a design input. Engineering decisions and contract decisions are made against the same set of incentives, so treating them as separate loses information about how the engagement will actually run.
The difference matters in practice. Under the separate-container view, a mismatch between what the contract rewards and what the product needs is discovered late, if at all. Under the design-input view, the same mismatch is a question the FDE can raise while the structure is still being shaped.
Three Things a Contract Structure Touches
The source names three things that a contract structure touches. The first is the customer's incentive to actually use the system. The second is the vendor's incentive to ship features that drive adoption. The third is the long-term arc of the relationship between the two parties. The contract is the thing being designed, and the incentives on both sides are the things it moves.
The diagram is a summary of the relationships the source describes, not an exhaustive model. Its arrows from the contract to each incentive are stated by the source. The arrow from customer usage back to the vendor is an interpretation added here: the source says these three things are not independent, and this is one way that dependence can run. Reading the figure as a loop, usage shows the vendor what the customer actually does, which then bears on what the vendor chooses to build.
The source states the dependence directly. The three things are not independent, and a structure that rewards one party for something the other party does not care about will tend to produce the wrong behavior, even when everyone signs in good faith. The contract does not need bad intent to misdirect effort. It only needs a misaligned reward.
The FDE's Three-Part Sequence
The source does not stop at saying the contract matters. It describes what an FDE who takes the contract seriously actually does. The sequence has three parts: the FDE proposes a contract structure, defends it, and adjusts it. Each part answers a different question about the engagement.
The word that matters in the sequence is adjusts. A structure set once at signing and then ignored is treated as fixed. The source frames the structure as something the FDE keeps working on, and it reports that an FDE who does all three parts captures far more of the intended value of the engagement. The excerpt does not specify what triggers each change, so the timeline shows the order of the three actions and not the events that cause them.
Worked Example: A Milestone-Based Engagement
The source refers to a four-milestone contract and to a composite negotiation drawn from real engagements, but the excerpt does not describe their terms, so they cannot be reconstructed here. The following scenario is generated for this article. It is not a case from the source. It is built only to show how the three-part sequence and the incentive reasoning fit together.
Tracing incentives through a generated engagement
A vendor and a customer agree to a contract in which the vendor is paid in full when the system is accepted, with no payment tied to how much the customer uses it afterward. The FDE is asked what this structure will do to behavior on each side.
- 1Identify what the contract rewards
Payment is tied to acceptance. The vendor is rewarded for reaching acceptance, not for the customer's later use of the system.
- 2Trace the customer's incentive
Once acceptance is reached, the customer's payment obligation is discharged regardless of usage. Nothing in this structure gives the customer a direct reason to keep using the system, so the customer's incentive to use it is weak by design.
- 3Trace the vendor's incentive
The vendor's reward arrives at acceptance. Features that drive long-term adoption pay off only after the payment is already received, so the structure gives the vendor little reason to prioritize them before acceptance.
- 4Propose a structure change
Proposing, in the source's sense, means shaping the structure before it is signed. The FDE could raise the question of whether some payment should be tied to continued use, so that both incentives point toward adoption. This is a design option to evaluate, not a fact about the source.
- 5Name the relationship effect
The third thing a contract touches is the long-term relationship. With the acceptance-only structure, the relationship may be shaped more by the acceptance event than by ongoing value, which is a question the FDE should weigh before signing.
The structure does not produce bad faith. It produces weak incentives on both sides for adoption. Seeing this before signing is the point of treating the contract as a design input.
Likely Failure Points When Mapping Incentives
Applying incentive reasoning to a new engagement is not a one-time check. The chain runs from contract terms to customer behavior to vendor roadmap, and each link can break. The following failure points follow directly from the reasoning in the source.
Common mistake Treating the contract as settled once it is signed
What it looks likeA structure is set at signing and never revisited, even as the customer's usage or the product's needs change.
Why it failsThe source emphasizes that the FDE adjusts the structure. A structure treated as fixed stops guiding incentives once conditions change.
Do this insteadSchedule regular points to ask whether the structure still rewards the behavior the engagement needs.
Common mistake Rewarding one party for something the other does not care about
What it looks likeThe vendor is paid for a milestone the customer never uses in practice.
Why it failsThe source states that a structure rewarding one party for something the other does not care about tends to produce the wrong behavior, even among parties acting in good faith.
Do this insteadFor each payment or reward term, ask what behavior it produces on both sides.
Common mistake Assuming the contract is someone else's problem
Why it failsThe source argues that treating the contract as a separate department's concern is a missed opportunity, not a neutral choice.
Do this insteadInvolve the FDE in shaping the terms while the structure can still change.
Common mistake Assuming good faith prevents misaligned behavior
Why it failsThe source says misaligned incentives produce wrong behavior even when everyone signs in good faith.
Do this insteadCheck the incentive map itself, not the intentions of the parties.
Practice: Mapping a New Engagement
Take a new engagement described by a short set of contract terms, such as a payment tied to a delivery date. Without writing any technical design, map the incentives: what does the customer have reason to do, what does the vendor have reason to build, and what does the arrangement do to the long-term relationship? Then name one place where the incentives could break down.
Hints
- Start with the single term that determines when money changes hands, and ask which party it rewards for what.
- Use the three things a contract touches as a checklist: customer incentive to use, vendor incentive to build adoption features, and the long-term relationship.
- A break usually shows up where one party is rewarded for something the other does not care about.
Key Takeaways
- Contract structure is a design choice that shapes incentives, not a fixed container for engineering work.
- A contract structure touches the customer's incentive to use the system, the vendor's incentive to ship adoption-driving features, and the long-term relationship, and these three are not independent.
- The FDE proposes, defends, and adjusts the contract structure, and the source reports that doing all three captures far more of the intended value.
- Misaligned rewards can produce the wrong behavior even when everyone signs in good faith, so the incentive map should be checked before technical work begins and revisited as the engagement changes.