Subscribe
Share
Share
Embed
To subscribe to the podcast, visit https://stoplight.io/podcast
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/
--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.
Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro). Valid until December 31, 2022
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.
API Intersection
Podcast listeners are invited to sign up
for Stoplight and save up to $650.
Use the code INTERSECTION10
to get 10% off a new subscription
to Stoplight Platform Starter or Pro.
Take a look at this episode's description
for more details.
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,
versioning and more.
Welcome back to API Intersection Podcast.
Got some, some new friends on today
and you know,
we've had a few folks on like this
where it's like we're not saying,
you know, hey, we've mastered the world
and we have these really cool APIs
you use all the time.
But more of, I think kind of the,
the internals of like,
you know, how to build things out
and you know, somewhere along the journey
and I personally love these stories
because, you know, certainly for us
Stoplight, but I think just my personal
fascination in general is like, you know,
what does it take?
What's it like
when you're when you're in the mix of it,
having done that self a few times? So
I'd like to introduce our friends
from CarMax, Brandon and Erin,
I guess maybe Erin
first tell us a little bit about yourself
and then hand it off to Brandon.
Sure.
I'm excited to be here today.
I love API.
I feel like I've been doing API since
I was out of college some 20 years ago.
I've been with CarMax for three
and a half years.
That whole time as a solution architect,
I've split my time kind of at CarMax
between API and some other team work
across the enterprise.
A lot in the payment,
the digital payments space as well.
So I now, or probably not as much,
but I know quite a bit about payments
and them.
I've also been working
in the consumer finance space
for about a year with product
heavily in that space too.
And then prior to CarMax,
I was with the government
space and government contract ing spent
almost ten years
with National Science Foundation
contracting there
and really building out
a set of domain based API.
Starting to hear
about 40 when I left to help
build the
future for at least couple of applications
there.
Applications like everyone who has 30
plus year
old systems are tightly coupled
in many different ways.
So trying to build this API
after at least coupling
government work.
So Erin’s good at the rules.
That's what I hear.
So that's my background.
So what about you?
Yeah, that's awesome.
So I've been at CarMax
a little over 15 years,
pretty much straight out of college.
I started as a programmer
on internal corporate apps,
and then I moved to our web team,
CarMax dot com team, and that was great.
I worked on a number of things there.
Search the first rest ish.
Jason APIs behind our iOS and Android
apps, which is a lot of fun
online financing, things like that.
I moved to be the tech lead on redesigning
and replatforming CarMax dot com
and getting it out of on prem
and into the cloud.
And so big focus on you, you know, service
architectures, use it using platform
as a service, stuff like that.
I was a technical product manager
for a little bit for a team
that really helped teams
focus on moving fast, high quality.
So helping them release on demand
and getting some
of our first APIs out into the cloud,
which is pretty cool.
And the past two and a half years
I've been an enterprise architect,
so business architecture, domain driven
design, stealing things from TOGAF
and helping teams get aligned on, you
know, big tech initiatives and programs.
Nice.
Yeah, it's a I met the CarMax team
a couple of months back, and
I guess it was probably in the spring
where you guys have this sort of big
like internal DevOps day kind of thing
and talk about all the things we did
sort of a like private company event
and give a talk there on like product
managing APIs.
It was really interesting, you know,
I think these days it's like, you know,
I tell folks like stop by its biggest
customers, make electrical parts
and sell beer. Right.
Like APIs are everywhere
and it might not be evident to anyone like
why the APIs matter at CarMax
and you know, having like a big event
and committing time to this stuff,
you know, how is this important
to what you guys are doing?
You mean DevOps days specifically?
I think DevOps days,
you know, APIs as a topic, just, you know,
what's kind of the role that I don't know.
I guess I don't want to be too broad
and say the role
that technology's playing right
now, but, you know,
bring it down to a two hour crowd.
Yeah. Now it's good.
I mean, from my perspective, you know,
one of our executives
said, you know, our technology
strategy is our business strategy. Right.
So how do you make sure that
like as we're scaling, like we've started
with, you know, a handful of product teams
and we move to dozens of product teams.
So as you do that, right, it's
just it's harder to keep everybody aligned
and focused on the right things
and still able to operate
as quickly as they can,
you know, given their mission.
And so
events like that really help, like, hey,
are we all pointed at the right thing?
And when we think about APIs,
like what's a good API
and how do we work together on
some of these things that require
lots of different APIs
from lots of different teams.
So it's great to have things like that.
Just keep us all focused.
Yeah, it's it's something,
you know,
especially in like smaller startups where
I've spent a good chunk of my career,
us kind of to remind folks like
just take some time to think big, right?
Like, yeah,
that time investment is so worth it
when you're, you know,
you get sucked into the day to day
and just can't think big.
So I love that.
So in our kind of show notes and I guess
pre discussions, Aaron, it sounds like
you've been doing some things around
kind of building this internal community
around kind of this practice of APIs
that's particularly interesting.
And coming from what must be a good rule
making background,
I assume there's some standardization
and things going on.
So give us a picture
of what's going on there.
And yeah, so I joined.
Part of my role is to kind of focus.
I had a lot of like we had about 40 APIs
and they were all rest based API
and I've done the to APIs
to suit contracts and all of that.
A lot of experience there too.
Quick question on those 40 APIs.
Is that sort of external surface area
or is that just in general?
They were in general deliver.
So trying to help like teams think bigger.
So that's kind of
I think one of the things
that I always think
like bigger than your API,
it's like a lot of the empathetic
API design.
There was one of your early podcasts
really focused on that
and that one just fit.
You felt like
sitting up with your consumers
like your of your API, of which most of us
are other teams, other product
teams are consumers of your API. So
we have
an API guild, it meets every two weeks.
So we have a bunch of guilds,
but one of the oldest ones,
in addition to the DevOps one, which feels
the DevOps day we have is the API Guild.
So really trying to bring
teams to the guild to talk about APIs.
I think it's been hard at the beginning.
It was sort of just my team due
to the nature of some of the API
tooling that we had with the Gateway.
I'd say since COVID hit,
more and more teams
have actually gotten engaged.
It's actually been a lot better.
It was really hard to run it
like we had multiple offices.
Some of the product teams
were at a different office.
The technology wasn't kind of meshing,
but now that everyone
is pretty much remote,
it's actually works really well.
We have teams contribute
and when I hear about APIs,
someone's developing
like go knock on their virtual door.
I'll be like, Hey,
I hear you're developing this API
when it can present it.
And I think a couple of teams.
And so I have gotten really good feedback.
They've come early
and they've talked about it
and we say like, Oh, well, here's
how we might look at this.
Our processes, which are asynchronous
in nature, I want to schedule this,
but I'm going to request to schedule it
and the scheduler to go off
and do some things.
What might that look like?
How might the status like
what do we want the endpoints to look like
where we kind of
have not been focusing quite as much
as sort
of like on this fantastical nature.
And I think we're going to probably look
at wanting to help solve some of those.
There's problems.
I really love the ones
where we're talking about
end points and routes
and how people are going to use it.
I do love talking about fields
that they are important.
Like what if you expose this
to five other teams,
what suddenly starts to happen?
So the Guild has been really helpful
to get that feedback
and it's there for teams to use to
if they want the
to just come and say,
Hey, I need some feedback and I'll come.
And so I think that's been really helpful
in our journey and especially this summer,
probably over the past year
then extremely helpful as teams
have gone forward with the API.
Interesting.
I think, you know, one thing
I want to call out, there's
sort of the proactive
aspect of kind of leading
a change like this where you're saying,
you know, I hear that someone's
doing something, reach out, draw them in.
I think that's a thing that sometimes,
you know,
folks try to kind of build hard gates
to force people to engage.
But that sometimes that kind of
just proactive, you know, reach out
can make a big difference.
Yeah, I don't ever want anyone to
no one's ever come to the guild.
I've been like I've had some developers
be like, Well, I have a deadline.
I'm like, That's fine.
You can have your deadline.
Whatever we suggest are just suggestions.
There's no like
you have to make this change prior
to going to production
or just trying to get ahead of things.
And we want to share.
And it's also a great way for teams
to help promote their API
or someone might be in
that meeting and two weeks later
someone's like, Hey, I need this data.
And then they make the connection
between teams.
So it's an enabler of empathetic design,
it's an enabler
of like networking across an enterprise
that's still growing.
And so it's very helpful,
I think, for everyone to attend.
And if the company doesn't have one,
I think fruits just sort one
and see what happens.
So it sounds
then like you all don't really have
sort of a formal review process
or anything like that
and that that this is kind of
where these things are coming together.
And you both have that
funny grin when I say that.
A lot of autonomy.
A lot of autonomy.
Yeah, I think it's it's really
community of practice driven review.
So we have a GitHub repo where teams
are encouraged to submit open API specs.
And then to Aaron's point, it's like, hey,
you can come to the Guild and review
that as a group or we can do it
async and leave comments and get feedback.
So it's been really good.
But yeah, we don't have there's
nobody doing the sort of gladiator
thing for an API, right?
And saying,
you know, that's not going to make it.
What's interesting that we do
so we think about APIs and API contracts.
We also have this like internal
marketplace around events and event
exchange.
So publishers come along, they say, Hey,
I have an event, this is great.
I think subscribers may like it,
but you don't necessarily
have to have
somebody who's going to consume it yet.
Subscribe on the other side and there is a
gate to publish onto that platform.
Just one review gate
in a small group of folks looks at it.
And it's interesting to me
because as much as I
fear having gates in front of things
like it's been great to catch
certain design conversations early
before a team went down this path, like,
Oh man, did you know that
this team had that capability too?
And actually they already are
publishing an event that does that.
So it's I'm always wondering like,
how can we have that design conversation
a little bit sooner when folks
are just starting to think about it?
Yeah, I mean, I think it's interesting
because like this notion of, you know,
gating things are having some kind of,
you know,
mandatory step involved in your
development process to do that review.
I think one is before development,
you know,
makes it a lot
less contentious as opposed to like,
okay, we built this thing,
we're ready to launch and then,
you know, you pump in the brakes.
That never works out well.
And then I think the second factor is,
you know, use the word
like approve, right.
And it's like, I think, Erin,
the way you frame it that like, you know
you know,
I is tell folks working in these roles
like we're here to make you look cool
and make you look like you fit in, right?
So these are all things to help
you do that
and maybe explain
why the things you're doing
could get you in trouble
in ways you don't understand.
But I think hard approval, I don't
really see anyone do that as much anymore.
But I guess I'm curious.
And Erin, you mentioned
like in your guild stuff that this
you know, you use the word syntax.
But I'm curious,
do you guys have sort of standards
that you're sort of sharing or
some sort of style guide or something yet?
Or is this just somewhat subjective
at this point without guides.
We have a style guide.
It is still being written out
as like side of desk.
I try to write as much as I can,
but there are some things
that know is inevitably get in the way.
I think we've hit the major ones.
We hit like versioning kind
of how carmack's kind of listed things
and things.
We've had versioning for your resources,
kind of the big ones.
We had an interesting one at the last
API guild
that I'll probably do a PR
for about around the word certs.
So I see certs and my bigger brain goes
like if we say searches, okay
then I'll see like get resource
or create resource.
And I think people start thinking
the search is actually a noun.
It is isn't
that I'm going to run a search.
So there is this.
So we may put in a note there and say,
you know, you can have the word search,
but I understand you're using it
in terms of it.
And now we're not going to allow you
to have a verb.
So there there
interesting things like that
that we come up with that will like PR
and it's actually all automated.
So one of the great
things is we have a good
developer portal, it's getting filled out.
And so like
if I just check in a quick change,
someone reviews it and it'll be out,
you know, seconds later build out there
for everyone to see and consume.
So it's a living document.
It's never, ever meant to be like
this is written in stone,
make it feel free to change it
and any engineer can go in and
comment on it
at any time and be like, Hey,
I saw this or I know
the query verb thing is coming out.
So we were looking at that the other day
to see what might happen there.
All right, cool.
So it sounds like you're kind of the
curator of standards as it stands today.
Yeah, I love that trick.
By the way, the
if you just plurals a verb, it's a noun.
So that to some extent, though,
it sets the tone
of how you're going to use it, right?
So, for instance, if the context is,
I want to look through historical searches
and use them for something,
well then of course,
like you need a collection thing, right?
Plural. Makes sense.
You just start from that context
in the discussion rather than the actual
act of searching
it. That makes it easier.
But that tactic applies in so many places.
It's so useful
and keeps
you out of everyone
always wanting to make search a post.
It's like
make the hardest thing to do uncatchable.
Thanks guys.
Circling back a little bit to the Guild
thing, you know, I personally have this
like depth of trauma
with standing committees
and lots of talk and no action.
The end, you know,
I hear a lot about guild stuff
and it's
something that I personally have been like
a little anxious about the notion
and I've seen plenty of examples of it
working well.
But I'm curious, you know,
do you feel like you guys are seeing as
this has picked up steam
that real action is taking place
as a result?
I do think so
because sometimes of thought that this is
super helpful.
We climb steps like as you are
engineers have looked at certain things
or they're starting up a new effort.
Someone else will come in and say,
oh, well, this is missing.
It's like this is missing the title holder
or something or a line of business
that it's been helpful
to to catch business things as well.
I found it extremely helpful
to have the debates that are
with people that aren't necessarily
in consumer finance.
Right?
So I'm setting up a new end point
for something that's very finance
that I want to get everyone's input into
to kind of what they think as well
as I'm heads
down in my own business domain,
what if someone takes
a different lens at it?
So that's been really helpful. Yeah.
Yeah. Add
and add to that.
That definitely,
you know, I like the Martin Fowler quote
that, you know, architecture
is all the really important stuff
that's hard to change.
And so I know once we get these
API contracts out there, right,
clients are going to depend on them
and we can't break them.
But I'll say, you know, for the APIs
that have come through,
there's always a change
or a few rounds of change
that I think we would all say, well,
you know, it's not perfect.
Like it's
probably going
to have to change in the future, but
it's a lot better than it would have been
had we not talk together and share it
with clients and things like that.
So I love that we're getting to facilitate
that conversation in the Guild
and we're seeing better APIs as a result.
Cool.
Yeah.
I mean,
it sounds like you're accomplishing
a couple of different things
and you both keep touching on this kind of
sort of peer review aspect
being the highest value thing
there.
And you also use the word kind of promote
their API earlier
and I'm curious
to dig into that in this notion of like
how do you measure
what's valuable about APIs?
And the way I read into that one
is that kind of this, you know,
sharing leverage or adoption
kind of stuff, you know,
are those measures
that that sort of management types
are looking at to see
if API development is is working right or
what does it mean?
I think I think there are some APIs
where there's been we have multiple APIs
that maybe are native to the same thing
and maybe we should coalesce some of it.
Some of that is due to a
lot of how you organize your
your your structure
and then your if your architecture
follows for a and what's that.
Noise level.
I was going to say
see inverse Conway maneuver for more info.
Yeah so some of that
I think it's also
product
teams are kind of like every other team.
They're all doing their own thing,
they've got their own goals
that they're working towards.
And so are other architectural
things that are coming down
that are usually going to be associated
with APIs
and promote in terms of like making sure
it's more of an awareness,
making sure that we can use it to help
get everyone on the same page, say,
hey, we're all going to move to this new,
new thing and start incorporating it.
And here's also why we're doing it.
Not just like, hey, do this, you know,
this is why we need to do it.
Here's explained to everyone.
So it's a promotion to like
get the word out,
get make everything transparent as well,
provide that transparency.
So when a team are not surprised by like,
Oh, I'm now getting told
I have to use this,
like we want to make sure
that everyone kind of spread the word.
And so the guilds are a great way
to just kind of spread the word
and get the the architecture changes
and the API changes out to everyone.
Cool.
So it
sounds like a
lot of this is kind of the abstract design
aspects in terms of, you know, is there
consistency of these interfaces?
But you keep mentioning
architecture stuff too.
So, you know, I'm curious from kind of the
the tooling standpoint
kind of how the stacks built,
is that sort of a directional shift
that's part of this?
Or is there a lot of kind of diversity
in how implementations
work?
Yeah, it's like, can you answer this?
Fantastic.
I'm curious how you answer that, Erin, but
I haven't seen a whole lot of
here's a brand new take on
how we compose APIs in general.
Like I feel like we have a few what we
call internally like Golden Paths, right?
This is sort of the happy path, common way
that we've had success in composing APIs.
But every now and again someone will bring
something new to the group
as it's a chance to discuss that and like,
Well, how do we want to try it?
What's a good way to experiment with it
before you know,
everybody takes it and runs with it,
but it does feel like
it's been more on the design consistency
and then also scoping.
That's something that I think has been
a real improvement
over the past few years as
to Aaron's point, thinking about Conway's
law in verse kind of way maneuver,
well, what is that business domain
that you want to point this API at?
And how do you know
you've exceeded the scope
and kind of gone out of the bounds of it?
Because, you know, we've seen cases
where maybe a team
would take on a little more scope.
And now your backlog coupled
to another team because you're a part
of that feature from then on out. So,
you know, I think those are the two
really big things that we're talking about
and catching in the guild.
And then I guess for listeners,
we keep mentioning this Conway thing,
this is the idea and Aaron
kind of hinted at it, right?
If you
let your organization
define how the software is built,
then you tend to end up
with kind of duplicated effort.
And that being intentional with,
I think, reusability front of mind
that, you know, can we have something
that regardless of how we're organized,
is, is a core capability of what we do.
Well, that's great to hear that.
You don't really have too much of the
tooling challenge.
I know for a lot of places
that kind of mucks up the discussion
with like, you know,
how do we even build APIs, much less
how should they be composed around?
So another bit that I think
is related to this in this notion
of kind of building the internal developer
community around APIs is training.
And it sounds like you're and you've
kind of got big efforts coming on this.
Yeah, it's
been kind of a long time coming.
I thought about how we kind of
got where we've where we are
and a couple of different needs.
We have a great learning
path here at CarMax.
We've heard learning
we have like a certified technology
professional thing
that everyone can get every year.
And part of that learning is technology.
There's great classes that we've offered
in some of our business,
things
that are actually run by the technology.
People that manage those business systems.
And we run like our CDO class runs
through a training rotation
which are basically our
or our associates to join
either right out of college
or 1 to 2 years experience.
We have a rotation through that
and we had a management offsite
last winter and part of
that was focused on APIs and issues
and management's perspective on API.
And one of the ideas was a class
and I thought, well,
this is interesting in this journey, three
and a half years being here at the API
Guild and I'm running our,
you know, our new associates, third class,
I thought maybe it's time to run our
current associates and offer our class.
We've been offering different
skilling programs as well.
And so this fall, sometime
in the fall, probably November
is where I'm thinking right now
I'm going
to run a API class built for associates.
So I've kind of everyone,
I think minimum viable product.
I did a hackathon in February
at Virginia Tech, my alma mater,
and I created this sample
vehicle API design, real simple.
And then I took our our incoming class
for rotations and I revamped their class
for the first time
and made it completely designed
only a really high level rest API.
And then it was hands on design, no coding
and it used to be like mostly coding.
I felt that that was just too much
and there were other classes
that focused on code.
It's a really trying to hone in on design.
And so for the associates, we're going
to run a similar class and we're going to
roll with
it and then come back around
and figure out what needs to change.
Probably 2 hours
and it'll be a little different
since everyone's then coding for a while.
And I do want to have management
take it as well.
So managers love to have that join us
because it is just going to be design
coding necessary.
We're going to have pre work system
like pre designed like come with your
prebuilt designs and we'll talk about them
and like the nuance stuff around design.
And we'll probably also focus on one thing
as well and helps highlight some of that
capability and how that can be built out.
So I think it's going to be exciting
and we'll keep having the class and
and have associates come through it
and management come through it too.
I really hope that they have a few
that attend so.
Well, having been the subject
of having to do these things before,
I can say congrats for
for getting to that point.
It's it's a lot harder
than it looks to put together a curriculum
and also props for putting the stake
in the ground
on like the design centric view of it.
I think it gets people in the right
frame of mind that, you know,
we're designing a platform here.
Building the API is the easy part,
relatively speaking.
I'm curious with, you know, we're sort of,
I think touching a lot on this notion
of being customer centric and design.
You keep using the term empathy
and that's what it kind of means.
And I'm sure customer can be a complex
topic
as to what that really means at CarMax.
But I'm particularly curious,
are you guys doing anything to sort of
engage with folks that are buying
and selling cars in any fashion?
Or is that what really matters in
what you're doing with APIs?
I think it matters all the time.
It's all above the store.
And I think we also view our customers
as everyone like
with our associates that are working
with our customers day to day,
whether they be us, the
service or any anyone else
in our customers.
So I try to sit in on as many discovery
sessions as I can,
even though I'm the solution architect,
because I love learning from them.
And I will take any store, visit,
any, any.
I would love to sell cars for a week.
I can sign up and raise my hand
and and go in there and just learn.
And I think that that is if anyone ever
has the opportunity to learn
from any sort of business aspect,
like jump on board and take it
because you'll never know what idiot
may spark
two weeks from now, two months
from now, two years from now.
And you kind of have made mention
of like terminology throughout this.
And I think, you know, the way I read
when you say like
it's always about kind of that, you know,
it's always about that
end customer is like, you have to be able
to talk in all these different contexts
about that in the same way, right?
So that you're all saying the same thing.
And I can say from having spent some,
some of my early hustle days
working in various retail contexts, when
you're at the counter in the real world,
you know, it's different
than it looks in the system.
And connecting with those folks at work
can make them
most effective,
can have a huge amplifying effect.
So I love that.
So, you know, Brendan,
I know you've been around there 15 years
and from talking to you before,
it sounds like this has been, you know,
to some extent a long term
evolution journey kind of thing.
And Aaron, it sounds like last few years
have accelerated, but I guess as you guys
kind of look back and think about,
you know, let's say we wipe the slate
and we started fresh, like what would be
the most important thing to you?
Where would you start?
You know, this question come coming.
You guys have listened before. Yeah.
From my perspective,
we would just start sooner.
We would do a lot of the things
we're doing now just way in advance.
Yeah, I would have started sooner.
I would have started with empathy.
Like we talked about first podcasts.
I think we would be asking better
questions sooner.
I'd love to get some structure in place
that helps teams
and I don't know what that is exactly yet.
I think we're starting to experiment
with limiting and having some standards
around marketing and things like that.
But really
I think the design focus up front
before we ever start coding has has been
one of the most important things.
And something I'd like to
do, ignore me on that question.
Let Aaron.
Aaron cover that one.
It's okay.
It's okay to say
that you want to do better at things.
There's nothing wrong with that. Yeah,
that's good.
Yeah, it's good.
I think I agree with Brandon.
Everything he said,
I would have started sooner and
and focused on design
things that I thought about this.
And I think the other thing
I probably would have done is
if any company
has the technology of the technology
managing meeting every two weeks
approximately,
I probably would go to that meeting
every six months,
maybe even every quarter,
and stood up in front of it
and just highlighted
kind of where we are with the API.
I think I'd love to.
The Guild is like a bottoms up approach
that I do think there needs to be
an aspect of kind of top down as well,
not like big tech governance
or a little bit more awareness,
transparency, getting the word out.
So that's something
I think I would have done
and I am slated to start
in the next couple of weeks or so to get
back to that board to kind of highlight
some of the stuff that we've been
working on because we had that meeting
and then we've left that meeting,
we've actually gone off and done
some of the things that people have asked
for, which is really good.
So I think any time
anyone has an opportunity
to promote API,
just don't be afraid of, of doing it.
Spearheaded jump right in.
Yeah.
I love that point.
I think you know,
the one start early is like
you know I would say this all the time
I'm here is like if you don't you're
not already kind of buried in API
strategy, you're probably behind
and like that's
kind of the way the world is.
But this notion of you know,
kind of managing up a little bit,
I think, you know,
I always talk about like,
you know, build your band of rebels,
find the people
who like understand the API thing
and, you know, give them authority,
autonomy or whatever and come together,
define some roles and play nice together.
Right? That's all fine and dandy.
But at the end of the day, like,
nobody there controls purse strings
and you need investment in these things.
And quite
often, you know, this Conway stuff
we were talking about
leads you to insights about how
to organize things more efficiently,
and you need kind of a venue for it.
And I mean, it is a topic like a stoplight
that we think about a lot lately.
It's like, okay, great.
You know, we can help people design stuff
all over the place, but
to really move your program forward,
you know that it's still a band of rebels
until you kind of have that anointing or,
you know, really the funding,
frankly, is what it tends to boil down to.
So I think it's a super important point
and I love that you already mentioned
earlier like involving managers
and I would certainly chip in.
Product managers are a great addition
there to to that kind
of education and
and community sharing process.
Good to have a podcast on
and it's a repeated theme here.
API says your APIs are your products.
So I took that one this summer and I did
put it in the product,
which chat that time was then.
It's like here
everyone or managers loves this.
Like listen to it. It's not technical.
Yeah, great.
Yeah.
This, you know, it
reminds me of back when like, you know,
I was trying to explain to people
like, here's how you should build
your architecture with APIs
and all this stuff and take me 10 minutes
just to do the elevator pitch
and then, you know, bright consulting guy
who wants to sell more consulting
like Fowler goes, Hey, there's
this thing called microservices
and all of a sudden it's stuck, right?
It's like just a catchy phrase for
and I think like this kind of API first
thing has really taken hold
in the last couple of years
and folks get really down in the weeds
and lost a little bit on what that means.
And I think that's
the first thing is like, you know,
treat your API as a product
and design it before you build it.
If you do those things, everything else
kind of tends
to fall in place, assuming a lot of things
about how you manage product.
But you know,
in terms of, you know, aligning
business and tech strategy
and you know, there's certainly
a rabbit hole to go down in both of those.
But yeah,
I think there's it's hard to avoid.
Aaron To your point on the podcast,
when we talk to folks like yourselves
who are trying to lead companies
through these things that
that's what's working, you know,
across the board, which has been
a revelatory validation for me
and always
feeling like that was the right way.
So very cool.
Any other sort of closing thoughts
or stuff that you want to highlight
about kind of things going on at CarMax?
Yeah, from my perspective.
So I mentioned, you know, I've been
in the enterprise architecture space
the last two and a half years,
so I'm actually moving into a management
role for a team focused on
digital payments, but also API engineering
as part of our charter,
which I'm really excited about.
So to your Band of Rebels comment,
like I feel like
we've been a really good band of Rebels,
really excited to work together on that.
Now that we have
some dedicated investment,
how can we start to add some good low
friction structures to help teams?
Right.
Congratulation, guys. Thank you.
Appreciate that big first step. Know.
And you get anything?
I don't think so.
I'm excited to see where is going to
take things, but it's going to be amazing.
You'll definitely be leading out
on that with me.
So appreciate it in advance
thanks in advance.
Of thanks so much to you guys for
for coming on and really sharing
you know kind of said at the beginning
of hearing about these kind of along
the journey stories
and I think it'd be fun
and you know a year or two down the road
check back and see where all this is
led and kind of,
you know, what's worked out
and what hasn't and that sort of thing.
Yeah, but love that
cool criteria.
Thanks, Jason.
Jason, 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.