Many folks don’t quite get my work and writing style. They are confused by the erratic flow of stories being published to API Evangelist, the incomplete nature of some of my research sites, and other annoying factors that don’t quite make sense when you view API Evangelist a particular way. If you think it as a technology blog like Techcrunch, ReadWrite, The New Stack, or others, you will be passing certain judgement on the content of my work, the tone of what I say, and the chaotic way in which I publish my research and stories across hundreds of separate sub-domains. People expect me to write up their API, review their approach, or know everything about the thousands of APIs that exist across the public landscape. API Evangelist isn’t this type of blog—it is simply my workbench for things that interest me, are relevant to the industry and my career, or is valuable to someone who pays me to generate value in the API universe.
Two Distinct Layers Of Research
There are two main layers to my research, which I use to mine API information and knowledge. These two dimensions feed off of each other, but ultimately drive my research, storytelling, and at times the wider conversation in the API space. Helping me organize everything into these two buckets:
- Landscape - Reviewing the public and private API offerings across many different business sectors, providing me with a unique view of how API providers are doing what they do.
- Life Cycle - Taking what I’ve learned across the landscape and organizing information and knowledge by stops along the API life cycle, for use in my regular work and storytelling.
These two layers are constantly feeding each other. For example, after making a pass through all the payment APIs, updating the landscape for that area, I will add new building blocks I’ve stumbled across to my API life cycle research. Then when I embark on research into the transportation API landscape I leverage my evolved API life cycle perspective to help me look at things differently--powering both sides of the coin with the momentum I have built up over the last decade of my work.
Three Ways I Produce Value
My research is ongoing. It will never stop. However, along the way there are three main ways I produce output from my research, delivering a never-ending stream of exhaust from my work each day. There are three ways in which I produce value from what what I read, study, and ponder each day as I obsessively think about APIs. Here are the top three ways to consume what I do as the API Evangelist, providing observability into what I do.
- Short Form Content - Producing Tweets and blog posts to share and ideate on what I am seeing across my API work, producing a real-time stream of consciousness from my work.
- Long Form Content - Producing long form guides, white papers, and other publications that distill down my work into portable snapshots into the API landscape, life cycle, and other API dimensions.
- Projects - Contributing to free or paid projects, helping inform the API conversation, and assist other stakeholders to make more informed decisions around what should happen with a project.
Really, the short form content is just exhaust from the machine operating each day. The blog posts are just me scribbling on my workbench, trying to refine my understanding of what is going on. Ultimately I am just working up towards some long form or project level output. This is why some of my short form posts are so rough, and sometimes not fully fleshed out, or well-written. I’m not publishing a post because I want everyone to read it and understand, I am simply getting the idea out into the open, existing on the workbench, so it can be reviewed, refined, and potentially used later on in some other work. I am not writing it for page views, or attention, I am simply publishing it to my workbench, and my API workbench happens to be more open and transparent than most—something that has transformed how I do what I do…but, that is another story.
An Open Source Page For Your API Platform
After wrapping up one project, and beginning to embark on a new one, I wanted to take the time to document I how work, and share with some of my newer audience who might not be aware of my working style. To get a glimpse of how I work you can take a look and the open source page work I’ve recently done, which ultimately ended up contributing to the development and publishing of the Postman open source philosophy page. Producing a range of outputs from me thinking deeply about how to craft and publish an open source page for your service, tool, or platform.
- 20 Open Source Landing Pages From Leading API Providers - After looking at and documenting a whole bunch of open source pages for API providers I thought I’d take some of the more noteworthy ones and publish as a blog posts for others to think about.
- A Dedicated Open Source Page For Your API Platform - All of the common building blocks I found while looking at many different open source pages, distilled down into an easy to understand list I can share with my team while producing an open source page for the Postman platform.
- Postman Open Philosophy Page - The resulting page for sharing the open source story at Postman—produced as a team effort within Postman, wit my research input helping steer the conversation and resulting work.
Ultimately there might be a guide and / or white paper on the subject down the line, as well as some more storytelling on the subject here, and on the Postman blog. However, this provides a simple look at how I work. Depending on the subject I may produce many more blog posts as part of my research, ideating and breaking things down as I go along, but ultimately my work is all about informing some project, or at the very least esnuring this knowlege on the tip of my tongue when I talk to companies, organizations, institutions, and government agencies about their API strategies. Repeat over and over, cycling through every dimension of the API space, and you have API Evangelist, a wealth of knowledge about how things work (or don’t) in the API sector.
What I like most about this work is it keeps me learning. Also, that it keeps me writing. These are my two most favorite things in the world. Thirdly, it keeps me generating value for companies like Postman to keep paying my bills. Fourth, I am hoping it helps other people. I’m thankful I have an employer like Postman who invests in my work, allows me to keep doing this research, and share it openly with the community, while also helping (hopefully) influence the Postman road map. While there are aspects about the technology sector that drive me nuts, ultimately I have a pretty sweet gig. I get to spend my days researching something I find interesting, sharing what I know with the public, while also helping to contribute to what I feel is one of the most important platforms when it comes to defining the API economy—Postman. ;-)
