Most API Owners Are Just Focused On Issues
One of the biggest challenges I face in reaching API practitioners in my work as the Chief Evangelist for Postman is that most people in these roles are more focused on the day to day details of their work, and are often cognitively unable to zoom out and see the bigger picture. It isn’t that they don’t have the interest or capacity to do this, it is that the day to day demands of their jobs prevent them from having the bandwidth to pause even for a few minutes to think about the bigger picture, let alone get up to speed on what they need to, and craft a more robust API strategy. My biggest competitor when it comes to reaching these folks is not another service or tool, it is just the expectations placed on them by their organizational environment.
I may be able to get my stories read by API architects, designers, and developers, but if I can’t figure out how to make them more applicable in their day, I’m not going to make a difference. To help me shape my storytelling I want to better understand the challenges on the ground, and regularly document the common challenges so that I can actually craft not just stories that are relative, but also create collections and influence other Postman features that might actually reduce friction wherever I can, to help give people more room. So, what are some of the common challenges my readers face?
- Bugs - Every one of my readers faces a steady stream of bugs in the APIs, and applications they are in charge of. Regularly distracting them from the work that will move things forward making most feel like they are always drowning.
- Infrastructure Failures - When you are running large scale systems there will always be infrastructure challenges involve failures, bottlenecks, and limitations imposed by the infrastructure in place, and the impact of decisions made, or not made.
- Productivity Losses - Bugs and infrastructure failure always introduces productivity losses that often seems to be perpetually putting teams behind, making it feel like they are never moving forward, maintaining friction across operations.
- Broken Workflows - Even once we’ve rolled out new Ads, the dots aren’t always connected in ways that ensure business gets done, and there are regularly broken or fragmented workflows that will trip us up in getting our work done.
- Legacy Constraints - The decisions made by previous teams, or just the decisions we made on our own 5, 10, or more years ago will always work against us, introducing regular waves of constraints on what we are trying to get accomplished.
- Security - The number of security concerns each team faces exponentially increases each day, distracting us from our work and perpetually limiting the impact we can have with the APIs we are delivering each day.
- Governance - Managing data and API governance is a never ending job, and something that becomes even more unwieldy if we can’t ever pause and take a look at the bigger picture—introducing a self-fulling cycle of friction.
It is difficult to pay attention to the big picture when you are down in the weeds of operations. This is one of the reasons I’ve stuck with consulting for different companies over the years, and why I’m focusing on talking to Postman customers about the realities of their API operations on the ground floor. I find that if I’m too removed from these stories I run the risk of becoming too academic in my work, and I’ll just be telling stories that do to speak to folks in the trenches. I’ll be taking each of these areas and working to establish ways of using Postman collections to help reduce the friction, execute valuable tasks, and most importantly for me, wrap them in stories I can tell that will reach and speak to the average enterprise developer.
I am determined to not be creating more work for folks, and crafting executable solutions in Postman. Our director of customer success Sanjeev Sisodiya (@ssisodiya) has a vision that every support response, and customer success story should also be a Postman collection. Making everything we do actionable by our customers, and helping make any concept we are looking to get across something that is portable, sharable, and executable, just like everything is in Postman. I’m looking to try and realize Sanjeev’s vision in my storytelling, and work harder weave Postman collections into my narratives, and begin solving more of these common issues that my readers are focused on, providing little nuggets of value they can put to work reducing friction in their world. I’m going to focus on some of the governance areas first helping manage more of the API design issues that get injected into the API development lifecycle, creating a variety of collections that can be adopted to help standardize the APIs our customers are defining using collections.