Every capability is reached somehow.

Someone or something asks it to do its work, and the way that asking happens is a design decision — usually an unexamined one, and one that determines more about how the organization moves than the capability’s own quality does.

There are only two fundamental shapes. Synchronous: ask, and wait for the answer before continuing. Asynchronous: announce what happened, and carry on without waiting.

The difference sounds technical and isn’t. Synchronous means one capability’s availability has become another’s availability — if the thing you’re calling is slow, you are slow; if it’s down, you’re down. You’ve coupled the two in time, which is the most expensive kind of coupling there is because it can’t be scheduled around. Asynchronous decouples them and charges you differently: you give up certainty about when, and you take on the work of handling things arriving out of order or twice.

Neither is correct. What’s incorrect is choosing without noticing you chose — which is what happens when the shape of the interface is inherited from whatever the first integration happened to do.

But the friction that costs most isn’t the shape. It’s the hiding.

Consider what it takes to use a capability someone else owns. In a healthy organization: you find it, read how it works, and use it. In most organizations: you ask around until you find out who owns it, book time with them, explain what you’re trying to do, discover three special cases that aren’t written down anywhere, and build against a shared understanding that exists only in the memory of the two people who had the conversation.

That conversation is a handover. It happens every single time anyone new needs the capability, forever, and it never appears as a cost because it looks like helpfulness.

Then the special cases accumulate, and they accumulate for a specific reason: when nobody can see how something was meant to be used, everybody uses it slightly differently, and every one of those differences has to be supported afterwards. Undocumented interfaces don’t stay simple and undocumented. They become complicated because they were undocumented.

An interface nobody can find isn’t an interface. It’s a person you have to know.

Which brings up the distinction most organizations get backwards.

Internal and external interfaces are usually treated as two categories with two standards. External ones get documentation, versioning, examples, a support commitment, and someone who thinks about whether they’re pleasant to use. Internal ones get a Slack message and the name of whoever built it.

The distinction is false, and the cost of believing in it is paid daily. An internal consumer has exactly the same needs as an external one — to discover that the thing exists, understand what it does, and use it without a meeting. The only difference is that internal consumers can’t take their business elsewhere, so they absorb the friction quietly instead of complaining, and the organization never learns what it’s paying.

So the standard should be the same, and the way to make that real is to publish internally as though you were publishing externally: a catalogue where anything can be found, documentation written for someone who has never spoken to the team, worked examples, and someone who treats the experience of using it as part of the product rather than as an afterthought.

The word for that discipline is developer experience, and it’s the wrong word, because it makes it sound like a courtesy extended to developers. It’s a friction control, and it belongs in the same conversation as ownership and guardrails.

And if any part of your business depends on other organizations building on top of what you do — the API economy in its unglamorous, everyday sense — then the same discipline has to extend outward, published and discoverable, because a partner who has to ask how to use you will find someone easier to use.

The principle underneath all of it isn’t technical, and it applies to capabilities that have no software in them at all. A finance approval, a legal review, a procurement route: if the way to request it isn’t written down, you have to ask someone who knows. And asking someone who knows is the most reliable friction generator in any organization, because it works well enough that nobody ever fixes it.

Make how to use it as easy to find as the thing itself, or you have built a capability that only works when the right person is available. How that gets built is a practice, and it has its own chapter in Part III.