In the last few years, I've focused on helping organizations build up their API programs and platforms. This is very different work than designing, building, and deploying APIs in production. Instead this is the work of "administering organizations". The good news is that we've got hundreds of years of experience in defining and refining the work of "management". The bad news is that this detailed level of what Fredmund Malik calls "the transformation of resources into utility" is just in the early stages for the API space. We have lots of opportunities to learn and grow this vital set of skills.
There is no Single Path
My recent work has been focused on helping individual companies learn more about planning, organizing, and implementing API platforms or programs. Along the way, I've confirmed, time and time again, that no two companies -- no two cultures -- are the same and that one of the best ways to help teams improve their API management is to help them travel their own path to success. As Fred Brooks reminded us in 1986, there is "no silver bullet".
A helpful metaphor for transformation in an organization is "the journey". It is easy to see how the story of "getting from A to B" can inspire and motivate people when it comes to taking on the task of changing a culture and/or growing an organization. In fact, there are lots of presentations at API conferences and online & in print that tell these very stories. The AWS story, the Netflix story, the Spotify story and so forth. These are all helpful and inspiring.
However, while instructive, they can also be misleading.
Too often, people hear these tales of success and decide to reenact the same story at their own company. "We're going to do it just like Netflix" or "Let's adopt the AWS principles" and so on. When taken to the extreme, this never results in sustained, healthy transformation. At worst, teams are subjected to arbitrary rules bolted onto shallow goals that don't align with existing company values. At best, there is a short-term set of successes that don't survive changes in leadership or market dynamics.
There is no single path to success in the APIM space.
Focusing on Landmarks
So what is the right approach? While each company is unique, they all seem to go through the same phases, focus on the same general tasks, and meet up with similar challenges along the way. These shared topics can help delineate the APM journey even if they don't narrowly define it. We can help each other by sharing our perspectives on these shared challenges.
Staying with the journey metaphor, we can all see the same "landmarks" even if we each travel our own unique path between each of them. We don't share a path, but we do share the same map of the landscape. And, while Korzybski tells us "the map is not the territory", it is a helpful rendering of our possible journey.
This general notion of paying attention to landmarks in the journey was explored in the book "Continous API Management" to which I was a contributor. We talked about pillars, elements of a decision, change models, lifecycles, and more. And, especially in the last several chapters of the book, we focused on landscapes and journeys. And throughout the book we emphasized that each company's journey was unique; that an important part of the job of management was navigating the landscape in your own unique way.
Shared Skills
While we each need to make our own way through the territory, we still have lots we can share with each other along the way. We all need the same set of general management skills (planning, organizing, coordinating, etc.). In the APIM space we also need skills specific to the domain. Skills like designing, documenting, securing, implementing, deploying, monitoring, cataloging, discovering, upgrading, and deprecating API products and services. Just naming these broad categories probably triggers readers as they recall the most recent struggles to define and manage efforts in all these topics.
And each of these broad categories have their own set of processes and practices that teams need to sharpen and apply. While API program management is a kind of big picture "top level" management skill, these key categories (design, document, catalog, deploy, etc.) are a kind of "middle level" management where companies need to pay close attention to making sure each of these communities of practice are healthy, robust, and widely-available. Finally, at the "low-level" management space, teams need to apply specific technologies and practices to make sure API design meets the company's objectives, that security activities are robust and ongoing, that monitoring and analysis provides insights into just how the APIs are used and whether they are fostering the company objectives.
It is the shared skills that we can focus upon as we prepare for our journey across the API landscape. It is a combination of recognizing landmarks and having the ability to apply your skills to the task -- even skills you just learned along the way -- that can make APIM leadership successful. And throughout all of this is the reality that technology is just a means to an end; that real success comes from "getting things done through people" as the mother of modern management Mary Parker Follett is quoted as saying.
Join Us on the Journey
I and one of my "Continuous API Management (CAM)" co-authors, Erik Wilde, are combining our experience gained through talking with various companies about APIM into a workshop open to the public in 2024. Based on our work with individuals and companies over the last few years and based, in part, on the content of the CAM book, Erik and I are already scheduled to offer the workshops in April at API Conference London and JAX Mainz.
You can get a feel for the kind of material we'll be covering by watching a recent episode of Wilde's "Getting APIs to Work" entitled "API Management for Developers: You are not alone!".
I hope you'll join us in April and at other events this year as we share our journey with you and help you sharpen your skills and prepare for your own journey through the API management landscape.