Everyone wants to ‘digitally transform’ these days, and they think APIs are the quick and easy way to do it. But change is never easy, and there are some critical steps to get right if you want your program to succeed. This week on API Intersection podcast, we interviewed Shane Hastie, a Global Delivery Lead at SoftEd and lead editor at Infoq. He has multiple decades of experience in information technology and has worked in various roles, such as authoring, consulting, and teaching.
We chatted with Shane about the challenges of cultural change in company transformations and the need for a growth mindset when it comes to building our API team and program. Let's dive into some common challenges that teams encounter when it comes to change and how to maximize your API efforts to transform successfully.
Check out Shane's book, #noprojects: A Culture of Continuous Value
and be sure to follow him on LinkedIn: https://www.linkedin.com/in/shanehastie
_____
To subscribe to the podcast, visit https://stoplight.io/podcast
--- 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).
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
As always, your host here,Jason Harmon, CTO at Stoplight.
And I'm joined today by Shane Hastie allthe way on the other side of the world.
I guess at the end of the summerthey're in New Zealand, right?
Shane
It is indeed coming into early autumn
And Jason, thanks very much for having me.
Absolutely.
(00:43):
So Shane's done a bunch of things
between sort of authoring and consultingand all sorts of stuff.
So I guesstell us a little bit by yourself.
I don't think I cando a good job summarizing.
Okay.
Well,
40, 41 years in
information technologynow, I did a long, long time ago
(01:05):
code in assembler and COBOLand on punch cards.
I do remember doing that
fairly early in my careerand shifted into working
with at that stage it was called end usercomputing, working very closely with
with the customers, with thethe people who needed the data
and making that availablein, in a self service type way.
(01:31):
Early dashboards or early reporting tools
and so forth, working very,very much on large mainframes.
Then I was in the right placeat the right time.
And for the PC revolution in about 1919
8384, the companyI was with, a large financial institution,
(01:52):
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 deskand said, See what we can do with this.
So I was incrediblyfortunate to get into that
desktopcomputing era right at the beginning.
(02:14):
Ended up running my own business in SouthAfrica for ten years, actually 15 years.
It went on for selling airline back officetechnology, back office systems
for small to medium sized airlines,which involved traveling around large,
large parts of Africa to a lot ofvery small, very strange airports.
But it was an interesting time
(02:36):
and some some great customers,some great experiences there.
And alsoeven at that stage was was very heavily
focused on thethe interface between customers.
Consumers useshorrible term and technology development.
The people who are building the buildingthe products
(02:57):
that these that these consumers consume.
Yeah.
The only other domain where we talk aboutuser is drug addiction.
So this just it's just somethingwrong here and I feel badly I think.
There's a Tron joke in here somewhere.
User Yeah, and
(03:18):
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 liveswe impact by the products we make.
And I think as a communitywe need to get better at thinking
(03:38):
about the impact on people's livesthat we make because the things
we do have a huge ripple effect.
So then I came back to New Zealandand in the mid-nineties
settled in here, worked worked on againproduct development from an I.T.
IT product perspective, building productsthat we were selling
(04:00):
and installing all around the worldgot a little bit burned out and tired
and moved into a role of teachingwhat I used to do
and still continuing to do a more as aas a consultant and
and now an instructor and have been doingthat for 15, nearly 20 years.
And it's been it's been good fun.
(04:21):
Nice.
See, I told you I couldn'tpossibly summed it up. I
one thing that,
you know, I was particularly excited abouttoday is seeing that you've done
quite a bit of work aroundkind of transformations that companies
which certainly is aa hot trend of failure, as I like to
call it over the last few years,in that if people fail at this,
(04:45):
you know, and obviously in the APIcommunity, you know, you can't have
a real sort of digital transformationwithout APIs being at the core of it.
And we've certainly heardfrom practitioners over and over again
that the biggest challenge to these kindof 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 timeand so curious to hear, you know, kind of
(05:09):
what are some of the high pointsthat you look at for, you know, the signs
that this transformation might just workif 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 wayseffectively at a leadership level?
(05:31):
Are people curious or are they entrenched?
You know, I've worked with a numberof 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 reportsunderstand the value of it.
(05:52):
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 topand driven from the bottom.
So it's a it's top down, bottom up.
The we talk about the frozen middle.
They exist.
(06:13):
People whose careers
career successhas been about working in the old way.
And now we're asking them to change
and often what the organization doesn't dois is put in place
the structures, the incentives, thethe tools for these particularly
the middle this middle management groupin large organizations
(06:38):
are the oneswho really are often left behind.
They often feel threatened by the changes,
know people at the topknow why they're doing it.
People at the bottom are excited
about being able to workperhaps more collaboratively.
Cross-functionallyBut these people in the middle
are actually threatened by this stuffand sometimes with good reason.
(07:00):
You know, the
large consulting firms
come in and say, Yeah, we'regoing 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 ridof large numbers of people.
And typically it's in this middlemiddle layer.
So it's in their interests not to change.
(07:21):
We have to find ways to make the changevaluable for these people.
They're intelligent, responsible adults
who genuinely care about the peoplethat they look after,
about the organizationthey're in and about their own careers.
So how do we position
(07:42):
what needs to change in the transformation
in ways that are going to be valuablefor 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 middleand you're going to bounce.
And sadly, the statisticstell us that 70% of these transformations,
(08:02):
whether we're saying digitaltransformation, agile transformation
or whatever, 70% of those fail,
and that's a huge waste of human potentialand a huge, huge waste of money.
Yeah. Yeah.
It's funny, there's there's a couple ofthings, you know, from the API world
when you weretalking about, you know, the exact soft
and you say they knowwhat they want to do, but it's like
(08:25):
what exactlyit means quite often is like, well,
I read somewhere that, you know, like doAPI is good, things happen, right?
Like let's transformand be an API driven platform
because I read thatin a Harvard Business journal
and it's like, Well,do you know what that means?
Like, how is that going to changeyour business model?
Like, do you think about those thingsa lot of time?
So I certainly see that.
(08:45):
And then I couldn't help but plugin one of my favorite quotes ever from,
you know, the idea for perhapsinfamous Grace Hopper write Most dangerous
phrase in the languageis we've always done it this way,
which, you know, wecertainly in working with our customers,
see this sort of thing like you havea pocket of the band of rebels, right?
The resistancethat's trying to change things.
(09:06):
But it's like, you know, if youI 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 practiceside of things.
You know, are there kind of aspects therewhich, you know, certainly
(09:28):
I mean an API is justanother chunk of software, but you know,
are there sort of cultural facetsthere 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 basedthinking to value streams and products.
(09:49):
So getting away for from from project
based work where we're handing work offbetween different groups
to true cross-functional end
to end value streams and buy into.
And I literally mean that the it's notit goes beyond the you build it you run it
(10:11):
it's starting with the product
initiation thinking all the waythrough to customer support
and and sales so that the value streamthere is ownership across
that whole value stream that in my mindis the, the big predictor of success.
(10:33):
If we can get thatand this is it's a structural shift, it's
a cultural shift, it's a behavioral shift,
There's a whole lot of thingsthat 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.
(10:55):
Yeah, I was going to say you got thethe No projects book out there
that I learned about inand kind of reading up before the show.
So that's on my listnow. That seems interesting.
I'm curious,
you describeda whole lot of roles in there
that, you know, this more pervasiveownership.
I guess I'm curious, like,does that tend to kind of most change
the product management roleto sort of have a broader purview
(11:16):
of those things and like how they'rebringing things into the organization.
But product
management absolutely needs to change.
Product management needs to actuallybecome product management.
In many organizations,
the product manager is an order taker.
(11:37):
The product owner is an assistant.
Yeah.
If we're going to talk about owner,then they must own
not just the productbut the revenue, the profits, the
the costs so that they'rethey truly understand this,
what this thing is and how it contributesto the organism, to the organization.
(11:58):
So, yeah, product management widening
and having that that bigger picture.
Now ideally product managerstruly understand the market.
They are in the technologyadoption lifecycle where it where
as their products their target audiencein that they need to understand the
(12:20):
the market phases that their product isis working in as well.
They need to have at their fingertipsthat the various tools you know
things like design thinking techniquesand ideation tools and so forth.
But they also need to understand thethe technical aspects of implementation.
(12:42):
They don't need to be
experts at that level,but they need to have access to experts
that they trust and that work closelyin collaborative with them.
So the the interaction, the
this idea of a truly cross-functional team
who have all of the skillsneeded, who collaborate effectively
and can deliver valueand can remove obstacles for themselves.
(13:06):
Now certainly reads like a descriptionof how to enable team autonomy.
Yeah. Yeah.
Which I suppose is the the best outcomeyou 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
(13:26):
I think kind of the one just the ideaof an API centric product manager.
But more importantly than thatis that they're they're taking
a more active rolein designing the APIs themselves
in defining what the kind of taxonomyor grammar across the company is,
or at least leading that in conjunctionwith engineering leadership,
(13:47):
but particularly curious on this,like this idea that you should have
a picture of the whole platform as youenvision it to be in some sketch format
before you really diveinto any big investment in it.
And I'm yes, I'm curious like I knowAPIs aren't your thing per se, but like,
is there a sort of an analog
to that organizationally onhow to paint that sort of bigger picture?
(14:10):
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, clearunderstanding of the why.
Simon Sinek start withwhy put your why right in the middle.
(14:33):
If you've got a compelling why the howand the what will figure themselves out.
If you've got a group
of highly educated, highly motivated,
cross-functional people who understandwhy we're doing what we're trying to do.
They've got access to the tools,they've got the skills,
(14:54):
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 thingwe say in product management, as you know,
especially in Agile, right, is like,what's the story?
(15:15):
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 tomatter for customers?
Right?
I think what's made
harder in the APIspace is the head listing, right?
(15:38):
Yeah.
So quite often,you know, we see like techniques
like business capability modeling,
trying to sort of
create this picture of here'sall the things that we do as a company,
which, you know, my experience is oftenenlightening 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 allthat is like a mystery, right?
(16:00):
We have to trust engineeringand they feels like they're always lying.
So I guess I'm curiousthat sort of business capability view,
is that something that you've seenand as part of these transformation.
Business capabilities,but also really important to think deeply
about the you're right, API is a headlessthere are still customers.
(16:21):
That's right.
What is the impact we're going to makeon the lives of these customers
through the availability of the API?
And if we can't figure that out,
we just never goingto solve the right problem.
And what's the value proposition and toolslike the value proposition canvas
(16:42):
really usefulbecause there's no need for a user
interface and the value proposition, it'swhat is the what is the customer problem?
What is the customer's job to be doneis another one of those tools that
will help us understand the the needs.
How will we measure success?
(17:04):
How will we know thatthat thing has worked for this customer?
How will they tohow will they tell us what are the
so the metrics is itis it the pirate metrics?
Is it okay? RS Whatever.
But do we have a clear understanding ofhow will we measure success?
What are the quality elementsthat are going to matter?
(17:27):
What are the ethical elements?
Yeah, it's funny.
I think the thing I've probably saidthe most over the years, some people
go, you know how to how do we manageAPI 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, youknow, a little tricky to get on your side.
(17:50):
But once you get there,you know, it can really grow fast.
But yeah, don't forget the fundamentalsfor sure.
Mean, peoplesometimes go, what's the success measure?
Well, then people call it a lot.
Well, what does that matter?
That might just be costing youa lot of network,
You know, cloud costs or something, right?
Like, did it actually make any moneyor did it
have some positive network effector whatever?
(18:10):
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 sortof transformational efforts.
Is this like you havesort of the technology strategy
that folks are looking and I call thislike the the MIT school of thought.
It's like, how do we create this
distributed modular systemwith reusable things and engineer types?
(18:32):
Go Yeah, of course.
Like that's just let's drythings 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 strategiestogether, it's just like they're
two different things and no one talkedabout how they're going to fit together.
(18:54):
So I'm curious if you see thiskind of like disconnect between
sort of technologyand and business strategy and these things
constantly.
Sadly, yeah.
And part of itis 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.
(19:15):
But the people that people down the bottomhaven't had those conversations.
So the way to overcome it sounds trite.
Have the conversations
to get all of the people in the roomor on the on the call
and make sure that the thewhy is well communicated
and then get the differentstakeholder groups from technologist
(19:39):
to customer support to sales
to marketing to even things like h.r.
And finance, get them all in the same roomand talking about
what would it mean to us to do this?
What are the potentialsand then prioritize?
(20:01):
Yeah.
What's the first small step?
What's the experiments we can runthat are going to tell us
whether we can even do thisas an organization?
Yeah, definitely recreates like,you know, in what we do at Stoplight,
it's like we're, we're helpingfolks like design
somethingbefore they actually implement it, right?
Because that's, you know, good.
(20:22):
But we often say like left of usis probably a marker board
with a small group of peoplewho have great influence.
Ignore the org chart.
Yeah. Right.
That'swhat's going to produce great design.
And I feel like that's a part too,that folks fall into is
trying to envisionthe future in today's siloed constraints
(20:42):
rather than getthe people who have brought influence,
domain knowledge and a passionfor 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 groupsthat go, Yeah,
we get ten of the right people in the roomand we don't even leave with anything.
(21:04):
It's just a marker board picture andit just sparks all kinds of stuff, right?
Yeah.
See, I couldn't agreemore on what we see on that side too.
I'm going to totally changegears here and it's, you know,
this is more just in in
gathering upsort of some details on before the show.
(21:25):
There is one thingthat you sort of shared with us
that software is a creativeart 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.
(21:46):
I wrote my first piece of code.
I was at high school.
The school had a teletype terminalinto an Olivetti
mainframe, and I wrote codethat was recorded on paper type.
And then you ran it through this papertype reader.
So it was that old technology.
But I wasI wrote code and I've continued writing
code up until about 2017.
(22:08):
So I'm not absolutely currentin 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 expresstheir creativity is through
the discipline of code, the
(22:30):
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 APIwhere an API tool is generating stuff.
But that's great because it's taking awaythe mundane things.
(22:53):
What that does is it frees up
the creative mind of the programmerto really build that.
That piece of artis a well-written piece of code
that solves a user problem,that solves a customer problem,
that that makes an impact in the worldis a thing of absolute beauty.
Yeah, I couldn't agree more.
(23:15):
You know, I was just kind of explainingin 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 engineersand then give you a problem to solve,
do you think I'll getany of the same solution out of those ten?
I mean, assuming it's not like,you know, add one and one, right?
(23:36):
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 definitionof engineering,
engineering is the creative application
(23:59):
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 ruleswe can build on.
But it's the it's
the creative application of that sciencethat makes change in the world.
Yeah.
(24:19):
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 overthe last 20,
25 years and trying to look at it,designing something that doesn't have
exactly like it'skind of a human interface,
but it's kind of a machine interfacewith API and trying to think about this
(24:39):
sort of, you know, developer experienceas being an emergent discipline too.
But if I looked at user experience,
I'd say there is absolutely sciencein that work, right?
Any good user experience designer
isn't going to tell youI 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,
(25:02):
that designing things for developersis sort of a
in some ways a weak spot, broadlyspeaking, because of the way
that this sort of scientistoriented 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
(25:24):
another number of conference talksabout the developer experience,
and we're seeing this coming outover the probably the last four years.
There's this, this emphasis on developerexperience and removing friction
in the development processand making things easier
because if we remove those distractions,the creativity can come through.
(25:49):
If you my wife is an artist,
she did the paintings that are behind meand the carving.
If she's going to be creative,she needs a quiet space.
She needs uninterrupted time.
Nothing is different to the developerwho's
trying to figure out how to solve
a difficult technical problem.
(26:10):
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 coveredthe edge of the edges of this pretty well.
This is a huge topic and trying to do itin a bite sized chunk here is difficult.
(26:34):
But any sort of,you know, closing thoughts or
you know what I usually kind of askfolks here is like, you know, for those
who haven't gone down this road,
there's a lot of thingswe 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-promotionand Say is a book by Shane
(26:57):
Hasty and Evan Laban has no projects.
It's available as a free downloadfrom 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 valuestreams is a big part of that.
And really one of the biggest shifts,the most
(27:20):
I think one of the most valuable shiftsyou can make is that starting
to to at least think and workin, 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
(27:42):
just figure out how to do that effectively
and then genuinely start to think about
what is the impact that we makeon 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 safeway. Hmm.
It's funny, it occurs to meone of the things that we've heard
(28:05):
quite a few times when asked this questionon folks that are in that kind of API,
you know, core of this transformationin a lot of places is start with empathy.
And I think that's really acrossthe course of our discussion.
What you're saying,
right, is like, treat those peoplethat you work with like human beings.
That's a good start.
But also remember that the customersusing these things are humans too, right?
(28:27):
And, and yeah, I think I'm with youthat like the craftsman's mindset.
I would say likeif I'm going to make a chair
and give it to somebody, I dream thatthat person will give that chair
to their children, right?
Yeah.
That has a long lasting impactabout something they really care for.
So yeah, start with empathy.
I love it.
(28:48):
Perfect.
Shane, thanks so muchfor 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 onand there should be a link there
so you can go submit a questionand we'll do our best to find out
(29:11):
the right answer for you.
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
Use the code intersectionten to get 10% off a new subscription
(29:34):
to Stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
As always, your host here,Jason Harmon, CTO at Stoplight.
And I'm joined today by Shane Hastie allthe way on the other side of the world.
I guess at the end of the summerthey're in New Zealand, right?
Shane
It is indeed coming into early autumn
And Jason, thanks very much for having me.
Absolutely.
(00:43):
So Shane's done a bunch of things
between sort of authoring and consultingand all sorts of stuff.
So I guesstell us a little bit by yourself.
I don't think I cando a good job summarizing.
Okay.
Well,
40, 41 years in
information technologynow, I did a long, long time ago
(01:05):
code in assembler and COBOLand on punch cards.
I do remember doing that
fairly early in my careerand shifted into working
with at that stage it was called end usercomputing, working very closely with
with the customers, with thethe people who needed the data
and making that availablein, in a self service type way.
(01:31):
Early dashboards or early reporting tools
and so forth, working very,very much on large mainframes.
Then I was in the right placeat the right time.
And for the PC revolution in about 1919
8384, the companyI was with, a large financial institution,
(01:52):
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 deskand said, See what we can do with this.
So I was incrediblyfortunate to get into that
desktopcomputing era right at the beginning.
(02:14):
Ended up running my own business in SouthAfrica for ten years, actually 15 years.
It went on for selling airline back officetechnology, back office systems
for small to medium sized airlines,which involved traveling around large,
large parts of Africa to a lot ofvery small, very strange airports.
But it was an interesting time
(02:36):
and some some great customers,some great experiences there.
And alsoeven at that stage was was very heavily
focused on thethe interface between customers.
Consumers useshorrible term and technology development.
The people who are building the buildingthe products
(02:57):
that these that these consumers consume.
Yeah.
The only other domain where we talk aboutuser is drug addiction.
So this just it's just somethingwrong here and I feel badly I think.
There's a Tron joke in here somewhere.
User Yeah, and
(03:18):
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 liveswe impact by the products we make.
And I think as a communitywe need to get better at thinking
(03:38):
about the impact on people's livesthat we make because the things
we do have a huge ripple effect.
So then I came back to New Zealandand in the mid-nineties
settled in here, worked worked on againproduct development from an I.T.
IT product perspective, building productsthat we were selling
(04:00):
and installing all around the worldgot a little bit burned out and tired
and moved into a role of teachingwhat I used to do
and still continuing to do a more as aas a consultant and
and now an instructor and have been doingthat for 15, nearly 20 years.
And it's been it's been good fun.
(04:21):
Nice.
See, I told you I couldn'tpossibly summed it up. I
one thing that,
you know, I was particularly excited abouttoday is seeing that you've done
quite a bit of work aroundkind of transformations that companies
which certainly is aa hot trend of failure, as I like to
call it over the last few years,in that if people fail at this,
(04:45):
you know, and obviously in the APIcommunity, you know, you can't have
a real sort of digital transformationwithout APIs being at the core of it.
And we've certainly heardfrom practitioners over and over again
that the biggest challenge to these kindof 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 timeand so curious to hear, you know, kind of
(05:09):
what are some of the high pointsthat you look at for, you know, the signs
that this transformation might just workif 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 wayseffectively at a leadership level?
(05:31):
Are people curious or are they entrenched?
You know, I've worked with a numberof 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 reportsunderstand the value of it.
(05:52):
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 topand driven from the bottom.
So it's a it's top down, bottom up.
The we talk about the frozen middle.
They exist.
(06:13):
People whose careers
career successhas been about working in the old way.
And now we're asking them to change
and often what the organization doesn't dois is put in place
the structures, the incentives, thethe tools for these particularly
the middle this middle management groupin large organizations
(06:38):
are the oneswho really are often left behind.
They often feel threatened by the changes,
know people at the topknow why they're doing it.
People at the bottom are excited
about being able to workperhaps more collaboratively.
Cross-functionallyBut these people in the middle
are actually threatened by this stuffand sometimes with good reason.
(07:00):
You know, the
large consulting firms
come in and say, Yeah, we'regoing 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 ridof large numbers of people.
And typically it's in this middlemiddle layer.
So it's in their interests not to change.
(07:21):
We have to find ways to make the changevaluable for these people.
They're intelligent, responsible adults
who genuinely care about the peoplethat they look after,
about the organizationthey're in and about their own careers.
So how do we position
(07:42):
what needs to change in the transformation
in ways that are going to be valuablefor 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 middleand you're going to bounce.
And sadly, the statisticstell us that 70% of these transformations,
(08:02):
whether we're saying digitaltransformation, agile transformation
or whatever, 70% of those fail,
and that's a huge waste of human potentialand a huge, huge waste of money.
Yeah. Yeah.
It's funny, there's there's a couple ofthings, you know, from the API world
when you weretalking about, you know, the exact soft
and you say they knowwhat they want to do, but it's like
(08:25):
what exactlyit means quite often is like, well,
I read somewhere that, you know, like doAPI is good, things happen, right?
Like let's transformand be an API driven platform
because I read thatin a Harvard Business journal
and it's like, Well,do you know what that means?
Like, how is that going to changeyour business model?
Like, do you think about those thingsa lot of time?
So I certainly see that.
(08:45):
And then I couldn't help but plugin one of my favorite quotes ever from,
you know, the idea for perhapsinfamous Grace Hopper write Most dangerous
phrase in the languageis we've always done it this way,
which, you know, wecertainly in working with our customers,
see this sort of thing like you havea pocket of the band of rebels, right?
The resistancethat's trying to change things.
(09:06):
But it's like, you know, if youI 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 practiceside of things.
You know, are there kind of aspects therewhich, you know, certainly
(09:28):
I mean an API is justanother chunk of software, but you know,
are there sort of cultural facetsthere 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 basedthinking to value streams and products.
(09:49):
So getting away for from from project
based work where we're handing work offbetween different groups
to true cross-functional end
to end value streams and buy into.
And I literally mean that the it's notit goes beyond the you build it you run it
(10:11):
it's starting with the product
initiation thinking all the waythrough to customer support
and and sales so that the value streamthere is ownership across
that whole value stream that in my mindis the, the big predictor of success.
(10:33):
If we can get thatand this is it's a structural shift, it's
a cultural shift, it's a behavioral shift,
There's a whole lot of thingsthat 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.
(10:55):
Yeah, I was going to say you got thethe No projects book out there
that I learned about inand kind of reading up before the show.
So that's on my listnow. That seems interesting.
I'm curious,
you describeda whole lot of roles in there
that, you know, this more pervasiveownership.
I guess I'm curious, like,does that tend to kind of most change
the product management roleto sort of have a broader purview
(11:16):
of those things and like how they'rebringing things into the organization.
But product
management absolutely needs to change.
Product management needs to actuallybecome product management.
In many organizations,
the product manager is an order taker.
(11:37):
The product owner is an assistant.
Yeah.
If we're going to talk about owner,then they must own
not just the productbut the revenue, the profits, the
the costs so that they'rethey truly understand this,
what this thing is and how it contributesto the organism, to the organization.
(11:58):
So, yeah, product management widening
and having that that bigger picture.
Now ideally product managerstruly understand the market.
They are in the technologyadoption lifecycle where it where
as their products their target audiencein that they need to understand the
(12:20):
the market phases that their product isis working in as well.
They need to have at their fingertipsthat the various tools you know
things like design thinking techniquesand ideation tools and so forth.
But they also need to understand thethe technical aspects of implementation.
(12:42):
They don't need to be
experts at that level,but they need to have access to experts
that they trust and that work closelyin collaborative with them.
So the the interaction, the
this idea of a truly cross-functional team
who have all of the skillsneeded, who collaborate effectively
and can deliver valueand can remove obstacles for themselves.
(13:06):
Now certainly reads like a descriptionof how to enable team autonomy.
Yeah. Yeah.
Which I suppose is the the best outcomeyou 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
(13:26):
I think kind of the one just the ideaof an API centric product manager.
But more importantly than thatis that they're they're taking
a more active rolein designing the APIs themselves
in defining what the kind of taxonomyor grammar across the company is,
or at least leading that in conjunctionwith engineering leadership,
(13:47):
but particularly curious on this,like this idea that you should have
a picture of the whole platform as youenvision it to be in some sketch format
before you really diveinto any big investment in it.
And I'm yes, I'm curious like I knowAPIs aren't your thing per se, but like,
is there a sort of an analog
to that organizationally onhow to paint that sort of bigger picture?
(14:10):
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, clearunderstanding of the why.
Simon Sinek start withwhy put your why right in the middle.
(14:33):
If you've got a compelling why the howand the what will figure themselves out.
If you've got a group
of highly educated, highly motivated,
cross-functional people who understandwhy we're doing what we're trying to do.
They've got access to the tools,they've got the skills,
(14:54):
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 thingwe say in product management, as you know,
especially in Agile, right, is like,what's the story?
(15:15):
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 tomatter for customers?
Right?
I think what's made
harder in the APIspace is the head listing, right?
(15:38):
Yeah.
So quite often,you know, we see like techniques
like business capability modeling,
trying to sort of
create this picture of here'sall the things that we do as a company,
which, you know, my experience is oftenenlightening 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 allthat is like a mystery, right?
(16:00):
We have to trust engineeringand they feels like they're always lying.
So I guess I'm curiousthat sort of business capability view,
is that something that you've seenand as part of these transformation.
Business capabilities,but also really important to think deeply
about the you're right, API is a headlessthere are still customers.
(16:21):
That's right.
What is the impact we're going to makeon the lives of these customers
through the availability of the API?
And if we can't figure that out,
we just never goingto solve the right problem.
And what's the value proposition and toolslike the value proposition canvas
(16:42):
really usefulbecause there's no need for a user
interface and the value proposition, it'swhat is the what is the customer problem?
What is the customer's job to be doneis another one of those tools that
will help us understand the the needs.
How will we measure success?
(17:04):
How will we know thatthat thing has worked for this customer?
How will they tohow will they tell us what are the
so the metrics is itis it the pirate metrics?
Is it okay? RS Whatever.
But do we have a clear understanding ofhow will we measure success?
What are the quality elementsthat are going to matter?
(17:27):
What are the ethical elements?
Yeah, it's funny.
I think the thing I've probably saidthe most over the years, some people
go, you know how to how do we manageAPI 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, youknow, a little tricky to get on your side.
(17:50):
But once you get there,you know, it can really grow fast.
But yeah, don't forget the fundamentalsfor sure.
Mean, peoplesometimes go, what's the success measure?
Well, then people call it a lot.
Well, what does that matter?
That might just be costing youa lot of network,
You know, cloud costs or something, right?
Like, did it actually make any moneyor did it
have some positive network effector whatever?
(18:10):
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 sortof transformational efforts.
Is this like you havesort of the technology strategy
that folks are looking and I call thislike the the MIT school of thought.
It's like, how do we create this
distributed modular systemwith reusable things and engineer types?
(18:32):
Go Yeah, of course.
Like that's just let's drythings 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 strategiestogether, it's just like they're
two different things and no one talkedabout how they're going to fit together.
(18:54):
So I'm curious if you see thiskind of like disconnect between
sort of technologyand and business strategy and these things
constantly.
Sadly, yeah.
And part of itis 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.
(19:15):
But the people that people down the bottomhaven't had those conversations.
So the way to overcome it sounds trite.
Have the conversations
to get all of the people in the roomor on the on the call
and make sure that the thewhy is well communicated
and then get the differentstakeholder groups from technologist
(19:39):
to customer support to sales
to marketing to even things like h.r.
And finance, get them all in the same roomand talking about
what would it mean to us to do this?
What are the potentialsand then prioritize?
(20:01):
Yeah.
What's the first small step?
What's the experiments we can runthat are going to tell us
whether we can even do thisas an organization?
Yeah, definitely recreates like,you know, in what we do at Stoplight,
it's like we're, we're helpingfolks like design
somethingbefore they actually implement it, right?
Because that's, you know, good.
(20:22):
But we often say like left of usis probably a marker board
with a small group of peoplewho have great influence.
Ignore the org chart.
Yeah. Right.
That'swhat's going to produce great design.
And I feel like that's a part too,that folks fall into is
trying to envisionthe future in today's siloed constraints
(20:42):
rather than getthe people who have brought influence,
domain knowledge and a passionfor 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 groupsthat go, Yeah,
we get ten of the right people in the roomand we don't even leave with anything.
(21:04):
It's just a marker board picture andit just sparks all kinds of stuff, right?
Yeah.
See, I couldn't agreemore on what we see on that side too.
I'm going to totally changegears here and it's, you know,
this is more just in in
gathering upsort of some details on before the show.
(21:25):
There is one thingthat you sort of shared with us
that software is a creativeart 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.
(21:46):
I wrote my first piece of code.
I was at high school.
The school had a teletype terminalinto an Olivetti
mainframe, and I wrote codethat was recorded on paper type.
And then you ran it through this papertype reader.
So it was that old technology.
But I wasI wrote code and I've continued writing
code up until about 2017.
(22:08):
So I'm not absolutely currentin 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 expresstheir creativity is through
the discipline of code, the
(22:30):
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 APIwhere an API tool is generating stuff.
But that's great because it's taking awaythe mundane things.
(22:53):
What that does is it frees up
the creative mind of the programmerto really build that.
That piece of artis a well-written piece of code
that solves a user problem,that solves a customer problem,
that that makes an impact in the worldis a thing of absolute beauty.
Yeah, I couldn't agree more.
(23:15):
You know, I was just kind of explainingin 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 engineersand then give you a problem to solve,
do you think I'll getany of the same solution out of those ten?
I mean, assuming it's not like,you know, add one and one, right?
(23:36):
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 definitionof engineering,
engineering is the creative application
(23:59):
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 ruleswe can build on.
But it's the it's
the creative application of that sciencethat makes change in the world.
Yeah.
(24:19):
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 overthe last 20,
25 years and trying to look at it,designing something that doesn't have
exactly like it'skind of a human interface,
but it's kind of a machine interfacewith API and trying to think about this
(24:39):
sort of, you know, developer experienceas being an emergent discipline too.
But if I looked at user experience,
I'd say there is absolutely sciencein that work, right?
Any good user experience designer
isn't going to tell youI 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,
(25:02):
that designing things for developersis sort of a
in some ways a weak spot, broadlyspeaking, because of the way
that this sort of scientistoriented 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
(25:24):
another number of conference talksabout the developer experience,
and we're seeing this coming outover the probably the last four years.
There's this, this emphasis on developerexperience and removing friction
in the development processand making things easier
because if we remove those distractions,the creativity can come through.
(25:49):
If you my wife is an artist,
she did the paintings that are behind meand the carving.
If she's going to be creative,she needs a quiet space.
She needs uninterrupted time.
Nothing is different to the developerwho's
trying to figure out how to solve
a difficult technical problem.
(26:10):
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 coveredthe edge of the edges of this pretty well.
This is a huge topic and trying to do itin a bite sized chunk here is difficult.
(26:34):
But any sort of,you know, closing thoughts or
you know what I usually kind of askfolks here is like, you know, for those
who haven't gone down this road,
there's a lot of thingswe 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-promotionand Say is a book by Shane
(26:57):
Hasty and Evan Laban has no projects.
It's available as a free downloadfrom 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 valuestreams is a big part of that.
And really one of the biggest shifts,the most
(27:20):
I think one of the most valuable shiftsyou can make is that starting
to to at least think and workin, 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
(27:42):
just figure out how to do that effectively
and then genuinely start to think about
what is the impact that we makeon 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 safeway. Hmm.
It's funny, it occurs to meone of the things that we've heard
(28:05):
quite a few times when asked this questionon folks that are in that kind of API,
you know, core of this transformationin a lot of places is start with empathy.
And I think that's really acrossthe course of our discussion.
What you're saying,
right, is like, treat those peoplethat you work with like human beings.
That's a good start.
But also remember that the customersusing these things are humans too, right?
(28:27):
And, and yeah, I think I'm with youthat like the craftsman's mindset.
I would say likeif I'm going to make a chair
and give it to somebody, I dream thatthat person will give that chair
to their children, right?
Yeah.
That has a long lasting impactabout something they really care for.
So yeah, start with empathy.
I love it.
(28:48):
Perfect.
Shane, thanks so muchfor 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 onand there should be a link there
so you can go submit a questionand we'll do our best to find out
(29:11):
the right answer for you.
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
Use the code intersectionten to get 10% off a new subscription
(29:34):
to Stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.