Subscribe
Share
Share
Embed
In our latest podcast episode, we spoke with Josh Austin, Director Of Technology at InnovateMR. In late 2021, Austin completed a Brand30 30 Day Content Challenge, producing a month's worth of API-related content for the world. Austin's goal is to introduce the rest of the world, non-technical folks and business leaders alike, to the greatness of APIs.
He shared with me two of his main takeaways from the content challenge. The first focuses on encouraging those who aren't your average developer to be as jazzed about APIs as the rest of us are and creates a little more clarity around the API space. The second piece centers around advice for API fanatics looking to create an API program of their own.
Whether you’re a seasoned developer or a nontechnical enthusiast looking to learn more about APIs, Austin provides a wide array of content on the world of APIs that you can check out on his LinkedIn. The Stoplight API design blog also caters to many of the topics discussed.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
I'm Jason Harmon, and this is API Intersection, where you'll get insights from experienced API practitioners to learn best practices on things like API design, governance, identity, and more.
Welcome back to API Intersection.
Got a fun topic today with another local Austinite.
I don't know if you're actually from Austin.
We'll find out.
Co hosting again is Anna Dougherty, also from Stoplight.
By the way, I'm Jason CTO at Stoplight.
So, Anna, once you give us your little intro blurb and then we'll talk to our guests here.
I'm Anna Doherty.
Like he said, I am the product marketing manager at Stoplight, which if you haven't had a chance to Google what a product marketing manager is highly recommend, you do so.
Agreed.
And I'm Josh Austin.
I am the director of technology at market research company called Innovate.
Mr.
I am not from Austin, but it seems like a great place to be, but I'll take my name as a special placeholder that maybe one day I'll call it home.
Who knows? How long have you been in Austin? I've been in Austin for what, 34 years? I currently live right outside of Providence, Rhode Island.
So we're getting ready to hunker down for winter.
It's a good place.
Well, thanks for joining us, Josh.
This kind of whole conversation about Josh being on the podcast kind of came up because I had seen this sort of 30 day of content challenge that you did, and you kind of picked making APIs more clear or easier or whatever as your topic.
So how did that whole thing start? I think much like, with a lot of things in life, I kind of fell into it out of maybe frustration or just general.
Like, I really want to lick this problem.
So part of my day job is to I live and breathe APIs from a design standpoint and from a technical standpoint.
But I interact with a large number of non technical people, and that really requires some different language and a different approach to do that.
So that's one reason.
The other reason is that I'm noticing that APIs are a really great way to get into tech because I think they say they sit at the cradle of innovation because it seems like if we're going to do anything tech wise, it's going to have an API or it's going to be an API and some interconnectivity.
So what a better way to help people get into tech than kind of demystify and kind of take that edge off of getting into the world? So it's kind of just like peeling back just enough to where you can have those conversations, but not too much to where you're overwhelmed.
So I think it's really a sweet spot to get there.
And I don't know if I've gotten there yet, but it certainly takes reps, as you mentioned, the 30 days to begin to try and like, let's tease out, let's see, how do you actually go about this and the feedback was good, but there's a long way to go in terms of how do you actually get someone ready to have those conversations so that they can either be a part of a product development team for APIs or go into the technical route and implementing them or designing them themselves? It's funny.
It reminds me over the years, I used to sort of bug people for what's your favorite kind of metaphorical explanation of what an API is? I used to sort of collect those to try to find the good ones.
I've forgotten them all because none of them were very good.
Coffee shop restaurant.
Yeah.
I've used the restaurant one quite a bit, and I arrived at it independently, so I didn't like trying to go copy some people.
I was like, again, it's hard to figure out what even spans just the west, like, what goes to what metaphors are kind of global and eating.
We all love that, and we all have restaurant experiences, so it seems like it's okay, but certainly it loses steam after a while.
You certainly get in that deep into the pool, and you're like, we're going to have to start talking a little more concrete here.
All right, well, you two just tease the heck out of the listeners with this coffee shop metaphor.
That must be great.
So you got to share.
How does that one go? Yeah, you could use yeah, coffee works just fine.
Any food that you're going to have either way, at the end of the day, you end up placing an API as the waiter or the waitress that kind of delivers and communicates and acts as your proxy to the kitchen because that's why you're there, right? You're there to eat, but you're getting a whole lot more, and you can have the best food in the world.
Right.
But if your meal is cold or you can't communicate and get what you want, it doesn't matter if you have a Michelin chef or not, it's going to be a poor experience.
And I think that's a good metaphor for APS as a product, because it's not just what someone in their basement codes away and throws up on a Lambda function and calls it an API.
There's a lot more that comes with it.
And I think that's where the API has made clear was coming into it is that there's a lot of people with other skill sets that we really good at helping this part of API development, as opposed to just coding it, which is, I say, just.
But that's a small piece, as we all know of what it's actually like.
So to continue that metaphor, it's like, do you have a good waiter? How's your hospitality, your hostess, your menus? Like, all those things start spidering out and you're like, okay, I think you start getting the picture that a lot goes into making a good experience and good meal for your patron.
Yeah, people will say developer experience.
And I've learned to ask them, do you mean a developer portal or actual developer experience? Because so many places that's the organizational name for the portal builders.
But yeah, in full stop, there's a lot going on.
So I think my particular fascination with this content challenge that you did and really shared really good interesting bits.
And I love that some days you're like the best I can pull off is a quick video.
It's not a full post or anything.
Right.
You got to fill in the blanks.
But my experience has always been that when you try to go share what you know and kind of teach, you always end up learning more than you taught anyone.
So I'm particularly interested to get your introspection on like, what did you learn out of that experience? And what can we all maybe kind of glean from that experience so that we're better teachers ourselves? Yeah.
Well, I would say the first thing I learned is that writing content every day is hard.
So it's not API related.
But when you're really trying to set out to have a good coherent I don't want to say course, but really a path, if you're driving someone down, it takes a lot of time and a lot of energy.
So the number one thing is make sure you're ready.
Make sure you have the space, and make sure you give yourself the freedom to not post 100% content like just to the nines.
And don't get held to a posted day because you probably can't keep it up for a day job, right? Yeah.
I mean, it was part of it.
I did it because I said I was going to do it and I'm tired of letting myself down that way.
So I'm going to finish it.
But I hated posting on the weekends.
It was awful, but nonetheless.
But I think what I learned about in terms of APIs and things like from that small piece of the content, it was really that you've got to have enough experience to where you know what wrong looks like, because you're really trying to steer the reader away from bad practices as much as you are trying to steer them to good practices.
And you've got to find ways to do that creatively because you're really vying for someone's attention.
So that was like the limitation of one of these things with LinkedIn is where I did this series is that you're trying to get the reader to stop.
So that creates it's not always the best learning mechanism.
So I think the other side of that is like venue, the context that you do this stuff in matters as much as the content itself.
So when it comes to APIs, you want someone who has motivated and they're ready to listen and learn and do all those things.
And then you've got to keep them interested and tie it back to these metaphors that they can understand because I wanted to.
I think specifically, Jason, it would be like we have a lot of acronyms, a lot of language that we just regurgitate.
And it's like I joke that I know about APIs because I can spell them right.
I can spell it.
Whoever's coming to this API is made clear that's the number one thing you should know how to do, and you got to want to learn it.
And then after that, it's up to me as the guide through this to help you build on your knowledge.
Who's the audience for your content? Who are you trying to reach? Yeah.
So I'm trying to reach business professionals that are dealing with APIs but don't have that technical background.
But they found themselves in a position of like, I can no longer avoid it.
I've got to understand how these things work or I'm going to be limited in creating good products.
So that's one that's who I rub up against the most, whether it's that we have a whole network of other companies that have integrated into our platform.
So I'm continually dealing with these business leaders and technical leaders.
And the texts, they're fine.
They understand the core components, but it gets tricky when you start trying to explain why should we build this new feature? And that's when the rub comes with the business people.
And then the second persona I know everybody says right for one, but the second one is people that want to get into that role.
They want to get into tech and they want to get into APIs, but they just don't know how.
And it's a really I want to hire more nontechnical people, but it's a tough sell because you've got to have the space and you've got to have the ability to educate them, to make them productive.
So this course kind of goes after the business person that needs some workplace training, and then the College grad or the career changing person wants to how do I do this? You get in there.
It is an interesting call out here, though, that line that you're kind of drawing that we're reaching a point these days where if you're not part of the API economy, as they say, in some fashion, you better work on learning.
Yes.
I feel that in a lot of places, too.
By the way, Anna, you must be snickering to yourself right now, hearing us tech leaders sit here talking about how hard content is.
Well, yeah, that's exactly what came to my mind, is one of the hardest parts of creating a training program is creating a training program.
It's so hard to just get the content out there.
So just making yourself do it every day for 30 days.
I'm sure you are really proud of having an output that reaches people.
Yeah, absolutely.
The feedback was better than expected.
So that was the icing on the cake.
Part of this was really to understand as Jason you mentioned, what do I know? But it's really the next level of teaching when you can translate it locally and whatever that means.
Right.
So I find it to be incredibly difficult but very rewarding.
So I enjoy just being able to go.
I think I got that one or I swung and I missed on another one.
Like, man, this one didn't get any feedback.
I must've not like, did I not explain it well? Or was it, you know, so it just gives you stuff to start tweaking.
I mean, we talk about design, all the stuff you've got to get that down draft to start working with.
So that was my downdraft.
And now I take it back and build version two, so to speak.
And hopefully it will be helpful to people.
These two camps, what was the highs and lows? What did best in terms of kind of engagement and folks wanting to know more? And then what did worse in terms of just landed flat and you thought everybody wanted to know.
So the piece that we got the most engagement or the one that I was proud of was the piece about why do APIs matter? And that almost felt like a justification for my job.
I don't know, that sounds grandiose, but the place that APIs have at the table now, so that felt good.
It felt good that people resonated.
So that means that there's an appetite out there for people to learn more about that.
So that was great.
The piece that did the part that I was surprised by, it wasn't APIs related.
It was about leadership and giving and taking time.
And I was like, man, this is like an essence of leadership and nothing.
So I don't know if it's over saturated on LinkedIn about that kind of stuff.
Oh, yeah.
But then with the piece on API specifically that I want to get back into was, I think it's a understanding.
I don't see, like async and synchronous.
Like requesting response.
Like this idea of this conversation you're having, if we're going to call them digital conversations, actually figure out a way.
For example, I wanted to highlight that we have timeouts in conversation.
Right.
Like if I say Hi to you and you don't say Hi, I'm eventually going to walk away, right.
So there's a time out.
And that same metaphor continues in APIs.
You get a chance to respond to me, but if you don't, I got to do something about it.
So really trying to again, take these concepts that we experience and show how everything in tech really follows the real world.
That was another thread that I was trying to drive home is that if you see something or experience something in the tech work, chances are it's modeled after something earthy and physical because we're just really good at imitating things and copying and pasting as humans.
Don't get me wrong, it's incredible.
But at the end of the day.
We take what we know and we put in other places and we try to iterate on it.
So there's plenty of work to be done.
But I think in the end it was fun to do and I'm not signing up for any more 30 days of content for a while.
I can tell you that you're braver than me in the first place.
I don't think.
I know.
I couldn't commit to it.
It reminds me, though, and I think it's an interesting one for people that are looking to hire and try to figure out kind of who knows something is one of my favorite starter questions for someone in kind of the API space is like, why do APIs matter? What's the relevance? What does this mean to the industry in the world? I don't use it that much anymore because I feel like it must be better now.
But it's funny when I talk to folks like you and that having this experience that I go, maybe I should because there's like a moment where you get it right and people that haven't reached that yet shouldn't be in charge of it, which I suppose goes to hiring and all that.
But I don't know that you want to go there.
What was the thing that you hoped that you kind of touched on, like what people are going to take away from this? But I guess when you kind of started, is it helping get more people into this topic? And what did you hope for in the beginning and did that pan out selfishly? I was hoping to put myself out there as someone who knows something about APIs, to be quite honest, it's becoming unavoidable, I think as a career move to kind of like take charge of your own career.
And I think these conversations, like some of the examples I've used and some of the stuff in this content, they've been practiced on with real people and real situations, trying to explain things.
So I was like, all right, let's find out how well this kind of works and set up myself as someone who, if you have an API question, let's talk about it.
Because I genuinely enjoy discussing this.
So what I hope to get out of it was things like this where we get to talk to people who are chest deep in the API space, and that comes with more connections, more conversations about this stuff, and I get to learn along the way, right? I get to learn.
It's not just about what I put out there.
It's like, oh man, like this guy, I've read some amazing articles recently about other people doing very similar things, and it doesn't feel competitive because there's a ton of courses out there to learn this stuff.
So it's just like, let's see how this works and try to meet some people along the way.
So I think that's like mission accomplished, but certainly not done there's plenty more to chew.
Let's say someone played this episode for a product manager who isn't API specialized right now, what advice would you have for them to get started on that route? That's an excellent question.
A product manager who basically needs to get API up, they need to get it ready.
First thing is go check out stuff.
The first thing I would do is that you've got to go slow as smooth and smooth is fast.
Because the underlying thing with API's.
Right.
Is that we all are aware that when you ship an API and you produce something, you put it out there, you're essentially creating a relationship and a dependency and a vulnerability between two companies or two people.
Right.
So if you're a product manager, you've got to understand that the actions you take, you can't just change a screen or change the way the colors look or all this kind of stuff.
And these people are going to be okay.
So you've got to get in the mindset of the first job is everything you design first is debris.
Because when you produce an API, you're dictating to other companies how they have to interact with it, what they're going to do with it, how they're going to support it.
So I would say you have to go slow and understand that you have to be really judicious and deliberate about what you ship.
And while the idea of failing fast is important and things like this, but you want to have a good idea where you want to go.
So I don't know if that's very practical, but the first piece would be you've got to read up on what an API is.
And part of this API has made clear things will help do that.
The other piece is to find other people like myself that are in this boat and you can talk to them and understand to get this cross pollination of ideas.
Right.
I don't want to say consultancy, but it's almost like a peer group or API user group of sorts.
Right.
Which there's a ton of flavors for that.
But then it's to really start thinking about the APIs and what relationship am I going to extend to these other companies, and how do I do that? In a controlled way? Because the worst thing you want, maybe not the worst, but a very bad thing to do is go too quickly because you want to go to market and you've realized like, oh, shoot, we didn't do this right.
And now you can't just change the color or the where the button is, but you've got to go get all these other people to reintegrate against your API, which they're not always willing to do, which means you've just now impacted your business revenue flow or stability with that.
So that's something we face a lot in my day job is where I inherited a lot of an older legacy API, and we're trying to bring it up to design first, a new thing like rest, actual rest, and getting these dozens of people that have already integrated to change, that is a significant task.
So a product managers go slow, learn the basics, meet people that you can ask you've been there before, kind of like that might be a recipe for a lot of new hires, but I would just say you've got to go really be really deliberate when you're designing API products.
Well said.
The only other bit I would maybe add to that is like the API is just kind of the connection.
And it quite often doesn't mean that you are changing your business per se.
But understand what the thing is that you're doing first.
And you already mentioned there's a relationship piece.
Understand how that relationship is equitable because of the connection from the API, which I think for a lot of product folks who come from more of an almost business analyst kind of perspective, that's a helpful way to reduce the barrier, because there's this thought that like, oh, it's this technical thing.
I must have to do technical stuff.
And quite often that's not the case.
Right.
We're fascinated by this topic, I think at stoplight, certainly, because this last year or two, we've seen so much that designing APIs certainly has a lot to do with developers, but that is not the whole story at all.
There's so many other people involved when it's done.
Right.
Yeah.
And I think product people are certainly front of mind, especially this kind of API first as a strategy.
And these kind of things are out there.
It's like, well, how do I do that? So I got it through the question, I hear, because that's what we do.
The only thing we do consistently on the podcast is like when folks are thinking about getting into APIs as their company and they don't know a whole lot.
Where do you get started? Like, there's so many moving parts, there's so many things.
What do you think is essential to kind of and by the program, I just mean having some sensible, thoughtful approach to how to build APIs into your platform or your product set, where to get started, man, it's such a thorny, big, messy question.
That's why I ask it every time.
Yeah.
I think you have to work the program from top down and bottom up.
Right.
I think there've been a number of guests on your show that talked about you're not going to get anywhere unless the people with the purse strings understand the value in it.
Right.
You shouldn't try.
Quite honestly, you're going to either get really frustrated, you're going to leave, or you're going to make some people mad.
So I would say you have to figure out a way to have the buy in.
But then, Jason, I think you've used it with the band or Rebels.
You've got to find people that have relational clout within a development organization.
They don't have to have titles or anything like that.
But these are the guys that everyone leans on when it gets tricky, right.
And you've got to kind of find a way for these to meet and work together.
And chances are they are so different that it's going to be tough.
So you're probably going to need this product team in the middle to wrap.
Like, Joel Spokesky talked about development abstraction a long time ago where you've got to make the developer feel like he's the only or she's the only person in the building and all that stuff.
So you got to have a layer that lets these guys implement and design and do these things, but you got to have buy in and you got to have clout to get it done.
But that's like strategy.
What the specifics are is you've got to find people that have already integrated with APS.
Right.
They're everywhere.
So find the people that have already done it and they're going to tell you ways to not do it, because we've all experienced.
Like when you're building an API, you're kind of forcing some practices on the integrator, the consumer.
So you got to find the people that know what's good and what's not good and who can take their good development practices that have gotten them to where they are and apply those to APIs, because chances are consistency.
Don't repeat yourself.
Just not don't repeat yourself.
Don't reinvent the wheel.
Right.
Like we all see, like in a tech space, like, you see the classic example of I get a 200 response, okay.
But it says there's an error, right.
Like that's, reinventing the wheel.
You have a mechanism to do that.
You've just got to know that it's at your disposal.
So you've got to find a way to utilize these people that have good practices, professionalism and things like that.
And they're going to naturally seek that stuff out because they know they don't know enough and they're going to go read how to do it.
But again, you've got to create a safe space for these people to work, to kind of flesh it out because it's going to take a long time.
So I was at an enterprise company and I saw this stuff like this guy and team did it amazingly well.
Right.
But if I were to take those practices and put them on our scale up, it's not going to work.
Right.
So you've got to find some ways to adapt and have a fit for purpose program.
You don't want too much like style guys.
Right.
So another, this is kind of around a way to answer the question.
So I would have top down, bottom up relational clout, and then we call it a playbook.
But it's something for your developers to lean on.
People call them style guides.
It doesn't really matter.
But I chose playbook because it's like every time you're going to go run your API offense.
Here's what you're going to do.
That's enough governance for us.
Now, I've seen Spectral, I've seen the Lenting and all that stuff, and you need that when it's huge.
But chances are you can get away with a lot with just good education and the people that have been burned by bad APIs in the past.
And this is all predicated on hiring.
Well, like hiring, whatever that means for you.
You've got to have a good set of people that are willing to chase this problem down.
I think you made a little point in there that is really useful, because you're right.
This is like the whole assemble the band of rebels try to get by and all that stuff.
It's definitely a recurring theme here.
I like that you said that there's a safe space to do it, and that maybe is the first ask, right? Because it's like you can get a group of people together to kind of kick around ideas on like, how should we be more consistent? Or how would this be productized or whatever.
But if it's completely off the books for too long, it's probably dead.
But I guess maybe the management asking there is like, let this be okay, right? Let's have some time to explore these things and figure it out.
Even if it's not like a full time resource allocation, at least we're allowed to have some time to spend on this.
That's a great point.
Yeah.
And I would say that I would extend that.
So one of the biggest benefits that we've ever had at Innovate is beta partners.
So it's one thing to have a safe space internally.
You need a safe space externally to deploy these things and get feedback that says beta, right? Things will break and they're not going to come Hunt you down.
And we've got some of the best feedback we've ever had through that.
They were like, oh, you're right.
And the other pieces, like the way computing is changing.
I don't know if people have talked about this, but we bumped up against it to how you design your APIs for serverless architecture or serverless consumption.
It's starting to begin to think you might do things a little differently if you're using Lambda or if you're using your son.
And on whatever the case is, you got to have some flexibility there, and you're not going to figure those out until you get some people with real API keys and they're hitting this thing beta.
I feel like it's such a loaded term.
So I always end up calling this, like early access.
But I've told plenty of people, like, if you spend six months a year building up all your API stuff and you launch it externally and no one's ever written code against it, you're probably in trouble getting that trusted group early to say, hey, here's this thing.
This is what we think.
Good.
Looks like.
You tell us if it's not and don't rely on this until we say it's generally available.
It's a dose of good old school product management of like show it around before you commit to it.
Oh, man, that single thing makes such a huge difference.
Right.
And almost like an afterthought of it because if you build it like that whole thing, they don't necessarily show up.
Right.
You've got to entice someone in there to reward them for that feedback and that pain of that early access.
Absolutely.
Pizza and beer can accomplish so many things.
Simple incentives that Amazon gift cards find some small incentive to get that input.
I love it, man.
I think all very practical advice and I love all the perspective from engaging with the community that you've done and can't wait to see more from you.
Yeah, well, I appreciate you guys having me and it's fun to talk about these things and with people who kind of to, like, get it.
You can nerd out a little bit on all the nuance and the difficulty of the space but it's getting better, right? I mean, we no longer rely on the Twilios and the stripes to have good APIs like the tide is rising so I'm excited about it and it's fun to kind of swim in that ocean a little bit.
Congrats on 30 days of content.
That in itself is an achievement.
Huge props.
Thank you.
Huge props.
All right, well, Anna, thanks for co hosting again and keeping me from being too boring.
And Josh, thanks for taking some time with us and we really appreciate all the advice.
Listeners.
As usual, we're all on social media, so bug us if you have follow up questions from this.
And with that, I think we'll call this a wrap.
All right.
Thanks for having me.
Thanks for listening.
If you have a question you want to ask, look in the description of whichever platform you're viewing or listening on and there should be a link there so you can go submit a question and we'll do our best to find out the right answer for you.