A short list of the ways I have watched it go wrong, in rough order of frequency.
They show up as gates. Governance becomes the office that says no, the board that adds three weeks to every launch. Teams do the rational thing and route around it — a shadow API here, a service that “isn’t really an API” there.
The rules have no traceable why. A team gets a linting failure over a trailing slash with no explanation of what business outcome that protects. Rules without policies behind them read as arbitrary, and arbitrary rules earn contempt.
There is no feedback path. Governance without feedback is just control. If a team cannot propose a rule change, request an exception, or argue that a rule is wrong, they will conclude the program is not for them — and they will be right.
It gets imposed on an organization with low API literacy. The same rules land completely differently depending on whether the recipients understand the reasoning. Imposed on a low-literacy org, governance is experienced as arbitrary control; offered to a literate one, it is experienced as shared discipline.
And it is understaffed and over-scoped: three fractional people, already overworked, asked to govern four hundred APIs across nine business units. That is not a governance program; it is a reporting function with a governance job title.
Underneath all of it is one fact: governance is about people conducting business, and most of the work is herding, navigating and building trust with humans. The technical machinery is the easy part.
