Library Podcasts

Ep. #7, API Evangelism with Kin Lane of Postman

Guests: Kin Lane

In episode 7 of Developer Love, Patrick Woods and Kin Lane of Postman unpack how the API evangelism landscape has changed over the years. They also discuss Kin’s career educating developers through writing and storytelling.


About the Guests

Kin Lane is Chief Evangelist at Postman with an extensive background working with APIs. He also publishes writing on the technology, business, and politics of APIs at API Evangelist.

Show Notes

Transcript

00:00:00
00:00:00

Kin Lane: So my name is Kin Lane, I'm chief evangelist at Postman, I'm also sometimes known for being API Evangelist.

I have a blog that I've had for the last decade, just showcasing the API life cycle, what are APIs, and really I focused on the technology, the business, and the politics of doing APIs, which I think the Venn diagram at the center of that is evangelism and advocacy.

Patrick Woods: Awesome. Can you talk a little bit about your journey getting into the world of APIs and evangelism?

Kin: Sure. So I'm a database guy, so I've been doing databases since, my first job was in 1987, doing cobalt databases.

So fast forward that 10 years, the internet comes out, I'm doing database driven web applications, by 2003/4, I'm doing a lot of web services, service oriented architecture, but then I started playing with the likes of Delicious and Flickr.

And then the Twitter API came out, which changed my world.

And I saw the potential of web APIs and the internet and public APIs.

And what it does for bringing you out of our silos, our database silos, our enterprise silos.

And I was really intrigued with what Twitter was building, because the app was just, you could sign up, follow friends and then tweet.

And then they launched the API. And like, everything we know as Twitter today was built by the developer community.

And then once Amazon happened in 2006, shortly after or around the same times as Twitter, like I could deploy APIs for infrastructure storage.

I could deploy a server using web APIs. So I was like, wow, there's something going on here.

And then in 2009, I met my now wife who is a folklorist and she introduced me to storytelling and I saw the combination of public web APIs and community, and then storytelling being a really powerful combination.

And I quit my job at SAP. I was a VP at SAP running North American events, and I didn't much care for it.

And I started API evangelist and I've just been studying the space and telling stories ever since.

Patrick: That's quite a journey.

How would you say that the API and evangelism landscape has changed maybe just beyond the technology, but maybe speak a little bit about the tools and methods for adoption and awareness, things like that?

Kin: Yeah, I would say 10 years looking back, I mean, I just rolled over 10 years looking back and not a lot has changed.

I would say the main thing that has changed is it's gone mainstream.

So in 2010, 11, I was talking to the Twilio's, the Stripes, Amazon, the core of the tech world.

Now I'm talking to banks, I'm talking to insurance companies, healthcare providers. And so the sphere of who I'm talking to has widened significantly.

And there's more leadership VPs involved in the overall API life cycle and what's going on around APIs.

So it's really, for me, it's you got to keep simplifying, you got to keep focusing on the people, the end value, the users over and above just the technology, the tools, and make it inclusive, make it a conversation that business stakeholders can be involved in as well as developers and help developers be more successful in that kind of landscape.

Patrick: How has storytelling as a practice or a discipline helped you navigate the transition from predominantly a tech audience to more of a business stakeholder audience?

Kin: Yeah, I mean every technical detail I do, building an API, consuming APIs, documenting, I have to find a way to explain it to other people that are outside of the circle.

And I would say, this is really the value of APIs and advocacy and evangelism on top is you're forced to do that.

You're forced to pause the tech the thing that you're really excited about and make it make sense to a wider audience.

So this further expansion into business circles has just really forced me to further distill things down, keep things simple, make sure things are explainable and easy to onboard.

And complexity just has to not go to the wayside.

I mean, there's still complex technical things that have to occur, but you have to really work to make sure that they have purpose and meaning, and they add actual business value to the bottom line.

Otherwise, if you can't explain that you're not going to be successful, and if you can't measure and help other people understand that and say, hey, we were successful or we weren't successful, you're always going to be stumbling.

Patrick: Hmm. I'm curious, do you have any tactics or mental models that help you translate those complex topics into something that might be more digestible or understandable by a broader audience?

Kin: Yeah, I mean, the writing for me is how I develop those mental models and refine them and move them forward.

If people read my blog, API evangelists, it's very rough, it's not a finely edited, it's very much almost my notebook, but it's that first step in me going, okay, here's what I'm doing, here's why it matters, here's how I'm going to explain it to someone.

And then I can flesh out more scaffolding around that, through that process.

Like, who am I speaking to? oh, wait, am I speaking to a developer? Am I speaking to an executive?

What persona or what, who's my target audience for this. And so that helps you in craft that scaffolding and then repetition, doing that over and over and over.

I mean, I'm up to like 4,500 blog posts in the last 10 years.

It's very much the exercise of distilling those technical bits down into little nuggets that I can communicate, I can articulate, I can make a single slide in a slide deck if I'm doing a presentation or a talk and it just helps me better refine those nuggets, build my toolbox of those nuggets and then be able to effectively communicate those in any situation.

So I can jump on calls pretty quickly and pull from that toolbox and make things work.

Patrick: So you're obviously a prolific creator of articles and content.

I'm interested to go inside your head a little bit. How do you decide what to write about next or which topic to tackle next?

Kin: Yeah, that's an important one because the process of writing helps me slow down, because if I'm too busy internally with projects, meetings, deadlines, I don't write.

So just forcing myself to say, hey, I got to get something up on the blog, anything, slows me down.

But then in that moment, I'm able to really think about, okay, what's the priority?

What should I be writing about? I've got a massive notebook of ideas, of topics.

I've got Google analytics and other things telling me what people were interested in over the last week, over the last month, over the last year.

I tend to have a feeling for what people want to read and what's going to generate the page views or what's going to generate and drive conversation.

So I have lots of data that will feed into that, but then it's still very much a gut level, in the moment, here's what I'm working on, here's the problem that I need to work through.

It's not always about what people want to hear. And I would say what drives traffic and what drives interest and conversation is being open and honest about the problems I'm working on.

One way you can think about this is the success of Twitch, as a channel when it comes to DevRel and at Postman, Joyce and Arlemi run our Twitch and Arlemi, he's like, come in unprepared, just come in with idea and let's work through it.

Let's not have all the parts and pieces and have this perfectly scripted, people appreciate you working through the problems and figuring things out.

So I would say that in my overall storytelling is what I try to make my storytelling and writing about is, hey, I have something I'm working on.

I want to figure it out. So that task list of things that I have to figure out for the next week tends to drive that prioritization.

But with that said, I do have a larger scaffolding of the API life cycle that I'm like, hey I talked about docs last week.

I need to talk a little bit more about mocks. I need to talk a little bit more about code gen.

I need to talk about things that are going to help people with their holistic strategy.

So I do have that wider strategic view, but it's still very much often a tactical thing.

Here's a problem I got to solve this week or next week, I'm going to write about it, I'm going to pause, I'm going to be thoughtful about it, and I'm going to work on this little piece.

Patrick: Yeah. It reminds me of the Pasteur quote, "Fortune favors the prepared mind."

It sounds like you do a lot of work to keep that notebook, to keep ideas fresh, so when the time's right, you've got a library to pull from.

Kin: Yeah, that's exactly what API Evangelist is for, is that catalog to work from.

Patrick: So I'm interested, you've been creating a ton of content for API Evangelist over the past decade. What drew you to a role at Postman?

Kin: So I started with API management 'cause that was the most mature stop along the API life cycle, really studied it 2010, but over the last 10 years, I've really mapped out what is a modern API life cycle from design and define first to deprecating an API down the road and everything in between.

And so done a lot of studying on how leading API providers like Twilio, Stripe and those do what they do.

I've done a lot of research on successful enterprise organizations, gone in and helped them with that strategy.

So how do you, what's that life cycle look like? But I engage in these conversations.

I engage in one or two weeks of consulting with the enterprise and then I'm gone and it was living in a perpetual academic mode.

And I wanted to get my hands dirty more. I wanted to see it working or not working.

I wanted parts of my strategy to fail.

And so, looking out there right now, I mean with the old API management guard consolidating and all of that, the apogees, masteries, all of that's been acquired, the new guard, there's Kong and there's like Tike and there's a handful of others, but when it comes to full API life cycle tooling, there's really only Stoplight and Postman moving forward there.

And so I would say I have been working with Stoplight for quite a while, but my friend Phil is leading the charge there.

And then Abhinav and I got talking at Postman and just talking about what's needed and really started looking at how Postman collections work and how the platforms evolving.

I'm like, that's the tool that's going to help me really, help me make the rubber meet the road when it comes to a lot of my ideas and allow me over the next decade to take him to that next step, I think, where it's more applied rather than theoretical API life cycle and governance stuff.

Patrick: So you mentioned something in there that I want to dig into a little bit.

You mentioned that in your role with the API evangelists, it felt very academic and the opportunity at Postman gives you the chance to test some of those ideas.

And you said, I wanted parts of my strategy to fail. Can you talk a little bit about that observation?

Because that seems a little counterintuitive for a lot of people who might be terrified of their thinking being incorrect.

Kin: Well, for me, I know enough about the API life cycle, and helping build the factory floor at large enterprises, that something sounds good and then once it meets the people and meets the masses within the enterprise, that it didn't play out the way you thought, it was perfect technical implementation.

And for me, that's why I really focus on the three spheres, the technology of APIs, the business of APIs, and then the politics of APIs.

And there's internal parts of that and there's external, but you can have a perfectly designed restful, all the things we love to talk about when it comes to API design, everything down to your I's dotted and T's crossed, and then it comes against the business strategy of an enterprise organization or the business strategy of a startup or the lack of a business strategy for a startup. And it will fail.

I don't care how technically perfect it is.

And then the politics for me can be either internal politics, it can be external politics or industry level, and you've got to know how to play the politics game when it comes to putting an API out there, understanding how it's going to be wielded, how it's not, what's that look like with your competitors.

Internally, you got to think of other groups, there's a lot of infighting.

There's a lot of how do budgets work when you launched this API, what's it going to cannibalize?

There's just a lot of things to consider.

So I know a lot of my ideas are pretty robust, but without actually taking them into an enterprise organization and seeing them through, or building a product or set of features that actually implement that, they're just never going to harden or mature enough for my liking.

So I need that to grind against the actual operations to make 'em work.

Patrick: Yeah, so as you've tested your ideas in real time inside of organizations and at Postman, what's something that has really surprised you as you started to test those ideas live?

Kin: Just how much education is needed as laying the groundwork.

Just everything from fundamental literacy around HTTP.

I mean, I go into a lot of enterprise organizations where super smart PhD level CS people running the show, just run circles around me when it comes to programming and architecture, but they don't understand HTTP headers and they don't understand some basic fundamentals of how the web works and, so a lot of those fundamentals surprised me going in and then how defensive people get about that.

But then other levels of education around the tooling that they're using.

So they have a three to five year license for a vendor A or B, and they don't really understand what it does 'cause that decision was made up above them.

They aren't educated and aware of it. I come across a lot of teams who are using Swagger open API, but really don't understand how it works, why it does what it does.

And so all of those layers of people, just not knowing everything they need to be successful.

A lot of it's not having time because of prioritization within organizations. It's like they're not given time to prioritize education and learning.

I knew that was going into a lot of these, but I just didn't understand the scope and severity, I think, and organizations need to invest in an education a little bit more, I think.

Patrick: Hmm. What keeps you coming back to this space or this problem set?

Kin: I mean, and I'll say coming back is appropriate.

'Cause I think I've burnt out three times over the last 10 years, pretty high profile, pretty seriously.

Like I'm not coming back type things, you know?

And so I'm having to constantly reinvent myself there and I would say the diversity of ideas, diversity of implementations, that's why I like APIs specifically is I can be doing healthcare one day, I can be doing transportation and other, I can be doing machine learning.

So that diversity keeps me interested.

But I would say the people, the stories, like really finding the people who care about their jobs, care about their projects, care about their communities.

Listen, have the good stories and stick around long enough to tell them.

I would say that's where I feel pretty accomplished is, I've been around 10 years now, gathering these stories, retelling them and building relationships with people within enterprise organizations, government agencies.

And so it's really the people in the storytelling I think are the most important thing. It's the thing that keeps me energized.

It's really not APIs, to be honest, it's the people and the stories that get told around what's going on.

Patrick: Hmm. What would you say is the secret to building things developers love?

Kin: Yeah, I mean, it's got to be useful. It's got to solve a problem in their world, reduce some friction, help them feel more accomplished, feel like they're doing well, stay afloat in their drowning, sprint driven world.

And this is one, another reason I'm really at Postman, or I'm happy to be at Postman is we did AWS reinvent in November, it was back when we were all in person, being able to see other and the number of people who would come up and hug me and profess their love of Postman.

You can tell like sincerely, the tool saves them pain and suffering in their daily jobs.

And so for me, like if I can't write a story or make a little proof of concept or tool all the way up to a full platform like Postman, if it's not solving a problem for developers, you might be able to get some business people involved or some IT leaders and get them to buy your product, but it's not going to stick around longterm.

You've got to really reduce friction for developers to make their life easier. Otherwise it's just not going to be sustainable.

Patrick: Do you think there's anything beyond solving the problem that makes a tool or a product or platform something developers love?

Kin: I would say make it inclusive, make it something that showcases, helps them be part of the conversation in the community.

I think this is why community approaches really work is because we really want to belong, we really want to be showcased when we do good things.

So yeah, if it's reducing friction in my world and making me be more successful and then I can contribute more and be part of the conversation and even be showcased as someone doing interesting things, being a thought leader, which I don't like that phrase, but like showcasing people doing good and exciting and useful things, people like that.

That's some parts of open source really works well is people like contributing.

So you got to figure out how to create an environment where that exists and that thrives and that's part of the business strategy and the bottom line is just make people feel like they're included and they're part of something and they're doing meaningful work because after over 30 years now in the tech space and tech just doesn't love you back as much as we tend to love tech.

And so if we can build communities and build environments where you feel like you're included and you belong and you matter, and you're doing something relevant, then that's going to be a success.

Patrick: Yeah, yeah, I totally agree.

I wonder if you have any examples of communities you think do a good job of this, or maybe just tactics or lessons to learn from building that environment that really makes people feel valued?

Kin: Yeah, I mean, there's the easy ones.

I mean, you can grab Twilio, they get it. The stories they tell, the showcasing the developers, the showcasing of partners.

They really get the formula at a lot of levels. So those are easy ones.

But I would say looking outside of the tech echo chamber for communities and tactics, think of places like the US Census Bureau, which is super high value data set, fairly complex set of APIs, but you got data stewards who really care about the data.

Like really, they've been working on a survey for five years formulated the questions, saw the execution of it, the gathering of the data, the publishing of the API.

And they're in the Slack channel for the API community DevRel, so they're there answering questions and doing things. And so there's government agencies that have communities that are really engaged like that. But as far as tactics, I mean, feedback loops are pretty critical. So Slack channel, a blog with comments, forums, those are all the usual feedback loops.

How do you give your community a voice?

But I would say the tactics, those are good strategic level, hey, we're going to have a developer Twitter account. We're going to have a forum.

But it's really the tactics and how you employ that that make people feel included and make them actually feel like they have a voice.

Make sure they feel safe. I mean, code of conducts, making sure people are heard, people have a voice they're not talked over.

So there's a lot of those little nuts and bolts that go into these.

So have a diverse set of channels, have ones that make sense are meaningful and are active, are true feedback loops.

They're not just community owners just broadcasting. And then explore and find new channels, but don't open up too many so you have too many channels.

Twitch is an important one that we're learning how to use and understanding because it's a unique type of feedback loop.

You put yourself out there, it's less prepared, you're more exposed, so thus you're honest and you're more vulnerable.

And I think that helps build relationships.

And then there's a live stream, people are talking and asking questions and you're responding to those questions, so it's a real time feedback loop, which really augments our forum nicely, our Twitter presence nicely.

And so being thoughtful about lighting up these channels and then finding those little details that really make them inclusive to developers and give them a voice and then help them amplify that voice is key.

Patrick: So thinking about your role at Postman, I guess the question has two parts, but what's the day to day look like, and then how do you know it's working? What's success look like for you?

Kin: I have to admit, I don't have as many ways of measuring the impact. I tend to know whether something was successful or not.

A number of stories I'm telling, so it's not just blog stories, it's webinars, so more prepared, Twitch, less prepared. Virtual events where I'm doing a virtual conference.

And so the number of those like that I'm doing, I would say the diversity of those.

So being able to tag and measure and go, hey, I told X amount of stories in docs, X amount of stories about cogeneration.

So number of stories, diversity in stories, and then the reach of those stories, did they drive conversations on social media, how many page views?

So I do have some basic tools to measure, hey, that got a lot of page views or hey, that got a lot of retweets or the collection or the proof of concept or demo behind it got a lot of stars on its GitHub repo.

But I would say for me, it's much more like the conversations, like did it strike up a conversation that went on for a couple of days on Twitter or on whatever the channel was and people were engaged and I was engaged.

So the depth and relevance of the conversation is really--

And that's, you can't measure that, but I guess you can machine learning and some sentiment analysis and whatnot, but really it's like me just going, man, the last two days that conversation around, I'm building a DevRel Twitter list right now which I ended up with a list of DevRel Twitter lists because me just asking, hey, who's doing DevRel?

And then I'm building a list, started a whole conversation.

Well, I've got a list, I've got a list. And then I built a list aggregator. So other people could then aggregate the lists.

And then people were like, hey, we're doing this over here. It just struck up a lot of interesting conversations.

So yes, this got a lot of retweets. Yes, this got the usual metrics, but really like two or three people DM'd me and were like, hey, I want to do one on one video conversations with you.

So it spawned more conversations.

And so that I would say is success in my book is just generating more of that love to use a phrase that you guys, that I really love about you guys, so.

Patrick: Yeah, we saw the conversation around the Twitter list and then it went from a couple of people on the list to like over a thousand.

So I suspected you had some magic going on behind the scenes there.

That's pretty cool to see that grow. I'm curious, what led you to want to build a list of DevRels?

Kin: 'Cause Joyce, Arlemi and the rest of DevRel at Postman, we're trying to build an internal directory 'cause we want to know, well who other DevRel folks are out there that we don't already know, and this is core to our partner outreach, DevRel proper, but then our wider partners building these relationships and then understanding we don't have a podcast, so here we joined other people's podcasts.

We have a Twitter stream, how can we get other DevRel folks to come build cool things?

And so we're building that directory right now of who's out there, what companies, what brands, what tools do they work for?

And we're tagging and organizing that. And then we're going to build relationships with people and hey, how can we scratch each other's back?

I mean, this is what we all do. Let's just be very vocal and open about it.

And so the Twitter list is the seed of that directory, but I would love to figure out, well, how do we cross pollinate across each other's channels, schedule things out, make sure there's a diverse suite of guests blog posts, blog posts, webinars, Twitch streams, and whatnot going on. So.

Patrick: Very cool. I'm curious, what would you say has been your proudest moment in your career as API evangelist and at Postman?

Kin: I've said over the last 10 years, I would say like in 2013, I got invited to work in the Obama administration on APIs.

That was, I would say a very classic, hey look, mom, I worked for the president type thing, doing APIs, and all those people at SAP, I was like, hey you're crazy for leaving a cush six-figure job to go do this.

I would say that still would be the one that I tell most stories about, but more, I would say subtly is just rolling over the 10 year mark this July.

And it just happened softly 'cause of COVID, but I've been doing it 10 years, successfully and I feel very accomplished.

I've got lots of great stories to tell. I've learned a lot. I have a great job now at Postman.

I mean, I wasn't always paid very well over the last 10 years, so it was a hustle.

And so just for me personally, I feel accomplished having done this for 10 years, it really is the most significant milestone that's going to move me into the next 10 years and keep me on a positive track with my career.

And that people are still listening to me and people still want to talk to me and I'm somewhat relevant and I matter, so that just makes me feel good, it's back to that inclusive thing.

I feel like people still want to hear what I have to say. So.

Patrick: What are you most excited about, shifting from looking back to looking forward, what excites you about the next 10 years?

Kin: I would say the maturing of all of this we're doing.

I still feel like technology, the web mobile apps, IOT, all these things that we do with APIs are still very in their infancy.

And I would say us growing up and maturing is really what excites me.

And I would say in turn those partnerships conversations that I'm in. So the platforms like Twitter, still weathering all of their trials and tribulations and I'm doing regular calls with them to partner with them and talk through like how V2 of the API gets used by researchers at universities.

And having similar conversations with Twilio and Dropbox, where, how do we make, not just hell here's the Dropbox API, build something cool.

It's no, how do we actually help administrators and business users be more successful with Dropbox and actually thinking through the application of these APIs and how they solve problems and make our lives easier at this mature scale.

'Cause I feel like it's been really crazy wild West, a lot of money, a lot of ups and downs over the last 20 years.

And I'm hoping for a little bit more stability. I'm not entirely sure we're going to get it, 'cause sometimes it seems crazy right now with Twitter and Facebook, but I think we're entering a phase where there's going to be more regulations coming into play.

And I've done a lot of research on early telecom industry, early power industry, early the automobile industry, there was wild wild West and then regulation came in, things stabilize.

And then they grew massively and there was consolidation.

But I feel like that's what's going to start happening with the tech space is we're going to see a little bit more regulation, we're going to see a little bit more stability, security, privacy, and that's going to be a good thing for all of us because then our platforms are going to be healthier, businesses, industries are going to be healthier.

So that's what I'm hoping for. I don't think it's going to happen entirely in the next 10 years, but I think the next 10, 20 and 30 years that's going to be the key to technology and community driven technology is, it's got to be, it's got to be less scary, more stable for all of us.

Patrick: Where in the tech stack or the value chain do you think we'll see the most regulation?

Kin: Yeah, that's going to be a tough one. It starting in the existing heavily regulated industry.

So, just saw the health and human services and Center for Medicaid and Medicare mandated that if you're a public or private entity across all 50 States and you take money from the federal government for Medicaid, Medicare, any of these CHIP programs that you have to have a FHIR-compliant API.

So fire is the Fast Healthcare Interoperability Requirements.

It's a standard for how you do healthcare APIs.

The Department of Veterans Affairs uses it, Center for Medicaid and Medicare use it, but now all state level public and private entities have to use this.

So this is the same API, but across many providers.

And so that helps stabilize how you build mobile apps on that, how you do system interoperability in healthcare sharing. And so that's the first mandate we've had in the US, the federal government saying you have to do an API, and it has to look like this. We've seen that in Europe with PSD2 in banking, but we haven't seen it in the US for any industry. And I would say, that's just the tip.

So all of the heavily regulated industries are going to go that route in the next five, 10, 15 years is there's going to be some mandate that you have to have an API, and then your API has to be designed using standards, and you have to have common practices for how you operate your community.

Because in Europe, we're seeing with banks is, oh, I have a PSD2 API, well, your community can't actually get to it because it's not public, it doesn't have a portal, it doesn't have docs.

It doesn't have all of those parts and pieces you actually need to onboard people with your API, so thus it doesn't matter.

And so the things we take for granted as DevRel and community managers, the rest of the world has to wake up to that.

And someone that's going to be mandated as part of these API standards.

So we're going to see that in healthcare, we're going to see it in FinTech, we're going to see it in transportation and all those industries over the next decade.

Patrick: So we've talked a lot today about stories. I'm wondering, what are you reading these days?

Kin: So, I'm straddling two books right now.

One is just a collection of James Baldwin essays from the 50s and 60s, which as a white male in this day and age, I think that's where I want my head at right now to try to make me think a little differently.

And then the second one is Abhinav bought me a copy, came in the mail, it's the systems management behind the Apollo program.

So going the other direction and going super deep is, if you use Postman, you know we have a space theme, we have the little rockets where all Postmanauts, is what we call.

And so we're always mining the space program for interesting stories.

And he's like, hey look, here's how we got to the moon, let's run Postman like that.

And so he sent me that book, so I switched between James Baldwin and that, and try to spend my evenings and weekends doing that.

Patrick: That's awesome. Have you pulled any interesting vignettes from the space program yet?

Kin: Oh yeah, I'm trying to figure out collaboration.

So defining collaboration, if you're in the tech sector right now, that's one of the words du jour right now, we're all collaborating, we're all on, you know?

So what does that mean? And so I'm really going through the space program and understanding, okay, well, how did this work as far as each of the teams for the Apollo program?

How did they collaborate, share information, work together? What did that look like?

But then what did it look like from a vendor standpoint?

So how did you know the actual capsule, the Apollo capsule, this vendor bid on it to do it, said they could do it like this, and there was these failures and then.

So grabbing a lot of those practices and really applying it to, well, how do we build systems that have a longer life, are more reliable and sustainable, because if you're sending something into space, updating patches and doing things are significantly more expensive.

You want it to be longer lived, so how do we take those practices and apply them to just everyday technology to make sure that we're building a little more reliable and stable systems?

Patrick: So, one question I ask every guest, this podcast is called Developer Love, so I'm curious, what's one thing that you're loving right now?

Kin: So, I mean, dream job, pinching myself, I'm where I want to be.

Rehashing a little bit of what I've already just said is I get to have really interesting conversations with big companies.

So just the scope of the people that I get to talk to now, and the projects they're working on, how smart they are, the things I get to learn.

That keeps me excited. 'Cause I'm, I mean, again, it's really not the APIs.

It's just the way that the Twitter team sees the world and what they're doing, APIs, I would always say the Twitter API for me is one of the most important API is out there.

And it's one of the ones I love and hate the most and so endless lessons.

And so I feel totally blessed that I get to work with them on a regular basis, but then extending that to other companies, I'm talking to the Salesforce people and then I get a go to government and I'm working on the healthcare stuff and I get to talk to European bankers.

And so just the scope of the conversations and the diversity and the people that I get exposed to are really what keeps me going. And I totally dig my job, it's cool like that.

Patrick: I love it. Thanks so much for coming on today, Kin.

If people want to learn more about you and what you're up to, where should they go online to find you?

Kin: Kin Lane or API evangelist on Twitter.

I'm pretty prolific under both channels. APIevangelist.com is my blog, but Postman.com is, you know API Evangelist, as I said is very much my notebook.

It's a lot rougher, it's a look behind the scenes, but the Postman work that I'm doing on the postman blog, the Postman webinars and those conversations, I have a production team behind me, I have an editor, it's much more polished and refined, and I'd definitely recommend tuning into Postman.com for what I'm cooking up there.

Patrick: Well, thanks for your time today and thanks for all of your work over the past decade.

I know the team at Orbit and a lot of folks in and around Orbit respect, and really appreciate the work you've done. So keep it up and thanks again for coming on.

Kin: Thanks for tuning in, like I said, it's what keeps me going, so appreciate it.

Want developer focused content in your inbox?

Join our mailing list to receive the latest Library updates. After subscribing, tell us your preferences to receive only the email you want.

Thanks for subscribing, check your inbox to confirm and choose preferences!

You've been here a while...

Are you learning something? Share it with your friends!