Harmony Humans: Defining The Role of API Governance

As I introduced earlier this year, I gather and analyze API job postings. The work helps me keep a pulse on what initiatives companies are investing in and inspires topics to write about. Out of all that I've seen, API governance positions have been consistently inconsistent. While they constitute a small minority of the "help wanted" ads I scan every month, what does appear is anything from an affable standards evangelist to a draconian bad cop.  

As companies rely on a growing number of APIs to facilitate every aspect of their business, leadership has become increasingly concerned with the cohesion (or lack thereof) these software systems exhibit. All too often, the comprehension overhead required to traverse the complexity introduced by ad-hoc governance approaches threatens to swamp even the best faith efforts. So, with increasing regularity, these leaders fund efforts to "get some governance in place". 

Unfortunately, successful API Governance encompasses so much more than a single project or drop-in tool. The scattershot expectations of what the role is and the resulting implementations only exacerbate a difficult situation. In this newsletter, I'll propose a definition for API Governance beyond the trivial, articulate where I've seen many folks go wrong, and end with how you can promote - not seek to eliminate - creative conflict within your organization.

With that setup, it's time to get into this edition of the Net API Notes newsletter. 

Role Clarity is Important

Imagine a situation where talented musicians gather together to perform but aren't told who is playing what, or to whom. Even the most improvised jazz doesn't spontaneously occur from nothing; there is clarity about which instrument each musician contributes to the whole, who is responsible for bridging from one section of a song to another, and how their interplay will communicate emotional themes. To illustrate this, contrast the musicians' roles in Hans Zimmer's touring show with how they behave in the studio; the same people and music but entirely different role expectations given a different context. 

The people within a company are highly skilled individuals like our talented musicians. Still, without a shared understanding of the music (the company goals), the audience and venue (the customers), and their specific parts within it (their roles and responsibilities), the results can be raucous. 

According to research, professionals with role clarity are:

• 53% more efficient
• 27% more effective
• 25% more productive

So, what is the role of software governance, especially concerning APIs? 

Governance's Role Is Managing Conflict Between Competing Concerns

There are as many takes on the role of API Governance as there are dance moves at a wedding reception (with some just as cringe):

• Defining the job as "slowing things down to improve quality" only works until good faith efforts are inevitably exhausted, after which stressors shortcut governance efforts. 
• If it is only about a company meeting external regulatory compliance, that box-checking slog will fail to elevate and encompass internal needs. 
• And if API Governance is only marketed to skeptical developers as an accelerant, somebody eventually will point out that if it is only about throwing more things at more walls faster, governance isn't needed at all. 

All but the smallest companies are roiling, churning masses of competition; disagreements over priorities, battles for talent, conflicting incentives, and so on. It is tempting to look at the energy expended over the totality of those confrontations and assume that conflict is wasteful. "If we could just have perfect alignment, maybe run one of those 'ONE <Insert Company Name Here>' campaigns", the thinking goes, "we could get back to the real work".  

However, as Jeff Weiss and Jonathan Hughes point out in their classic Harvard Business Review article, acceptance and active management of conflict is the work: 

"Executives underestimate not only the inevitability of conflict but also - and this is key - its importance to the organization. The disagreements sparked by differences in perspective, competencies, access to information, and strategic focus within a company actually generate much of the value that can come from collaboration across organizational boundaries. Clashes between parties are the crucibles in which creative solutions are developed and wise trade-offs among competing objectives are made. So instead of trying simply to reduce disagreements, senior executives need to embrace conflict and, just as important, institutionalize mechanisms for managing it."

Governance is a cross-cutting concern, and the farther the responsibility spans, the greater the conflict that will need to be managed. It's a conflict when a development team wants to use GraphQL despite not being supported by the enterprise logging stack. Multiple API producers advocating different security mechanisms is friction. Having no broadly accepted expectation for communication, depreciation, and sunsetting an API is a vacuum that will be filled with dozens of conflicting assumptions.

Software governance, particularly API governance, is the institutional mechanism for managing conflict. Or, as I like to say colloquially, when everything else is flying around and people are moving as quickly as possible, API governance is how we co-navigate our shared spaces, safely. The point is not to freeze the work to prevent a bad thing from happening (that is legal's job). Likewise, the role is not about policing every action to avoid a crash. Instead, someone performing API governance is a constant and evolving conversation with the environment, creating the "guardrails" capable of mediating conflict toward productive ends. 

Someone performing the API governance role should foster healthy debate and empower teams to make informed decisions within established boundaries. Those hiring for the role need to focus less on tool familiarity, as the nuance between one API management provider and another can be learned. Instead, hiring managers should focus on "soft skill" examples - demonstrated cases where the individual has applied their talents to mediate (rather than eliminating or avoiding) conflict. 

Those skills to hire for would include:

• Communication Ability: The ideal candidate bridges the gap between tech and business stakeholders, ensuring everyone can contribute and understands the shared goals of the API ecosystem.
• Empathy and Emotional Intelligence: They can see issues from multiple perspectives and navigate potentially heated API design and management discussions with diplomacy and understanding.
• Problem-Solving Savvy: They can identify conflict areas, analyze the root causes, and facilitate collaborative solutions that address everyone's concerns.
• Change Management Prowess: They can effectively guide teams through the inevitable adjustments that come with API practice maturation.

Governance Is Not a Project Or Tool But A Thing You Do

"Sure, Matthew," I can hear some of you say, "We'd all love to hire more employees with better people skills. But what would we actually have these people do?" 

I have previously written about understanding the three organizing dimensions for API governance activities. Those activities start with clarifying who owns which decision rights, identifying which touchpoints can be configured as part of a control portfolio, and creating pricing and subsidy incentives. If that sounds relevant, definitely check that more detailed piece out.

"What if I'm not a hiring manager, but this stuff still affects me and my API team?"

You're not alone if you're a software developer frustrated by unclear API governance. The lack of clear role definition or well-understood activities leads to implementations that run the gamut from glorified linting to bureaucratic gatekeeping. The net result is governance that creates confusion, slows development, and stifles innovation.

If you're concerned about the lack of governance clarity in your org and would like to drive better exchanges, consider: 

• Becoming an Advocate: Speak up and clearly articulate the challenges unclear governance creates for your team. Advocate for well-defined roles, clear communication channels, and a focus on collaborative decision-making that seeks your team's input.
• Focus on Solutions: Don't just point out problems. Work with your colleagues and leadership to propose solutions. Suggest workshops to clarify roles, define decision-making processes, or establish communication channels.
• Embrace Conflict: Disagreements over API design and management are inevitable. Use those discussions to learn from each other and arrive at more robust solutions.

When designed with a more expansive definition in mind, governance provides a creative environment for exchange. By actively participating in shaping governance efforts, you can turn frustration into a positive force for change.

Milestones

• API Developer Weekly, the link roundup newsletter from James Higginbotham and Keith Casey, has celebrated its 500th issue! Congratulations to both gentlemen for demonstrating such longevity in an area pockmarked by impermanence. I'm excited to see what the following 500 issues will bring. 
• Another anniversary that I'm ashamed to have failed to mention when it happened was this past March when RSS turned 25! It has been, and continues to be, a fantastic way to syndicate content. It also makes a pretty awesome T-shirt. 
• Atlassian has acquired Optic, an API documentation and management tool. The team and product will be integrated into Compass, Atlassian's developer platform product. 
• Boomi acquired APIIDA's federated API management business and "API management assets" from Cloud Software group. I didn't see a number associated with the swap at this time.
• The email publishing platform Ghost announced plans to begin federating over ActivityPub shortly. 
• As a reminder, Google Fit's API - launched in 2014 - was deprecated May 1st. No new signups are being accepted, and the service will officially be shut down at the end of June, 2025.

Wrapping Up

Another issue is in the books. While content farms exploit AI to red queen themselves to generate more faster for smaller slivers of aggregated attention, I chose to go in the opposite direction. Pieces like this can take 10-20 hours to research, analyze, write, edit, and syndicate. Maintaining a cadence of two "regular" newsletter pieces with an additional, more in-depth ¡APIcryphal! case study each month equates to Net API Notes being a part-time job (BTW, have you checked out the latest APIcyphal: An Abridged History of Twitter, Its API, and 18-Years of Strategic Pivots To Learn From? I'm really proud of how that turned out.).

There may be other, more enjoyable ways of spending my time. However, this particular technology niche remains fascinating to me. Becoming a paid member supports this ongoing analysis and preservation work. A monthly or yearly pledge helps Net API Notes remain ad-free and ensures previous commentary, analysis, and insights remain accessible for those in less financially certain situations. A complete breakdown of signup versus paid subscriber benefits is on the newsletter's About page. 

Thanks for considering it. Till next time,

Matthew - @matthew (Fediverse) matthewreinbold.com (Website)