Samir Amzani is the Team lead of the AsyncAPI team at Postman and contributes to the open-source AsyncAPI Initiative.
I’ve been in over a decade in the API space, helping different companies with their API program strategies and scaling their API practice.
Six years ago, I was leading the API transformation for Adidas, trying to kill the monster that was 6000 point-to-point integration interfaces. That was frustrating and extremely challenging at the time, but also rewarding. I learned many things on the way. I wanted to find a way to build APIs cheaper and faster than point-to-point integration.
To address this challenge, we created an API Centre of Excellence responsible for leading Adidas API transformation, moving away from the old way of integrating APIs as a product. We were providing two things, API management, and we were helping different teams with API design. This model didn’t scale well, as it was completely centralized. Then, we switched to a more decentralized model by creating an API platform team. As a mission, we were providing API management as a service, and we were scaling the API practice in different teams, especially API design, which was the most challenging one to get right.
Martin Fowler said, “Putting effort into the design of your software improves the stamina of your project, allowing you to go faster for longer.” In 2023, API developers have spent only 9% of their time in design. So, this is not enough. You cannot trade off design quality to go to market faster, especially when you have a new product or are adding new features. It will just add to the costs later.
To scale APIs as a product, you must become an API-first leader. To do this, you have to –
- Establish a sense of urgency – You must establish a sense of urgency of why being an API-first leader is critical. The core idea is to ensure everyone understands and feels a sense of urgency. I’ve seen many companies and strategies failing because of missing some simple facts. When we studied problems, we found that organizations were struggling to find the right API owner and the current, updated API documentation. The core idea is to communicate all such findings to the people. After that, we wrote an API vision. This was live documentation and was created in a participative manner. We validated our progress by creating hypotheses. We wanted to shift from how we consider APIs, not just technical assets but first-class citizens. We invested in providing APIs Foundation with common API guidelines and a single source of truth. We also verified API developer onboarding, API user satisfaction, and the Net Promoter Score. We increased our expectations regarding API user satisfaction and how quickly we can recover from API incidents.
- Enable the organization – Whatever model you adopt must integrate your company’s culture. This will make it easier for teams to adopt the changes and work towards success.
- Sustain the change
The core idea behind this is to ensure a strong commitment to change. This is not easy, as there are many moving parts that you need to keep track of, from understanding the leadership to understanding engineers’ day-to-day frustration and resistance to change. One way to overcome this is to show progress. At Adidas, we were tracking API maturity for our core APIs. This helped us to get a sense of engagement and commitment from our different teams. In addition, you need to show some quick wins from time to time because it’s a long change, and people can get frustrated. We shared API users’ satisfaction, and an improvement in that was encouraging.
Another aspect of sustaining the change is understanding your developer journey by integrating whatever API tooling you decide for your engineers into your software development lifecycle.
To summarize, to scale your APIs as a product for future success, you need to be an API-First leader.
There is no shortcut. It’s a big mindset shift where you need an API vision that involves your engineers. You need to enable your organization and sustain the change.
