Evolving DevOps with Matty Stratton

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Matty (00:00):
You know, I've spent a lot of my career recently
working in developer relationsand a lot of folks in DevRel be
like business doesn't understandDevRel, and I've come to the
conclusion that it's theopposite problem.
And the problem is DevReldoesn't understand business and
I'm not, you know, slamming ondeveloper relations.
People that's me, devrel arethe only place.

William (00:39):
And if you talk to anybody else in any other kind
of job and said I don't feellike I should show the business
value of what I do, they wouldsay what?
All right, folks, strap intoyour X-Wings and power up those
hyper drives because it's time.
I'm with me.
As my co-host, Yvonne Sharp.
She is a cloud DevOps Jediwho's been battling the dark
side of downtime and latencyacross the galaxy for ages.
You know, when she's notwielding her lightsaber of
automation or force pushingdeployments to the cloud, she's

(01:00):
keeping the rebellion, or atleast the servers running the
rebellion, running smoother thana freshly waxed Millennium
Falcon.
Yvonne, they say the force isstrong with you.
I know the force is strong withyou, but I say it's the puns
that keep us skywalking.
How's it going today?

Eyvonne (01:21):
Let's just say I'm daily battling with the powers
of the dark side.
Yeah, trying to balance thepull of the challenges of
leadership with the forces ofthe rebellion out there actually
doing the real work, so tryingto ride the line.

William (01:41):
Yeah, with us we have a pretty special guest, one that
I pray I don't need to introduce, pretty well known in the you
know, especially the communitycircles that I frequent in.
But, matty Stratton, welcome tothe show.
How's it going?

Matty (01:53):
It's good it's good, Glad that it's.
You know, nobody ever wants totalk about the weather, but in
Chicago, when it gets a littlebit warmer, that's all we want
to talk about.
So it's 50 degrees out, whichmeans we should be running
around in shorts and tank tops,I guess.

William (02:05):
Yeah, well, that makes everybody happy.
So we're not too far fromChicago.
Like what?
Four hours and the snow isalmost completely melted around
my house, which is very exciting.
We're just talking about this.
I've slipped probably like fouror five times this year.
Usually I'm extremely carefuland I never slip on ice or snow.
This has not been my year, butglad to see the snow gone.
Um, yeah, so the windy city, doyou?

(02:27):
Uh, I always ask us.
I don't know why, but whenever,whenever I'm in Chicago, I
always go to lose.
I love that place.
Do you?
Do you like the Chicago stylepizza?

Matty (02:37):
I have strong opinions about this.
This is this is actually, youknow, one of the things that, uh
, you know, people like I don'twant to say give me a hard time
about, but so I don't mind thedeep dish.
But the like secret of Chicagois that we only eat deep dish
when y'all come to visit.
Like real Chicago pizza is astyle called tavern style.

(02:57):
It's the first time we've heardthis on the podcast, I
guarantee you said you had TimBanks on the show.
I bet he talked about thisbecause he loves to give me a
hard time about this.
But yeah, tavern style is likeit's a thin crust and it's a
party cut, which means insquares.
And the reason it's calledtavern style is it used to be so

(03:17):
at the bars and you know folkswould come off their shift and
they'd go to the bar right after.
They'd get these little slicesof pizza on a napkin.
So it's sort of like pizzatapas or whatever, so you could
drink more.
So that's the tavern style andagain, I'll do deep dish, like
once a year we actually have atradition with devops day,
chicago, you know, when peoplecome in and the sort of
unofficial after after eventspeaker dinner is we'll go go to

(03:40):
lose or you know, giordano's orwherever and and you get that.
But also, I mean, you couldn'tpossibly eat that regularly
anyway, you know you would eveneating it once.

William (03:49):
Honestly, the last time I had, I think the last time I
was in chicago, we didgiordano's, yeah, and you, it's
so good, and I hadn't eaten allday, so it was like I flew in.
It was straight to the office,straight with customers and all
this other stuff, and then itwas like later that evening I
was starving.
We go to Giordano's and Iovereat, it's so good, you just
keep eating and then you almostlike need a vacation because you

(04:13):
just feel so it's just like youjust oh yeah, oh, it's terrible
.
And then the next day you wakeup and it's it's equally hard,
so Hard, so yeah, so one of theI'm.

(04:33):
You've been a huge, justadvocate for DevOps for so long.
You know in modern, you knowmodernizing enterprise IT
practices.
I think you co-authored a bookabout developing apps in the
cloud and you co-host ArrestedDevOps, which is an awesome
podcast for those listening.
If you have not tuned intoArrested DevOps, which is an
awesome podcast for thoselistening, if you have not tuned
into Arrested DevOps, it'sgreat.
So what else are you working onthese days?

Matty (04:52):
Yeah, so I, like I said, I started, started ADO a little
over 10 years ago.
I always say we're the longestrunning DevOps podcast still
running.
I'm using that term a littlebit loosely, I'm a little behind
in publishing, but I also liketo.
We're always at the top of allthe lists of DevOps podcasts and
maybe that's because we startwith an A, I don't know, I like
to prefer it the other way.
I also, you know, I startedDevOps Day Chicago over 10 years

(05:15):
ago.
We actually have our 10thinstallment of that coming up in
a few short weeks and I feellike, with that event, I love it
so much but I, you know, I'vebeen trying to step away from it
because it's a lot and I feellike you know michael corleone
and the godfather, where it'slike every time you think you're
out, you know so, um, but andheavily involved with dev ops

(05:35):
days around the world and um,yeah, right now just sort of
trying to figure out what my, mynext professional thing is.
But i've've been involved inlots of different types of work
within that space, a lot of theplaces I've been.
I always like to say, you know,I spent two decades working in
technology operations and nowthey pay me to talk about it.
You know.

(05:56):
So a little over 10 years agois when I moved over from the
vendor side after how many yearsof working in technology
operations and lots of insuranceand finance, because Chicago
and and when I was runningtechnology operations at
apartmentscom here in Chicago.
It was interesting because Iwas towards the.
That time is when I gotinvolved in the DevOps movement

(06:16):
early on, but a lot of the whatwe were doing was like it was
like that it's DevOps but wedidn't know what to call it.
You know, know, because youknow I owned infrastructure but
we were so tightly coupled withapp dev.
But also, you know, I look backat the things that we've
learned over the last 10 plusyears and you think about how
you would do work differentlyand that's sometimes interesting

(06:54):
and them directly.
As you know, a solutionarchitect or a customer
architect, like when I was atChef or in developer relations,
cause I was like when I was apager duty.
It was traveling the world andworking with all these different
companies, visiting and seeingand talking and hearing, and you
, you see these stories and yousee these things and on one hand
you sit there and you're likewe've come so far and this is so
great, but then you sit and yousit.
Sometimes you know it's acognitive dissonance, right, you

(07:17):
know.
And then you're like, but wekeep having to say the you know
there's still lots that that hasto be done.
And I think we've looked at theevolution of you know kind of
the starry-eyed early dreams.
And then you know it hits thereality of vendors and marketers
and you know, and I think abouthow my you know strong opinions

(07:39):
have changed because of other,of collision with reality.
Um, do all, do you all give agreat example.
So I I was always been a bigproponent of you know, I say
DevOps is not a tool, title orteam.
It's a way of doing work.
I still believe that to be true, and so I would be very noisy
about like oh, there should beno such title as DevOps engineer
.
That's not a thing.
That's like saying you're anagile engineer.

(08:00):
You know that's not a job title, and I've changed my stance on
that.
I still believe that DevOps isa way of doing work, but I don't
publicly make a big deal out oflike oh, it's a terrible title.
And there were two things thathappened that made me rethink
that.
So one was Ian Coldwater madethis point once and they said
you have to remember that thepeople who have the title DevOps

(08:22):
engineer, that's not aself-bestowed title.
Someone else gave them thattitle.
So all you're doing is makingthem feel bad and it's not their
choice, which I think is a veryempathetic way to think about
it.
Ago, and he said the the paycompensation difference between
cloud engineer or systemadministrator and devops

(08:48):
engineer was about 30 percentincrease.
So I was like cool, callyourself whatever you want, go
get your bag, you know.
Call, you know.
Call yourself the king offrance if it's going to get you
more money.
So but I still do think that alot of this is, while org
structures are what they are,ultimately, a lot of this is
just thinking about how we dowork right, you're not going to

(09:10):
solve this with and, and I think, in as a, as a community and as
a movement.
It feels like early, you know,we over rotated, or it appeared
to over rotate.
On culture, if we think about,you know, the acronym COLMS,
which is kind of the prototypeof thinking about DevOps, the
culture, automation, leanmeasurement and sharing which I
still think applies, and itseems like we really

(09:32):
overemphasized or felt like itwas all about the C, and part of
the reason to me I alwaysthought about this way is all of
them are equally important, butthat's the one you have to
convince people about.
You don't have to, likeconvince engineers to, to, to
use automation tools Likethey're going to want to do that
, like we want to do.
Those things come a little morenaturally but, like the culture
part is also one of the hardestparts.

(09:55):
Similarly, early, early on inthe movement, there was a very
brief and thankfully briefmovement attempted to have this
idea of enterprise, devops,which was columns without the C,
and there was a person who Iwon't name, who was a big
believer in this, who used tosay culture is for yogurt and I

(10:15):
was saying, oh, in theenterprise it's all about
getting this work done.
And, honestly, who saved usfrom all of that was Gene Kim
and DevOps Enterprise Summitbecause you had this came up and
said this is enterprise andit's DevOps the way we talk
about it and it kind of shut allthat down.
That was a really importanttime.

Eyvonne (10:32):
Well, and you know, I think one of the challenges and
this happens in the trajectorywith any ideology, right so you
know, I was introduced to thePhoenix Project very early on,
like 2013,.
Right, the book hadn't been outa year yet.
It was a shiny new idea.
There was all this excitementaround it that, oh, like,

(10:53):
there's this new way to thinkabout things.
And then there was NicoleForsgren's book coming out of
Google and Accelerate and all ofthe things that we've learned
there, out of Google andAccelerate and all of the things
that we've learned there.
I think there's a reality towork, though, when these ideas

(11:14):
and principles start reallyhitting the real world and get
mainstreamed, that there's justthe weight of work and people
and processes that gets attachedto it over time.
That dilutes the idea, and Ithink that's part of where we're
at in the evolution of theconcepts is like it was

(11:36):
important enough that it didmake some changes and that
people did make good faithefforts to implement agile
development, devops principles,but that has come against things
like corporate compliance, ahundred years of enterprise, you

(11:57):
know culture, especially inorganizations that were built in
a manufacturing world,organizations that were built in
a manufacturing world, right,and so there becomes all this
weight associated with theconcepts that aren't the core
principles and and people startlooking for okay, so what's the

(12:18):
next thing?
But because it doesn't seem sopure anymore, but really it's
all kind of the same thing wejust reinvented and attach new
words to it because we're tryingto get rid of the stuff yeah,
yeah, it's I.

Matty (12:31):
I had an episode of of of ado.
It was called.
You know, platform is platformengineering, just devops with
better marketing, right, youknow everything old is new.
Again, I think a couple ofthings that you said are really
key.
One thing that was a problem,if you will, is that you know
there was no such.
There was no DevOps manifesto.
In fact, devops was very, very,not specific and that was by

(12:52):
design, and the problem ispeople want that and so when
there's a vacuum, that getsfilled, right, so it gets filled
with.
Well, then it means this.
And the other thing is, like yousaid, when you run into
organizational things, you know,I don't remember the exact
idiom, but it's like you willnever convince someone, you'll
never sell something to someoneor convince them when it's

(13:12):
contrary to basically how theymake a living.
And that's what got us saferight.
Scaled Agile framework is howprogram managers get to still
have a job and call it Agile,right, and I think you have to
figure out.
But the thing is, like you said, about as long as you're still
getting to the core improvement,and that's the other thing we
have to.
When we look back, we can bevery frustrated and say, oh,

(13:35):
it's not what it was, but Iremember, yeah, I remember what
it was like.
I did this work right and thisis so much better.
And I think there's contextthat we have to take into
account and we have to look atthe larger perspective.
Two things come to mind when itcomes to that.
One was I remember on my firstday at PagerDuty I was in the
new hire onboarding and a lot ofthe people in my group were,

(13:58):
we'll just say, newer in theircareer you know it was one of
their first or second jobs orwhatever and they're sort of in
the onboarding, they're tellingthe story of PagerDuty and like
what it first came out to be.
And I remember all these peopleyou know who were much younger
and earlier in their career werelike I don't understand how
that was a problem to solve,like you mean, like getting the
alert to the right person.
I was like, oh, let me tell youstories about having to update

(14:20):
exchange distribution list oncea week to whoever was on call
and I'm like it seems like sucha simple little thing, but it
was so big that's it.

Eyvonne (14:28):
That's a bless your heart moment.
Right, you're just a little bitsweet summer child, you know
like how fortunate for you thatyou didn't have to.

Matty (14:36):
That this seems like what's the problem, and the
other part when you think aboutthe context, when I was leaving
my role at Chef and so I hadbeen a pre-sales person and then
I also switched over to on thetechnical side of success.
So I work with theseorganizations at the beginning
of their journey and then oncethey had started to adopt, and
when I was leaving to go to mynext role, you know I kind of

(14:58):
had, you know, the last meetingsI would have and I remember
when my last week at Chef I hadmy quarterly meeting with the
Chicago Mercantile Exchange,were one of my favorite
customers here and I was withthem for a long time.
And you know one of the peopleon the team said you know,
maddie, I feel like we've letyou down.
We have not gotten as much doneas we should have in the last

(15:20):
couple years.
And I said hang on, let's takethis back.
I said you're in the middle ofit and you know what you want.
I said I have the luxury ofstepping back and I'm like, let
me remind you, let's go in theWayback Machine 18 months ago.
Look at how much you've done,and oftentimes we don't see that
when we're so close to that,and even as an industry, we get

(15:41):
frustrated because when ourreach should exceed our grasp,
but then that means if we'regoing to have our reach exceed
our grasp, we can't beatourselves up when our reach
exceeds our grasp.
Right, that's the trick of itand a lot of it.
Like you said, that's the trickof it and a lot of it.
Like you said, there's allsorts of reasons, but I still
think the net is positive and westill have a bunch more work to

(16:03):
do and things continue toevolve.
The problems we were trying tosolve 15 years ago were
different than today's problems.
Cloud changes things in so manyways.
You think about Javon's paradox, right, like it's, the easier
it is to do something, the morethere is of it.
And you think about the scalewe talk about that you can do
with cloud and I'm my old schoollike rack and stack, you know.

(16:23):
I remember.
You know if I wanted a serverwhen I was at the bank, I mean
that was, that was four months,you know, to get that done.
And the idea like, oh, I meaneven virtualization, like when
we rolled in you know vm, whereit was like you know what do you
mean?
It's just like press thisbutton and now I have a server.
You don't get things that fast,you know, and that comes with
its other problems.

(16:45):
Maybe we need to go back tosome of those old back in tech
days because maybe a little morethoughtful.
I don't know, but you know welland as we look forward.

Eyvonne (16:55):
You know there are going to be new challenges with,
you know, ai and inference, andthere are new problems
associated with that technologyand new scale that we're going
to have to solve.
There's a whole arena of AI, ml, ops.
That's virginal right.
We've got all of these modelsall over the place that are

(17:18):
doing all the things.
We need them all to beorchestrated and working
together and have kind of thesame training and the same
backend and we and but we alsoneed them close to the users.
How are we going tooperationalize that whole
process in in a world wherethere are new problems?

(17:39):
So there are fresh horizons outthere that the progress we've
made in the last 10 to 15 yearsis going to provide the platform
that we build on in the nextdecade, and that's a whole new
set of operational problems thatthe technology is still
maturing into.
That I see coming.

William (18:00):
And speaking of hardware, there's an investment
in hardware again to run thisstuff locally in the data
centers that you know.
Some of these companies didn'tget rid of all their data
centers and put everything incloud.
Thank goodness, because there'sa balance here and it turns out
running some of this stuffagainst smaller subsets of data
and figuring things out beforemaybe you put it in the cloud is

(18:20):
so much cheaper that it is ano-brainer.

Matty (18:25):
Well, I was going to say, with the value you're saying,
as we move to these next things,we build on the shoulders of
giants, learn their lessons andthe core, while the
implementation detail willdiffer, but those core, I
wouldn't even necessarily sayfirst principles, but you know
it all comes down to.
These are socio-technicalsystems and what has not changed

(18:46):
is the socio part of it.
And you know, as I say,computers are easy, people are
hard.
Right, we will learn the newtechnology, but there's changes
to the socio part of thesocio-technical, because the,
the tendrils of all the llms,like like we used to.
You know, separation was easybefore, to a certain point, we

(19:07):
could argue about it, we couldsit there and say maybe some
things were too separated, butit was like this.
This data was here for the mostpart.
Yeah, you can distribute it,you can do whatever.
But now you're sort of like asyour, your llms and everything
are kind of reaching into all ofthese things.
It's like how do you have thattraceability?
How do you have that?
And then what?
I think the the important partis and this goes back to

(19:30):
something you said early on,yvonne is that like when you
sort of hit we can't just keepdoing things the same way,
because the world can see, ourworlds continue to change.
So what we need to do is saywhat can we take from how we've
done it?
How do we apply it?
But you know, we've always doneit that way.
It doesn't work right.
You know what got you there isnot.
What got you here is not goingto get you there and I and it's

(19:53):
hard because so many things thatwe've done, and especially when
you talk about biggerorganizations and people have
things they've built and it'syou have to.
You know, I was anytime, I wasworking with anybody in
transformation or any kind of achange.
One of the first thing I say issay every decision you've made
up till right now has been theexact right decision, right.

(20:15):
None of this is because youwant to.
Oh well, we do it this waybecause that's how we did.
It's like fine, cool things aredifferent.
Now we, we, we have to, we lookin the rear view mirror, but
we're going forward.
So what does need to change?
Because?
And and how often do we havethings that exist?
I mean, this is we could do awhole episode of of war stories
about weird processes that existbecause of one wacky thing that

(20:38):
happened once.
There's a couple that just Ialways think about.
I remember when I started atapartmentscom, so we had, you
know, the backend databasecluster and all the front end
databases that serve the website, and you know we would do
releases and distributions and Iwas like, why does it take an
hour for data to replicate fromthe backend to the front end?
And it was because it would hiteach front end server with 10

(20:59):
minutes in between, and thereason was because one time
someone pushed out a jacked upchange and it took down all the
front end data.
So now, to be safe, we do this.
And it was like, well, andagain, I didn't know as much of
that as I did now.
Now I would know a little bitmore how to frame it.
But you're like, again, thisgoes back to what do we build in

(21:22):
the system to keep that fromhappening?
Because what we've done is wemade every single release take
way longer than it has to.
Or there's a great story and andI, I, every year this becomes
less and less likely to still betrue.
But in 2005, um mozilla, therewas a change made to firefox and
it broke mlbcom, and thischange was pushed out on day one
of the world series.
So for years, as long as I knew, there was a smoke test in

(21:43):
Firefox that was test MLBcom.
You know now those are okay,cause those are just.
They exist.
No one.
They're not part of your.
They don't slow you down,they're not part of this.
But how much do we have?
You know, it's also the otherside and they're supposed to be
a part of the socio-technical.
One of my friends used to saynever be the reason a policy is
created, but so many of the wayswe work are built around things

(22:06):
that may no longer be relevant,but they're in our operational
DNA and we do need to pull them.
It's really it is important tolook back and to say why do we
do this?
But it's not from a oh well,that's wrong.
It's just more like let'sunderstand it, but none of this
is oh, the way you've beenworking has been wrong and
you're bad.
It's just like with theinformation you had and the

(22:29):
world the way it was at the time, that was the right decision.

Eyvonne (22:39):
Things change but let's adjust.
I gave an internal talk just aweek or so ago where we were
unpacking these things.
You know, let's understand anorganization and where they come
from.
What was their missionstatement?
What are they in the world todo and accomplish?
And what they're in the worldto do and accomplish shapes not
just their product but who theyare as an organization and in

(23:01):
order to impact change at thatorganization, you have to
understand those things.
I feel like sometimes we have tobecome almost an organizational
forensic archaeologist andunpack some of those things and
say this is why this thingexists.
Now let's talk about what's newand different.
Now that gives us permission tochange that thing.

(23:23):
Right, because a lot of peopledon't understand that and they
and and and people havedifferent fear and risk
thresholds, and some folks arelike you know, burn it all down,
I don't care, like we'll justgo make it all new.
There's value in that kind ofmentality.

(23:43):
But then there are also peoplethat like these things exist for
a reason and we might breaksomething if we change it, and
you, you need both of thosementalities to come together and
solve the problem and determinewhat the way forward is, and
and we also have to be patientwith one another through that
process right If things don'tturn on a dime.

Matty (24:04):
I always people ask me and say what's the most
important DevOps book I shouldread, and I say go read
Freakonomics, understandincentive and you can do DevOps
right.
And it comes back to I thinkabout, like you know, pagerduty,
and I would teach theseworkshops on incident response
and incident command and one ofthe things we would teach is,
say, during an incident, one ofthe things is we'd say don't

(24:26):
litigate severity, which meansduring the incident it's not.
Oh, is it a really?
It came in as a SEV1, you knowwell, maybe it's really a SEV2,
blah, blah, blah.
So you know, and I wouldconstantly have folks who come
on and say we do this all thetime, this happens all the time,
and they said I bet that youhave an executive that measures

(24:46):
success by how many SEV1incidents exist, and they're
like yep, and I'm like, so thereyou go, right, so that's the
thing.
So why?
We say then the most importantmetric on a team then is not
mean time to resolution, it'smean time to innocence.
Right, how quickly can youprove that you didn't break it?
It wasn't a sub one, and noneof that serves restoring service
or getting the stuff done andthis goes all into.
You know you talked about DrForsgren and you know she's a

(25:10):
big believer and leverages theWestern model so much.
Right, and it's kind of funnybecause I, my, my fiance, works
for a small business and she'shaving some not in tech and I
think she's an operationsmanager for a heating and air
place and she would, we actually.
I I told her about the westernmodel the other day because,
talking about things it happensin a company of 20 people, I'm

(25:31):
like pathological and she's like, yep.
Yep, that's because I was likeit was funny, she's describing
certain things.
Yep, that's because I was likeit was funny, she's describing
certain things.
And I was like, oh, these areliterally in the West room.
So it's, it happens.
And those are the hardestthings.
The technology is easy.
We figure that out because itdoes what we say, it acts the
way we expect it to mostly, andif it doesn't, our expectation

(25:54):
was probably wrong.
You know people don't, althoughyou know, if you kind of
understand how people work, itdoesn't mean you can manipulate
them, it doesn't mean thatyou'll always get it right, but
if you know what's important tothem.
I have an old talk called thefive love languages of DevOps
and it's fundamentally aboutchange.
And I think it comes to mindwith anything when you're trying

(26:23):
to affect change, because thething that resonates to you
about why this thing isimportant is not going to be the
same as the person you'retrying to convince.
And I had, you know, a fellowwas on my podcast early on and
he's not a tech person, he's a.
He's actually a leader, aleadership coach, and he's the
one I got all my managementtraining from and I've told him
I was talking to him the otheryou know recently and I said
Billy got all my managementtraining from.
And I've told him I was talkingto him the other you know
recently and I said, billy, youdon't understand how many large
organizations have heard yourname when I'm talking about

(26:43):
DevOps, because I talk about.
He talks about committed versuscompliant people in a change,
and that's a differentconversation.
But also he's like if you'retrying to convince somebody of
something and you find yourselfsaying, you know, william just
doesn't get it, that's on you,that's not William, right?
That's I'm not speaking yourlanguage.
And you know, the thing thatresonates to me is, maybe, as
the system engineer is like,okay, if we have all this much

(27:04):
better automation, this iseasier, or whatever.
Well, you're maybe on thefinance side of it, so you're
going to resonate more with thereliability.
You know different.
You have to.
You have to understand thedrivers of the people you're
trying to make change with andit it feels like falling in deaf
ears.
And I've I've also, you know,on the.
You know I've spent a lot of mycareer recently working in
developer relations and I cameto this conclusion over the last

(27:28):
year or so, cause a lot offolks in Deverell be like oh,
the business just doesn'tunderstand what Deverell does,
they don't understand why we'reabout.
The business doesn't understandDe rel, and I've come to the
conclusion that it's theopposite problem.
The problem is dev rel doesn'tunderstand business.
Right, you know, it's like andand this is true for, uh, you
know, uh, it's funny becausedeveloper I'm not.
I'm not, you know, slamming ondeveloper relations people,
that's me, but dev rels are theonly place.

(27:51):
And if you talk to anybody elsein any other kind of job and
said I don't feel like I shouldshow the business value of what
I do, they would say what?
And the only other people whowould say that are software
engineers, by the way, you knowguilty from you know the new
King makers, like screw thewhole thing up.
Right, we got into this whole.
I remember early on in ArrestedDevOps we had someone on and

(28:12):
she said the value of DevOps wasthat it protected the time of
your most valuable people inyour organization, your
developers.
And I was like I want to belike get off my show, right, you
know like that's not what thisis at all, but and yeah, like
I'm kind of giving me so manyone liners for shorts video

(28:34):
shorts that I can make just outof that sort of blurb right
there.

William (28:39):
So I'm loving this back and forth between you two, like
that was I'm loving this.
It's almost like I'm in theaudience right now and I'm
loving every second of it.
I want to propose something andI want to hear you both talk
about it now.
So one thing that I've noticedin the past like it's really
become real to me, like over thepast two years, I used to think
that organization or team sizedidn't matter so much.

(29:01):
It wasn't that big of a deal.
And something I realized when Iwent from large enterprise to
startup is I've seen small teamsscale huge things, but I've
also seen the more hands youhave in that cookie jar, for
some reason or another, tends toslow things down.

(29:21):
So, like when I worked inenterprise, there would be this
thing where they would say okay,we're just going to hire an
army of DevOps people and we'regoing to pair you up and we're
going to hire a partner to comein, give it a steroid injection.
You have 40 people at yourdisposal, we'll taper them off.
And the more people that wethrew into these big initiatives
, the slower, the morecomplicated, like it would

(29:42):
completely nerf the whole.
It would be a waste of money,pretty much like why you're
light your money on fire.
But even in the startup space,like having like a very small
agile team like the, the, theamazon, you know two pizza box
thing, was like a really sweetspot if you did it right.
And then as you start injectingmore people and more opinions,

(30:04):
you find that it starts becomingproblematic and I don't really
even know at this point how tothink about this problem.
Like, does team size matter?
What does it mean?

Matty (30:16):
Well, the first problem with the two pizza team thing is
that I'm a two pizza team.
You know I can eat two pizzasby myself.
So you know it's all relative.
But I don't think there's likea magic number right.
There's not this magic Dunbarlike.
At this size it's too big.
But you're 100 percent right,because I mean, just even think
about if you've got you know,know how hard is it to figure

(30:37):
out where to go for dinner ifyou're deciding between four
people or a dozen people.
There's there's more opinions.
I like to think about ways thatyou can leverage.
You know, and a lot of it, thesize of the team you can handle
to be able to move quicklydepends a lot on how that team
works and what yourorganizational culture is,
because if you have high levelsof psychological safety, that

(30:59):
team can be bigger.
Now, that being said, thebigger the team, the harder
psychological safety is, becauseyou're mixing more ways of
thinking, you know so, gettingalignment, but you get too small
, you get too aligned, and thenyou don't have any voices of
dissent, you don't have anyother pieces of that.
I think you have to if you wantto be able to make a larger

(31:21):
team work better.
You have to have a little morerigor that you can abandon when
you come to how you do things.
You can say we have a certainamount.
You have to be able to say wewill bike shut on this only so
long, but eventually a decisionhas to be made.
I like to think about voice butno vote.
Sometimes in certain types ofdecisions where we're like I

(31:41):
want to hear what everybody hasto say, but ultimately this is
decided by these two people.
Because if it's complete, againthe consensus protocol right,
the bigger, the more people, theharder it is to get to
consensus.
And I think there's lessons youcan learn and also how you
rotate that, because what youdon't want to do is have the
same people always be the votepeople and the same people are

(32:02):
the voice people.
But maybe you say okay for thisone.
At the end of the day, the buckstops with Yvonne and William.
We want to hear from everybody.
Okay, but the next time.
Maybe it's not the next time,but you have different ways you
could structure it.
Okay, this is your place whereyou make the ultimate decision,
but you can bring so.
So the bigger the team, theharder it is to do it, but I
think just to say, well, thenwe'll just do a really small

(32:24):
team there's, there's.
You lose something from thatbecause now you're going to get
way more homogenous.
You know, because even if youdon't enter that team that way,
that will tend to happen overthe course of you know, four or
five people are going to tend toeventually is how we do this.
Part of that so part of it isalso maybe even just maybe,
smaller teams that are moreephemeral as well, like if you.

(32:47):
That's.
The one thing about it too, islike you can have a bigger team
on the thing, but you're like,for this problem, we have this
squad that exists, it comes upto do this and then it's done,
done and next time it's adifferent squad.
So that way, if we have to makefast decisions, we can do that,
but we're not always the samepeople making the decisions and
we're able to distribute it andbring that in I love that.

William (33:09):
so you're basically saying that's one more thing I
want, sorry, okay.
So you're saying basically,like, instead of like decision
by committee, like that youwould see at a large company,
you basically have the fewpeople that are like, in charge
of this one thing and, yeah,they're going to take feedback
from all sorts of differentsources, but whether they use
that feedback, they're justusing it to inform their
decision that they get thatfinal decision.

Matty (33:30):
The bug has to stop somewhere because otherwise you
get into analysis paralysis.
Same thing happens in incidentresponse Analysis paralysis same
thing happens in incidentresponse.
That's why you have to have youknow, if you think about it in
the proper incident commandsystem, the incident commander,
whoever that happens to be, in aproper incident command system
it's a different person.
All the time they outrankeverybody on the call, even the
CEO, because someone's got to beable to be like.
This is the decision, becausethe right decision is the wrong

(33:53):
decision is better than nodecision Right Oftentimes is
better than no decision rightoftentimes so.
But I think you have todistribute that, though similar,
like innocent command can'talways be the same people that
are the decision makers evenaround the same thing, because
people will eventually turn intothen why am I even involved?
Because I'll undo.
All I am is an opinion.
But if it's like, hey and again, I wouldn't necessarily say
you'd structure it that itchanges every week I'm using

(34:15):
this as an analog.
But it's well, it's not my turnthis week, but I know I'll get
my turn, and that also if youeventually and then also brings
in that making the decisions ishard, what do you think about?

William (34:25):
it.

Eyvonne (34:26):
Well, there's God, there's so much.
I mean because there's teamsize and I do think, like beyond
a certain size for particulartasks, like it.
Just teams don't work once youget past a certain size.
If they're, if they're allworking together on a discrete
task, you know, and and in mymind that's somewhere around 10

(34:46):
or 15.
At the same time you've gotorganization size, which is a
completely different thing.
Because here's the thing thebigger organization, the more
discrete teams you need.
And then you've got to figureout how are all those teams
going to coordinate with oneanother and work together.
And when you start with a verysmall company, it's a
non-problem, because you know,and I think what we know, is

(35:12):
that a group can really onlyever be as big as around 150
people, like that's how manypeople we can know well and keep
track of In a startup.
That's perfect.
But once you start growing tothousands or tens of thousands
of people, you need a certaindegree of organizational
scaffolding to make all thatwork.

(35:34):
And the analogy that I use islike if you're building a single
family home that can be framedup with wood, with lumber, but
eventually, if you're building amulti-story apartment complex,
you've got to have some steelunderneath to keep that thing
from collapsing in on itself.
And then the question becomeshow much scaffolding do you need

(35:55):
?
And then how much room do youneed to give these teams the
ability to bend and flex, to beable to work together?
And it's actually a verydifficult problem because,
depending on the organization,depending on its mission,
depending on its culture,depending on its skill level,

(36:15):
that's going to look different.
But I think that the teamproblem is one problem.
But then part of your question,william, was like
organizational size, and that'sa completely different thing,
because at some point anorganization has to scale beyond
.
Like we just hire smart peopleand let them do their thing,

(36:37):
okay, but if you have five smartpeople all working on the same
thing in different ways, thenyou're working against yourself,
right?
So it's a much bigger, morecomplex problem than a lot of
times we want to give it credit,for it seems like it should be
simple.
It is not simple.

Matty (36:55):
To take an analogy, that's probably going to fall
apart halfway through it.
But it's kind of like, you know, when you're talking about,
like in that start of that smallteam, when it's like, hey, we
got this small group, that's amonolith and there's great
things about a monolith, right,you can move fast with that
because there's one thing orwhatever.
But then as you distribute out,so the large organization,
that's your microservice.
So if you're going to have amicroservices architecture,
there's a whole lot of differentkinds of not just technical but

(37:19):
just procedural infrastructureyou have to have in place and
you have to have well-definedAPIs, right where that comes in.
And I've really pushed thatmetaphor in maybe terrible ways
before.
But you know, teaching my teamin my last role would say you
have to learn the marketing API,you have to learn the sales API
, like how do you communicate?
And I have a talk I gave.

(37:42):
I just forgot the name of it,I'll get to it in a second.
Oh, it said zero trust is fornetworks, not for teams.
But it's kind of this idea ofthat.
If you think about aservice-oriented architecture,
it's like what happens insidethe team is the black box.
But you can only do that whenthe same thing with a server,
like nobody cares how thatservice executes as long as its

(38:03):
contract is fulfilled.
So if you say this is how wework with the larger part of
that, and we agree that nobodycares how you do it inside there
, so to speak, you know it'slike that's fine because this
thing goes in, I get this result, that's the thing that happens
and that's so.
But just like we said, you knowthe advantage of a monolith is

(38:23):
you got one repo, you got onething.
You know it's easy, it's fine,you know.
But you know.
So you can't just suddenly saywe're going from a monolith to
microservices but we're notgoing to build all the right
things in place to let theseservices we're not going to have
a service mesh, we're not goingto build all the right things
in place to let these services.

Eyvonne (38:39):
We're not going to have a service mesh.
We're not going to have acontract, yeah, yeah.

William (38:43):
That's a great analogy.
That didn't fall apart at all.
It's perfect, great thoughtexercise.
So where do you so?
I know one thing in listeningto a rest of DevOps here the
past few months, on and offwhenever I can there's so much
good content out there.
It's crazy.
You know, platform engineeringis one of those things that sort

(39:04):
of crept up.
It's almost like the new andthe new and shiny thing.
And I remember in enterprise,like you mentioned safe earlier,
which made me cringe because Iworked for a large Fortune 50
that went all in with SAFeStraight from Waterfall.
We didn't even know what washappening at the time and they
came in and the next thing weknew we had scrum masters, we

(39:28):
had program managers we hadproject managers, we had product
owners, we had more peopledoing process than actually
doing technical work.

Matty (39:35):
SAFe is all the ritual and none of the result right.

William (39:39):
It was so hard.
So do you think platformengineering is like a new?
Is it really a new idea at thispoint?

Matty (39:46):
No, and I don't think so.
I don't mean that in any kindof a dismissive way.
That's actually the good thing.
It's where we're in a positionthat we can.
It's interesting when you seethings and you're like we've
actually wanted to do this forso long and we were not capable
because the technology wasdifferent, the places were
different.
I think you know it's what isit?

(40:08):
James Governor said you know,everyone's just out there trying
to replicate Heroku.
You know, and if you thinkabout it, this was the idea,
right, you think about.
You know I've been talkingabout for years, about treating
your platform, treating yourinfrastructure as a product
internally, and that's real Ialmost said real platform
engineering here.
Now I'm going to be this purist, but if you kind of look at
platform engineering from thatperspective and the places that

(40:30):
do it successfully, that'sexactly how that works.
Right, it is.
This platform that we build isan internal product and we have
to treat it like a product.
You know, in terms of we havecustomers that have to use it,
so there has to be.
So DX matters, right, you know,giving the features that that
are.
You know whether your customersare one that's directly or

(40:52):
indirectly giving you money, andI think that's something that
has been sorely needed on theinfrastructure side and we
haven't really been in a goodway to do that.
I think there's also, just likeyou know, well, I'm going to
DevOps.
I'm just going to, you know,throw some Terraform at stuff
and now I'm DevOps.
Right, there's a lot of youknow, platform engineering isn't
just like go install Backstageand now you're a platform

(41:13):
engineer.
Right, it is a modality, it's away of of working and I think
it is an evolution of some ofthe things we talked about in
devops.
I think they go, I thinkthey're very closely aligned.
I think having, if you, if youespouse platform engineering
principles, devops as aprinciple and a way of working,
it's easier, right.

(41:35):
And also, I think where it cameout of was a little bit like
yvonne's point early, very earlyon, which said okay, you can
have these ideas and they work.
And then you start to hitcertain types of scale and you
know michael deuce used to say,you know, I mean, silos are good
, right, like silos like keepthings from blowing up a lot of
times on farms.
Right, like there are reasonswe have these things, but for

(41:55):
them to work well, they have tobe friendly silos and the models
of platform engineering allowfor that.
This says we can have becausethe scale is so big that it
can't just be everybody doeseverything.
We just sort of talked aboutthis in team side, but you have
the way that it's like servingthe right thing versus you know.
So it's not kind of the the wallof confusion stuff that andrew

(42:17):
schaefer would talk about whenyou're talking about interacting
with a platform team, becauseyou're interacting with it like
a product, not just like hereyou go, you know, and you can,
you can kind of take some ofthose or socio part of the socio
technical and kind of codify itand productize it a little bit.
I think that's where I think.
But just like every other time,we've tried to make things

(42:38):
better in this industry, people.
You know I again I'm really I'mgiving you all the things, but
one of my, my favorite littleoff the cuff ones, is you can't
buy DevOps but I sure can sellit to you, you know Well and one
of the one of the unfortunateside effects of the DevOps
movement was that there was thismentality that grew out of it.

Eyvonne (42:56):
was that there was this mentality that grew out of it
that, like your developers coulddo the ops and they could do
all the things right, and so itwas this bastard it was the
dumbest word.

Matty (43:08):
It should not have been called that.
You know, and Shea will tellyou that.

Eyvonne (43:12):
It was a bastardization of that ideology, right?
And so I think what platformengineering is doing is coming
back and saying, okay, theplatform is a thing that
developers need and we needpeople who specialize in
maintaining that platform anddelivering it right.

(43:33):
Because what we whitewashedaway as we started talking about
DevOps is that very importantjob of the operations people and
the folks who maintain all thethings that everybody needs to
work.
Because what the bean countersheard was oh, it's the full

(43:56):
stack engineer, we just needfewer, better people, right, and
it's.
It's kind of like that's,that's not how any of this works
, right?

Matty (44:04):
So I it's like ops is a skill right you can't just and
it's funny because there's, youknow, this happens and this is a
lot of this is human andorganizationally human.

(44:24):
You know, I remember I had afriend that I worked with many,
many years ago when I was awebmaster.
That'll date the conversationin the first place, but it was
for a computer catalog companyand you know so I worked very
closely with the person who diddesign the graphic designer, who
did the catalog, and she wouldsay, you know, like people come
and be like hey, tammy, can youteach me Photoshop this
afternoon?

(44:44):
And it's like this diminishingof what you do into like well,
it must be easy, I can just doit.
The only reason I don't do itis I don't want to.
And that was a lot of that toyour point of a lot of that was
to your point.
A lot of that was okay, well,if we just teach the devs and
then they can do what that waswe're like.
No, we're not saying that.
We're not saying everybody,it's just one persona.

(45:04):
What we're saying is break downthe walls, like devs should be
thinking about how this will beoperationalized, but not, they
do it.
And same thing and we.
The same damn thing happenedwith shift left, right, like the
idea of shifting security leftwas not get rid of the security
people and make all the securitybe done.
That we're just saying movesome of the thinking about that

(45:25):
earlier in the process, right,but you still have to have.
You can still have softwareengineers thinking about testing
and thinking about security andstuff, but that doesn't mean
you don't have security people.
You know it doesn't.
But it means that you're,you're, we're just sort of
making it more holistic andthat's harder to sell, cause,

(45:46):
like you said, cause same thingis how many things have been
misinterpreted as this will saveyou money.
And if that's your cloud, ifyour thought was cloud was going
to save you money, you're doingit wrong.
All cloud did was move CapEx toOpEx.
Right, there's no magic thing.
Automation does not.
Automation is not a headcountreduction exercise.

(46:07):
Automation is a reprioritizingof effort exercise.
It's getting more value out ofthe people that you have.
But it's not like, oh cool,we'll bring in Puppet and now we
can fire all the sysadmins.
You're like no platformengineering.
I agree with you 100% thatthat's a way of saying, okay, we

(46:30):
can have it in this way, butyou still have this domain
expertise.
That has to reason about thatand it doesn't work.
It doesn't scale one-to-one,and I think that's why you need
to have that, because you arealways going to have more
developers than ops for lots ofreasons.
And so I remember atapartmentscom when we, when we

(46:51):
took on agile, it was the ideawas okay, so now we moved into
these different agile teams andwe said, okay, we want to get
sysadmin like integrated.
So we said, okay, cool, sothere would be on every feature
team.
You know the team would made upoh, there were the testers, and
there was the scrum master andall the developers and like, and
then there was the sysadmin.
There were like seven featureteams.
I had three sysadmins, whichmeant everybody was on multiple

(47:16):
teams.
And we actually hit a pointwith the rituals where my team
came to me and they said do themath, let's do the math.
I literally have no time toactually do any work because my
entire day is taken up by Agileritual, because I go to three
standups a day, three sprintreviews every time, you know,
and all of this stuff, becauseyou're never going to.
It doesn't scaleorganizationally.

(47:36):
So you kind of build those andthat's what I'm saying where
everything old is new again,because that's how you would
approach it.
From infrastructure.
You said, okay, well, there wasinfrastructure as a service
different kind of as a servicethan cloud type thing.
We said you consume it becausewe have to be able to scale
behind it.
But that created a really bigwall and I think at least with
PlatEng we are better equippedto be able to treat it in the

(47:59):
way that we can use a lot ofthose great things.
But I'm going to remember whatyou said about it being a
pushback to that.
I think that's spot on, spot on.

William (48:11):
This was.
I think we need to startwrapping it up at some point.
This has been an amazingconversation.
It makes me so we were supposedto have, uh, tim banks on at
some point in the future.
We should have both of you onand do like a future of platform
engineering or the future ofdevops, one of those sort of
round table things.
I think having both of yourpersonalities in here at the
same time would be a riot itmight be a multi-episode

(48:33):
conversation.

Matty (48:34):
We might have to chunk it up into series yeah, I was
thinking, william, when you weretalking about the one-liners
for the shorts.
Um, we, uh, I started early onin arrested devops just sort of
randomly doing cold opens whereI would, you know, just pull a,
a quote kind of out of contextand throw it before the opening
music.
And then we, uh, we had, uh, mypodcast co-host, her husband,

(48:56):
was doing our audio editing forme and, my favorite thing, when
I would get the, the edit backfrom him, I'm like, ooh, I
wonder what, what, what Joe isgoing to pull out for the cold
open.
You know, and, and it was uh,it was always.
And then sometimes you sitthere and then, as you're doing
the episode, you're like, allright, oh, yep, I just said it,
that's the one.

William (49:15):
So you got to keep things entertaining, got to keep
it fresh.
Got to, you know, throw somecurveballs in there, right yeah.

Eyvonne (49:21):
We're all about the one-liners and platitudes.

William (49:24):
And I wasn't going to ask this before I just got to.
I have to know.
So I was in, I was presentingit.
Um, it was, uh, it was.
Aws community day, like twoyears ago, is in Chicago, and
I'm pretty sure I met you there,tim says there as well,
valtieri runs that she didDevOps days Chicago with me many
years.

Matty (49:43):
Tim Tim banks was actually at that one too.
Yeah, um, which I didn'trealize, and that was part of
what.
Yeah, and it was one of the.
I think when I came it was avery like last minute, like, oh,
I don't have anything going ontoday, let me come in and hang
out.
But I think you're right.
Yeah, that's crazy.
When you said I would be likeit wasn't two years ago, it was
like no, it probably was threeyears ago it was in the morning
star building.

William (50:01):
It was that month okay, great.

Matty (50:04):
Yes, hey, I know that, I remember that part.

William (50:07):
Yeah, it was.
It was very nice.
Okay, that's good.
And you so.
One thing too you motivate me.
So I've been on like sort oftrend, kind of like in between X
and blue sky.
At this point, and you're noshame, you're posting those leg
day updates, and leg days arelike the worst days for me.
I've hated them forever, sinceI was in high school, but I'm

(50:28):
starting to love them as I getolder because I've had these.
So I play competitive icehockey that's my one hobby and
I've had these hip issues overthe years and like doing legs
the right way and starting tobuild up that strength with hip
core glutes and all that hasbeen a life changer for me
because I sit so much.
That's a problem.

Matty (50:48):
Very, not to go into the whole thing, but it was like
what, what turned it around withme as I started like I was sort
of messing around withprogramming when I was starting
the lift.
I did, I did like, oh, I'll doa PP, I'll do whatever, I'll do,
like day.
And then I was.
I did a couple of months whereI did the five by five, and five
by five is every day, is issquats and so, and that was what
drove, that's really what wouldpush my squats way up as I was

(51:10):
doing them three days, you know,and I don't do that anymore but
like, yeah, it's, uh, it's,it's a good three days.
And I can tell the differencefor myself, just how I'm getting
older and that's a big part ofdoing this is you get around
differently.
You feel more comfortable doingcertain things, you know, and,
um, it's, yeah, it's, yeah, it'suh, they're, they're not fun,
but but then they become alittle fun, because then you're

(51:32):
like, okay, you know and whenyou see the gains and you see
the benefits.

William (51:36):
that is when it's like real and you're like you will
suffer through it.
Wake up early, do whatever youhave to do, but like how?
How often do you do legs out ofcuriosity?

Matty (51:44):
Well, I mean, so I do.
Um.
It's funny too, cause I wasjust about to change my program
and I'm like no, I'm going tostick with it.
So I do a four day.
So I'm probably doing, I'mdoing something with legs every
day, so it's either my main liftor my second lift.
So it's either so like on oneday, like for example today,
I'll do my, my heavy lift willbe squats and my secondary lift
will be bench press, so likemore reps but less weight, and

(52:08):
then tomorrow it's going to beoverhead press is my main lift
and then deadlift for volume,and then on thursday it will be
bench for volume, and then I dobulgarians, because they're
terrible.
You know I'm gonna hate myself,but there's still a squat, and
then on, and then on friday I'lldo deadlift heavy and overhead
lighter.

(52:28):
So so there's somethingposterior chain every day, um,
and and that also makes itbecause the same thing if you
have quote-unquote leg day, thenyou can hate leg day, but if
every day is leg day somehow butI also like doing it that way,
because there's other variantsI've done where, instead of
spilling them up, it would belike like the you know, um, five

(52:49):
, three, one.
It could be like, okay, you doheavy squats for, and then you
do, you do lighter ones and dothat all in the same day.
I'm like I like to mix them upbecause then it's not like then
you'd also don't have that day.
You just like you do somethingdifferent.
And you know, I told my son, my,my one of my 15 year old son.
He started lifting with me forthe beginning of the school year
.
Now he's doing it for baseballand he would talk about and he

(53:11):
sees all this stuff on YouTubeand he's like all this stuff,
and I said Joey, I said we arenovice lifters.
I said again, I've been doingthis for a year and I'm still a
massive beginner with a lot ofstuff.
You know, since I was doing it,however, long ago and to be
like so far, when it's like howdo I optimize and make sure I'm
doing exactly the right thing?

(53:32):
You know it's uh, it's justlike fundamentally, the best way
to get gains is just like dosomething with intentionality
all the time or show up and makeyourself sweat right, you know,
discipline over motivation soum love that, but it's, it's,
it's fun stuff so awesome,motivation so um love that, but
it's, it's, it's fun stuff, soAwesome.

William (53:49):
Well, it's been great having you, having you on the
show.
We've got to do this again withTim.
Yeah, it would be awesome.
Uh, where can?
So?
Where can folks find you?
You've got to ask.

Matty (53:57):
Um, yeah, you know that's a really good question.
Where can you find?
I mean it's, this is thebizarre thing.
You can find me on LinkedIn isa thing I never really would
have thought, but I was talkingto someone recently about how
all the tech content is over onLinkedIn.
You can find me at BlueSky, onmaddiewtf on BlueSky.
Just look up Mattie Stratton onLinkedIn.
Those are probably the mainthings.
Follow us, DevOps.

(54:17):
We'll get some more episodesout of there.
I'm excited Just having thisconversation.
I'm like all right, you got apodcast again, although it's way
more fun.
Maybe we'll get you guys tocome on my show, because being a
guest on a podcast is even morefun, because you just show up
and talk.
You know I know what peoplelistening don't understand is
you know William especially.
You know you guys are sittingback there going, ok, what's the
time and and OK, got to wrap upthis part or whatever.

(54:39):
Then you come on and you justrun your mouth.
So we'll do a crossover episode.
It'll be great.

All Episodes

Episode Transcript

Popular Podcasts

Fudd Around And Find Out

Crime Junkie

24/7 News: The Latest

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Evolving DevOps with Matty Stratton

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}Fudd Around And Find Out

Crime Junkie

24/7 News: The Latest

All Episodes

Evolving DevOps with Matty Stratton

Fudd Around And Find Out