I regularly spend time with business and technical leadership at large enterprise organizations where I walk through my big picture strategy around the API Lifecycle and governance. 90% of these conversations end with heads nodding, and folks saying, “That all sounds perfect, but where do we start?”. This is a question I am increasingly prepared to respond to, but truly understanding where someone is in their API journey, and providing them with some possible next steps for them to focus on, takes a lot of work. I just wrote about the four main areas needed to ground API strategy conversations, but I need to do more thinking about how to better help people in the moment, meeting them where they are, catering to what they need, speaking to their incentives, while also hanging guidance on an overall strategy that we can check-in on from time to time.
Where are you in your overall API journey?
Understanding where someone is at in their API journey is critical to sharing where you can start. At Postman we break these down into three major phases, 1) API-Early, 2) API-Aware, and 3) API-First. Most companies I know are API early, so I focus on the fundamentals like having an OpenAPI contract and achieve more coverage across teams when it comes to standardizing testing. These three buckets really help shift between the different dimensions or zones of the API journey, and determine if we are focusing on fundamentals, optimization of what already is happening, as well as how strategic we will be talking. If you are API-Early, it is unlikely that you are ready for governance, and really we should just be working to map the landscape, and define what currently is before we try to do anything new.
What matters the most to you right now?
I love it when I come across a kindred soul that cares about doing APIs well, and the finer points of optimizing our API-first strategy. However, the majority of folks I come across are just trying to get a job they need done, put out a fire that has been burning for some time, and in general just make it through the day or the week. When my API Lifecycle and governance presentations strike a chord with folks, but then they ask where do we start, it really will depend upon what matters the most to them at the moment. I really want to help get you thinking more strategically, but 80-90% of the time people are looking for solutions that solve a problem for them at the moment, and bonus points if it can hang on some wider API strategy. This is why I work to distill my advice into as snackable solutions as I possibly can, because when I am feeding people with ideas for where to start, it needs to be something small and actionable that will bring value—otherwise it will be a non-starter.
How can I help reduce the cognitive load?
Doing APIs can easily become a complex affair. Doing many APIs well is always always a complex thing. I may have all the moving parts of an API strategy, lifecycle, as well as governance laid on the table, but the cognitive load that comes with it is often pretty painful and overwhelming. Like APIs, I try to keep my API guidance as modular as possible so that it can be dished up and consumed in little bits. You don’t have to understand how it all works–you just have to understand a single piece of the puzzle that is relevant to a job you have to do. I don’t expect everyone to care about the entire API lifecycle, and being thinking strategically, and it is up to me to make sure that the cognitive load associated with my guidance is as simple and valuable as it possibly can. I see them more as breadcrumbs that I need to lay out for someone to follow, snacking their way through the day, with a series of destinations in mind, keeping everyone moving forward safely in their API journey.
Having the right questions and answers
Ultimately, to be able to answer where someone should start, I need to assemble the right series of questions that will get to understanding where they are at in their journey, what matters the most to them, while not overloading with too many questions and other information. This isn’t easy to do. I am the king of overloading people with information. I have all the answers. I just need to get better at the questions I ask. I need to get more organized and structured with how I organize the elements of my API guidance, and attach common questions with each one. This way I can start with a handful of opening questions, but based upon the answers I can tailor the information I provide based upon who I am talking to, where they are in their journey, and what matters to them the most. The questions I ask throughout my presentations need to better prepare me for how I respond at the end to, “but where do we start?”
While just operating as the API Evangelist I could pontificate on all of these API Lifecycle, governance, and strategy ideas all day, but I wasn’t actually responsible for making the rubber meet the road and solve real world problems. Now that I am at Postman, I am much more accountable to large enterprise customers who are in need of guidance. I can’t just come in and throw a bunch of ideas on the table and then tell them to figure it out. I have to actually provide value to them at the moment, meeting them where they are. I can’t just hand-wave my way to an API-first utopia, and I need to provide actual guidance that will move things forward. With this round of storytelling I think I’ve managed to refine some aspects of my approach to deliver guidance, and I am hopeful that I’ll have a few API-driven solutions that will help folks answer the question, “but where do we start? Without me having to be directly engaged as part of the conversation, providing a more self-service journey through their API-First transformation.
