Subscribe
Share
Share
Embed
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.
When they're applying for these roles
early in their career,
look for the things that you did,
even if they're not necessarily
you know, “I look-
I organized JavaScript meet up.” Right?
Great
if you did that, but not a requirement.
What we're looking for
instead is evidence that you've done
enough of community leadership
and/or organizing and or moderating
to know that you're not going to hate it
as soon as things get difficult.
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, auth, versioning and more.
Welcome back to API Intersection.
We're bringing back an old name today
with a new face.
So sometime just last year
we had Gleb from Nylas on
to kind of talk about the business
of kind of what they did.
Today we've got Ash.
Ash Ryan Arwin?
Say your name for me, sorry, Ash
Ryan Arnwine.
Yeah, I’m the new face.
That part I was afraid to screw up. Sorry.
I usually get the name right in the green
room, but every now and then I forget.
Sorry.
Anyways, we got Ash on.
So Ash tell us a little bit about
yourself and what Nylas does.
Yeah, sure.
So, hi, I'm.
I'm Ash.
I am Director of Developer
Relations at Nylas and I joined to Nylas
about a year and a half ago to bootstrap
the developer relations function.
So now this is an API platform
that lets you put
email, calendar and contacts
functionality into your application.
So folks use this for things
like extracting insights from email
or customizing scheduling workflows
and that kind of thing.
Lots of different use cases
that we could potentially talk about.
But the idea here, of course, is build
a developer relations function
that gets developers excited
and inspired to build with our APIs.
Cool.
You know, fundamentally
now this is kind of an API aggregator
in the sense that you are making a variety
of different APIs easier to use
by kind of providing your own design
interface to it.
And we we covered that pretty well
with cloud before.
I think today is really more just a year
in setting up a different program.
What are the things that you've had
to think about and set up?
And you certainly have
some past experience at this.
I think that's that's the different take.
We'll look at kind of
what's going on at night with us today.
So that's
maybe the first place to start in my mind
is the year ago you came on board
the function didn't exist.
How do you think about
setting up a team to succeed?
Yeah, and luckily
I've gotten a couple of different passes
at walking into a place
that needs Devereaux or believes it does.
And then that's basically
where the sentence starts.
And you come in to start
trying to figure out what that means
when it came
to, you know, where Neelix was a year
and a half ago, we had an awesome product
marketing team and,
you know, great support and sales folks,
lots of outward facing people in general.
But when it came to really starting
to understand, like, what do we need to do
to better enable developers, better
help them understand what it is that we do
have that message connect
and then ultimately help them feel like
they're being taken care of
when they're building on the platform.
There were some aspects of that
throughout,
let's say the sales and implementation,
engineering and support cycle.
But when when
when you start looking at, for example,
one of the paths that we're on at
the moment is getting to
a place as a platform
where it's truly self-serve.
A year and a half ago we weren't.
So you would always have the high touch
white glove treatment from Nike+
when integrating.
And that's amazing.
But at the same time,
that's tremendously difficult to scale.
And I probably don't have to get into why
most of the listeners
here would know that.
So how do you start to build out
developer education
pieces where people can come in and really
without having to talk to somebody
or knowing a phone number of somebody
at Nihilist, if they don't want that,
they can just build?
And how do you ultimately make sure
that they even know
who we are in the first place?
If it's not someone directly reaching out
through some sort of sales mission?
Again, that's
a super valuable part of what we do.
But we also needed to go bigger
and really kind of blow up in the top
end of the funnel,
if you will, to enable developers
to find us and ultimately to succeed
as they started kicking the tires on
what our APIs can do for them.
So those were kind of the open
ended questions.
When I started out about a year
and a half ago,
had tremendous amount of support
from around the organization.
And yeah, we're about a year
and a half into that journey.
So you kind of mentioned like,
you know, this sort of brand recognition
piece and I almost would sort of reframe
that is just building
street cred with developers
is kind of the way I heard you say that.
But I think all of this, what you're
sort of enumerating through in my mind
and this is just from years of seeing
folks go into devel and find themselves in
precarious situations is sort of
you have to justify why the role exists
and why it brings value to the business.
And i thought that was interesting
that you're touching on.
There were customer folks, customer facing
folks before trying to deal with this.
Do you see it that this boosts
the capacity of sort of those support
customer success, whatever other functions
at some point?
Yes, although I wouldn't draw necessarily
a direct line.
You know, if there's a
there's certainly a Venn diagram there
and we'll be figuring out
some of that stuff continually.
But at the same time, like let's
look at it, for example, just like people
knowing that nihilists exists
in the first place
when they have a problem
that we can solve.
One of the main things we really wanted
to focus on early on as a small team,
as a team, kind of getting up and running
even internally at the company,
was focusing more on what can we do
that has the capacity
to be high leverage activities.
And so for example, like
a lot of times
and I certainly had this when I first
joined, we'd be like going out,
meeting different people in the company
and saying,
Oh, so you're going to be our hackathons?
Guy And you know, that's pretty typical.
So I'm used to hearing that as a response
to developer relations in the beginning.
But quite honestly, no, that wasn't
what we wanted to started at all,
you know, And the reason is it's just
incredibly resource intensive and all,
you know, sort of meanings of the word
resource to do things like that
and then to turn around
and prove some sort of result.
It's a valuable activity at some point,
but that's really not
where we needed to start,
where we needed to start was really around
a couple of different things.
One was
we had a sort of
discovery issue, if you will, where
let's just say the organic traffic
at the time wasn't what it could be,
especially for the developer audience.
And part of that just had to do with
we didn't have the content out there.
So really starting to figure out
how can we bring on
some developer advocates
who are super creative, great at writing,
great
to kind of putting their ideas together
and communicating them in a way
that get developers interested.
So we've had, especially over the past
six months, just a tremendous
interaction and partnership
with our SEO team
on the growth marketing side.
And it's been incredible.
So we're just really excited about that.
At the same time, let's say, for example,
a developer
has found us, they know
they want to do something with our APIs.
Maybe they have a use case
and it's one thing to have
marketing content
that speaks to the purchaser persona
or the decision maker,
but it's totally different to sort of
have content out there that would also
help the developer connect with what
the possibilities are inside of our
our APIs to give them some fodder
for things to consider.
So we focused a lot at the outset
on, you know, doing things like blogs,
going out and doing livestreams
on both YouTube and LinkedIn
and ultimately building out
this catalog of live
streams that the developer advocates
have done over time.
Yeah, I, I believe for quite some time
that endeavor all like content's king
get that part right.
Everything else is
nice to have. And I feel like
the kind of COVID
period really kind of killed off
a lot of live events
that have struggled to come back to life.
So I feel like now more than ever,
that's super relevant
because you're talking about,
you know, people
like, good at writing understand
SEO. Like,
you know, workshops,
all this kind of stuff.
It's all content creation, right?
So that's an interesting one
from a skills standpoint for folks
who are looking to hire,
seems like priority one, right?
So I would agree with that.
This is a this is a fun thing
to get to chat about actually,
because like recruiting endeavor
is like such a hard thing to do.
Oh yeah.
And why is it hard?
Well, at first, as a hiring manager,
I get to go on a journey
with the recruiter
that I work with, wherever that context is
and or wherever, wherever the
company happens to be typically, you know,
while you might have recruiters
that specialize in hiring engineers,
because a lot of times you're doing that,
especially in, you know,
maybe the before times it was at scale.
Whereas with several teams,
you're typically not hiring
that frequently.
Not the same
as like in engineering organization.
So that means we get to talk about
talk to the recruiters
first about what is it,
what is it that we're looking for?
My take on this and I know there are
multiple takes on this out there
in the universe when it comes to dev role.
But for me, all other things being equal
without any other data
in terms of what the role is or what
the goals are or anything like that,
what I'm going to focus on
or is what I ended up calling
and pardon me for having an acronym here,
but what I ended up calling the three CS,
which is I'm looking for coding ability.
That one's going to be controversial.
But in, in my situation every time, it's
always been a requirement.
I'm also looking for content
creation ability
and sometimes a track record there.
If we're looking for a senior or above
and also community engage ment experience.
So happy to dive into any of those.
But typically you're looking for
those three things
and one of them kind of coming back
just to, to the events.
Part of the question for just a moment,
one of the things that I found
is really nice
about not having to, let's say,
have that sort of X percent travel
requirement baked into every job
description is that
it makes your hiring more inclusive.
We've been able to bring people on
who quite frankly
couldn't travel
frequently for different reasons.
And, you know, whether it's family
or whatever else it might be
and and that feels awesome.
So because there's a there's a role there
for someone like that who,
you know, there
there are somewhere
we can find the best person,
wherever they are,
in a remote environment.
And then we don't have to like
put them on the road constantly.
And so that helps them kind of like
feel comfortable raising their hand
and saying, Yes, I too can do this role.
Yeah, for sure.
I love the three CS thing
that's actually really simple
and straightforward and makes sense.
So I think we already touched on content
a couple of different ways there.
I guess from, you know, you said coding
is, is one of those which seems
kind of obvious if you're in developer
relations that you got to have something.
But I guess do you look for a particular
sort of spin or flavor or,
you know, I'd imagine, for instance,
you don't want to
go find somebody who spent the last
ten years building some, you know,
stupendous
giant backend for a massive platform
and then go, okay, go write samples
all day.
Right. Like, how do you approach that?
Totally. Well.
And so coding in the context
of also the content in the community
will often filter that, right?
Because one of the reasons I'm
really looking for, even for someone,
let's say they're going to be a new grad,
you can still look for community
leadership
or engagement in some of their background.
Typically, if someone's been spending
ten years building out a back end
and is super deeply expert in that,
if they have tried at all to, you know,
do the content
and do the community pieces of,
you know, chances are
they're going to realize that
that's not what they want to spend time
doing anyways.
So in some ways, having that balance
of these different areas is helpful.
In that way, it helps people self filter,
especially as they start to interrogate
their own background and say,
Well, where is my history of,
you know, creating content in some way?
Whereas my history
of community engagement,
when it comes to the coding piece of it
though, you know, if someone's
like an excellent developer
and happens to want to move into
developer
relations, we can absolutely make space
for that.
I found, for example, in the past
that, you know, people like solutions.
Engineers
can be excellent developer advocates
because they know how to interface
with customers.
They understand what it means to have
a business need for building on an API
so they can be really awesome,
you know, as long as they're fine
kind of going into, let's say,
like the more ephemeral aspects of what
we're going
to need them to do
kind of at a community level.
The other things that we might be looking
for, though, in terms of codes are,
you know, you know, look at your whatever
your API happens to be offering.
And in our case, like,
you know, at Nihilist, we have for SDK,
we've got Node.js, Java, Ruby and Python.
So bare minimum, we'd
like to have coverage on that if we can,
if we're going to be creating content.
And that's all I know.
Jobs, for example,
which is kind of my personal fave
and none of the other
ones, then that kind of sends
a weird mixed signal to your customers
and you want all of your SDK
is being a first class citizen.
So what does that mean?
Well, it doesn't mean that
we're looking for a developer advocates
who are an expert at all languages
because one that's not really possible.
And two,
maybe that's an unreasonable expectation.
But if we can find somebody
who is really good in one area and shows
a healthy amount of curiosity in another,
that might be enough to go with.
And occasionally
you'll just get really lucky like we have
and find, you know, one or two folks
that happen to be like
really into the idea
of being a polyglot developer.
And that can work out really well.
But I would say that like
that would be setting the bar too high.
If that's all you're filtering on.
Generally you're looking for
some depth of capability
in in one particular language or stack
and natural curiosity and ability
to learn across the other ones.
Yeah, So this
sounds like a smart way to think about,
especially if there's SDK support and
I guess community being that third leg,
you know,
I know for me, like I try to always
get a recognition within an organization
that yeah, like customers are important
but especially if you have developer
centric things and open source,
there is a community of developers around
what you're doing that may be customers,
but you have to have a community voice
for it.
I guess
in some cases,
especially if it's open source, it's easy
to go find that track record, easy
to find how they've engaged.
But in other more kind of like, say,
partnership API
kind of things, harder to see that stuff.
So how do you look at gauging
like how successful someone's been,
you know, building communities?
Well, I think it's
going to be a mix of different things.
And I've operated in two
different contexts
of leading developer relations
where the core product wasn't open source.
But that doesn't mean that
we can't do things in open source.
So that's one area
we'll focus on for sure.
But I suppose, like I like that
you called out, for example,
that customers, not your community
necessarily, and that gets so easily
overlooked that I find myself
somewhere in the back of my head.
There's a talk on this
that I just never get around to doing,
but basically exploiting the that
the concept of different
kind of outward facing stakeholders
or sort of external stakeholders.
Right.
So you're going to have, for example.
Yes, of course you have your customers
and they're super important.
You also have a community.
There's naturally going to be
some overlap there.
But just because I think it's
really important to remember that
just because someone's
a customer doesn't mean
that they want to be involved
in your community effort.
Some definitely don't.
And it's important to remember that
and use language that reflects it.
But I would also add that, for example,
there's probably a couple of other areas
that we should be thinking about
that would again have some overlap here.
One is your audience.
So again, what's an audience compared to
your customer base
compared to your community?
And there's an overlapping circle here.
The audience could be potentially way
bigger depending on how you handle
building that audience.
And you know, cultivating it.
The last one I'd probably add
is contributors.
So contributors are in some ways,
I think again, like you could
maybe put them into community,
but to me, like that's just like a special
like next level sort of thing
that you really want to take care of.
And so, you know,
there are things out there
and developer relations
like for example, I've, I've seen the,
the orbit model talked about where
it's like different sort of circles
and people are coming
like closer and closer to the center.
This is a good thing usually.
And that's
probably I like that view of the world.
But there's also
part of me that thinks like
maybe these circles are not all sort of
sort of nested Russian dolls,
if you will, but there may be some overlap
and then some parts
where the orbits kind of
are elliptical, so to speak.
So, yeah,
we can in any one of those areas,
whether it's customers,
whether it's audience, whether it's
community or open source contributors,
measure effectiveness in different ways
depending on what we want to focus on.
One thing, though, and I'm happy
to get into details on any one of those.
One thing I would call out though, is in
both of the companies
I've worked leading dev role
we have, even if the core product
wasn't open source, we have had success
engaging developers through open source
with our own projects in different ways
and you just don't want to overlook
that possibility as having
some way to get out there into the open
source community, even if it's not like
exactly traditionally
what we might think of is as open source.
There's some really good stuff you can do,
and I think
that's something
that all developer relations leaders
and even like folks on
the teams should really be thinking about.
Yeah, well said.
Boy, I feel
like I poked Bear on that subject, man.
You're full
full of great advice is awesome.
Yeah.
I mean, I think like at stop light
you know
certainly like the idea of,
Hey, let's have a podcast.
It's like, all right, but
straight up upfront, very clear,
like this is for the community.
This is not a place that we're doing
product demos
and, you know, doing stuff
customers want to hear.
We have webinars for that
and all those things. That's fine.
But like this is where, you know,
we get folks together
who are in our circle and,
and just share and learn from each other.
I was, you know, still my favorite way to,
to describe a basic
principle of how to approach community
from Adam to vendor.
One of my prior
co-hosts on here is Teach Don't Sell.
Like it's as simple as that, right?
It's just not a place to sell things
when we're doing community stuff.
But I guess bringing it
back again to like looking for
how to build a team to do this.
You kind
of touched on the open source bit,
but what if there is no evidence, right?
What are the kinds of maybe questions
that you're probing out
that tell you
whether or not this is somebody
who's going to be a good community
builder?
Right.
So do you mean for candidates
when you're looking at hiring?
I'm still trying to get three
or three CS there deep CS, So yeah.
Oh, I love it. I love it.
So yeah, I honestly,
I don't know that I've been in a situation
where I could necessarily
get to a place
where someone who had had
no kind of involvement
in, especially as a community leader
of some kind,
I would have felt comfortable
bringing them in.
And that's not to say that that's a hard
truth about developer relations,
but it does definitely speak
to my previous experience.
And so let's let's
kind of blow open the doors a little bit,
though, on what that experience can be.
And at the extreme end, I think, you know,
like people coming out of college
and going straight into developer
relations is a thing they can do.
Now, if we were having this conversation
five years ago, even, maybe
we wouldn't have seen
a lot of evidence of that, surely.
But let's say if you're looking to hire
a new grad, what could you be looking at?
Well, chances are they're not, you know,
probably they're not leading like,
I don't know, New York's
biggest JavaScript meetup, for example.
Maybe they are that be pretty cool.
But there are other things
that we can be looking at
and you're not necessarily looking for.
Like, was it a technical community right?
So you can start to instead
look at different aspects of what
they've been doing, for example,
where they had to in college
or did they have some kind of club
that they were actively involved in
from a leadership perspective?
And if they can really talk you
through that
and have a have a great story to tell,
I think that's important.
The reason
why this matters ultimately is this
A lot of people think they want
to be in community until they're in it.
I think at least I've seen this over
and over again.
Yeah.
You know, and so, like,
this is one of those things where
especially when you're
if you're hiring for a team
that isn't going to be huge and it's
or you're bootstrapping a team,
this is I've done a couple of times now,
you're really looking for people
that already know that
like this is their happy place,
even if they don't, you know, again,
like you could have been
an organizer
for your local soccer club or whatever.
Great.
If you were in college
and that's what you were doing,
and you also integrated JavaScript in to
you like writing articles about plants.
Somehow or another,
all of these things come together.
We, I can work with that as,
as a, as a manager
to get all of those skill sets aligned
for someone earlier in their career.
And so that's what I would often encourage
candidates to consider as well.
It's like when they're applying
for these roles early in their career,
look for the things that you did,
even if they're not necessarily,
you know, I look,
I organized a JavaScript meet up, right?
Great
if you did that, but not a requirement.
What we're looking for
instead is evidence that you've done
enough of community leadership
and or organizing and or moderating
to know that you're not going to hate it
as soon as things get difficult.
Yeah, yeah. It's
this is definitely one of
those jobs that's like if someone goes,
Hey, I think I want to be Devra.
Yeah. You know, this isn't for everybody,
right?
It's a weird, ambiguous thing.
And to your point, like,
community can get messy real fast.
I love that, though, that
in some sense,
you're looking really more for a mindset,
an approach,
and a comfort with the crowd, so
to speak.
Another you know, another thing
for me,
and I'm I'm not, you know, just chit
chatty stuff here, not necessarily
a hard question, but I'm curious to hear
your take is having done a bit of this
kind of hearing myself before,
I'm always looking for somebody
who has that understanding
of how to sort of like hack
a trend, right?
It's like if all of a sudden everyone's
talking about a subject
that, you know, they just go,
Oh, I know what'll get attention on that.
So I'm going to pick on Nikolai Grenier,
who I hired at Typeform
and is still there, as far as I know,
while we were interviewing
and and kind of had like a little lull
between interview people,
I think it was like Slack had announced a
a feature
around form stuff and we're like, Oh,
how's that going to fit in with Typeform?
And I start getting calls one morning or,
you know, messages and stuff
from like our executives
and our salespeople,
all these different people saying,
Did you see this
this thing that this guy built
against this Slack forums thing?
It's so cool
and I'm just grinning ear to ear.
I'm like,
because he went off and built
the thing that got everybody
in the company's attention.
And I was like,
okay, that's it. You got it.
You understand
the like how to jump on something.
People were paying attention to you
anyways and getting some free marketing
out of it.
So, you know, I'm curious
from your perspective that
on this set of weird
soft skills that you're looking for,
is that a thing that you sort of
think about? Yes.
And we're literally thinking about it
this week,
and you can probably
guess what it's about.
We we've had our
developer advocates starting to already
put out content related
to leveraging GPT APIs
inside of, say, for example,
an email integration.
So like the most recent live stream
on our YouTube channel
that our developer advocates
did is around basically
working with the nihilist APIs
to, I believe, send and receive emails.
But ultimately, like when you write
something and then you want to translated
or localize it, you can use GPG for that
and then ultimately send that.
That's something that they're kind
of broaching that topic
kind of a little bit here and there.
But I love that
we're having open conversation about it.
And by the way, for,
for the people that manage teams,
one of the really important
things about this is
if you have content
creation processes
that are on a schedule that we do,
I mean, we ship a blog post in
to livestreams that week, which is a lot.
You've got to, as a manager, make space
for people to have these crazy ideas
and push some other stuff out of the way
to get it out there while it's hot.
And that's something that is,
you know, I'd say
that we're still figuring that out,
but we are actively
we know that that's a thing
that we've got to inject
some more flexibility in our process
and make the space for it.
The other part of it
that's really important in my mind,
it's just kind of the way I think about
developer advocates in general is they're
equal parts
engineer and creative.
Both of these things require
a ton of like time to focus on
deep work, to experiment,
to really get in there
and just be left alone and, you know,
let them play and ultimately
know that when they know
what their sort of schedule
is or their OKRs or whatever else
that they will deliver on that.
But you've got to get out of their way
and let them work.
So I think kind of both of these things
is really important
in your content process.
They need enough space to play with things
as they come up.
Even if you are planning content
two months in advance, which we do.
So that's an interesting balance
that you have to strike.
One other facet of this that I might
recommend folks consider is also
yes to the external trends,
whatever it may be, but also consider that
internal trends are equally as important
with your product, for example.
So one of our developer advocates
has really been focusing
on our new onboarding flow,
which we've just started rolling out
at Nihilist to, you know,
a small percentage of our new signups.
This onboarding flow is super cool
as dreamed up by our product team
and our engineering team
and our designers, which is like
you show up
and you basically select a use case,
say I want to send and receive email in
my application that you pick your stack.
It's like I'm going to do Node in React.
Then on one side
you get a tutorial and live kind of
like you can follow through with the code
at the same time.
Like you can export that code as a repo
and pull it on down and follow along.
If you want to.
So this is obviously
really important for us.
And we've had the Devil team
also super involved in this process.
But what's really cool about it
is I've already seen before
we've even done the full launch
that our developer advocates are using
that internal trends
and taking those little applications
that we can bootstrap for our customers
and extrapolating from there on live
streams already.
And it's super cool.
I mean, it helps us move faster,
but we're also like dog
feeding the experience
and we're just coming up
with like better ideas
with perhaps even like a nicer
UI than we might have on our own.
Well, I'm going to suggest right now
that your three CS needs to be amended
with a fourth C of creative,
because certainly
a lot of what you're touching on there,
I think it's critical attribute
and I totally agree with you
that like makes space to play
and just come up with ideas.
Right.
But I also think here
that you're touching on really this
what I see is is really a more mature
view of developer experience is that,
you know, if you're bringing developers
onto your platform,
there's a whole lot of variables
to consider and it's not like devil's
just going to go master that alone.
There's product,
there's engineering, there's marketing,
everybody's got to kind of
have the shared perspective on what makes
the experience great
for developers, right?
But I'm curious on this topic
of kind of developer experience, are there
other facets that you look at to say, you
know, gauge whether or not it's working?
Yeah.
So currently, for example,
and actually let me start with
just affirmation of what you just said
there, which is, you know, when, when
I joined Naylor's,
we were already starting
to talk developer experience
a high level
and realized that this is something
that we need
to get a lot better at it as a company.
And you know, I've heard
it said in multiple contexts,
not just at Nellis but in other places,
that if you asked ten people
what developer experience
means, you're going to get,
you know, 11 different answers.
And so that
maybe that's not always the worst thing
as long as you're aligned on the outcomes.
Because, you know, to me,
when Gleb was on,
our CEO
Gleb was on this podcast last summer,
he alluded to the fact
that Devex isn't just a team
now in a large corporate environment,
sure, it could be but 150 people
if we're only thinking
about the experience of our customers
in an isolated sort of silo of five
or ten people like that, that's trouble.
And so that's one of the things
he was really working
on engendering across
the company was like, Hey,
we've all got to be thinking about this.
And and so for us, like we,
we look at making sure
we've got an awesome solid collaboration
skill across
marketing and product
and engineering and design
bare minimum
so that we were able to ship products
and ultimately experiences that are really
going to connect with developers.
How we know it's working.
Let's say, for example, in our onboarding,
you know, like you're looking at things
like the ability for developers
to get to completion in the first place
or feature discovery, right?
That's another thing we're focusing on
is just like,
are people
finding our new onboarding experience
and then are
they getting to the end of that and so on?
And so forth.
So I'd say that right now
we're really at a stage where,
particularly for onboarding, where as we
slowly ramp up the launch of this thing,
looking at the numbers
and seeing what we can learn from them.
The other thing that I really like
is we're starting to reach out to folks
that got that experience
and just like offer to sit down with them
and ask questions about it.
Metrics are super important,
but there's something about being able
to sit down with a developer
and kind of really understand like,
what were you expecting?
What are you trying to get out of this?
How did it work for you?
There's just insights
that you're going to pull from that.
So sometimes there's going to be a bit of,
let's say,
resistance to the notion of, oh,
this doesn't scale
sitting down and talking to customers.
But of course, the reality is
we've known to talk to all of them.
But you know, early on
in the endeavor, it's
really important
to try to champion for that.
And I'm really glad that we're doing it
well.
There's kind of a habit to have here
as we get through, you know, 20,
30 minutes of talking about a discipline
or how to, you know, to build something.
And I'm
try to be empathetic to listeners who
maybe haven't done any of this stuff yet.
And they're just going like,
I found this episode because I'm
trying to decide what I should do for Dev.
I don't really know what this is,
and you just listed off a whole lot of
things, a whole lot of activities, right?
And it's like, Oh my God, I'm overwhelmed.
How do you get started?
If you had to go in
and do it all from scratch?
Maybe one of my favorite questions
is how you get started.
So I think a lot of companies out there
definitely approach developer relations
as something they feel like
they might need
but don't totally know
what that's going to entail.
And so one, I'd say approaching
this was an open mind
and talking to practitioners
that have done this stuff is important
because if you know, if your first thought
is let's do hackathons
like I would, I would
submit that you're probably
not exactly on the path to success.
So taking a more open mind about this and
finding folks that can help you bootstrap
this function,
the developer relations
function is rooted in the in the business,
so it can be easy to jump right past
that and move into tactics
and, you know, that kind of thing
that devil does really well.
But you really want to start
by kind of focusing on
where is this business right now?
What do developers need
that they're not getting currently?
And then unpack that into different areas
of responsibility for that team.
So I think really if you're just like,
I think I need this, but I'm not sure
what it is one you really like kind of
do a little bit of the homework.
There's some great books out there.
I'm sure some of them have been mentioned
on this podcast before, but
the business value of developer
relations is a great one by Mary thing.
Well, there's one called Developer
Relations Full stop, I believe,
and it has a number of different authors
on, but I won't turn around and look it up
and you know, I've seen some by slash
data as well that they do a compilation
of essays around developer relations.
But I know it's tough,
but maybe you could ask chatbots to
summarize
some of these things you're interested,
but ultimately get a wider view of what
developer relations could potentially
do to your business and bring on somebody
who is willing to start at that place
and not jump straight into tactics.
And really,
I think those are the two places
I would start
to be quite honest from there.
If you've got a good person who can say,
okay, this is where the businesses
where we need to go and help you define
those areas of responsibility.
After that, it's just unpacking
the tools in the belt for your specific
situation right now.
Awesome.
Yeah, I can.
Couldn't agree more on this one.
I guess.
Like I said at the opening,
and this is just from having
lots of friends
who do Dev Patel full time.
I've dabbled,
but it's never been a thing I've done
full time
as seeing how often they get sort of
feeling ambushed at some point
when suddenly the business goes,
Why did we do this at all, you know,
and just reboots.
The whole thing
from scratch happens all the time.
And I think it's because of what
you're saying is it didn't do step one.
Why does this exist?
Why do we need it, and
how is it going to help grow the business?
Right. Yeah, I love that.
I think for Dev else out there
who don't have that scramble to get it
just for your own job security. Right.
Fantastic.
Thanks so much for sharing.
I think I'm loving your
your brand new forces framework
we just came up with here.
I'm obsessed with this and I think it's
going to make a great accompanying blog
for a lot of folks to kind of quickly
learn how this discipline works.
So thanks so much for for being open
and sharing this with us.
Yeah, thanks, Jason, for having me and
thanks for adding a C to the framework.
I fully endorse that and will be using it
in the future.
Awesome. Creatives welcome
always.
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.
API Intersection Podcast listeners
are invited to sign up for Stoplight
and save up to $650.
Is the code intersection
and tend to get 10% off a new subscription
to Stoplight platform starter or pro.
Take a look at this episode's
description for more details.