Scaling your API practice in 2024
4 Core questions to ask to help you be an API First leader
This post is part of APIFutures, a community-led, collaborative effort to identify the top challenges and opportunities facing the API economy in 2024.
In the past decade, I’ve witnessed APIs evolving from point-to-point integration to sophisticated API products while supporting different organizations in scaling their API practices.
Six years ago, I was leading the API transformation at Adidas as a way to kill 6000 point-to-point legacy integration interfaces. That was like fighting a multi-headed dragon.
We’ve learned that killing 70 years of Adidas integration legacy is tough and we decided to make building APIs faster and cheaper than point-to-point integration interfaces. I’ve learned as well that scaling APIs is more about how you build a system where API users can break rote habits.
“A worker is asked: “Why did you do it this way ?” The answer, “Because that’s the way we’ve always done things” The answer frustrates every good boss and sets the mouth of every entrepreneur watering. The worker has stopped thinking and is mindlessly operating out of habit” Rayan Holiday
To scale your APIs you need to ask four core questions consistently.
Have you established a sense of urgency?
Do you remember the collapse of Blockbuster (once valued at $4.8 billion), that is a typical illustration of not establishing a sense of urgency and adapting to change.
Blockbuster is a typical example of “mindlessly operating out of habit” and avoiding complacency.
But what does this mean for us “API leaders”? In practice, we need to:
Feel the urgency: The best way to establish a sense of urgency is to feel it yourself, for instance, I’ve spent some time with BackMarket engineers while fixing API incidents to understand why we had a high MTTR (Mean time to recovery), and I’ve also tried to build an integration and feel what a bad DX (developer experience) look like.
Communicate the urgency: Once you have some facts and collected key insights, everyone should know about them and get a clear commitment to change.
Is your API vision good enough?
A good API vision is not just inspirational but a catalyst for change, your vision shouldn't be just a boring statement but a well-documented desired state. Additionally, ensure that your vision is created in a participative way otherwise the resistance to change will increase.
For example, at Backmarket, to guarantee a better alignment with their team goals and new business requirements, the API Chapter challenged and revisited the API vision every 6 months.
How is my organization supporting the API Vision?
The essence of a supporting organization is the ability to easily iterate and adapt whatever governance model you use.
The key to scaling your APIs is adopting a decentralized decision-making approach and empowering your teams to make local API decisions.
For instance, BackMarket had inconsistent API errors that impacted DX (Developer Experience) score, so we picked HTTP problem detail standard. A naive model was to create a Pull-Request in our common API guidelines, get it approved, and present it in our API community of practice and different chapters. This didn’t scale well as some teams didn’t commit to this change that was painful to implement, then we delegated this decision to a “Working group” to make a second DX-friendly iteration by building an API Error library and implementing HTTP problem detail standard.
To go further we scaled our API governance model by creating API champion roles in different squads. The API champion was responsible for tracking his squad's API maturity, making local API decisions, and contributing to common API guidelines.
How do you sustain the change?
Maintaining a change over time is like quitting smoking! Insights from the realm of personal development show that to adopt good habits you need :
To make your new habits easy to use
A rewarding system
A strong commitment to change
Let’s take the HTTP problem detail standard adoption example, I’ve failed to get the commitment of some teams as we simply lacked the second and third ingredients. I’ve learned that any change should integrate this narrative and ensure systems are in place to support it.
Another example is the trend we see in the API tooling space where you can directly author your API specifications like AsyncAPI and OpenAPI from your favorite IDEs.
In the upcoming decade, we will see more and more vendors bringing their capabilities closer to engineers' SDLCs (software development life cycle).
Wrap up
To wrap up, here are your 3 core questions to ask this year:
Have you established a sense of urgency?
Is your API vision good enough?
How is my organization supporting the API Vision?
How do you sustain the change?
👉 If you enjoy reading this post, feel free to share it! Or click the ❤️ button on this post so more people can discover it on Substack 🙏