Subscribe
Share
Share
Embed
This week on the API Intersection podcast, we spoke with Barb Maclean, who up until very recently worked her entire career at Celero Solutions as a VP of Integrations and Analytics. She is now a founder of her own company barbmaclean.co. With her over twenty years at Celero, a credit union company, she’s helped grow her team exponentially and make transformational change via their API program. She started at the help desk, dabbled in a product role, and eventually expanded all the way up to the VP of Integrations and Analytics.
To subscribe to the podcast, visit https://stoplight.io/podcast
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/
--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.
Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro). Valid until December 31, 2022
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
I'm Jason
Harmon and this is API intersection
where you'll get insights from experienced
API practitioners to learn best
practices on things
like API design, governance, identity,
versioning and more.
Welcome back to API Intersection.
So I'll be honest with you guys.
I don't know and always enjoy
talking about fintech stuff.
You know, it's a complicated, compliance,
filled, messy kind of world.
And next meal, anxious.
I know I've worked in that space before,
but I don't know.
It's doubtful it'll happen again.
At any rate, I think today's guest
convinced me that it was worth
digging into.
And I think it's a different
look at kind of the,
you know, edge of fintech stuff
here and maybe a more approachable scale
than we often hear about.
So first off, my
trusty sidekick, Hannah,
thanks for joining again.
Thanks for having me.
And our guest today is Barb McLean,
Vice President of Integration
and Analytics at Solaris Solutions.
Barb, thanks for coming on.
And hey, Jason,
thanks for having me today.
So Barb, tell our listeners
a little bit about yourself.
So I'm a born and raised prairie Canadian
and I've spent my entire career
working with Celerio.
It's the only real job I've ever had
and we've had a lot of opportunities
to do some fun and interesting things.
Working with credit unions over the years,
credit unions
are our primary set of customers
and indirectly our owners.
So it's a really interesting space
to work in.
And you know,
I think I get to work with the best team.
We have a lot of fun,
we do interesting things.
So it's a great spot to be.
Yeah, I,
we were chatting in the green room before
and I probably should have said this
before, but
the fact that you've only worked
at one company
your whole career kind of freaks me out.
It's a bit unusual.
There's not a lot of folks
out there like me anymore these days.
It's true.
Yeah. What's the story there like?
It must be something really great, huh?
Well, I think it's probably one of those.
You know, your parents imparted
some wisdom on you when you were a kid.
And growing up,
both of my parents were of the
I worked for one company
for my entire career ilk
that was probably imparted on me
a little bit.
And I think it's also true to say,
certainly in the early years of my career,
there wasn't a lot of opportunities
in tech coming out of Brandon, Manitoba.
So what are you going to do?
If that's a field of interest to you?
You've got to kind of find your spot.
And I feel like I was really lucky
coming into the organization
when I did when I left university,
they were just starting to talk
about this idea of Solara
and it was the coming together of these
five IT divisions
to bring economies of scale
to provisioning technology,
to credit unions.
And so here I was moving to the big city
to get my first job,
and they were already starting
to talk about this thing
that was bigger than I thought
I was even joining.
It was actually quite exciting.
And, you
know, we I really have been lucky
in that career inside of this one
organization that we take on an awful lot
for a relatively small company.
We're about 250 people
working on behalf of credit unions
in this space.
We actually do an awful lot
and I think maybe punch above our weight,
so to speak, for a company of our size.
And it really afforded
a lot of interesting opportunities
and different things that I was allowed
to do in my career in the last 20 years.
Can you highlight a little bit
about sort of the job
descriptions you've had as you've worked
your way to where you are now?
So I started on the Help Desk, you know,
and I think that taught me everything.
I didn't know anything
about banking at the time.
I knew I put my card in the ATM
and gave me money back, you know,
that's all that I knew.
And if you work on the Help Desk,
if you don't quickly figure out who's
who in the zoo of your organization
and who does what and how it works.
Well, where are you going
to send the tickets to to get resolved?
You can't do your job
if you don't understand that.
It was a really good start
for me to understand,
you know, how we served credit unions,
how we worked as an organization.
From there, I went on
to do a bit of sort of business analysis
and we stepped
into a bit of a product role
because there was an opportunity
that arose to develop some subject matter
expertize on a particularly important
score system for us.
And from that moved
into working in product.
And I think that probably is
my one true love.
You know, I think I will never get away
from wearing that product hat
no matter what I do.
And I think that's
still partially true today.
And then started to work
with some of our more technical teams
and we were trying to figure out
how to respond to the desires
of our credit unions
to not be the slowest cog in their wheel.
And so we had this hypothesis that, well,
maybe
if we choose to work in a different way,
we can drive a different outcome
and decided to stand up this little sort
of self-contained, highly autonomous
team of developers to see if we can do
differently than we had before.
And nine days later,
their first app was ready to deploy
and we went, Holy smokes, maybe there is
something to this changing your mindset
and changing the kind of skillset
that you decided to bring into your team.
And every little thing that we've done in
that team
has continued
to earn us permission to do more.
And that's really been the story arc
for our team in the last five years,
is just that consistent,
constant delivery of new value
and that will continue
to get you to new spaces.
And that takes us to today. So
I feel like this is one of those stories
that like
we easily get sucked into like,
you know, me starting also in
like I.T helpdesk kind of stuff, right?
Like I love the, the journey of ending up
and you're totally singing my song
with ending up in the product.
But I kind of ask like we're on an API
show at the end up here.
So a few years ago
we actually and I sort of
had a revelation on Houston,
we have a problem.
So it was both a technical
and a business challenge.
And it will be no surprise
probably to listeners to
who have played the same game
as we are, to say
I've got all of these legacy systems
and we're really having a hard time
making sure that the data moves
between them and we were just staring down
this pile of,
you know, an exponentially increasing
number of point to point integrations.
And we're like, this is not sustainable.
We can't do this.
We can't technically manage this.
The business model for this makes sense
for none of us.
We need a new story and plan.
And so we decided at that point
we had Bebe, you know,
we need to go and build our own
integration platform,
kind of that one single place
where we're managing this.
But it's got to consistent
and more modern tech stack,
something that we can actually
effectively manage on behalf
of all of these credit unions,
because part of our role is to enable
their choices.
As much as credit unions
like to work together,
it's one of the cooperative principles
that drives cooperatives is cooperatives
helping cooperatives,
but ultimately they're all independent
financial organizations
and make their own decisions.
So we need to position ourselves
to enable those choices.
How can we effectively do that
if we don't have a platform to do it?
So that was the decision at that time.
And so we went down this road
of building a platform for ourselves,
something we as an organization
had never done before.
We had never really focused
on, you know, building out
APIs that we would then create and manage.
So it was an entirely different skill
set than we had ever undertaken before.
And we really are fortunate
to work within this set of customers
who are so supportive of the work
that we do.
They were with us
in lockstep all the way along
and it
continued to follow that same path
where we had proven success already.
Do good work, prove that the use cases
you're focused on first are actually going
to do the thing they were asked of
and people will ask you to do more.
And so the next springboard for us
was fleshing out that API platform
to support new digital banking
applications that credit unions
were trying to totally reinvent
their member experiences.
I need a new app
to lay on top of all of this.
And so it was like,
you know, the traditional building,
the wings on to the plane as you're flying
it kind of stuff
where we were
not only running the platform
but building it out to support this
completely different scale of use case
than we had maybe necessarily imagined
when we started.
And, you know, Canada is not unique
in going
through a complete transformation
of financial services.
We're working on payments, modernization.
You know, open banking is going to come.
Every credit union is trying to reinvent
their member experience
to be that more relevant,
always on personalized experience
and you know,
you can't do any of those things
if your data is still trapped
in all of their traditional silos.
So we've been really fortunate.
I think that we had a bit of that
foresight that we would need to be here
now that we're here today,
because we're not caught flat footed
trying to be responsive along with credit.
What, you know, members, modern
financial services expectations are.
What's your advice for
people needing to make that pitch right?
What if people are trapped right now?
I mean, that's a big undertaking.
You have to start small, you know,
if you're staring down the future,
if we were looking at ourselves
kind of seven years on thinking,
how do you get there?
You would you would be paralyzed,
probably with fear, concern, risk
that you're trying to mitigate.
You have to start small.
I think there's also a bit of a mindset on
we don't necessarily know
how we're going to get there,
but we're very confident that, you know,
kind of as we start small and grow it,
that we will get there
because that's actually
the the muscle memory
we've proven to ourselves.
Start small, continue to build,
make sure you're getting that feedback
from customers
that it was what they wanted.
So I think,
you know, that story of somebody's
got to have a little bit of courage
to take that leap.
You have to be surrounded
by a team that you trust
and that they trust you,
that you can get to that end.
But don't try and build
the whole darn thing from the start.
You'll never be successful
if you're trying to solve
for everything from the beginning.
You can't possibly know
everything from the start.
That's the best advice
you don't actually know, and that's okay.
But if you trust yourselves enough,
if you empower yourselves enough,
you will find the right ways
to get there together.
I've heard this concept
described as like
just build the existence proof.
Give people the sense that, yes,
this is possible in small portion,
and that you can
then kind of fan out and scale from there.
And yeah, don't buy all the ocean I think.
I don't know.
Seems like every other episode
we have that, that phrase in there.
So that certainly lines up
with what we hear a lot.
You mentioned
as you guys are looking at building out
this new platform
that kind of more consistent,
you know, kind
of mechanisms
rather than the sprawl of integration.
What have you done to kind of
make sure that things are like
what's different about this new platform
besides presumably it's, you know,
newer code and all that stuff?
What's making it more consistent for you?
I think because we had a deliberate home
and a deliberate home
team, that
that was the thing that they cared about.
It was a side of a desk project
for people in the past, you know, Oh,
I have a vendor that gave me a small tool
that allows me to do this.
And when I get this kind of a request
to plug thing A and the thing
be for a customer,
this is what I know to do.
But it was never their primary purpose.
I think giving that purpose to a team
was really stop one for us to say,
you know, this is what you do
and we're asking you to do it really well.
So that was probably the first stop
for us.
We also started to make some more,
I think then strategic decisions to say
any new integrations
will use this platform.
And so, you know,
you have to start to draw some lines
in the sand for yourself
and your organization
on, you know, there's going to be a time
we're doing things the old way.
Don't make sense anymore.
And we've probably actually
had a series of those.
But making those deliberate
strategic decisions to say
it doesn't make sense for us to try and,
you know,
extend the thing that can't be extended.
We've got a way better capability
over here.
Here's a new project
or series of initiatives
now that will leverage it as well.
So it's almost like a series of decision
points along the way to go.
Okay, now this one makes sense to take on
and put it
in this new platform that we've built.
Yeah,
that's the sort of stuff that
works in the sense
that and we hear this a lot too.
You can certainly go like Boy Scout the
thing and try to, you know, do your best.
But somewhere along the line
you need that sort of leadership, buy
in and out of the mandates.
Right
for are backing support for these things.
I mean, I suppose with BP in your title,
you're playing a big role in that.
But I'm curious, like it seemed like you
mentioned, you know, getting some of these
smaller things done, build the confidence
to make the bigger decisions like
but I'm Athena like, you know, how do you
how did you drive those things home?
Right.
What are the specific sort of value points
or whatever
that made sense at each of these steps?
Yeah, I think we had supportive leadership
to drive the decisions
to say this makes sense for us now
to start this work.
But we were also really blessed
to be working with this group of customers
that are very supportive of us,
an organization
it was working in lockstep together.
To your point on buy in and support
and desired to invest to do something,
something different and better
because we all knew what we were doing
wasn't the answer.
So being able to make those early proof
points along the way really helped
aligning the underlying value proposition
that, you know,
you can't layer on a new experience,
you can't build the house
if you don't have the plumbing,
essentially was the story.
And everybody
certainly recognized that that was true.
I think we also
because we work on
so many of these initiatives together
with our clients repeatedly,
we had enough stories
of where what we were doing
wasn't working.
And we kept reminding each other
of those things to be like, Hey,
remember when Apple Pay needed
the email address and we couldn't get it
because it was locked in a silo?
You know,
I think you start to remind yourselves of
why you need to do these
and then use those as the examples.
Hey, if we choose to start to build this
another way and we actually sort of wrap
one of the stored procedures of the core
in a different way because we can
well look like a week later
the developers gone and these surfaced
thought up to show you how easy it is
if you just choose a different path.
So it was really about unlocking,
thinking, allowing people
to be super creative with how they seek
the answers to those problems.
It's really been a blessing for me
to work with these kind of teams and
the individuals that I do get to work with
because they are super creative.
People that don't work with these teams
don't understand
how creative developers are.
I think there's this complete urban legend
about how black and white and,
you know,
there's just a complete misrepresentation
of how software
development works, actually,
until you get to be embedded in working
alongside those teams, you don't see it.
But literally the most creative people
I've ever worked with,
I don't know that there's ever been
a problem that we've been asked to solve,
that we haven't at least surfaced
a potentially plausible solution for,
because you just can't stand
to see those problems go unsolved.
And that tends to be, at least
in my experience, the sort of people
that are attracted
to working with these teams.
Yeah,
I hold the often unpopular opinion that
developers are just
another type of creatives, right?
So I'm with you on this one.
I think the notion that
this is some sort of,
you know, cold, analytical, mathematical,
you know, we all just build algorithms
for a living, like, that's crazy.
Yeah, there's you know,
you give ten developers the same problem
and you've got ten different
solutions. It's inherently creative,
I guess, in terms of assembling
that team, you know, kind of the tip
of your spear for this transformation.
Is that the kind of things
that you were thinking about or where
there are other sort of skill sets
that you were looking for?
So I actually joined the team along
the way as a member of the team.
And, you know,
it was either that fate, happenstance,
luck, some confluence of all of those
that that started this for us.
We ended up with a really great core
group of people,
couple of super strong senior devs and,
you know, really motivated
to work with them and sort of myself
from the product view to drive.
This is what we think the customers are
telling us that they want.
So I didn't have the opportunity
necessarily
build the team from the very beginning,
but at least work with them.
And you know that
that team had such a culture of acceptance
of new people joining us because,
of course, a team of four people can't
necessarily sustain this on their own.
You're going to end up bringing new people
as you go.
And that,
I think, is one of the most consistent
cultural threads that we have benefited
from, is we've been so accepting
of new people to come and join us
and those people really in most cases
have been additive to that culture.
So we have a consistent thread
of all of that.
But then we've had this sort of series of
comers and goers
who have then added their own flavor
and flair to how we do our work.
The other thing that I think has been
really consistent is just,
you know, choosing to work in the way
that makes sense at the time
and then giving the freedom to the team
to do that, not being,
you know, sort of dictating process or,
you know, a process
document says that you should approach it
in this way,
always approaching things
that made sense at the time,
whether it was for the work
that we're being asked to do,
whether it was because
of the shape of the team
and the individuals in it at the time,
but just always sort of shifting and
morphing and figuring out the right way
to to approach how the work gets done
and giving yourselves the freedom
to actually change consistently.
So, you know, when your environment
is constantly changing around you, you,
I think, have to then be
constantly changing how you do your work.
Because if you're sort of locked
into this is the only way
for us that hasn't been successful.
Leicestershire
Yeah, we've heard this one
over and over again in our right that like
how much as has Barb
talked about tech here so far
and like the technical challenges.
It's all culture.
Yeah people and culture that's well
and just the mindset to write like that.
Change is possible, especially in
an older, more entrenched industry.
And I've worked in those.
There's no no stones guest
What was,
I guess Barb
kind of telling the story of progression
that, you know, got the right people
on, they've got the right mindset
and you kind of have these existence
proof moments and you're building up
what was kind of the big scary step
in this in this progression,
like where they're sort of big moments
where you really had to go big?
Not really.
You know, I think I remember the night
that we deployed the first set of digital
banking APIs that we'd been
working on for over a month.
But it
actually was kind of unusual
for us to have those big moments.
I mean, you know, the first
production, deployment of anything
that was a big first for us.
And we got a few things wrong there.
You know, I think people don't always
want to admit out loud
that things went wrong.
Things absolutely went wrong.
If people are telling you
they didn't do anything wrong
along the way, they're totally lying.
The point is to learn from those things,
right?
Hey, we made a mistake
deploying it like this.
Let's never do that again.
And here's how we can approach it better.
But, you know,
because we have always chosen to work in
pretty small increments, actually,
you never end up with these big moments,
which is, I think, kind of deliberate.
One of the bigger decisions, though,
more recently was
as an organization, Flora was getting out
of the data center business.
So all of the teams, of course, are
then start to be asked, what are you going
to do with all their workloads?
They can't live there anymore.
They have to go somewhere else.
And so for us, it was almost an obvious
and immediate decision.
We're going to go run in a public cloud.
We are sort of Microsoft folk here,
so we're all Team Azure.
And that was the decision.
Let's go put our workloads in Azure.
And it wasn't just a lift and shift,
right?
There's obviously many
kind of paths and permutations
of doing that that you can follow.
But for us we said, well,
if we're going to go to all this effort
of, you know, moving and testing
and doing work, why not actually set our
our credit unions and ourselves up
better for the future
and sort of build a new future
ready platform?
And that actually
was probably one of the bigger things.
But I would say for me,
maybe one of the easiest decisions
I've made to say
we're going to literally go
and rewrite this platform from scratch.
And here's why it makes sense,
because we can take advantage
of the most modern tools
that are out there.
We can ride the wave of billions
of dollars in investment
that we obviously as a small organization
could never hope to match.
It's become really important that I think
actually
a bit of a recruitment tool
for us really to say, Hey devs,
we're giving you literally
the best tools that are available,
come, come work with us because you can
work in this now completely modern stack.
And so I think in terms of big moments,
that was certainly one of them,
but it was big but easy.
Literally, probably one of the easiest
decisions of my career actually to say,
we're going to go do this,
we're going to go rewrite it from scratch
because it's the right thing to do
and it sets us up well for the future.
How long ago was that?
That kind of the decision point came up?
Oh, that's
probably about 18 months ago, I think.
And, you know, I think for us,
we really started
the work in earnest, you know,
probably halfway through last year
and started to get some of our production
workloads running early Q1 of this year.
So again,
trying to choose these small increments,
you know, we do work in a highly
regulated, highly risk averse industry
and that does because we grew up out of it
and formed some of our culture as well.
So taking those small incremental paths
to going,
okay, we're going to do this 1/1
because it might be a little less
impactful,
you know, shows true value to a customer,
but we're not going to blow our brains out
and try and,
you know, lift everything
and deployed in one night.
That would be a little bit crazy.
And kudos to you
for not doing the lift and shift thing.
I've seen that stuff before where it's
like, Oh, let's not run a data center.
It'll be cheaper in the cloud.
It's like surprised.
It's probably
not if you don't adapt the workload.
So I mean, yeah, 118 months ago.
So call it,
you know what 20 the beginning of 20,
21 is probably,
you know, an easy
one in the sense of like, hey, clouds
where it's at, you know, newer stack like,
yeah, it's time, folks, right?
Where do you think within kind of this
this journey within the organization is
has the kind of recognition already hit
that that this feels right now?
Or do you feel like you're
still kind of working through resistance?
I think
there is an additional mindset shift
happening
in our organization and then out across
kind of the ecosystem that we work.
I would say I think we still have
a bit of a self perception
and maybe it's know perceptions reality,
but maybe it's not true.
But the we're a bit different.
We still operate a little bit differently
than a lot of our colleagues do.
But on the flip side,
a lot of our colleagues are still
then entrenched with trying to operate
mainly legacy systems.
And so we're
that very typical kind of bimodal.
If you follow the Gartner
parlance organization, we have things
that need to move at different speeds
and we're allowed to move at one speed.
And that actually suits our style of work
best in the kinds of things
we're trying to do.
People are showing up all the time to say,
I have this problem, can you help me
solve it? It's
not a tool or product that we have.
You're going to solve that problem.
You got to go build something new,
very different style of work
and a different mindset.
Then here I go and I run this batch
and you know, there's there's
a completely different
kind of capability and approach
that you're trying to drive
when you live in those worlds.
They are a little bit kind of like
two different worlds, honestly.
And so, you know,
sometimes there's a rub there
inside the organization on
we work one way and you work another.
But I think there's also
an acceptance of it.
And as long as you're still proving
kind of the value
that the customers are trying to derive
out of that part of the business,
everybody recognizes
that it's actually okay
that you don't necessarily
all approach it in the same way.
So, you know,
we're going to continue that, I think
blazed the trail a little bit.
We're okay being the trailblazers
in terms of our organization
because we've shown that
that's a path that we can be successful.
And there are then breadcrumbs
that we're leaving for the folks
that are following the trail behind us.
So you went from this mode of of you know,
you had lots of ways to integrate
and now kind of APIs are,
you know, the front edge of that
or the way
that you're doing things
in terms of kind of standardizing or,
you know, all this kind of stuff.
I assume there are, you know, a
significant number of teams and, you know,
how are you kind of
making sure
that you maintain this consistency
going forward in terms of process
and tools?
We're fortunate as a small organization,
we're
still the one team that's doing this.
So our approach is the approach right now.
And, you know,
I think what we're wanting to ensure
is that as others
then are going to use these capabilities,
we're treating those internal customers,
so to speak, the same as we would
treat our external customers.
Hey, you know, here's
this API and here's the specification.
And, you know, we may have an SDK
that suits your development environment
better or not, but, you know,
not necessarily changing the approach
that we've got to say this team leads it,
this team builds it.
We're the ones with the expertize.
And yes, you can be consumers of it.
And yes, we may actually find that there's
an interest inside the teams for
tours of duty, so to speak, on
you're going to come help us build.
But because we're a small organization,
we're fortunate in that
that governance overhead hasn't
come to need to look different today.
So that's been one of the benefits of
not only a small company, but, you know,
sort of a small team.
We can still just continue to make
those decisions that make sense for us
and our customers
in a self-contained way right now.
So when I guess is it just this team
that's building
kind of the core of the APIs right now
and you don't have a lot of other teams
developing APIs as such?
Yeah, exactly right.
So it's it's us in this team were the the
only ones that are working in this way.
And you know, we, we do have intersections
back across the organization
because you know, when you're the
the plumbing in the middle
in some way, you either rely on them
or they rely on you.
So one great example there for us is,
of course, one of the primary systems
we actually integrate back
to is our core banking system
that we provide for credit unions.
The responsibility
for that core banking system
lives in another part of the organization.
But we we sort of play in that gray zone
where we actually understand
the APIs that have been provided
by the vendor of that system better
than the team that runs it.
They've never really needed to dig in deep
like we did,
and so we sort of crossover
with each other in terms of
these are the APIs
that are provided for this software,
but the, you know,
sort of running management upkeep release
cadence of that system
is the ones with this other team.
On the flip side,
our colleagues over in the digital banking
part of the business are 100%
reliant on us.
They really don't have a product
if it doesn't intersect.
Back with the data in the core
banking system.
And so it's this really great symbiotic
collaborative relationship inside.
We all sort of
stay in our lanes to a degree,
but there's also these key points
of intersection between all the teams on
I Can't Do My Thing Without You.
So Bob, now
normally this is the part of the episode
where I ask folks, you know, Hey,
you got a big, complicated thing.
If you did it all over again,
where would you start?
But I feel like, you know, you're just
at the beginning of a bigger journey here
and and you're still in that magic moment
of a single team
that's that's still delivering
all the APIs.
That doesn't last forever. Right.
So I'll frame it a different way
as like rolling the clock back two years.
Like,
is there anything that you would have done
different looking back to kind of avoid
some pitfalls in this these early steps?
You know, some of the things
I think that we learned were
if you're the folks that have
been early
in that curve of shifting mindset,
you need to consistently remind yourself
that not everybody is there with you
and you have to take them with you,
and that is definitely applicable sort
of internally for us and our colleagues.
It's definitely applicable as well for us
and our customers.
We were probably ready to move
and deploy things
and use them
and run them in production way before,
you know, most of everybody else
that's been in the ecosystem with us.
So it's that bringing people along
the journey
with you
is definitely one of those things.
I think we've also learned that
the pressure of delivery
doesn't necessarily mean
blowing your brains out
on scaling up people to do the work.
That's actually been a learning
along the way there as well.
On how to balance,
you know, capacity versus delivery
and are you always making
the right decisions there?
I don't think we've always made
the right decision there.
You know, knowing that it's a single team,
we are definitely the small team sport,
you know, monitor kind of folks.
Small teams win.
And we believe that truly.
And I think we're at that interesting
juxtaposition in time.
And growth is exactly as you say.
This probably won't continue
to sustain us forever in the future.
And so we talk a lot about, you know,
how are we actually
then going to grow the team?
What does that actually look like?
So, you know, it's this kind of beautiful
spot, as you say, small number of people.
We all know each other.
We all know our own quirks and sort of
who works best or how that all works.
And it'll be quite different,
I think, to look back on ourselves
in a year's time on
Remember when we were still that one team
and now there's more of us and it's great,
but it will certainly be be different
looking back in the years time. I think
I would
certainly offer the advice from folks
who've kind of scaled out programs is like
keep the small team
and change its purpose.
Right?
I think in the early days
it's like you're there
to build all the APIs,
to set the example for everyone else.
And the shift at some point becomes what
what's what is the standardized approach
so that we can hand off the development
to a bunch of other teams and really
just kind of curate those mechanics.
So I would love to hear about
how that transition goes
down the road in the next year or two.
I'd love to have you back
and see where you're at in that journey.
Thank you.
Yeah, it would be a real pleasure.
And a remind me of your cat's name.
Oh, this is sleeves.
Okay, that's sleeves.
I couldn't tell them apart.
I feel like we have to think sleeves today
for those of those random.
A few of you who watch this on YouTube,
you've been entertained
by a sleeves today.
And I think he's done a fine job.
He's the worst.
But we really appreciate you coming on.
And I, I love these stories of kind of,
you know, early on, things are messy.
You're figuring it out.
And I really appreciate
your vulnerability on this.
I think people love stories of, you know,
trial and failure
and all the things that you learn from it
and I love that you've been willing
to share the messy side of it.
Well, thanks for having me here.
I love the opportunity to talk about
my team and the great work we're doing.
So thanks for that.
API Intersection Podcast
listeners are invited to sign up
for Stoplight and save up to $650.
Use the code intersection
ten to get 10% off a new subscription
to Stoplight, platform, starter or Pro.
Take a look at this episode's description
for more details.
Thanks for listening.
If you have a question you want to ask,
look in the description of whichever
platform you're viewing or listening on,
and there should be a link there
so you can submit a question
and we'll do our best
to find out the right answer for you.