People are what API governance is actually about, and recognizing that is the single most important shift in how I’ve come to understand governance. For years, governance was discussed as if it were a technical problem — rules, engines, linting, specifications — and the people were an afterthought. But I’ve come to believe almost the opposite: governance is fundamentally a people problem wearing a technical costume. The rules and tools matter, but they’re the easy part. The hard part — the part that actually determines whether governance succeeds or fails — is the humans: getting teams to understand, agree, collaborate, and change how they work. I wrote in 2025 that API governance is about people conducting business, and that it’s 75% herding, navigating, and building trust with humans. The technical machinery of governance is necessary, but it’s the human machinery that makes governance real.
The “governance is social” insight is the deepest expression of this, and it reframes the whole discipline. I wrote in 2025 that API governance is social — drawing on the sociology of how coordinated human work actually happens — because governance is fundamentally a social system, not a technical one. It’s about how people coordinate, how they communicate, how they build the shared understanding and trust that lets a distributed organization act consistently. The rules are just the visible artifacts of an underlying social process. When governance fails, it almost never fails because the rules were technically wrong; it fails because the people didn’t understand them, didn’t agree with them, weren’t consulted, or weren’t equipped to follow them. Governance as a social practice means the work is fundamentally about people — educating them, aligning them, and building the relationships and trust that make coordinated behavior possible.
The people landscape is something you have to map, just like the API landscape, and I made that explicit. When I broke down where to begin with governance, mapping the people landscape — the domains, groups, teams, roles, and individuals — was a distinct and essential step alongside mapping the APIs themselves. You cannot govern an organization whose human structure you don’t understand. Who owns which APIs? Who makes decisions? Who has influence? Who’s resistant and who’s a champion? Who’s overworked and who has capacity? The people landscape is as real and as consequential as the technical landscape, and governance designed without understanding it is governance designed for an imaginary organization. Mapping the people — understanding the teams, their incentives, their boundaries, their personalities — is foundational governance work that the purely technical view of governance completely misses.
The team dimension is where governance meets the reality of how organizations actually work, and I’ve gotten increasingly practical about it. I wrote in 2025 about embracing rather than overcoming team boundaries — understanding each team’s makeup, personality, incentives, domains, tooling, and motivation rather than trying to flatten everyone into uniformity. Teams are different, and good governance works with that diversity rather than against it. The API coaches at Capital One that I wrote about in 2017 were a brilliant people-centered governance model — internal advocates embedded in teams, trained to spread standards through relationship and coaching rather than through top-down mandate. The reality that many governance programs are staffed by a few fractional, overworked employees, which I wrote about in 2025, forces a people-centered approach: you can’t govern a large organization through a tiny central team enforcing rules, so you have to enlist champions within teams, build self-service, and distribute the governance work across the people who are actually doing the building.
The segmentation of people by their relationship to governance is a pragmatic insight I’ve found genuinely useful. I wrote in 2025 that API governance breaks down roughly to 10% who care deeply, 60% who don’t have time, and 30% who don’t care — and that this segmentation matters enormously for how you approach governance. You can’t treat everyone the same. The 10% who care are your champions and collaborators; the 60% who are time-constrained need governance made easy and frictionless; the 30% who don’t care need governance that works without requiring their engagement. Understanding the human reality — that most people are busy and indifferent rather than hostile or enthusiastic — shapes a governance approach that meets people where they are. Rule awareness amongst teams matters, as I’ve written, which means teams need to understand why rules exist, have a voice in shaping them, and have access to the reasoning behind them — because people follow rules they understand and resent rules imposed on them.
The synthesis I’ve arrived at is that the right people, process, and policies — in that order of importance — are what actually minimize technical debt and make governance work. I wrote in 2025 that the right API policies, process, and people help minimize enterprise technical debt, and the deepest version of that insight puts people first. You can have perfect policies and perfect tooling, but if the people don’t understand, don’t agree, and aren’t equipped, the governance won’t take. Conversely, an organization with engaged, literate, well-led people can govern themselves effectively with relatively little formal apparatus. This is why I’ve increasingly framed governance as a human and organizational challenge rather than a technical one. The engines and rules and specifications are tools, and tools are necessary, but they’re in service of the real work, which is coordinating human behavior. Getting people to understand what good looks like, agree on standards, collaborate across boundaries, and consistently make good decisions — that’s governance, and it’s irreducibly about people. The organizations that succeed at governance are the ones that treat it as a people challenge: investing in literacy, building champions, mapping and respecting team realities, segmenting their approach to match how people actually engage, and recognizing that the trust and collaboration among humans is the foundation that all the rules and tools depend on. Governance is about people. Everything else is implementation.
References
- What Is A Better Word For Governance When It Comes To APIs
- The API Coaches At Capital One
- What Is API Governance
- An API Governance Job Posting Template
- Where Do I Begin With API Governance: Mapping API People Landscape
- API Governance Is About People Conducting Business
- Our API Governance Is Staffed By 3 Fractional Employees Who Are Already Overworked
- API Governance Is Social
- Embracing Rather Than Overcoming Team Boundaries
- The Right API Policies, Process, And People Helps Minimize Enterprise Technical Debt
