Velocity is the variable that governance is always negotiating with, and the relationship between the two is the central tension of the whole governance discipline. Velocity is how fast teams can ship — and teams want to ship fast, businesses demand they ship fast, and the entire pressure of modern software development pushes toward more speed. Governance is often experienced as the thing that slows velocity down, which is why it gets resented and routed around. But the deeper truth I’ve worked out over years is that the relationship between governance and velocity is not simply opposition — it’s a negotiation, and good governance actually enables sustainable velocity while bad governance either obstructs it or lets it run unchecked into a wall of accumulated debt. Getting the velocity-governance relationship right is, in many ways, what API governance is fundamentally about.
The provocative framing I’ve used is that governance is about limiting speed, which I wrote in 2023, and the metaphor is deliberate. The word “governor” literally means a device for the automatic control or limitation of speed — the governor on an engine prevents it from running so fast it destroys itself. API governance is the governor on the engine of API development: it limits velocity to keep the operation from tearing itself apart through inconsistency, breaking changes, and accumulated debt. This sounds like governance is the enemy of velocity, but the engine governor isn’t the enemy of the engine — it’s what lets the engine run sustainably at high speed without blowing up. Governance limits velocity not to make teams slow, but to keep them from the kind of reckless speed that produces the technical debt that eventually slows them far more than the governance ever did.
The unchecked-velocity problem is what governance exists to prevent, and I’ve documented its costs extensively. When teams ship as fast as possible with no governance, they accumulate exactly the debt that compounds into crisis: inconsistent APIs, breaking changes that shatter consumer integrations, redundant APIs built because nobody could discover what already existed, and a sprawling mess that becomes harder and harder to change. I wrote about API versioning being just an engineering coping mechanism for unrealistic business deadlines — the perfect illustration of unchecked velocity creating debt. When business pressure forces teams to ship faster than they can design properly, they version their way around the problem, and versioning is debt. The right policies, processes, and people minimize the technical debt that velocity pressure produces, as I wrote in 2025 — because the debt from reckless velocity is real, expensive, and ultimately velocity-destroying. The team that ships fast and dirty is fast today and slow forever after, as the debt accumulates and every future change gets harder.
The reframe that resolves the tension is guardrails, not gates, and it changes velocity from governance’s enemy into its beneficiary. I wrote about this through the guardrails-not-gates framing — the recognition that governance done as gates (mandatory reviews, approval bottlenecks, blocking checkpoints) genuinely does slow velocity, while governance done as guardrails actually enables velocity. A guardrail lets you drive fast precisely because you don’t have to slow down to navigate the dangerous edges yourself — the guardrail handles the safety so you can focus on the speed. Self-service governance, governance automated into the pipeline, governance that fires inline as teams work — these enable teams to move fast safely rather than forcing them to choose between speed and safety. The whole evolution of my governance thinking has been toward governance that enables velocity rather than obstructing it: the goal is to let teams go as fast as possible while the guardrails prevent the reckless speed that creates debt.
The measurement problem is one I’ve flagged honestly, because the velocity claims around APIs are often unsubstantiated. I asked in 2019 how we actually measure the efficiency, agility, and velocity of an API-centric way of doing things — because the industry makes a lot of claims about APIs increasing velocity without much rigorous benchmarking. The honest position is that velocity is real but hard to measure, and that both the claims that APIs increase velocity and the claims that governance decreases it deserve more evidence than they usually get. What I can say with confidence is that the relationship is more nuanced than either the velocity boosters or the governance skeptics admit: good governance enables sustainable velocity, bad governance obstructs it, and no governance produces a burst of velocity followed by a long deceleration into debt. Measuring this well would require tracking not just how fast teams ship but how much debt they accumulate doing it, and how that debt affects future velocity.
The synthesis I’ve arrived at is that velocity and governance are not opposites but partners, when the governance is designed right. The business wants velocity, and it should — speed matters, shipping matters, responsiveness matters. Governance’s job is not to oppose that velocity but to make it sustainable: to be the governor that lets the engine run fast without destroying itself, the guardrails that let teams drive fast without going off the cliff, the discipline that prevents the reckless speed that creates debt while enabling the genuine speed that creates value. Bad governance — gates, bottlenecks, bureaucracy — does slow velocity, and it deserves the resentment it gets. But the answer to bad governance is not no governance; it’s good governance, the kind that’s automated, inline, self-service, and designed to enable rather than obstruct. The teams with the best sustained velocity are not the ones with no governance; they’re the ones with good governance that lets them move fast safely, year after year, without accumulating the debt that eventually grinds reckless teams to a halt. Velocity without governance is fast until it isn’t. Velocity with good governance is fast and stays fast. That’s the relationship governance has to get right, and getting it right is most of what good API governance actually achieves.
References
- How Do We Measure The Efficiency, Agility, And Velocity Of An API-Centric Way Of Doing Things
- Some Thoughts On API Governance
- API Governance Is About Limiting Speed
- What Is API Governance
- Hands-On Self-Service API Governance
- API Versioning Is Just An Engineering Coping Mechanism Amidst Unrealistic Business Deadlines
- The Right API Policies, Process, And People Helps Minimize Enterprise Technical Debt
- Guardrails Not Gates: Supreet Nagi On Taming The API Jungle
