Transaction Costs
The code can take two days while getting the right people aligned takes six weeks.
The work itself is only part of the cost. Finding people, agreeing, checking, fixing disputes and changing course can take far longer.
Two days of code still took six weeks
A product team wants to let a customer retry a failed payout, meaning a money transfer, through another provider.
The software change that chooses which provider sends the money is small. But the retry also affects the systems that confirm who the customer is, check risk, record where the money is, send updates and tell support what happened. Each area belongs to a different team.
Every team has reasonable questions. Could the same payout be sent twice? Which team records that a retry has started? Does changing where the money is sent need another risk check? What should support tell the customer while the first attempt is unresolved and another begins?
The product manager carries the same explanation from meeting to meeting. Engineers wait for decisions about how the systems will work together and when each team can release its part. The customer keeps seeing a failure that everyone agrees should be fixed.
The code took two days. Getting the teams to agree on ownership, safety and release order took the other five and a half weeks.
Transaction Costs are the work around the work: finding the right party, agreeing what will happen, checking the result, handling failure and changing the arrangement later.
What sits around the direct cost
When you buy something, the listed price is only one part of the cost. Someone still has to find a seller, compare quality, agree the terms, check delivery, deal with a broken promise and leave if the relationship stops working.
Inside an organisation, money may never change hands, but the same costs appear as meetings, approvals, documentation, queues, integration work and repeated explanation.
When estimating the work, count:
- Search: finding the right person, service, vendor or information.
- Translation: converting one team's language, data or priorities into another's.
- Negotiation: agreeing on ownership, interfaces, timing and acceptable risk.
- Verification: checking quality, authority, compatibility and completion.
- Enforcement: handling failures, disputes and promises that weren't kept.
- Switching: leaving the arrangement, migrating state and rebuilding lost context.
These costs show up as small waits spread across several people. That makes them easy to miss in an estimate even when they take most of the calendar.
Splitting the service doesn't remove the coordination
Splitting a large system into smaller services can let teams release separately, contain some failures and own clearer areas. It can also move the dependence out of shared code and into agreements between services and teams.
The dependence still exists. It now shows up in whether one service’s interface still works for another, whether messages arrive in the right order, whether teams agree on which version to use, how they respond together during an incident and who is allowed to change what.
A team can move faster on changes that stay inside its service. A change that crosses services now needs an agreement about the interface, the order of work and who owns each decision.
For the payout retry, the answer may be one shared record of where the payout is, one person responsible for the result from start to finish and a clear interface that lets some services stay unchanged. If this kind of change happens often, the services may be divided in the wrong places for the work the company does most.
Keep the boundary when the independence it creates is worth the repeated coordination cost.
How the same costs show up elsewhere
Economics and organisational design. Markets coordinate specialised parties through prices and contracts, but using a market also requires search, negotiation and enforcement. A company can bring repeated work inside to avoid some market search and negotiation, but internal approvals and management create another kind of cost. Buying, partnering and building are choices between those costs. People aren't interchangeable components, so trust, identity and power still affect whether an organisational change will work.
Law and contracts. A contract does more than set a price. It says who carries which risk, what counts as proof, what happens when a promise is broken and how a dispute will be settled. More detail can prevent later confusion while making the first negotiation slower and more expensive. Shared standards, warranties and agreed ways to settle disputes save time because people do not have to rebuild the same agreement every time. No contract can describe every future situation, which is why courts and ongoing relationships still matter.
Software and product architecture. Clear interfaces and service boundaries make repeated handoffs cheaper when each side knows what to expect. A bad interface pushes extra work onto every team that uses it through workarounds, support tickets and coordinated releases. Buying an online tool can reduce the code you write, but evaluating it, connecting it, watching it, depending on the vendor and leaving later still take work.
Which exchanges will happen often, and what arrangement makes those exchanges easier without making it too expensive to change course or leave?
Test the boundary before adding another one
Use Transaction Costs when choosing between building and buying, splitting or combining services, adding approvals, creating a marketplace, outsourcing work or introducing another organisational boundary.
Ask:
- What is the direct production cost?
- Which searches, explanations and approvals are required before work begins?
- How many independent parties must agree?
- What must be verified before the result is trusted?
- Who resolves exceptions and disputes?
- How often will this transaction repeat?
- What will switching or exiting cost later?
- Can one shared format, one responsible person or a smaller group allowed to decide remove repeated negotiation?
Frequency changes the answer. A painful one-off coordination process may be acceptable. A five-minute handoff repeated ten thousand times deserves architectural attention.
Friction can protect something worth keeping
Identity checks, code review, informed consent and contractual scrutiny create deliberate friction because mistakes are costly. A system can make exchange cheaper by hiding risk, weakening accountability or pushing the work onto someone with less power.
Transaction Costs can also become an excuse for centralisation. Combining everything under one owner reduces some handoffs while creating larger queues, weaker specialisation and expensive internal politics. A boundary may preserve fault containment, independent judgment and the option to replace one component later.
For each repeated check or handoff, ask what failure it still prevents. Remove, standardise or automate it when that protection is smaller than the burden.
Nearby models
Principal-Agent Problem concerns delegated action when the person acting has different information or interests from the person bearing the result. Transaction Costs cover the effort required to create, monitor and change the arrangement even when interests are aligned. Monitoring a vendor can be both a response to an agency problem and a transaction cost.
Theory of Constraints finds the part currently limiting how much the whole system delivers. One approval queue may be that limit. Transaction Costs cover the wider collection of finding people, handing work over, checking it and switching later. Those costs can be spread across the system without forming one obvious queue.
When a small change keeps taking a long time, inspect the path between the people and components involved. The work may be cheap while the exchanges needed to organise it are expensive.