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.
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.
As always, your host here,
Jason Harmon, CTO at Stoplight.
And I'm joined today by Shane Hastie all
the way on the other side of the world.
I guess at the end of the summer
they're in New Zealand, right?
Shane
It is indeed coming into early autumn
And Jason, thanks very much for having me.
Absolutely.
So Shane's done a bunch of things
between sort of authoring and consulting
and all sorts of stuff.
So I guess
tell us a little bit by yourself.
I don't think I can
do a good job summarizing.
Okay.
Well,
40, 41 years in
information technology
now, I did a long, long time ago
code in assembler and COBOL
and on punch cards.
I do remember doing that
fairly early in my career
and shifted into working
with at that stage it was called end user
computing, working very closely with
with the customers, with the
the people who needed the data
and making that available
in, in a self service type way.
Early dashboards or early reporting tools
and so forth, working very,
very much on large mainframes.
Then I was in the right place
at the right time.
And for the PC revolution in about 1919
8384, the company
I was with, a large financial institution,
purchased the third personal computer,
the third IBM, P.C.
in South Africa.
I was a New Zealander by birth,
but I was living in South Africa
at that stage and they put it on my desk
and said, See what we can do with this.
So I was incredibly
fortunate to get into that
desktop
computing era right at the beginning.
Ended up running my own business in South
Africa for ten years, actually 15 years.
It went on for selling airline back office
technology, back office systems
for small to medium sized airlines,
which involved traveling around large,
large parts of Africa to a lot of
very small, very strange airports.
But it was an interesting time
and some some great customers,
some great experiences there.
And also
even at that stage was was very heavily
focused on the
the interface between customers.
Consumers uses
horrible term and technology development.
The people who are building the building
the products
that these that these consumers consume.
Yeah.
The only other domain where we talk about
user is drug addiction.
So this just it's just something
wrong here and I feel badly I think.
There's a Tron joke in here somewhere.
User Yeah, and
when you hear a lot of technology
folks talking about the user,
there is a bit of a sneer in it,
but they're not the users,
they're our clients.
They are designed to approach the,
the people whose lives
we impact by the products we make.
And I think as a community
we need to get better at thinking
about the impact on people's lives
that we make because the things
we do have a huge ripple effect.
So then I came back to New Zealand
and in the mid-nineties
settled in here, worked worked on again
product development from an I.T.
IT product perspective, building products
that we were selling
and installing all around the world
got a little bit burned out and tired
and moved into a role of teaching
what I used to do
and still continuing to do a more as a
as a consultant and
and now an instructor and have been doing
that for 15, nearly 20 years.
And it's been it's been good fun.
Nice.
See, I told you I couldn't
possibly summed it up. I
one thing that,
you know, I was particularly excited about
today is seeing that you've done
quite a bit of work around
kind of transformations that companies
which certainly is a
a hot trend of failure, as I like to
call it over the last few years,
in that if people fail at this,
you know, and obviously in the API
community, you know, you can't have
a real sort of digital transformation
without APIs being at the core of it.
And we've certainly heard
from practitioners over and over again
that the biggest challenge to these kind
of larger company transformations
is the culture change that goes with it.
And I feel like,
you know, this is an area that you're,
you know, as
you just stated, have plenty of time
and so curious to hear, you know, kind of
what are some of the high points
that you look at for, you know, the signs
that this transformation might just work
if they're doing things right.
The the buzzword is a growth mindset.
Does the organization as a whole
have the the cognitive capacity
to consider new ways
effectively at a leadership level?
Are people curious or are they entrenched?
You know, I've worked with a number
of organizations where the transformation
incentive is coming from the top down.
The chief executive,
somebody very senior, wants this.
And very often the their direct reports
understand the value of it.
But it's almost to make them different
as opposed to help us change.
And and any culture transformation
has to be led from the top
and driven from the bottom.
So it's a it's top down, bottom up.
The we talk about the frozen middle.
They exist.
People whose careers
career success
has been about working in the old way.
And now we're asking them to change
and often what the organization doesn't do
is is put in place
the structures, the incentives, the
the tools for these particularly
the middle this middle management group
in large organizations
are the ones
who really are often left behind.
They often feel threatened by the changes,
know people at the top
know why they're doing it.
People at the bottom are excited
about being able to work
perhaps more collaboratively.
Cross-functionally
But these people in the middle
are actually threatened by this stuff
and sometimes with good reason.
You know, the
large consulting firms
come in and say, Yeah, we're
going to transform your organization.
And as part of this,
we'll give you a 30% cost reduction.
And the way they do that is by getting rid
of large numbers of people.
And typically it's in this middle
middle layer.
So it's in their interests not to change.
We have to find ways to make the change
valuable for these people.
They're intelligent, responsible adults
who genuinely care about the people
that they look after,
about the organization
they're in and about their own careers.
So how do we position
what needs to change in the transformation
in ways that are going to be valuable
for these people?
And if we can do that,
they become your strongest advocates.
If we get it wrong,
you're going to hit the frozen middle
and you're going to bounce.
And sadly, the statistics
tell us that 70% of these transformations,
whether we're saying digital
transformation, agile transformation
or whatever, 70% of those fail,
and that's a huge waste of human potential
and a huge, huge waste of money.
Yeah. Yeah.
It's funny, there's there's a couple of
things, you know, from the API world
when you were
talking about, you know, the exact soft
and you say they know
what they want to do, but it's like
what exactly
it means quite often is like, well,
I read somewhere that, you know, like do
API is good, things happen, right?
Like let's transform
and be an API driven platform
because I read that
in a Harvard Business journal
and it's like, Well,
do you know what that means?
Like, how is that going to change
your business model?
Like, do you think about those things
a lot of time?
So I certainly see that.
And then I couldn't help but plug
in one of my favorite quotes ever from,
you know, the idea for perhaps
infamous Grace Hopper write Most dangerous
phrase in the language
is we've always done it this way,
which, you know, we
certainly in working with our customers,
see this sort of thing like you have
a pocket of the band of rebels, right?
The resistance
that's trying to change things.
But it's like, you know, if you
I love your perspective that, you know,
if bottom to top folks don't agree
that it's time to change something,
it's going to be hard to turn the corner.
Yeah. Yeah.
Very interesting from kind of a,
let's say, product development practice
side of things.
You know, are there kind of aspects there
which, you know, certainly
I mean an API is just
another chunk of software, but you know,
are there sort of cultural facets
there that you see in the highs and lows?
One of the biggest predictors of success
in my mind is the ability to shift from
silo based
thinking to value streams and products.
So getting away for from from project
based work where we're handing work off
between different groups
to true cross-functional end
to end value streams and buy into.
And I literally mean that the it's not
it goes beyond the you build it you run it
it's starting with the product
initiation thinking all the way
through to customer support
and and sales so that the value stream
there is ownership across
that whole value stream that in my mind
is the, the big predictor of success.
If we can get that
and this is it's a structural shift, it's
a cultural shift, it's a behavioral shift,
There's a whole lot of things
that need to happen
for this to to become possible to
to shift to a culture of continuous value.
If I can quote the subtitle of my book.
Yeah, I was going to say you got the
the No projects book out there
that I learned about in
and kind of reading up before the show.
So that's on my list
now. That seems interesting.
I'm curious,
you described
a whole lot of roles in there
that, you know, this more pervasive
ownership.
I guess I'm curious, like,
does that tend to kind of most change
the product management role
to sort of have a broader purview
of those things and like how they're
bringing things into the organization.
But product
management absolutely needs to change.
Product management needs to actually
become product management.
In many organizations,
the product manager is an order taker.
The product owner is an assistant.
Yeah.
If we're going to talk about owner,
then they must own
not just the product
but the revenue, the profits, the
the costs so that they're
they truly understand this,
what this thing is and how it contributes
to the organism, to the organization.
So, yeah, product management widening
and having that that bigger picture.
Now ideally product managers
truly understand the market.
They are in the technology
adoption lifecycle where it where
as their products their target audience
in that they need to understand the
the market phases that their product is
is working in as well.
They need to have at their fingertips
that the various tools you know
things like design thinking techniques
and ideation tools and so forth.
But they also need to understand the
the technical aspects of implementation.
They don't need to be
experts at that level,
but they need to have access to experts
that they trust and that work closely
in collaborative with them.
So the the interaction, the
this idea of a truly cross-functional team
who have all of the skills
needed, who collaborate effectively
and can deliver value
and can remove obstacles for themselves.
Now certainly reads like a description
of how to enable team autonomy.
Yeah. Yeah.
Which I suppose is the the best outcome
you hope for in those kinds of changes.
Interestingly, just said the, you know,
drilling a little bit more on the product
manager thing, like in the API community,
we've seen a big rise in
I think kind of the one just the idea
of an API centric product manager.
But more importantly than that
is that they're they're taking
a more active role
in designing the APIs themselves
in defining what the kind of taxonomy
or grammar across the company is,
or at least leading that in conjunction
with engineering leadership,
but particularly curious on this,
like this idea that you should have
a picture of the whole platform as you
envision it to be in some sketch format
before you really dive
into any big investment in it.
And I'm yes, I'm curious like I know
APIs aren't your thing per se, but like,
is there a sort of an analog
to that organizationally on
how to paint that sort of bigger picture?
Yeah, yeah.
But on one level,
what is the organization vision?
But then what is the product vision?
What will the change be in the world
when this product is in the hands of many,
many people
and it's having a clear, clear
understanding of the why.
Simon Sinek start with
why put your why right in the middle.
If you've got a compelling why the how
and the what will figure themselves out.
If you've got a group
of highly educated, highly motivated,
cross-functional people who understand
why we're doing what we're trying to do.
They've got access to the tools,
they've got the skills,
they will figure this out.
Yeah, and we have in developers, testers,
these are people who are professionals,
soft problem solvers.
Absolutely. Give them a good problem.
Yeah, exactly.
Well, it's like a thing
we say in product management, as you know,
especially in Agile, right, is like,
what's the story?
But somehow people look at that as like,
you know, give me a list of requirements.
That's like,
yeah, you know, in my book I'm like,
If you don't write a detailed story,
I don't care.
Land the story, right?
Like, why is why is it exciting?
Why do we believe this is going to
matter for customers?
Right?
I think what's made
harder in the API
space is the head listing, right?
Yeah.
So quite often,
you know, we see like techniques
like business capability modeling,
trying to sort of
create this picture of here's
all the things that we do as a company,
which, you know, my experience is often
enlightening for executives.
Like we have a.
Vague idea of what we do,
we know how we make money roughly,
but you know, the plumbing of all
that is like a mystery, right?
We have to trust engineering
and they feels like they're always lying.
So I guess I'm curious
that sort of business capability view,
is that something that you've seen
and as part of these transformation.
Business capabilities,
but also really important to think deeply
about the you're right, API is a headless
there are still customers.
That's right.
What is the impact we're going to make
on the lives of these customers
through the availability of the API?
And if we can't figure that out,
we just never going
to solve the right problem.
And what's the value proposition and tools
like the value proposition canvas
really useful
because there's no need for a user
interface and the value proposition, it's
what is the what is the customer problem?
What is the customer's job to be done
is another one of those tools that
will help us understand the the needs.
How will we measure success?
How will we know that
that thing has worked for this customer?
How will they to
how will they tell us what are the
so the metrics is it
is it the pirate metrics?
Is it okay? RS Whatever.
But do we have a clear understanding of
how will we measure success?
What are the quality elements
that are going to matter?
What are the ethical elements?
Yeah, it's funny.
I think the thing I've probably said
the most over the years, some people
go, you know how to how do we manage
API as, as products manage the product?
It's just another product, right?
It just looks, smells,
feels a little different and it has quirky
customers, right?
There are developers there a little, you
know, a little tricky to get on your side.
But once you get there,
you know, it can really grow fast.
But yeah, don't forget the fundamentals
for sure.
Mean, people
sometimes go, what's the success measure?
Well, then people call it a lot.
Well, what does that matter?
That might just be costing you
a lot of network,
You know, cloud costs or something, right?
Like, did it actually make any money
or did it
have some positive network effect
or whatever?
Yeah, Yeah.
There's this weird thing that I think,
you know, we certainly see it a lot.
I've seen it a lot.
My career helping with seeds, these sort
of transformational efforts.
Is this like you have
sort of the technology strategy
that folks are looking and I call this
like the the MIT school of thought.
It's like, how do we create this
distributed modular system
with reusable things and engineer types?
Go Yeah, of course.
Like that's just let's dry
things up, right?
But then on the business side,
sometimes it's like
if we do API stuff,
then we can transform into a marketplace
and let's think about how, you know,
marketplace dynamics and network effects
and all that stuff works.
And then when you put those strategies
together, it's just like they're
two different things and no one talked
about how they're going to fit together.
So I'm curious if you see this
kind of like disconnect between
sort of technology
and and business strategy and these things
constantly.
Sadly, yeah.
And part of it
is the structure of our organizations,
because the incentives are different,
the reporting lines are different,
and they come together up at the top
of you somewhere.
But the people that people down the bottom
haven't had those conversations.
So the way to overcome it sounds trite.
Have the conversations
to get all of the people in the room
or on the on the call
and make sure that the the
why is well communicated
and then get the different
stakeholder groups from technologist
to customer support to sales
to marketing to even things like h.r.
And finance, get them all in the same room
and talking about
what would it mean to us to do this?
What are the potentials
and then prioritize?
Yeah.
What's the first small step?
What's the experiments we can run
that are going to tell us
whether we can even do this
as an organization?
Yeah, definitely recreates like,
you know, in what we do at Stoplight,
it's like we're, we're helping
folks like design
something
before they actually implement it, right?
Because that's, you know, good.
But we often say like left of us
is probably a marker board
with a small group of people
who have great influence.
Ignore the org chart.
Yeah. Right.
That's
what's going to produce great design.
And I feel like that's a part too,
that folks fall into is
trying to envision
the future in today's siloed constraints
rather than get
the people who have brought influence,
domain knowledge and a passion
for the subject and just have them talk
with you.
It sounds trite sometimes,
but we heard over and over again
from sort of API centric consulting groups
that go, Yeah,
we get ten of the right people in the room
and we don't even leave with anything.
It's just a marker board picture and
it just sparks all kinds of stuff, right?
Yeah.
See, I couldn't agree
more on what we see on that side too.
I'm going to totally change
gears here and it's, you know,
this is more just in in
gathering up
sort of some details on before the show.
There is one thing
that you sort of shared with us
that software is a creative
art more than a mechanical process.
And I just got to tell you,
it's like music to my ears.
But tell me more.
I I've been involved and writing code
since 1976.
I wrote my first piece of code.
I was at high school.
The school had a teletype terminal
into an Olivetti
mainframe, and I wrote code
that was recorded on paper type.
And then you ran it through this paper
type reader.
So it was that old technology.
But I was
I wrote code and I've continued writing
code up until about 2017.
So I'm not absolutely current
in terms of code writing, but I've seen it
and I,
I work with technologists all the time.
And what I see is that these are highly,
highly creative people,
but the way they express
their creativity is through
the discipline of code, the
the beauty of well-written programs.
It's it's amazing. It's it's something.
And what's really interesting,
you know, you've got things like copilot
now where an API so an unknown API
where an API tool is generating stuff.
But that's great because it's taking away
the mundane things.
What that does is it frees up
the creative mind of the programmer
to really build that.
That piece of art
is a well-written piece of code
that solves a user problem,
that solves a customer problem,
that that makes an impact in the world
is a thing of absolute beauty.
Yeah, I couldn't agree more.
You know, I was just kind of explaining
in simple terms to folks because I'll say
like, yeah, developers, designers,
whatever, like the creative disciplines,
and they're like, Whoa, whoa, whoa,
we are computer scientists.
That's like, let me ask you this.
If I if I grab ten engineers
and then give you a problem to solve,
do you think I'll get
any of the same solution out of those ten?
I mean, assuming it's not like,
you know, add one and one, right?
Anything with any complexity.
Let me get ten solutions.
You get 12 solutions.
That's right.
Yes. 14 poses and. Yeah.
Yeah, exactly.
Yeah, yeah. So I guess I'm curious.
Even if we go to the definition
of engineering,
engineering is the creative application
of science for the benefit of humanity.
It's the creativity.
Now there is a science,
there is a science or computer science.
We've got those, those scientific rules
we can build on.
But it's the it's
the creative application of that science
that makes change in the world.
Yeah.
I mean,
it's funny because we look a lot like the,
the discipline of user experience
and kind of what it's really become over
the last 20,
25 years and trying to look at it,
designing something that doesn't have
exactly like it's
kind of a human interface,
but it's kind of a machine interface
with API and trying to think about this
sort of, you know, developer experience
as being an emergent discipline too.
But if I looked at user experience,
I'd say there is absolutely science
in that work, right?
Any good user experience designer
isn't going to tell you
I did this because it felt good, right?
It's like, no, it's data backed,
it's been researched, it's been surveyed.
So I guess I'm curious like,
do you see this sort of that,
that designing things for developers
is sort of a
in some ways a weak spot, broadly
speaking, because of the way
that this sort of scientist
oriented mentality is taught.
I think there's a definite gap in on info.
Q We've been doing a lot of
publishing, quite a lot of stuff,
and that you can there have been
another number of conference talks
about the developer experience,
and we're seeing this coming out
over the probably the last four years.
There's this, this emphasis on developer
experience and removing friction
in the development process
and making things easier
because if we remove those distractions,
the creativity can come through.
If you my wife is an artist,
she did the paintings that are behind me
and the carving.
If she's going to be creative,
she needs a quiet space.
She needs uninterrupted time.
Nothing is different to the developer
who's
trying to figure out how to solve
a difficult technical problem.
They need the quiet space and they need.
Number one, developer productivity hack.
Check their calendar.
Yeah, right. Yeah.
Tell them.
Tell them there's meetings they can skip.
Yeah, Yeah.
With you.
All right,
Well, I think we feel like we've covered
the edge of the edges of this pretty well.
This is a huge topic and trying to do it
in a bite sized chunk here is difficult.
But any sort of,
you know, closing thoughts or
you know what I usually kind of ask
folks here is like, you know, for those
who haven't gone down this road,
there's a lot of things
we mentioned, a lot, you know,
can sound really complex and intimidating,
like how do you get the ball rolling?
You know, where to get started.
Both okay, I want to do the same.
This shameless self-promotion
and Say is a book by Shane
Hasty and Evan Laban has no projects.
It's available as a free download
from info queue or you can get the dead
free version on Amazon.
It's so that gives us our philosophy,
I suppose you could say around around
this.
The the why of moving to value
streams is a big part of that.
And really one of the biggest shifts,
the most
I think one of the most valuable shifts
you can make is that starting
to to at least think and work
in, in the collaborative
cross-functional value stream way,
even if the organization is not formed.
These we call them Bender Rebel.
Yeah.
Gang of rebels.
Thank you.
Beautiful way of putting it and
just figure out how to do that effectively
and then genuinely start to think about
what is the impact that we make
on the world, what is the impact
we want to make on the world,
and how can we do that?
And I want to put in an ethical and safe
way. Hmm.
It's funny, it occurs to me
one of the things that we've heard
quite a few times when asked this question
on folks that are in that kind of API,
you know, core of this transformation
in a lot of places is start with empathy.
And I think that's really across
the course of our discussion.
What you're saying,
right, is like, treat those people
that you work with like human beings.
That's a good start.
But also remember that the customers
using these things are humans too, right?
And, and yeah, I think I'm with you
that like the craftsman's mindset.
I would say like
if I'm going to make a chair
and give it to somebody, I dream that
that person will give that chair
to their children, right?
Yeah.
That has a long lasting impact
about something they really care for.
So yeah, start with empathy.
I love it.
Perfect.
Shane, thanks so much
for sharing your experience with us.
We really appreciate it and just thanks.
Jason. Thank you so much for having me.
I really enjoyed the conversation.
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.
Use the code intersection
ten to get 10% off a new subscription
to Stoplight platform starter or pro.
Take a look at this episode's
description for more details.