Mechanism Design
Before you make a rule, ask what each person has a reason to do under it.
Start with the outcome you need, then make rules that give each person a reason to help produce it.
An engineering organisation wants teams to report reliability risks early. Everyone agrees that this is the goal, and the first policy sounds reasonable:
Teams that cause serious incidents will lose part of their performance rating.
Incident numbers fall, so the system appears safer.
Then a release begins producing unusual payment failures. The owning team quietly retries transactions and describes the issue as expected provider instability. Because reporting the incident would reduce their score, the policy gives the team a reason to delay reporting it. By the time the problem can't be hidden, support is carrying an avoidable outage and the on-call engineer is exhausted.
Incident reports fell because teams had more reason to hide incidents. The reliability risk was still there.
Rewarding reports creates another problem
Leadership reverses course and gives teams recognition for every risk they report.
Reports increase rapidly, along with duplicate warnings, harmless anomalies and issues divided into several tickets. Reviewers become overloaded and start approving classifications by habit. A direct reward for reporting creates more visible reporting, while the organisation still can't tell which risks need action.
Both policies started with the desired outcome and rewarded a nearby number. Neither asked what people would do once they understood the new rules.
Check what the rules make sensible for each person
Mechanism Design works backwards from the outcome you want to the rules, information and incentives that make people's sensible actions produce it.
The central question is whether each person has a reason to take the action the system needs.
For the reliability policy, the goal is early, truthful reporting of risks that matter, followed by fast containment and learning. A stronger setup might combine:
- Automatic evidence from measures such as error rates and response times, so the team does not rely on self-report alone
- Credit for reporting uncertainty before customer impact grows
- An easy way to correct an honest first call about what is happening
- Clear, limited authority to pause a rollout without waiting for an executive
- Reviews that separate a controllable mistake from an ordinary system surprise
- Clear consequences for deliberate concealment or fabricated evidence
- A separate check for whether the policy makes teams avoid taking responsibility for difficult systems
Now an engineer who has weak evidence of a problem can raise it early without taking a predictable personal hit. Raising it lets the team pause the rollout, evidence beyond the team's own report helps show what happened, and hiding the problem becomes harder.
Changing the score changed which action protected the team, even though their values had not changed.
What to look at before you make the rule
To work through the reliability policy, start with these questions:
- Who knows what? Who has information the system needs, and what might they keep to themselves?
- What can they do? What can each person report, choose, refuse, delay or manipulate?
- Who gets what? How are money, access, attention, responsibility and decision rights assigned?
- What does each choice cost? What does a person gain or lose from each action?
- What happens once people adapt? After everyone learns the rules and responds to one another, which behaviour becomes normal?
Policies often model the first response and miss what participants will do after they learn how everyone else is responding.
Economists call a mechanism incentive-compatible when telling the truth or doing the useful thing is a person's best option under the assumptions. Incentives include money, delay, embarrassment, status, effort, access, blame, reversibility and the ability to appeal.
Before you ship a rule, list how a person could avoid it, delay it, report the wrong thing or game it.
How rules change the choices people make
Economics and auctions
An auction designer can't directly observe how much each bidder values an item. The designer chooses bidding, allocation and payment rules so bidders reveal useful information through their choices. Some formats make truthful bidding the strongest strategy under particular assumptions. The practical lesson is to start with the information the system needs, then choose bidding and payment rules that give bidders a reason to reveal it.
Auction efficiency can't decide which rules are fair, while rights and dignity still constrain the available design.
Law and constitutional design
Law distributes powers, creates procedures and anticipates actors pursuing their own interests. Separation of powers, disclosure duties, appeals and burdens of proof shape what officials and citizens can do, what evidence becomes visible and how errors can be challenged. The procedures should still expose and challenge a bad decision when an officeholder acts in their own interest.
Rules still depend on enforcement and culture. A formal appeal that's expensive, dangerous or controlled by the original decision-maker may exist on paper and provide no practical constraint.
Software, product and organisations
Rate limits, queues, defaults, access rules, reputation systems and the promises one service makes to another all change which actions are cheap or possible. A marketplace that ranks drivers mainly by acceptance rate encourages people to accept jobs optimistically and cancel late. Rewarding accurate availability and completed service gives drivers a reason to reveal better information. Inside an organisation, ownership rules and performance measures decide which work becomes visible and which risks people hide.
Software enforces rules consistently, which gives bad mechanisms unusual reach. A flawed policy in code can distribute harm faster and make exceptions harder to recognise.
In each case, test the rule and the response it makes attractive.
A practical design pass
Use this model when creating incentives, marketplaces, approval systems, team structures, pricing, elections, resource allocation, agent protocols or any process involving private information and strategic choice.
Work through these questions:
- What outcome must the whole system produce?
- Who participates, and what does each person know or want?
- Which behaviour makes sense for each person right now, even if it hurts the whole system?
- What can participants misreport, hide, delay or game?
- Which rules determine access, allocation and consequences?
- What happens after participants learn the rules and adapt?
- Can useful behaviour become easier, safer or more rewarding?
- Which rights and protections must the rule preserve, even when giving them up would improve the result?
- How can you test the rules on a small scale and reverse them if they cause harm before they govern everyone?
Test the rules with cooperative, tired, cautious, opportunistic and adversarial people, then fix the cases where they fail before applying them to everyone.
Where formal rules stop helping
Mechanism Design can create false confidence. People have mixed motives, incomplete understanding and relationships that exceed formal rules. Participants may collude, find an action the designer omitted or experience the same consequence very differently.
Incentives can also crowd out judgment and trust. Paying for every helpful act can turn ordinary cooperation into a transaction. Heavy monitoring can make truthful people feel distrusted and move important work into less visible channels.
There's a power problem too. A mechanism may be stable and efficient for its designer while shifting risk onto people who had no voice in choosing it. Optimising compliance doesn't make it legitimate.
Treat a proposed mechanism as a hypothesis. Test it on limited scope, inspect behaviour at the edges and provide a correction or appeal path before scaling it.
Models that sit close to it
The Principal-Agent Problem diagnoses a situation where someone acts on another person's behalf while holding different information or interests. Mechanism Design asks how the contract, information flow, authority and consequences could be structured so delegation produces a workable result.
The Cobra Effect shows one way an incentive can backfire. Mechanism Design asks you to model that response before shipping the rule and keep measuring it afterward.