February 15, 2023 • 50 mins
In this Breaking Changes, Postman Chief Evangelist Kin Lane is joined by Ben Mackley, Solutions Engineering Manager at Zoom. Ben shares another view of how business is leading the API lifecycle to deliver the next generation of API-driven technology solutions that have established a feedback loop with consumers and help business stakeholders find the signal in all of the noise across the increasingly chaotic business landscape.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
foreign
(00:02):
[Music]
thank you for tuning in to today's full
episode of the breaking changes podcast
I'm your host and chief evangelist for
Postman Kin Lane with Breaking Changes
we explore topics from the world of APIs
but through the lens of business and
Engineering leadership joining me today
(00:23):
we have Ben Mackley Solutions engineer
manager over at Zoom Ben shared with me
such a powerful view of how important it
is for today's API lifecycle to be a
business-led affair Shifting the long
history of it being an I.T thing
so let's dive in uh start with the
(00:43):
basics
who are you and what do you do
yeah so I'm I'm Ben Mackley I'm a
Solutions architect manager at Zoom and
I connect enterprise software systems
together as the solutions architect
manager so my team works with our
platform so we it's called Zoom contact
center now but we were essentially a
(01:05):
chatbot and we connect with
other crms and other software providers
out there so our team is really involved
in the nitty-gritty with the APIs making
sure that the data is Flowing properly
that we're we're secure when we're
connecting systems together and that are
we're fulfilling the customer's business
(01:25):
needs as well
interesting I like that it's not just
about the connections and and What flows
through the pipes it's about actually
meeting meeting business needs of people
the human beings that are involved here
which is so important but we'll we'll
dive into this a little bit uh the the
Integrations part of this is really
interesting but I want to understand I
(01:46):
want uh everyone to understand a little
bit more about you and and your journey
where you've come from so how where do
you you know where where'd you get into
all this how did you end up at Zoom
so it's been a winding journey I think
with with most people's careers that end
up as as Architects it usually takes a
winding path
(02:06):
um so I I started a company out of
school and I'm I haven't been
technically minded
um at least when you know I was going
through school and at the beginning of
my career uh I was more interested in in
starting things and doing a startup and
solving education problems specifically
I realized that technology was the way
to create an impact
(02:28):
um across that would scale across many
people
and because of that I got into
technology and the startup didn't end up
working out but that led down a path
where I was kind of searching for what
to do so I did product management I was
an engineer for a while and then I
finally found my home in Solutions
engineering and solutions engineering is
(02:50):
working on with the sales team selling
B2B software and as the solutions
engineer I was often doing the
implementations and would be connecting
the systems together and and that's kind
of what led into Solutions architecture
um where where I'm at now and I I didn't
realize this but throughout my career
I've worked on platforms and generally
(03:11):
within the industry there's more
products than there are platforms and I
guess when I say platform it's not like
AWS or Google Cloud as far as hosting
all of the services it's more having a
One-Stop shop to do everything that a
business user would need to do so I
worked at a process automation company
that
(03:33):
um automated
processes within within different
companies whether it was HR onboarding
flows or more on the the technical end
um
and then I've also worked at a user
monitoring company Quantum metric they
did a combination of application
performance monitoring as well as like
user experience monitoring that was a
(03:54):
really interesting experience and now
um interestingly enough at solvi it was
the first time that I was working with a
a product team but then we got bought by
Zoom to be a part of a broader platform
with Zoom contact center
I love love the journey
um definitely I love the product
(04:16):
management engineering Solutions
architecture and engineering kind of
focus and journey because I think
I I don't think those
those career paths are getting as much
of attention in this kind of Silicon
Valley or technology narrative you
hear a lot about engineers and being
an engineer you're starting to hear more
(04:37):
about product management I wouldn't say
it it Rivals as much but I hear very
little advice guidance uh showcasing
that Solutions engineering or Solutions
architecture is even a path that
you can find and you can go to so how
like I mean were you just
why why did you end up here because it
(05:00):
it spoke to you more or like what are
the reasons
so I I feel like the sales teams in in
B2B they they need
um somebody that thinks both on a
business side but also understands the
product and I I think I got into sales
because my uh working in the startup I
(05:20):
realized how important sales is to the
the lifeblood of a company if you're not
selling your product if you're not
interacting with your customers then the
product will die eventually and then the
business will die because there's no
Revenue coming in and so for me I've
always wanted to
solve the biggest problems that are out
there and I think within technology
(05:41):
there's a lot of problems that need to
be solved but the the flow of solving a
problem always starts with a customer's
pain not with a technical solution
um and so for me I think I got into
Solutions engineering because I wanted
to understand that life cycle of
identifying problems and solving
problems in the right way and coming
(06:03):
from the startup world where you wear
many hats I think Solutions engineering
is very very similar you have to
understand the technology you have to
understand the customer you have to be
able to communicate with the customer
and so information has to flow many
different directions and much like
product Management Solutions engineering
is is a connector role which I think it
(06:24):
makes a lot of sense that Solutions
engineers and solutions Architects work
with apis because apis do the same
connecting different systems together
and making sure that the technology can
communicate in the same way well I guess
not the same way but in a similar way
that that we communicate as humans
yeah it's it's about Connections I think
it's that's an important uh
(06:47):
highlight emphasis that I I I get and I
I've thought about but I think you you
put it pretty succinctly and the
difference between Solutions and product
management so I always say uh the the
the API space the whole Tech realm is
very API producer-centric
um and that's kind of Def that narrative
(07:08):
has been set kind of by API management
providers analysts like Gartner and
Forrester and others and vendors talking
about producing apis but for me the best
API producers are also API consumers
because you get you understand that pain
so from a product management and API
(07:29):
producer perspective I'm producing an
API uh I need alignment between business
and my developers who's producing this
but I I need to find that alignment with
consumers I need that feedback loop and
we iterate on this API and the velocity
we're able to achieve and the value
generated is is based upon my bridge as
(07:50):
an API product manager but what you're
describing as as in the solutions realm
is the same but from a consumer side
like I'm guessing you you see you suffer
a lot of pain and see a lot of things
problems that are introduced by the the
apis you're depending on at Zoom for
(08:10):
Integrations these CRM Solutions and
others so what what sort of what War
Stories do you got for us as far as from
that perspective
so I I think that's you described it
really well that
um
most API consumers so I'm more of an API
consumer as a Solutions architect as
opposed to an API Creator and I think
most API creators don't often consume
(08:32):
their own apis that they're they're
developing
um so I've seen it both ways where
um when I was working at a process maker
doing process automation we had an a
phenomenal engineering team
they they rebuilt the platform API first
and so they had the swaggered
documentation for all the endpoints you
(08:54):
can actually run our entire system in a
headless way without our UI using our
API endpoints
and they they did a phenomenal job of
creating a system a platform that we
could tap into without having to go to
the the engineering team for for custom
requests
(09:15):
and on on the flip side I I felt um we
were getting there and we were improving
as far as helping them on the consumer
side uh of giving them feedback of of
what would be
um you know helpful but I feel like that
was almost underutilized so the
marketing aspect of the product that
they build like letting our customers
know and then letting our sales people
(09:35):
know and and how to sell our product to
a technical audience I feel like there
there was a huge gap there
um and
uh I was I was there at the beginning
stages of the product so I I don't know
where they've gone since but hopefully
they've they've been able to make that
shift to to sell to those technical
audiences and
(09:57):
um educate the consumers in a way uh
where they can understand the power of
the product
um and then I've I guess I've been on
the opposite side where as a Solutions
architect we've been craving uh We've
we've craved apis on on our own side
that our engineering team could build
those so that we could pass the work off
(10:17):
to the customer instead of having to do
custom work
and and building custom products for
every
um you know every customer that we have
so I think it goes both ways and having
a connection between the team that's
building the product management team and
the engineers that are creating the apis
and then the consumers that are going to
(10:38):
be utilizing them whether it's customers
or you know that the internal users at
the company is is really important but I
know that you've done a lot of work on
this space so what what have you found
to be effective as far as
like working with with customers has
there been a process or a method that
you've used to get the feedback when
you're creating the apis that have been
(11:00):
helpful
yeah I mean there's this is definitely
one of those areas that
um
I've seen different things work in
different organizations and different
ecosystems because of the culture or the
industry or uh where I think everyone
collectively is in their API Journey so
I like most areas of API livestock I'm
(11:22):
always uh asterisks you know this is not
one solution that's going to fix you
know fix it for everybody but uh
definitely feedback loops that are what
I'm seeing right now shift is the The
Narrative around apis for the last
decade has been here's a portal
here's reference documentation for
(11:44):
everything
and here's us you can submit a ticket
here's a community forum and we'll we'll
we'll use the community forum and the
tickets as as this feedback loop and
what I've seen is is with with companies
like uh Twitter is a good example of
this uh not big on naming names but
(12:06):
Twitter I think is a is a really
interesting example of they've
they get a lot of hostility in that form
because for some reason forums as as a
feedback loop mechanism
brings out
the anger in some of us and we say
things in ways that either are we feel
empowered to be kind of mean and
(12:27):
ruthless or maybe we're just being not
heard in the right way and what I'm
seeing evolve right now is is developer
experience and investment in developer
experience
change and diversify these feedback
loops that you set up so the Forum and
the ticket
becomes blog posts and social feedback
(12:48):
around it or it becomes
um it's it becomes channels that are
very suited to the audience who who
you're targeting because you've done
your research you've done your due
diligence on who who are we targeting
with this so you're you're using Tick
Tock appropriately because you're
targeting the Right audience or you're
using Hacker News because you know who
(13:09):
you're going after is right there and so
your feedback loops gets tailored to to
that that channel that that target
audience if it's internal it's done
through teams and and the feedback loop
if it's for microservices and apis for a
certain domain within an Enterprise so
that developer experience that
(13:29):
investment in that consciously
constructing a feedback loop had it
really defines what how you gather that
how you use it in the tone of of it and
back to the Twitter example Twitter has
started for their Twitter spaces API
they before they got to work on it they
actually
fired up a Twitter spaces to have a
(13:51):
audio conversation a town hall
discussion about what should the Twitter
spaces API be or do or should we even
have one and
a whole bunch of people showed up a
bunch of developers in the developer
community and uh Danielle a the uh the
product manager in charge was was uh
(14:12):
looked at some of the names and goes oh
no like these are some of the angry
people from The Forum oh my gosh oh my
gosh and had a lot of anxiety about that
but then once turned on the audio
they were very cordial and very social
like and so he's trying to figure out
was it that they felt more empowered to
be mean and and cruel on the Forum did
(14:32):
he interpret it wrong is the audio more
of an experience the town hall format
and an audio people are more more uh
friendlier he's still processing all of
that but I guess my my point back
answering to your question is
developer experiences shifting
investment developer experience is
Shifting how we construct these feedback
(14:54):
loops and the maturity and visibility
public private partner of our apis
um very much dictates what channels we
use and how we gather feedback and then
how we listen and filter through based
upon the volume of feedback we're
getting
yeah I think that's that's an incredibly
important uh point and when I was
(15:14):
studying education I did my Master's in
educational technology and the the way
that we learn is through feedback and
whether that's uh technologically so
like with apis and uh with programs that
we write the reason that we have error
logs is because it's a feedback
mechanism
and like what you were describing with
Twitter it makes a lot of sense because
(15:37):
companies that are open to feedback are
the ones that are going to be improving
and creating this not only great
developer experience but I think the
great developer experience translates to
a great user experience down the road
and really a product that serves the
customers as opposed to a product that
customers have to adapt to to their own
(15:58):
environment so that's I think that's an
interesting
an interesting story but also an
interesting idea of developing these
feedback loops according to the the
product that it needs like might be
Hacker News might be you know Twitter
feed might be just issues on GitHub that
are aren't posted but really every
(16:19):
product that is is open to feedback
we'll we'll get that
um
what's the
what's the cultural like I see a lot of
folks who who talk about feedback loops
talk about product management talk about
empathy they're even like how do we
develop empathy for our customers but
(16:39):
really aren't honest about it I would
say to the degree because it's it's a
little scary to to be to open yourself
up to these the this criticism and the
because you're probably getting feedback
from some of the loudest folks but like
so how do you how do you find the signal
in this noise and what you're doing as
far as I mean you're hearing business
(17:01):
goals business you need a business
alignment you got developers and and
teams and you've got customers how do
you find the signal in that noise
yeah it's I mean there's so many signals
that that were being attacked with like
both internally and then externally uh
that it's it's hard to parse all of that
out and I think that's that's really the
(17:22):
role um of what great product managers
and great solution Architects do is
they're able to determine uh the signal
out of the noise
and so a few things that I I generally
do when I when I start a project is uh
getting face-to-face time with a
customer because
(17:43):
um I think there's the qualitative
aspect and then the quantitative aspect
and with signals I I think you need to
marry both of those the qualitative with
the quantitative to under to understand
and to correlate because a discussion
with a customer will often surface their
major pain points and the process that
we generally go through we call it
(18:05):
scoping but we'll we'll talk through
what their pain points are and what I
didn't and eventually we get to a
desired solution but during that process
we take that qualitative feedback in of
what's you know important to them what
they want to get to and generally it
might be something like uh where's my
order function that that's built into
our bot or where's my order or
(18:26):
um can I get a refund for for an item
and based on the feedback of the
problems they're facing we'll compare
that to my in most cases it's Financial
so like how much time will it take and
how much resources will it end up being
to create the solution they have and if
if it's a huge problem for them but it's
only I don't know 50 000 or a hundred
(18:48):
thousand dollar impact that they would
have and it's going to cost just as much
to create it they're not going to see
the ROI and so even though it would
resolve their pain Point
um the the numbers aren't correlating
with the qualitative information and so
I think with
um by pulling multiple sources the
qualitative and the quantitative you're
(19:09):
able to triangulate what's what's
actually important from all the
indicators that are coming through and
the general rule of thumb that that I
have when making these decisions and
then I got my team on is if we're if
we're not going to see a 3X Roi then
there's probably something else out
there that we focus our time and
attention on which means we need to to
(19:29):
dig further to see if there's other
problems or other stakeholders that
would be involved we need other data
points to understand
what what else could be out there and
not just focus on what's in front of us
so it's a long answer to the question
but I think getting as many data sources
as possible and then trying to
(19:50):
triangulate them and correlate them to
see not only what's feasible about
what's going to have the biggest impact
and then from there I think it's a it's
really hard to do it perfectly but
creating a prioritization and a project
plan and coming to agreement on that is
that the process that I've found but is
there anything that you've done
(20:11):
um as far as understanding
how to how to parse out the signal from
the noise that you get When developing
products
um you know I mean I I I'm the first to
admit so I I wouldn't be a good product
manager because I
I get too emotionally caught up I wanna
I wanna talk to everybody individually I
(20:33):
want to hear I want to you know for
breaking changes like I'm this show
won't go out till January because I've
already talked to so many people like
and and so many and we're releasing two
a week that these are super valuable
conversations that I'm having like the
number one reason I do breaking changes
is to get to talk to you and to learn me
(20:54):
learning from you but then there's also
this this bigger mechanism where I
filter out and find the signal here and
how does it how does this fit into the
overall life cycle like everything
you're doing right now is you're talking
about I'm gonna put into our Master
guidance around feedback loops and and
product management and so this is
(21:14):
actually my one of my mechanic you know
channels for my feedback loops and this
is part of my job in building a a API
lifecycle and governance a producer and
consumer life cycle that all works
together
product this is what I'm building out of
these conversations just so you know
you're a guinea pig so you're you're
like in the physical feedback loop right
(21:35):
now and I'm doing what you just asked me
how I do it so
my challenge is is I love just talking
to you and I get so caught up in the
moment that I forget about the big
picture and I just want to make everyone
like they're so right like and and I get
like I'll be talking about you for the
next like four or five days and and
everything we did but then in the bigger
(21:57):
picture I'll lose that signal and get
distracted by the noise or the next
signal so I actually would not make a
good product management and I need
people helping me with that and luckily
I have a team behind the scenes here who
helps me stay on track because otherwise
I don't think I would get a product out
the door I would have all the
conversations I would gather all the
(22:17):
signals but I wouldn't get it out the
door but with that said uh surround
yourself with smart people
um who can pay attention to things that
maybe you don't see diverse people
diverse voices
um that are going to ask questions that
you just didn't even think about or see
or point out data from it so having
(22:39):
those people are around you
prioritizing channels and and what what
matters the most because we can we can
find too many channels we can we can
gather too much information and know
when you need to start filtering that
down but then for me I just follow my
gut and what what I feel intuitively is
(23:01):
going to matter the most
um based upon those conversations I had
and my understanding of the space and
people and I talk to so many people
um I trust my God a lot I know gut based
isn't probably a sensible way to in
scalable way but I I talk to a lot of
people and I've been doing this a while
I I trust my gut but
(23:21):
I don't know if that's right or wrong
yeah I mean I call it you're doing so
much qualitative uh you have so many
qualitative feedback loops through the
conversation that it's probably why you
can trust your guidance you've
you've done this so many times that if
something feels off there's even if you
can't pinpoint the reason there's
there's data behind it uh but the the
gut comes much quicker than the data
(23:44):
does and yeah I think that's why it's
important that your team
yeah definitely the team is critical for
me like because I that's why I'm at
Postman because I um I was doing this a
long time on my own independently and it
only got me so far you have to have a
team you have to have people working but
you have to and I'm also learning one of
(24:05):
the things I'm learning from my team so
uh uh hired someone named Deepa goyas
from PayPal recently and she's helping
me think through all the product manager
developer experience stuff and
repeatedly in conversations I find
myself she catches me in a uh API
producer mindset where she's coming at
it from a developer Journey from a
(24:26):
consumer perspective and she's like what
she asked me like well that just didn't
make sense what you just said like it
and and I explained again yes it does
and she's like well that's that's you're
the producer like no this is about the
consumer and she's constantly advocating
for the consumer and getting and I just
made me realize how locked into this
mindset I am and that's really what I
(24:48):
think captured me about you and your
perspective so everything that you just
said about
um prioritization and and finding the
signal
how do you reconcile that with the apis
you depend on so your we won't name
names but you connecting to a CRM
solution that is trying to prioritize
(25:08):
what they should build and what they
should make available they have somewhat
of a maybe a a barrier between you and
them
um you know you have one or two channels
that you can you know submit your
feedback like how do you make yourself
heard or how much time do you make
carve out for being the signal for these
(25:29):
providers these producers and giving
them what they need to produce not just
what you need but a better product
that's going to make your job easier
down the road
yeah I think the answer is I don't carve
enough time out to get feedback and to
help the producers create better
products I think internally it's really
easy because you know having Zoom chat
(25:51):
or slack or you know the internal
communication tools it's really easy for
me to connect with my
um the Integrations engineering team or
our the back end teams that are creating
these apis you know we we have a really
good relationship and we've developed
that over time with other vendors
um so oftentimes we'll come into an
(26:11):
implementation and we'll we'll be one of
two or three or four different vendors
working on the project and it's a lot
harder because we don't have that trust
and we haven't developed a set routine
as far as how we communicate and you
know it's learning that
learning that relationship every time
(26:33):
and so I think for me the the process
that I I generally follow is if I have
to choose who I'm going to be working
with if I have to choose the producers
that I'm I'm working with I'm going to
look for the ones that are open the ones
that have invested in their developer
experience and have created
documentation and that have done
marketing or that have resources to talk
(26:55):
to others in the community because I
know that my when I do come with
feedback to them that they'll at least
hear that and internalize it and it
won't fall in deaf ears I was talking
with a friend of mine who's
um who's using the the company that I
worked at previously and he was trying
to integrate with customer on the the
(27:18):
chat side and he was telling me that the
process that they have they don't bubble
up their errors
um so it's it's a very tight system and
there's always a trade-off right having
an open system means that there's higher
security vulnerabilities and so you
can't be completely open but at the same
time if you're completely closed it's
it's very difficult
um for others to work with you and he
(27:38):
was having this problem where the error
messages weren't getting bubbled up and
the events weren't bubbling up and so he
wasn't able to connect uh the the
systems together to create this
monitoring with the application and with
the chat so the chat was essentially not
showing up in that that real-time user
monitoring that they had and he talked
with the customer team and he brought
(28:00):
this up he's like not seeing the errors
and I'm not getting the events that I
need
to handle these issues and the customer
team essentially said yeah we know it's
it's because it's going to be less
secure and we'll let our development
team know but we can't make any promises
and just like hearing his frustration
and having gone through that myself so
many different times
(28:21):
um I I'm in a position where I can
choose who I work with
um at least more than I have earlier on
in my career and so that's what I
generally look for now is people that
are willing to be open and to take
feedback and give feedback so that that
that feedback loop is really tight so
that we can deliver product quickly and
that we can deliver the best developer
(28:42):
experience and customer experience and
then I think from there once the the
relationship is established it's it's
really just doing the work and kind of
building on that but setting everything
up for success and choosing the right
people to work with is incredibly
important throughout that process
yeah the heard a couple really
(29:04):
interesting things in there the
so I've long advocated that part of your
feedback loop the design of your API is
part of your feedback loop meaning the
status codes you return is part of the
the feedback loop with your consumer and
so thoughtful design is is really
important because you're gonna minimize
(29:26):
people having to come and submit a
ticket and and be the I guess the direct
uh feedback loop mechanisms because
your your this indirect this kind of
soft feedback loop part of your design
is good or bad so your volume tickets
will be lower or higher based upon this
so that's like the design of your API is
(29:47):
is very much part of your feedback loop
but the the second dimension of what I
heard you say is for me apis are a
balance between access and control
and I and and I see this I was we just
released the stated API report today at
Postman and one of the biggest surprises
for me is is
(30:08):
um
or not surprises things I want to see
more of is it's heavily skewed towards
internal apis and microservices meaning
the majority we ask people where are you
doing private partner or public apis and
it's overwhelming with like 50 60
private and then a smaller a slice of
Partners and a smaller slice of public
(30:30):
because people have a lot of anxiety
about opening up they don't have a lot
of confidence in in in in this balance
what you just described in this company
they just don't they're worried about
opening up the pulling back the curtains
too much and giving access to too many
errors because they don't they don't
have a lot of security confidence
observability monitoring and so so
(30:52):
really I think what you just described
is how much your your design and the
operation of your API is your feedback
loop and is does set this tone for what
you're going to be able to gather
um and and filter out that signal from
the noise
yeah I mean it I think it all starts in
the design phase so on the product
(31:13):
design how how are we developing error
codes it seems like such a trivial thing
but in the the long run of launching an
application and maintaining an
application the maintenance is much
lower if the design is specced out
properly and user input is taken and
like you do the testing to to identify
like what error codes should be should
(31:34):
be coming up so it's I mean it's it's a
process and I think it's one of the
reasons why it's so difficult to do well
I've I've seen some companies that have
done it well but more often than not
um there's a lot of room for improvement
with with most companies and I think the
reason why it's so difficult to do well
is because the design phase takes so
(31:55):
much time and effort and for me what
I've found is there's the adage measured
twice cut once and I think within
software design and especially with API
development meant the it's more spend
eighty percent of your time designing
and getting input and testing up front
and then that twenty percent of time
(32:16):
like the build is actually easy and
should be the shortest amount of time uh
as far as the the entire life cycle of
creating a product and it's it's really
hard to do design well and I think you
know coming back to that that idea of
product management
um I think good product management takes
the time to do design well and to get
customer feedback and include that in
(32:38):
the product interesting and that gets
that so one of the idea things I've
noticed in the space is we have a lot of
times trouble having conversations
because we're not grounded in some some
fundamental things one example is the
life cycle when I ask people what is the
API lifecycle in an organization I would
get 10 different answers and once I did
(32:59):
that at Postman and got 10 different
answers I'm like all right this is a
problem because like we're not all in
agreement we like verbally say we're in
agreement on what the life cycle is but
when you get down to it it's actually no
we're not and I noticed that the life
cycle for a lot of you go talk to
developers is it's develop deploy
(33:20):
and then somewhere in there we added
tests so that you well you develop and
you build your test driven development
and then you deploy and those tests
benefit and then we start shifting
security a little bit left so you got a
Security review in there and you got
some security but it's still development
test security and deploy
and then once we start adding this
(33:41):
Define and design stage we got
pitchforks from developers going no I'm
not a designer I don't I'm not a yamler
I'm not going to design in yaml I'm you
know I'm a developer and so code first
kind of is winning out over design first
but what I heard you say is this is a
product management task so I feel like
(34:01):
the Define and design stage and then
we're also seeing it so that's the
bookend at the beginning of the
conversation once you deploy there's
observe I have observability and
distribute as the next stages those
bookends those two areas are also
product manager because what metrics and
how am I measuring all success all of
(34:22):
this and then am I Distributing it and
documenting getting it in front of the
right people and then getting that
feedback loop back to the beginning and
those so those book and stages
I I see a lot of groups expecting their
developers to do those but the ones that
I'm seeing be successful are the ones
who are bringing in product managers and
Architects to coll to work with those
(34:43):
product managers to do well and then
product marketers I would say on the
distribute side there needs to be
product marketers involved in that to
actually get it out so
that's a long life cycle right for a
product manager to work with customers
and work with the internal teams to
Define and then design a solution
because including engineering is really
(35:05):
important in that stuff and I think
they'd like to be included they just
don't like to run it it has been my
experience they like writing code they
don't like defining business problems
but that that life cycle
it takes a long time and so I think
there's there's information gaps and I
think that's one of the things that I've
realized in in my role recently
(35:27):
um you know stepping into management is
most problems are communication problems
and like even at the API level that's
what we've been talking about of error
codes is a way to communicate that
something is broken and so building good
communication paths and I'm doing it in
an agile way where it's iterative where
you can go through that process and then
(35:49):
come back and go go through it multiple
times in the title that Loop is the the
quicker the product will get out and the
higher quality it will be so I think
oftentimes we think that it's a divide
like quality if we want a higher quality
product it's going to take longer but if
at least in my experience it's been the
opposite the the products that ship
(36:10):
quicker end up being higher quality
because they have that Loop tied down
pretty quickly yeah the communication is
key so so I'm gonna uh let the cat out
of the bag here with the podcast called
breaking changes
there are no breaking changes folks
there are just poorly communicated
changes that cause systems to break so I
(36:34):
would totally support I totally support
you that it's all about communication
and it's all about us human beings not
doing that well or or doing it well
yeah and has there been something that
you found that's that makes that
effective of like going through those
steps and like building uh a process as
far as going from design to implemented
(36:56):
like the development to the deployment
to the observability to product
marketing and getting that Loop done
yeah the the foundational piece which I
just talked about is the life cycle is
is the first grounding piece that's
missing is people don't have a common
definition of what the life cycle is so
how do we get from Define to uh
distribute and then back again so
(37:18):
everyone's just wandering around running
around and doing what they can and
there's some overlap in it but once you
get people with a clear life cycle
definition saying the same things being
able to uh to speak to it in a common
way things stabilize the second one is
role based and so who are the owners or
(37:41):
who are the stakeholders at each of
those stages of the life cycle who
should be in the room and who shouldn't
be
um because this is what you said about
developers is like developers want to be
included and Define and design they just
don't want to own it and they don't want
to do all that business research so
having very clear ownership and and
(38:02):
roles defined for each stage of the life
cycle is is the next grounding piece
because
then you know who to communicate with
you know hey
hey Joanne I just finished uh the
requirements can you look at it hey Ted
I just finished the mocking and why
(38:22):
don't you play with it and see if it
actually meets the contract that we
discussed so and without those clear
stages and roles
that communication doesn't happen and
that's where the friction comes in
and maybe this is just the developer
mindset but to me it's almost like
designing good applications is the same
as designing good processes for building
(38:45):
those applications and just like we
would Define a get request and say which
parameter or which query parameters we
can use with that gitrobquest I think
Divine defining a role is very similar
to API documentation where if we say who
owns a role and like what
responsibilities are associated with
(39:05):
that role
um and then communicating that with the
team so that everybody knows
uh who else to talk to allows that that
information to flow much more smoothly
so it's I mean it's from an architect
mindset it's like interesting to me how
the same principles apply whether we're
dealing with code or whether we're
(39:25):
dealing with humans or you know
something completely different yeah yeah
well I was trying to write this up in an
articulate way yesterday but um is
are everything we're doing for
applications and Integrations the
reasons why we're doing apis the same
applies to the apis because our AP the
(39:47):
infrastructure we use to deliver each
stage of their apis have apis behind
them and so we can automate we can
communicate there's a lot of things you
can do
um strategically with your API lifecycle
that you can accomplish with apis
that'll help you automate stabilize
communicate iterate all these
(40:10):
collaborate all these things that are
the nutrients that are the deficiencies
that exist in the life cycle and so we
notice this with our apps we were
building web apps and then we're
building multiple mobile apps then we're
building partner Integrations here and
there and we started identifying along
the way we need a strategy for this we
(40:31):
need an API strategy for these resources
these capabilities and experiences
now we just need a strategy for our apis
also and and the life cycle and and the
governance in a similar way and so that
we can begin to stabilize how how we do
apis and get more consistent and how we
communicate because without that
(40:52):
the the humans are the biggest problem
because we're that's how we work you
know we we've got to be able to
collaborate and work together and
understand and and find that forward
motion and without that structure and
framework we're never going to get there
so how have you seen the best systems
set up so like you described that that
(41:13):
flow of like product management book
ending the development and then like on
the observability piece I imagine
there's a devops team that helps with
the deployments and setting up those
process and product marketing
um to like help interface with customers
but I mean there it takes coordination
so I'm like who's sitting on top of that
like what is the best organizational
design to help with good API design like
(41:36):
I imagine with everyone that you talk to
that you have some
um some good Instagram
yeah no I'm working on on I have a lot
of good Insight working on best how to
put that out there and communicate that
and like I said these these these
conversations are part of that and so I
hear I talk to a lot of groups who have
a center of excellences when it comes to
(41:57):
their API design their governance that
are creating design guidelines security
guidelines things that are cross-cutting
um uh across the life cycle so defining
the life cycle but defining how we
document how we test how we secure and
providing
um uh as much guidance and enablement
(42:18):
along those lines from a central
standpoint now with that said I've also
seen a lot of groups
try to govern
with a capital G governance from top
down and hand these down to teams and
just cause Mayhem because it was
mandated it was everything every api's
got to be exactly the same every team's
(42:39):
got to operate exactly the same use the
same Source control and CI CD and it's
just not how it works in across a an
often distributed Enterprise landscape
that's either broken up by lines of
business tribal boundaries Acquisitions
geographic regions regulatory compliant
(42:59):
you know so the the ones that I see
working are there is a centralized
guidance and investment in resources
um they have Champions that are part of
Federated teams who then help Champion
those centralized Concepts tasks but
(43:21):
capital G governance on the ground floor
is is lowercase G governance or more
appropriately enablement so I'm I can
apply these standards because they were
someone else did the work to go find
them and to make it easy for me to do it
in my vs code and apply standard
pagination or standard design or
(43:41):
standard
um and and I've got linting rules
someone thoughtfully put together a set
of spectral linting rules that when I'm
editing a yaml document or a Json
document for my API contract it's
catching most of the mistakes that I'm
gonna make as a designer and enabling me
to deliver a better API and oh by the
way I can have those in the pipeline if
(44:03):
I want if my team teams mature enough
and my API is mature enough I can have
them catch it in the CI CD pipeline
those those those design gaps because
you know even me as an expert like you
know Monday Tuesday I'm great at
remembering all those but you know
Thursday I woke up in a bad mood I came
to work I pushed some code and or a API
(44:23):
contract and it and I forgot 30 things
because I was just in a really bad mood
I know better
um so I need that that pipeline to catch
that for me and I don't see it as
enforcement so like being able to
centrally Define a lot of these
distribute and enable teams to use as
much but then also leave room for
(44:44):
autonomy and agency for teams to do what
they need that may work and be a better
solution and then feedback loops
keep that that API strategy guidance
governance a living kind of feedback
loop and then gather feedback from those
Champions and teams repeat repeat but
you have to embrace a Federated approach
(45:06):
and find the balance between
centralization and Federation that's
going to work and then you bring in the
Ops Team how does how does your Ops
teams fit into that how do your security
teams fit into that those cross-cutting
functions and then you just find the
dance that's going to work the best
I've been I've been studying agile and
(45:27):
how to actually uh follow agile and I
think one of the principles is
self-organizing teams end up producing
better code and I like that idea of like
that it's not a central governance uh
from my mandating things from the top
down but it's almost like uh providing
the teams with the tools they need
whether it's a ciucd platform or the
(45:49):
linting to check the code so that way
the teams can focus on what they do best
which is writing code or you know if
it's a product management team talking
with customers defining what the actual
business problems are and then designing
you know the the initial solution and
coordinating between people but having I
(46:09):
think that idea of enabling teams with
providing them the resources and the
structures and really the tools that
they need to succeed is really important
so that's uh that's something that I'm
gonna to try to do but I know that it
takes a coordinated approach right it
takes
many different people coming together
(46:30):
and agreeing
on that
yeah that's that's the trick right there
and and so for for my last question I
mean I could keep talking to you all day
this is great but
um for podcast sake I remember I got to
keep reminding me we're recording a
podcast
um one last question for you along those
lines is how much of your day is
technology how much of its business and
(46:52):
how much of his people related things
would you say
um I
so I find myself having to add
technology to my my schedule because if
not it would would just go away and I've
felt that over the last few weeks
especially it's like sometimes I'll come
into a project and get deep in the
technology
so I mean it obviously fluctuates but
(47:12):
I'd say on average
um it's at least 50 people
um and then maybe 20 30 on the the
business side and 20 on the technology
so
I think uh being involved in the Techno
I found that with my roles that I need
to be involved in technology outside of
work in order to stay current and stay
(47:33):
relevant and to help me on everything
else I'm doing but the demands of the
day
um being a manager being thrown in
meetings and working out HR issues tend
to take the majority of the time but the
fun stuff what I really love doing is is
teaching on the technology so like I
have past experience in boot camps and I
(47:54):
think one of my my favorite
responsibilities as a manager is is
mentoring and helping the team find the
positions that work best for them and
then like connecting everybody together
to build great products so I I wish it
was reversed I wish it was you know 80
percent on on the people side with the
technology and you know 20 business and
(48:16):
HR stuff but yeah it's sad reality I
think of being managers having to to go
through the the day-to-day
yeah well I I think you at least you
have an honest kind of pragmatic view I
think of your day I don't think as many
people are being as honest with
themselves when I ask that so I always
(48:38):
love hearing what folks say
um I keep talking all day Ben
um we're at 50 minutes which is like 10
minutes longer than shows usually go so
um I I'm gonna I I I wanna have more
conversations with you one I want to
bring in Deepa for my team to talk to
you she's she gets the product
management I think you two would
(49:00):
um really dive and maybe we could do an
added uh interview or a separate segment
where she and and you talk
um the other I would love to dive into
with you sometime is the Ed Tech the the
education part of it because you love
teaching
um I have to admit my wife is
um she's a tech specialist is what her
career's been so she like Spencer fellow
(49:21):
from uh from Columbia School of
Education teaching technology G in the
classrooms how does it work that's what
she's done for the last decade so I've
done apis and she's done Ed Tech and
overlap so
um but that'll be for another show we'll
have to uh
talk about that because I think learning
um and and is a is the number one most
(49:44):
important thing we can do be doing in
the API space and I I think it's under
invested we're not doing as much as we
should so
um
yeah I appreciate the work that you're
doing too to help with that because
there there needs to be a lot more
resources on that the API side so I
appreciate the podcast that that you're
putting together and all the amazing
(50:04):
people that you bring on to help with
that education
well do we do what we can thank you
um well I gotta close it up there uh to
be continued though because I love
talking with you Ben this has been uh an
amazing journey thank you for sharing
and thanks for joining me today yeah
thanks looking forward to the next one
definitely thanks again to Ben for
(50:26):
stopping by you can find more about Ben
on LinkedIn or Zoom at
zoom.us you can subscribe to the
breaking changes podcast at postman.com
events slash breaking Dash changes I'm
your host Kin Lane and until next time
cheers
(50:50):
[Music]
foreign
(00:02):
[Music]
thank you for tuning in to today's full
episode of the breaking changes podcast
I'm your host and chief evangelist for
Postman Kin Lane with Breaking Changes
we explore topics from the world of APIs
but through the lens of business and
Engineering leadership joining me today
(00:23):
we have Ben Mackley Solutions engineer
manager over at Zoom Ben shared with me
such a powerful view of how important it
is for today's API lifecycle to be a
business-led affair Shifting the long
history of it being an I.T thing
so let's dive in uh start with the
(00:43):
basics
who are you and what do you do
yeah so I'm I'm Ben Mackley I'm a
Solutions architect manager at Zoom and
I connect enterprise software systems
together as the solutions architect
manager so my team works with our
platform so we it's called Zoom contact
center now but we were essentially a
(01:05):
chatbot and we connect with
other crms and other software providers
out there so our team is really involved
in the nitty-gritty with the APIs making
sure that the data is Flowing properly
that we're we're secure when we're
connecting systems together and that are
we're fulfilling the customer's business
(01:25):
needs as well
interesting I like that it's not just
about the connections and and What flows
through the pipes it's about actually
meeting meeting business needs of people
the human beings that are involved here
which is so important but we'll we'll
dive into this a little bit uh the the
Integrations part of this is really
interesting but I want to understand I
(01:46):
want uh everyone to understand a little
bit more about you and and your journey
where you've come from so how where do
you you know where where'd you get into
all this how did you end up at Zoom
so it's been a winding journey I think
with with most people's careers that end
up as as Architects it usually takes a
winding path
(02:06):
um so I I started a company out of
school and I'm I haven't been
technically minded
um at least when you know I was going
through school and at the beginning of
my career uh I was more interested in in
starting things and doing a startup and
solving education problems specifically
I realized that technology was the way
to create an impact
(02:28):
um across that would scale across many
people
and because of that I got into
technology and the startup didn't end up
working out but that led down a path
where I was kind of searching for what
to do so I did product management I was
an engineer for a while and then I
finally found my home in Solutions
engineering and solutions engineering is
(02:50):
working on with the sales team selling
B2B software and as the solutions
engineer I was often doing the
implementations and would be connecting
the systems together and and that's kind
of what led into Solutions architecture
um where where I'm at now and I I didn't
realize this but throughout my career
I've worked on platforms and generally
(03:11):
within the industry there's more
products than there are platforms and I
guess when I say platform it's not like
AWS or Google Cloud as far as hosting
all of the services it's more having a
One-Stop shop to do everything that a
business user would need to do so I
worked at a process automation company
that
(03:33):
um automated
processes within within different
companies whether it was HR onboarding
flows or more on the the technical end
um
and then I've also worked at a user
monitoring company Quantum metric they
did a combination of application
performance monitoring as well as like
user experience monitoring that was a
(03:54):
really interesting experience and now
um interestingly enough at solvi it was
the first time that I was working with a
a product team but then we got bought by
Zoom to be a part of a broader platform
with Zoom contact center
I love love the journey
um definitely I love the product
(04:16):
management engineering Solutions
architecture and engineering kind of
focus and journey because I think
I I don't think those
those career paths are getting as much
of attention in this kind of Silicon
Valley or technology narrative you
hear a lot about engineers and being
an engineer you're starting to hear more
(04:37):
about product management I wouldn't say
it it Rivals as much but I hear very
little advice guidance uh showcasing
that Solutions engineering or Solutions
architecture is even a path that
you can find and you can go to so how
like I mean were you just
why why did you end up here because it
(05:00):
it spoke to you more or like what are
the reasons
so I I feel like the sales teams in in
B2B they they need
um somebody that thinks both on a
business side but also understands the
product and I I think I got into sales
because my uh working in the startup I
(05:20):
realized how important sales is to the
the lifeblood of a company if you're not
selling your product if you're not
interacting with your customers then the
product will die eventually and then the
business will die because there's no
Revenue coming in and so for me I've
always wanted to
solve the biggest problems that are out
there and I think within technology
(05:41):
there's a lot of problems that need to
be solved but the the flow of solving a
problem always starts with a customer's
pain not with a technical solution
um and so for me I think I got into
Solutions engineering because I wanted
to understand that life cycle of
identifying problems and solving
problems in the right way and coming
(06:03):
from the startup world where you wear
many hats I think Solutions engineering
is very very similar you have to
understand the technology you have to
understand the customer you have to be
able to communicate with the customer
and so information has to flow many
different directions and much like
product Management Solutions engineering
is is a connector role which I think it
(06:24):
makes a lot of sense that Solutions
engineers and solutions Architects work
with apis because apis do the same
connecting different systems together
and making sure that the technology can
communicate in the same way well I guess
not the same way but in a similar way
that that we communicate as humans
yeah it's it's about Connections I think
it's that's an important uh
(06:47):
highlight emphasis that I I I get and I
I've thought about but I think you you
put it pretty succinctly and the
difference between Solutions and product
management so I always say uh the the
the API space the whole Tech realm is
very API producer-centric
um and that's kind of Def that narrative
(07:08):
has been set kind of by API management
providers analysts like Gartner and
Forrester and others and vendors talking
about producing apis but for me the best
API producers are also API consumers
because you get you understand that pain
so from a product management and API
(07:29):
producer perspective I'm producing an
API uh I need alignment between business
and my developers who's producing this
but I I need to find that alignment with
consumers I need that feedback loop and
we iterate on this API and the velocity
we're able to achieve and the value
generated is is based upon my bridge as
(07:50):
an API product manager but what you're
describing as as in the solutions realm
is the same but from a consumer side
like I'm guessing you you see you suffer
a lot of pain and see a lot of things
problems that are introduced by the the
apis you're depending on at Zoom for
(08:10):
Integrations these CRM Solutions and
others so what what sort of what War
Stories do you got for us as far as from
that perspective
so I I think that's you described it
really well that
um
most API consumers so I'm more of an API
consumer as a Solutions architect as
opposed to an API Creator and I think
most API creators don't often consume
(08:32):
their own apis that they're they're
developing
um so I've seen it both ways where
um when I was working at a process maker
doing process automation we had an a
phenomenal engineering team
they they rebuilt the platform API first
and so they had the swaggered
documentation for all the endpoints you
(08:54):
can actually run our entire system in a
headless way without our UI using our
API endpoints
and they they did a phenomenal job of
creating a system a platform that we
could tap into without having to go to
the the engineering team for for custom
requests
(09:15):
and on on the flip side I I felt um we
were getting there and we were improving
as far as helping them on the consumer
side uh of giving them feedback of of
what would be
um you know helpful but I feel like that
was almost underutilized so the
marketing aspect of the product that
they build like letting our customers
know and then letting our sales people
(09:35):
know and and how to sell our product to
a technical audience I feel like there
there was a huge gap there
um and
uh I was I was there at the beginning
stages of the product so I I don't know
where they've gone since but hopefully
they've they've been able to make that
shift to to sell to those technical
audiences and
(09:57):
um educate the consumers in a way uh
where they can understand the power of
the product
um and then I've I guess I've been on
the opposite side where as a Solutions
architect we've been craving uh We've
we've craved apis on on our own side
that our engineering team could build
those so that we could pass the work off
(10:17):
to the customer instead of having to do
custom work
and and building custom products for
every
um you know every customer that we have
so I think it goes both ways and having
a connection between the team that's
building the product management team and
the engineers that are creating the apis
and then the consumers that are going to
(10:38):
be utilizing them whether it's customers
or you know that the internal users at
the company is is really important but I
know that you've done a lot of work on
this space so what what have you found
to be effective as far as
like working with with customers has
there been a process or a method that
you've used to get the feedback when
you're creating the apis that have been
(11:00):
helpful
yeah I mean there's this is definitely
one of those areas that
um
I've seen different things work in
different organizations and different
ecosystems because of the culture or the
industry or uh where I think everyone
collectively is in their API Journey so
I like most areas of API livestock I'm
(11:22):
always uh asterisks you know this is not
one solution that's going to fix you
know fix it for everybody but uh
definitely feedback loops that are what
I'm seeing right now shift is the The
Narrative around apis for the last
decade has been here's a portal
here's reference documentation for
(11:44):
everything
and here's us you can submit a ticket
here's a community forum and we'll we'll
we'll use the community forum and the
tickets as as this feedback loop and
what I've seen is is with with companies
like uh Twitter is a good example of
this uh not big on naming names but
(12:06):
Twitter I think is a is a really
interesting example of they've
they get a lot of hostility in that form
because for some reason forums as as a
feedback loop mechanism
brings out
the anger in some of us and we say
things in ways that either are we feel
empowered to be kind of mean and
(12:27):
ruthless or maybe we're just being not
heard in the right way and what I'm
seeing evolve right now is is developer
experience and investment in developer
experience
change and diversify these feedback
loops that you set up so the Forum and
the ticket
becomes blog posts and social feedback
(12:48):
around it or it becomes
um it's it becomes channels that are
very suited to the audience who who
you're targeting because you've done
your research you've done your due
diligence on who who are we targeting
with this so you're you're using Tick
Tock appropriately because you're
targeting the Right audience or you're
using Hacker News because you know who
(13:09):
you're going after is right there and so
your feedback loops gets tailored to to
that that channel that that target
audience if it's internal it's done
through teams and and the feedback loop
if it's for microservices and apis for a
certain domain within an Enterprise so
that developer experience that
(13:29):
investment in that consciously
constructing a feedback loop had it
really defines what how you gather that
how you use it in the tone of of it and
back to the Twitter example Twitter has
started for their Twitter spaces API
they before they got to work on it they
actually
fired up a Twitter spaces to have a
(13:51):
audio conversation a town hall
discussion about what should the Twitter
spaces API be or do or should we even
have one and
a whole bunch of people showed up a
bunch of developers in the developer
community and uh Danielle a the uh the
product manager in charge was was uh
(14:12):
looked at some of the names and goes oh
no like these are some of the angry
people from The Forum oh my gosh oh my
gosh and had a lot of anxiety about that
but then once turned on the audio
they were very cordial and very social
like and so he's trying to figure out
was it that they felt more empowered to
be mean and and cruel on the Forum did
(14:32):
he interpret it wrong is the audio more
of an experience the town hall format
and an audio people are more more uh
friendlier he's still processing all of
that but I guess my my point back
answering to your question is
developer experiences shifting
investment developer experience is
Shifting how we construct these feedback
(14:54):
loops and the maturity and visibility
public private partner of our apis
um very much dictates what channels we
use and how we gather feedback and then
how we listen and filter through based
upon the volume of feedback we're
getting
yeah I think that's that's an incredibly
important uh point and when I was
(15:14):
studying education I did my Master's in
educational technology and the the way
that we learn is through feedback and
whether that's uh technologically so
like with apis and uh with programs that
we write the reason that we have error
logs is because it's a feedback
mechanism
and like what you were describing with
Twitter it makes a lot of sense because
(15:37):
companies that are open to feedback are
the ones that are going to be improving
and creating this not only great
developer experience but I think the
great developer experience translates to
a great user experience down the road
and really a product that serves the
customers as opposed to a product that
customers have to adapt to to their own
(15:58):
environment so that's I think that's an
interesting
an interesting story but also an
interesting idea of developing these
feedback loops according to the the
product that it needs like might be
Hacker News might be you know Twitter
feed might be just issues on GitHub that
are aren't posted but really every
(16:19):
product that is is open to feedback
we'll we'll get that
um
what's the
what's the cultural like I see a lot of
folks who who talk about feedback loops
talk about product management talk about
empathy they're even like how do we
develop empathy for our customers but
(16:39):
really aren't honest about it I would
say to the degree because it's it's a
little scary to to be to open yourself
up to these the this criticism and the
because you're probably getting feedback
from some of the loudest folks but like
so how do you how do you find the signal
in this noise and what you're doing as
far as I mean you're hearing business
(17:01):
goals business you need a business
alignment you got developers and and
teams and you've got customers how do
you find the signal in that noise
yeah it's I mean there's so many signals
that that were being attacked with like
both internally and then externally uh
that it's it's hard to parse all of that
out and I think that's that's really the
(17:22):
role um of what great product managers
and great solution Architects do is
they're able to determine uh the signal
out of the noise
and so a few things that I I generally
do when I when I start a project is uh
getting face-to-face time with a
customer because
(17:43):
um I think there's the qualitative
aspect and then the quantitative aspect
and with signals I I think you need to
marry both of those the qualitative with
the quantitative to under to understand
and to correlate because a discussion
with a customer will often surface their
major pain points and the process that
we generally go through we call it
(18:05):
scoping but we'll we'll talk through
what their pain points are and what I
didn't and eventually we get to a
desired solution but during that process
we take that qualitative feedback in of
what's you know important to them what
they want to get to and generally it
might be something like uh where's my
order function that that's built into
our bot or where's my order or
(18:26):
um can I get a refund for for an item
and based on the feedback of the
problems they're facing we'll compare
that to my in most cases it's Financial
so like how much time will it take and
how much resources will it end up being
to create the solution they have and if
if it's a huge problem for them but it's
only I don't know 50 000 or a hundred
(18:48):
thousand dollar impact that they would
have and it's going to cost just as much
to create it they're not going to see
the ROI and so even though it would
resolve their pain Point
um the the numbers aren't correlating
with the qualitative information and so
I think with
um by pulling multiple sources the
qualitative and the quantitative you're
(19:09):
able to triangulate what's what's
actually important from all the
indicators that are coming through and
the general rule of thumb that that I
have when making these decisions and
then I got my team on is if we're if
we're not going to see a 3X Roi then
there's probably something else out
there that we focus our time and
attention on which means we need to to
(19:29):
dig further to see if there's other
problems or other stakeholders that
would be involved we need other data
points to understand
what what else could be out there and
not just focus on what's in front of us
so it's a long answer to the question
but I think getting as many data sources
as possible and then trying to
(19:50):
triangulate them and correlate them to
see not only what's feasible about
what's going to have the biggest impact
and then from there I think it's a it's
really hard to do it perfectly but
creating a prioritization and a project
plan and coming to agreement on that is
that the process that I've found but is
there anything that you've done
(20:11):
um as far as understanding
how to how to parse out the signal from
the noise that you get When developing
products
um you know I mean I I I'm the first to
admit so I I wouldn't be a good product
manager because I
I get too emotionally caught up I wanna
I wanna talk to everybody individually I
(20:33):
want to hear I want to you know for
breaking changes like I'm this show
won't go out till January because I've
already talked to so many people like
and and so many and we're releasing two
a week that these are super valuable
conversations that I'm having like the
number one reason I do breaking changes
is to get to talk to you and to learn me
(20:54):
learning from you but then there's also
this this bigger mechanism where I
filter out and find the signal here and
how does it how does this fit into the
overall life cycle like everything
you're doing right now is you're talking
about I'm gonna put into our Master
guidance around feedback loops and and
product management and so this is
(21:14):
actually my one of my mechanic you know
channels for my feedback loops and this
is part of my job in building a a API
lifecycle and governance a producer and
consumer life cycle that all works
together
product this is what I'm building out of
these conversations just so you know
you're a guinea pig so you're you're
like in the physical feedback loop right
(21:35):
now and I'm doing what you just asked me
how I do it so
my challenge is is I love just talking
to you and I get so caught up in the
moment that I forget about the big
picture and I just want to make everyone
like they're so right like and and I get
like I'll be talking about you for the
next like four or five days and and
everything we did but then in the bigger
(21:57):
picture I'll lose that signal and get
distracted by the noise or the next
signal so I actually would not make a
good product management and I need
people helping me with that and luckily
I have a team behind the scenes here who
helps me stay on track because otherwise
I don't think I would get a product out
the door I would have all the
conversations I would gather all the
(22:17):
signals but I wouldn't get it out the
door but with that said uh surround
yourself with smart people
um who can pay attention to things that
maybe you don't see diverse people
diverse voices
um that are going to ask questions that
you just didn't even think about or see
or point out data from it so having
(22:39):
those people are around you
prioritizing channels and and what what
matters the most because we can we can
find too many channels we can we can
gather too much information and know
when you need to start filtering that
down but then for me I just follow my
gut and what what I feel intuitively is
(23:01):
going to matter the most
um based upon those conversations I had
and my understanding of the space and
people and I talk to so many people
um I trust my God a lot I know gut based
isn't probably a sensible way to in
scalable way but I I talk to a lot of
people and I've been doing this a while
I I trust my gut but
(23:21):
I don't know if that's right or wrong
yeah I mean I call it you're doing so
much qualitative uh you have so many
qualitative feedback loops through the
conversation that it's probably why you
can trust your guidance you've
you've done this so many times that if
something feels off there's even if you
can't pinpoint the reason there's
there's data behind it uh but the the
gut comes much quicker than the data
(23:44):
does and yeah I think that's why it's
important that your team
yeah definitely the team is critical for
me like because I that's why I'm at
Postman because I um I was doing this a
long time on my own independently and it
only got me so far you have to have a
team you have to have people working but
you have to and I'm also learning one of
(24:05):
the things I'm learning from my team so
uh uh hired someone named Deepa goyas
from PayPal recently and she's helping
me think through all the product manager
developer experience stuff and
repeatedly in conversations I find
myself she catches me in a uh API
producer mindset where she's coming at
it from a developer Journey from a
(24:26):
consumer perspective and she's like what
she asked me like well that just didn't
make sense what you just said like it
and and I explained again yes it does
and she's like well that's that's you're
the producer like no this is about the
consumer and she's constantly advocating
for the consumer and getting and I just
made me realize how locked into this
mindset I am and that's really what I
(24:48):
think captured me about you and your
perspective so everything that you just
said about
um prioritization and and finding the
signal
how do you reconcile that with the apis
you depend on so your we won't name
names but you connecting to a CRM
solution that is trying to prioritize
(25:08):
what they should build and what they
should make available they have somewhat
of a maybe a a barrier between you and
them
um you know you have one or two channels
that you can you know submit your
feedback like how do you make yourself
heard or how much time do you make
carve out for being the signal for these
(25:29):
providers these producers and giving
them what they need to produce not just
what you need but a better product
that's going to make your job easier
down the road
yeah I think the answer is I don't carve
enough time out to get feedback and to
help the producers create better
products I think internally it's really
easy because you know having Zoom chat
(25:51):
or slack or you know the internal
communication tools it's really easy for
me to connect with my
um the Integrations engineering team or
our the back end teams that are creating
these apis you know we we have a really
good relationship and we've developed
that over time with other vendors
um so oftentimes we'll come into an
(26:11):
implementation and we'll we'll be one of
two or three or four different vendors
working on the project and it's a lot
harder because we don't have that trust
and we haven't developed a set routine
as far as how we communicate and you
know it's learning that
learning that relationship every time
(26:33):
and so I think for me the the process
that I I generally follow is if I have
to choose who I'm going to be working
with if I have to choose the producers
that I'm I'm working with I'm going to
look for the ones that are open the ones
that have invested in their developer
experience and have created
documentation and that have done
marketing or that have resources to talk
(26:55):
to others in the community because I
know that my when I do come with
feedback to them that they'll at least
hear that and internalize it and it
won't fall in deaf ears I was talking
with a friend of mine who's
um who's using the the company that I
worked at previously and he was trying
to integrate with customer on the the
(27:18):
chat side and he was telling me that the
process that they have they don't bubble
up their errors
um so it's it's a very tight system and
there's always a trade-off right having
an open system means that there's higher
security vulnerabilities and so you
can't be completely open but at the same
time if you're completely closed it's
it's very difficult
um for others to work with you and he
(27:38):
was having this problem where the error
messages weren't getting bubbled up and
the events weren't bubbling up and so he
wasn't able to connect uh the the
systems together to create this
monitoring with the application and with
the chat so the chat was essentially not
showing up in that that real-time user
monitoring that they had and he talked
with the customer team and he brought
(28:00):
this up he's like not seeing the errors
and I'm not getting the events that I
need
to handle these issues and the customer
team essentially said yeah we know it's
it's because it's going to be less
secure and we'll let our development
team know but we can't make any promises
and just like hearing his frustration
and having gone through that myself so
many different times
(28:21):
um I I'm in a position where I can
choose who I work with
um at least more than I have earlier on
in my career and so that's what I
generally look for now is people that
are willing to be open and to take
feedback and give feedback so that that
that feedback loop is really tight so
that we can deliver product quickly and
that we can deliver the best developer
(28:42):
experience and customer experience and
then I think from there once the the
relationship is established it's it's
really just doing the work and kind of
building on that but setting everything
up for success and choosing the right
people to work with is incredibly
important throughout that process
yeah the heard a couple really
(29:04):
interesting things in there the
so I've long advocated that part of your
feedback loop the design of your API is
part of your feedback loop meaning the
status codes you return is part of the
the feedback loop with your consumer and
so thoughtful design is is really
important because you're gonna minimize
(29:26):
people having to come and submit a
ticket and and be the I guess the direct
uh feedback loop mechanisms because
your your this indirect this kind of
soft feedback loop part of your design
is good or bad so your volume tickets
will be lower or higher based upon this
so that's like the design of your API is
(29:47):
is very much part of your feedback loop
but the the second dimension of what I
heard you say is for me apis are a
balance between access and control
and I and and I see this I was we just
released the stated API report today at
Postman and one of the biggest surprises
for me is is
(30:08):
um
or not surprises things I want to see
more of is it's heavily skewed towards
internal apis and microservices meaning
the majority we ask people where are you
doing private partner or public apis and
it's overwhelming with like 50 60
private and then a smaller a slice of
Partners and a smaller slice of public
(30:30):
because people have a lot of anxiety
about opening up they don't have a lot
of confidence in in in in this balance
what you just described in this company
they just don't they're worried about
opening up the pulling back the curtains
too much and giving access to too many
errors because they don't they don't
have a lot of security confidence
observability monitoring and so so
(30:52):
really I think what you just described
is how much your your design and the
operation of your API is your feedback
loop and is does set this tone for what
you're going to be able to gather
um and and filter out that signal from
the noise
yeah I mean it I think it all starts in
the design phase so on the product
(31:13):
design how how are we developing error
codes it seems like such a trivial thing
but in the the long run of launching an
application and maintaining an
application the maintenance is much
lower if the design is specced out
properly and user input is taken and
like you do the testing to to identify
like what error codes should be should
(31:34):
be coming up so it's I mean it's it's a
process and I think it's one of the
reasons why it's so difficult to do well
I've I've seen some companies that have
done it well but more often than not
um there's a lot of room for improvement
with with most companies and I think the
reason why it's so difficult to do well
is because the design phase takes so
(31:55):
much time and effort and for me what
I've found is there's the adage measured
twice cut once and I think within
software design and especially with API
development meant the it's more spend
eighty percent of your time designing
and getting input and testing up front
and then that twenty percent of time
(32:16):
like the build is actually easy and
should be the shortest amount of time uh
as far as the the entire life cycle of
creating a product and it's it's really
hard to do design well and I think you
know coming back to that that idea of
product management
um I think good product management takes
the time to do design well and to get
customer feedback and include that in
(32:38):
the product interesting and that gets
that so one of the idea things I've
noticed in the space is we have a lot of
times trouble having conversations
because we're not grounded in some some
fundamental things one example is the
life cycle when I ask people what is the
API lifecycle in an organization I would
get 10 different answers and once I did
(32:59):
that at Postman and got 10 different
answers I'm like all right this is a
problem because like we're not all in
agreement we like verbally say we're in
agreement on what the life cycle is but
when you get down to it it's actually no
we're not and I noticed that the life
cycle for a lot of you go talk to
developers is it's develop deploy
(33:20):
and then somewhere in there we added
tests so that you well you develop and
you build your test driven development
and then you deploy and those tests
benefit and then we start shifting
security a little bit left so you got a
Security review in there and you got
some security but it's still development
test security and deploy
and then once we start adding this
(33:41):
Define and design stage we got
pitchforks from developers going no I'm
not a designer I don't I'm not a yamler
I'm not going to design in yaml I'm you
know I'm a developer and so code first
kind of is winning out over design first
but what I heard you say is this is a
product management task so I feel like
(34:01):
the Define and design stage and then
we're also seeing it so that's the
bookend at the beginning of the
conversation once you deploy there's
observe I have observability and
distribute as the next stages those
bookends those two areas are also
product manager because what metrics and
how am I measuring all success all of
(34:22):
this and then am I Distributing it and
documenting getting it in front of the
right people and then getting that
feedback loop back to the beginning and
those so those book and stages
I I see a lot of groups expecting their
developers to do those but the ones that
I'm seeing be successful are the ones
who are bringing in product managers and
Architects to coll to work with those
(34:43):
product managers to do well and then
product marketers I would say on the
distribute side there needs to be
product marketers involved in that to
actually get it out so
that's a long life cycle right for a
product manager to work with customers
and work with the internal teams to
Define and then design a solution
because including engineering is really
(35:05):
important in that stuff and I think
they'd like to be included they just
don't like to run it it has been my
experience they like writing code they
don't like defining business problems
but that that life cycle
it takes a long time and so I think
there's there's information gaps and I
think that's one of the things that I've
realized in in my role recently
(35:27):
um you know stepping into management is
most problems are communication problems
and like even at the API level that's
what we've been talking about of error
codes is a way to communicate that
something is broken and so building good
communication paths and I'm doing it in
an agile way where it's iterative where
you can go through that process and then
(35:49):
come back and go go through it multiple
times in the title that Loop is the the
quicker the product will get out and the
higher quality it will be so I think
oftentimes we think that it's a divide
like quality if we want a higher quality
product it's going to take longer but if
at least in my experience it's been the
opposite the the products that ship
(36:10):
quicker end up being higher quality
because they have that Loop tied down
pretty quickly yeah the communication is
key so so I'm gonna uh let the cat out
of the bag here with the podcast called
breaking changes
there are no breaking changes folks
there are just poorly communicated
changes that cause systems to break so I
(36:34):
would totally support I totally support
you that it's all about communication
and it's all about us human beings not
doing that well or or doing it well
yeah and has there been something that
you found that's that makes that
effective of like going through those
steps and like building uh a process as
far as going from design to implemented
(36:56):
like the development to the deployment
to the observability to product
marketing and getting that Loop done
yeah the the foundational piece which I
just talked about is the life cycle is
is the first grounding piece that's
missing is people don't have a common
definition of what the life cycle is so
how do we get from Define to uh
distribute and then back again so
(37:18):
everyone's just wandering around running
around and doing what they can and
there's some overlap in it but once you
get people with a clear life cycle
definition saying the same things being
able to uh to speak to it in a common
way things stabilize the second one is
role based and so who are the owners or
(37:41):
who are the stakeholders at each of
those stages of the life cycle who
should be in the room and who shouldn't
be
um because this is what you said about
developers is like developers want to be
included and Define and design they just
don't want to own it and they don't want
to do all that business research so
having very clear ownership and and
(38:02):
roles defined for each stage of the life
cycle is is the next grounding piece
because
then you know who to communicate with
you know hey
hey Joanne I just finished uh the
requirements can you look at it hey Ted
I just finished the mocking and why
(38:22):
don't you play with it and see if it
actually meets the contract that we
discussed so and without those clear
stages and roles
that communication doesn't happen and
that's where the friction comes in
and maybe this is just the developer
mindset but to me it's almost like
designing good applications is the same
as designing good processes for building
(38:45):
those applications and just like we
would Define a get request and say which
parameter or which query parameters we
can use with that gitrobquest I think
Divine defining a role is very similar
to API documentation where if we say who
owns a role and like what
responsibilities are associated with
(39:05):
that role
um and then communicating that with the
team so that everybody knows
uh who else to talk to allows that that
information to flow much more smoothly
so it's I mean it's from an architect
mindset it's like interesting to me how
the same principles apply whether we're
dealing with code or whether we're
(39:25):
dealing with humans or you know
something completely different yeah yeah
well I was trying to write this up in an
articulate way yesterday but um is
are everything we're doing for
applications and Integrations the
reasons why we're doing apis the same
applies to the apis because our AP the
(39:47):
infrastructure we use to deliver each
stage of their apis have apis behind
them and so we can automate we can
communicate there's a lot of things you
can do
um strategically with your API lifecycle
that you can accomplish with apis
that'll help you automate stabilize
communicate iterate all these
(40:10):
collaborate all these things that are
the nutrients that are the deficiencies
that exist in the life cycle and so we
notice this with our apps we were
building web apps and then we're
building multiple mobile apps then we're
building partner Integrations here and
there and we started identifying along
the way we need a strategy for this we
(40:31):
need an API strategy for these resources
these capabilities and experiences
now we just need a strategy for our apis
also and and the life cycle and and the
governance in a similar way and so that
we can begin to stabilize how how we do
apis and get more consistent and how we
communicate because without that
(40:52):
the the humans are the biggest problem
because we're that's how we work you
know we we've got to be able to
collaborate and work together and
understand and and find that forward
motion and without that structure and
framework we're never going to get there
so how have you seen the best systems
set up so like you described that that
(41:13):
flow of like product management book
ending the development and then like on
the observability piece I imagine
there's a devops team that helps with
the deployments and setting up those
process and product marketing
um to like help interface with customers
but I mean there it takes coordination
so I'm like who's sitting on top of that
like what is the best organizational
design to help with good API design like
(41:36):
I imagine with everyone that you talk to
that you have some
um some good Instagram
yeah no I'm working on on I have a lot
of good Insight working on best how to
put that out there and communicate that
and like I said these these these
conversations are part of that and so I
hear I talk to a lot of groups who have
a center of excellences when it comes to
(41:57):
their API design their governance that
are creating design guidelines security
guidelines things that are cross-cutting
um uh across the life cycle so defining
the life cycle but defining how we
document how we test how we secure and
providing
um uh as much guidance and enablement
(42:18):
along those lines from a central
standpoint now with that said I've also
seen a lot of groups
try to govern
with a capital G governance from top
down and hand these down to teams and
just cause Mayhem because it was
mandated it was everything every api's
got to be exactly the same every team's
(42:39):
got to operate exactly the same use the
same Source control and CI CD and it's
just not how it works in across a an
often distributed Enterprise landscape
that's either broken up by lines of
business tribal boundaries Acquisitions
geographic regions regulatory compliant
(42:59):
you know so the the ones that I see
working are there is a centralized
guidance and investment in resources
um they have Champions that are part of
Federated teams who then help Champion
those centralized Concepts tasks but
(43:21):
capital G governance on the ground floor
is is lowercase G governance or more
appropriately enablement so I'm I can
apply these standards because they were
someone else did the work to go find
them and to make it easy for me to do it
in my vs code and apply standard
pagination or standard design or
(43:41):
standard
um and and I've got linting rules
someone thoughtfully put together a set
of spectral linting rules that when I'm
editing a yaml document or a Json
document for my API contract it's
catching most of the mistakes that I'm
gonna make as a designer and enabling me
to deliver a better API and oh by the
way I can have those in the pipeline if
(44:03):
I want if my team teams mature enough
and my API is mature enough I can have
them catch it in the CI CD pipeline
those those those design gaps because
you know even me as an expert like you
know Monday Tuesday I'm great at
remembering all those but you know
Thursday I woke up in a bad mood I came
to work I pushed some code and or a API
(44:23):
contract and it and I forgot 30 things
because I was just in a really bad mood
I know better
um so I need that that pipeline to catch
that for me and I don't see it as
enforcement so like being able to
centrally Define a lot of these
distribute and enable teams to use as
much but then also leave room for
(44:44):
autonomy and agency for teams to do what
they need that may work and be a better
solution and then feedback loops
keep that that API strategy guidance
governance a living kind of feedback
loop and then gather feedback from those
Champions and teams repeat repeat but
you have to embrace a Federated approach
(45:06):
and find the balance between
centralization and Federation that's
going to work and then you bring in the
Ops Team how does how does your Ops
teams fit into that how do your security
teams fit into that those cross-cutting
functions and then you just find the
dance that's going to work the best
I've been I've been studying agile and
(45:27):
how to actually uh follow agile and I
think one of the principles is
self-organizing teams end up producing
better code and I like that idea of like
that it's not a central governance uh
from my mandating things from the top
down but it's almost like uh providing
the teams with the tools they need
whether it's a ciucd platform or the
(45:49):
linting to check the code so that way
the teams can focus on what they do best
which is writing code or you know if
it's a product management team talking
with customers defining what the actual
business problems are and then designing
you know the the initial solution and
coordinating between people but having I
(46:09):
think that idea of enabling teams with
providing them the resources and the
structures and really the tools that
they need to succeed is really important
so that's uh that's something that I'm
gonna to try to do but I know that it
takes a coordinated approach right it
takes
many different people coming together
(46:30):
and agreeing
on that
yeah that's that's the trick right there
and and so for for my last question I
mean I could keep talking to you all day
this is great but
um for podcast sake I remember I got to
keep reminding me we're recording a
podcast
um one last question for you along those
lines is how much of your day is
technology how much of its business and
(46:52):
how much of his people related things
would you say
um I
so I find myself having to add
technology to my my schedule because if
not it would would just go away and I've
felt that over the last few weeks
especially it's like sometimes I'll come
into a project and get deep in the
technology
so I mean it obviously fluctuates but
(47:12):
I'd say on average
um it's at least 50 people
um and then maybe 20 30 on the the
business side and 20 on the technology
so
I think uh being involved in the Techno
I found that with my roles that I need
to be involved in technology outside of
work in order to stay current and stay
(47:33):
relevant and to help me on everything
else I'm doing but the demands of the
day
um being a manager being thrown in
meetings and working out HR issues tend
to take the majority of the time but the
fun stuff what I really love doing is is
teaching on the technology so like I
have past experience in boot camps and I
(47:54):
think one of my my favorite
responsibilities as a manager is is
mentoring and helping the team find the
positions that work best for them and
then like connecting everybody together
to build great products so I I wish it
was reversed I wish it was you know 80
percent on on the people side with the
technology and you know 20 business and
(48:16):
HR stuff but yeah it's sad reality I
think of being managers having to to go
through the the day-to-day
yeah well I I think you at least you
have an honest kind of pragmatic view I
think of your day I don't think as many
people are being as honest with
themselves when I ask that so I always
(48:38):
love hearing what folks say
um I keep talking all day Ben
um we're at 50 minutes which is like 10
minutes longer than shows usually go so
um I I'm gonna I I I wanna have more
conversations with you one I want to
bring in Deepa for my team to talk to
you she's she gets the product
management I think you two would
(49:00):
um really dive and maybe we could do an
added uh interview or a separate segment
where she and and you talk
um the other I would love to dive into
with you sometime is the Ed Tech the the
education part of it because you love
teaching
um I have to admit my wife is
um she's a tech specialist is what her
career's been so she like Spencer fellow
(49:21):
from uh from Columbia School of
Education teaching technology G in the
classrooms how does it work that's what
she's done for the last decade so I've
done apis and she's done Ed Tech and
overlap so
um but that'll be for another show we'll
have to uh
talk about that because I think learning
um and and is a is the number one most
(49:44):
important thing we can do be doing in
the API space and I I think it's under
invested we're not doing as much as we
should so
um
yeah I appreciate the work that you're
doing too to help with that because
there there needs to be a lot more
resources on that the API side so I
appreciate the podcast that that you're
putting together and all the amazing
(50:04):
people that you bring on to help with
that education
well do we do what we can thank you
um well I gotta close it up there uh to
be continued though because I love
talking with you Ben this has been uh an
amazing journey thank you for sharing
and thanks for joining me today yeah
thanks looking forward to the next one
definitely thanks again to Ben for
(50:26):
stopping by you can find more about Ben
on LinkedIn or Zoom at
zoom.us you can subscribe to the
breaking changes podcast at postman.com
events slash breaking Dash changes I'm
your host Kin Lane and until next time
cheers
(50:50):
[Music]
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.