Lowercase-g governance is the distinction that unlocked API governance for me, and it’s one of the most useful framings I’ve developed. There are two kinds of governance, and conflating them is the source of endless confusion and failure. Capital-G Governance is the formal, organizational thing — the governance board, the mandated policies, the centralized control structure, the official program with a budget and a mandate. Lowercase-g governance is the daily, practical, on-the-ground practice of making consistent, informed decisions about your APIs — the thousand small choices teams make about naming, structure, versioning, and design as they actually build. Both matter, but they’re profoundly different, and the most important insight is that lowercase-g governance is where governance actually happens. The Capital-G structure can mandate all it wants, but if the lowercase-g daily practice isn’t there, nothing real changes.
The capital-G versus lowercase-g framing is something I first articulated in 2019 and refined in 2025, and the contrast is the whole point. I wrote about Capital-G API governance versus lowercase-g API governance, contrasting the top-down, command-and-control, mandate-driven version with the bottom-up, educated, engaged version that lives in everyday practice. Capital-G Governance is what out-of-touch leadership imposes — being told to do something, often without the resources or understanding to actually do it. Lowercase-g governance is what an educated, engaged constituency does on its own because they understand why it matters. The failure mode of most enterprise governance is investing entirely in the Capital-G apparatus — the board, the policies, the mandates — while neglecting the lowercase-g practice that’s the only thing that actually produces well-governed APIs. You can have all the Capital-G structure in the world and still have ungoverned APIs if the daily practice isn’t there.
The deeper truth this framing points at is that good governance is just guidance, which I wrote about directly in 2024. When you strip away the bureaucratic connotations of “governance,” what good lowercase-g governance actually is is guidance — helping teams make good decisions by giving them clear, well-reasoned, accessible guidance about what good looks like and why. Not mandates enforced from above, but guidance offered to people who are trying to do good work. This reframe matters enormously because “governance” carries a whiff of control, bureaucracy, and the office that says no — and I’ve questioned for years whether it’s even the right word, going back to 2013 when I asked for a better word for governance. The lowercase-g version answers that question by being something teams can actually embrace: guidance, not gates; help, not control; the daily practice of good decisions, not the imposition of distant rules.
The social and human nature of lowercase-g governance is what makes it work where Capital-G fails. I wrote in 2025 that API governance is about people conducting business, and that API governance is social — drawing on the insight that governance is fundamentally a human, social practice, not a technical or bureaucratic one. Lowercase-g governance lives in the relationships, the conversations, the shared understanding among the people building APIs. It’s the team that has internalized good practices and applies them as a matter of course, the culture where consistency is valued, the shared vocabulary that lets people coordinate. This is why lowercase-g governance can’t be mandated into existence — it has to be cultivated, taught, and grown through the people who do the work. Capital-G Governance is a structure; lowercase-g governance is a culture, and culture is built through people, not policies.
Starting simple is the practical wisdom of lowercase-g governance, and it’s the opposite of how most Capital-G programs begin. I wrote in 2021 about starting simple in the overwhelming world of API governance — beginning with the basics (consistent info, versioning, paths, operations, schema) rather than trying to implement a comprehensive governance regime all at once. Lowercase-g governance grows incrementally, one good practice at a time, as teams adopt and internalize it. This connects to my insistence, in 2019, that nobody has API governance figured out — there’s no perfect end state, no finished governance program, just the ongoing, iterative practice of getting a little more consistent and a little more disciplined over time. Capital-G programs tend to aim for comprehensive coverage from the start and collapse under their own weight; lowercase-g practice starts small, builds momentum, and accretes into real governance through accumulated daily discipline.
The right relationship between the two is the resolution I’ve landed on, and it’s not that lowercase-g replaces Capital-G but that they need each other in the right balance. Capital-G Governance provides the structure, the visibility, the accountability, and the resources at the organizational level — and it’s genuinely necessary at scale. But Capital-G without lowercase-g is empty apparatus, governance theater performed for an audience of APIs nobody is actually governing well. And lowercase-g without any Capital-G is inconsistent — good practice in some teams, chaos in others, no portfolio-level coherence. The mature approach uses Capital-G to enable and support lowercase-g: the organizational structure exists to cultivate, resource, and spread the daily practice, not to replace it with mandates. The guardrails-not-gates framing fits here perfectly — the Capital-G program provides guardrails that enable teams to practice good lowercase-g governance autonomously, rather than gates that block them. The whole arc of my governance thinking has bent toward this conclusion: governance that works is mostly lowercase-g — the daily, social, cultural practice of making good decisions — supported by just enough Capital-G structure to give it visibility and resources, but never substituting mandate for practice. The organizations that get this build governance that teams actually follow. The ones that don’t build impressive Capital-G structures around APIs that remain, in daily practice, ungoverned.
References
- What Is A Better Word For Governance When It Comes To APIs
- Capital-G API Governance vs Lowercase-g API Governance
- Nobody Has API Governance Figured Out
- Starting Simple In The Overwhelming World Of API Governance
- Good API Governance Is Just Guidance
- Capital G Governance And Lowercase G Governance
- API Governance Is About People Conducting Business
- API Governance Is Social
- Guardrails Not Gates: Supreet Nagi On Taming The API Jungle
