The need for stakeholder buy-in
There are 200 million APIs as of 2024. It used to be that companies only expected their core software systems to talk to each other. But now companies have a whole host of different systems that they use, with software enhancing what was previously thought of as traditional businesses such as banking, automotive, and manufacturing. The resulting increase in customer demand for data integration has led to the rise of APIs.
But APIs are just another interface for your product. And just like how the quality of UI’s can vary widely, so too can API quality. It takes time and effort to build a high-quality API. But not all companies see the importance of this investment. They view APIs as a nice-to-have add-on to enable customers to interact with their product in a different way rather than as a core part of their product offering.
Richard Rodger, CEO of Voxgig, a developer relations consultancy, highlights this lack of stakeholder buy-in as the biggest problem leading to the poor quality of the APIs that companies produce. Voxgig provides tools and expertise to help companies with their developer relations efforts emphasising the importance of building effective APIs, documentation, and community engagement but they can only be effective if the company has buy-in from the top.
A lot of companies are extremely profitable, so in a way they can tolerate bad software development practices. But as any bank manager will tell you, you can't live on the never, never. Technical debt eventually has to be paid.
Richard Rodger
The impact of bad APIs for customers
Every API is different so it can be difficult to understand how you are supposed to use it correctly. If you’re looking for the solution to a problem with the React API you can go to chatGPT or StackOverflow and ask a question and you’ll get an answer because there is such a large community of people using React over many years. But if your company has built a proprietary API that maybe only has 50 or a hundred client companies using it then the community just isn't big enough. There isn't enough material out there so StackOverflow, ChatGPT and Google are not particularly useful. This creates a huge amount of friction for the teams trying to write the code to integrate the systems.
I can think of a particular project where delivery time was probably doubled because the importance of having a smooth integration wasn't really taken seriously by either party. It was just assumed that the developers will work weekends and make it happen.
Richard Rodger
If companies have more buy-in around the importance of good documentation, generating examples, or running webinars they can help reduce this friction and reduce the time and cost of integration.
The impact of bad APIs on the company
While the implementation costs are painful for the customers, some businesses might argue that it is not their problem. However, it can hurt the company as well in a few different ways.
A lot of API contracts involve usage-based pricing. So until the usage ramps up, you are not earning. And the only thing blocking billing is how quickly the developers can write the code to start using your product.
But even if your product does not use usage-based billing, it can cost you in other ways. Things take longer to build and support costs continue to rise because customers continually need to ask for assistance, and developers spend more time on support calls instead of building your products.
Getting buy-in
The challenge is that people need to recognise the problem. And unfortunately, it is a systemic problem rather than in any particular area. For example, development teams might invest more time in sprint planning to try to be more predictable in their commitments. Or the customer support team might offshore the first-line support to reduce costs. But both of these initiatives are just treating the symptoms instead of the cause.
Unless there is buy-in and at the highest levels that this stuff is important, literally the founder or CEO of the company, it ends up being a drag on the company. Companies need a crisis or some other forcing function to trigger them to improve their ways of working because if they are profitable they can tolerate bad software development practices.
There are no silver bullets for getting this buy-in but the good news is that some industries have done it in the past.
Airline safety is a great example. Airlines have an extremely strong forcing function to ensure high-quality work - people can die if an aeroplane crashes. Ryanair, a famously cheap low-cost carrier, said the one area they don’t cut costs is safety because that is the one piece of bad news they can’t recover from.
While the airline safety example may seem extreme, the equivalent analogy is that the current ways of working are increasing the technical debt in our products and, eventually, it will have to be paid.
Influencing without Authority
As an individual contributor, or as an external consultant like Richard, you need to try to influence that buy-in because you don’t have the authority to enforce it.
We have this concept of something called a trust battery. When you start engaging with a client, the job is to charge it up as quickly as possible. And that means not overcommitting on any early stuff. If you said, no, we can't do X because this part will take longer, but we'll do everything else and it will be delivered on time. Making sure that was a priority.
Richard Rodger
Trust is not easy. It takes time. And you have to earn it. But once you have it you can move away from hard schedules, where the focus is on delivering a large spreadsheet of features, to collaborating on the features that customers really need.
We give the client the ability to change their minds every week, and try to share the problem space.
Conclusion
While companies are recognising the importance of a high-quality user experience of their UI’s there is a need to recognise APIs as another form of UI that needs as much attention to ensure ease of use and high quality functionality.
And like all product development that involves customers, we can’t know what they want upfront. We need to work iteratively with our customers to uncover their real needs. This means we need to shift from big designs up-front and large spreadsheets of features to iterative, collaborative product development.
If you are struggling with the quality of your APIs, reach out to Richard and Voxgig to find out how they can help.
You can watch the full interview below