Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Narrator (00:02):
You're listening to
the humans of DevOps podcast, a
podcast focused on advancing thehumans of DevOps through skills,
knowledge, ideas, and learning,or the skil framework.
Nickolas Means (00:13):
If someone's
having a particularly bad Day,
that's important context fortheir teammates to know as
they're working, and not havingthe mental friction of having to
put that down, when you show upto work every day is a big part
of avoiding burnout. Have itbeen okay just to be a human
network?
Eveline Oehrlich (00:33):
Welcome to the
humans of DevOps Podcast. I'm
evolutionarily Chief ResearchOfficer at DevOps Institute.
Today, we have a very specialguest, I'm very excited to
introduce to you Nicholas means,and he gave me the permission to
call him Nick. So that's whatactually I will do during our
call, and during our podcast. Solet me introduce him quickly. So
(00:55):
Nicolas is the VP of Engineeringat sim S, Y M. That's how it's
spelled. That's the adaptiveaccess tool built for
developers. He's been anengineering leader for more than
a decade focused on helpingteams build velocity through
trust and autonomy. He also is aregular speaker at conferences
(01:16):
around the world, teaching moreeffective software development
practices through stories ofreal world engineering triumphs
and failures. And I was justlistening to one of his talk,
which we'll come to later on. Sowelcome, Nick to our podcast
today.
Nickolas Means (01:32):
Thank you so
much for having me on everyone.
I'm so excited to be here.
Eveline Oehrlich (01:35):
Yes, I am
excited to talk to you. And of
course, we'll try to make itshort and sweet. So that our
listeners can enjoy some of thelearnings from you. Because you
have been like, in myintroduction, a thought leader,
and a engineering leader. Andthat's really what the title
today of the podcast is. It'sleading an engineering team
(01:59):
today, which I think is noteasy. I'm sure it's fun. But
that's really kind of at thecore. But before we go there,
let's start with SIM digginginto sim solution, I found this
very interesting sentenceinfrastructure needs to be
secure. It's something we allcan agree on. But how to make
(02:20):
that a reality is different.It's a very different hat. And
this is where you guys sim havedone some great invention and
innovation. So tell us about simand what it does.
Nickolas Means (02:33):
Yeah,
absolutely. So sim at its heart
as a platform for creatingaccess and approval workflows
for production infrastructure,among other things. It lets you
declare workflows in TerraForm,right alongside the rest of your
infrastructures, code code, letsyou customize the logic using
Python and then execute thoseworkflows in Slack. And it's
(02:53):
probably easiest to understand,if I just tell you how we use
sim at sim we're still a smallteam, a lot of teams our size,
we would probably still havepretty wide open system access.
But because of some of the thecustomers that we sell to and
the kind of product we'rebuilding, that's not really an
option for us, we're actuallyalready sock two type two
compliant. So part of how weaccomplish that is putting a sim
(03:16):
workflow in place for accessingour own production
infrastructure. So if anengineer on our team needs
access to something in prod,they make that request in the
Slack channel using the sim botand then any of the other
engineers on the team can peerapprove that access for them. So
it's kind of a two keys tolaunch the rocket approach to
production access. And it worksgreat, except in the middle of
(03:39):
the night, because you don'twant the on call engineer to
have to wake somebody else upjust to get the access, they
need to troubleshoot. And so theway we've solved that we have an
SDK integration with pager duty.So we can tell if the person
that's requesting that access inthe middle of the night is also
the on call engineer. If theyare the system will
automatically approve thataccess for them and let them
access to production systemsthat they need. So they don't
(04:00):
have to wake anybody up in themiddle of the night to do it.
Very
Eveline Oehrlich (04:03):
cool. Wow.
That is very cool. Super duper.
I used to be a three on thisnight call in many years ago.
And of course, that is a greatappreciation on for my angle, if
I would not be have to be wakenup but at that time, we didn't
have things like that. Super.Excellent. All right. So we do
(04:29):
four or five years now we havedone research around skill skill
building, or upskilling, as wecall it, and from this recent
work this we call theupskilling. It 2023 research.
It's based on survey of overmore than 1500 folks across
different roles, developersoperations, etc, etc. We see
(04:52):
significant gaps across avariety of skill domains, right
there are skill gaps, of coursearound process skills. And
again, is it DevOps, isn't itTill Is it safe? Is it agile or
lean it for at all differentkinds of process skills, or
technical skills, those are thetwo top must have, or the areas
where we see the biggest skillgaps, but also leadership and
(05:14):
human skills right behind that.We also know that there are
significant gaps across thoseleadership and human skills
categories. And as you've beenan engineering leader for more
than a decade, I would love toquiz you on some of these
different skill domains inspecific leadership and human
skills. So my first question isreally around leadership skills
(05:37):
in today's organizations andteams. What would you say are
some best practices you haveapplied to lead a team of
engineers today?
Nickolas Means (05:49):
Yeah, that's a
great question. You know, today
is doing a lot of work in thatquestion, because it has
changed, leading engineeringteams has changed a lot,
especially over the last, Idon't know, year, year or two.
Probably the most interestingtrend is the shift to remote
organizations that used to be anofficer or remote. Now, new
companies that are forming aresort of remote by default. And a
(06:10):
lot of cases, just because ofthe the shift and work practices
that happened during thepandemic. And things that would
be good leadership practices,and in an office setting become
essential, you know, whenyou're, when you're in that
distributed context, and one ofthe first things on that list
for me is, is trust. You know,when your engineers are spread
out all over the place, they'renot in an office together, you
(06:32):
lose the ability to kind of dothe button seat management
thing, you can't look around theoffice, see who's there, see who
looks busy, and assume that youknow what's going on with your
team. And I think this is a goodthing. But it's also a hard
shift to navigate. As a manager,if you've been used to managing
teams in in an in personsetting, you have to be able to
(06:53):
trust the people on your team todo work, and you have to be able
to show them that they'retrusted. Because, you know, a
distributed team is by default,going to have to operate in a
more independent fashion than ateam in an office, they're going
to spend more time kind of ontheir own doing work. And then
when when you have a team ofengineers that are working more
(07:14):
independently, you have to spendmore time as a leader building
context. You know, I Youmentioned in the intro that I do
a lot of speaking at my talksare a little different than most
in that they're primarilystorytelling, I spend about 20,
or 30 minutes telling a storyand then draw a conclusion from
it at the end. But most of itsstorytelling, and that crosses
over into my day to day work alot as well. It's a, it's a
(07:37):
pretty key tool in my toolbox,around setting context for
engineering teams. And beingable to tell the story of the
organization, the story of ourcustomers, the story of the
feature that we're trying tobuild in a way that the
engineers on the team canconnect with it, and work from
it in an independent andautonomous fashion. And then,
(08:00):
you know, I mean that trust andautonomy, I think it's important
because it goes a long way tohelping engineers be happy and,
and more satisfied in theirwork. You know, it's one thing
to pick cards off of anengineering backlog and do them
and ship the code and thatsatisfying. But it's a whole
different kind of satisfaction,when you're able to take a
(08:20):
problem that one of yourorganization's customers is
experiencing, go from thatproblem statement, to figuring
out what the right solution inyour platform would be. And to
build that solution. And then tobe able to put it in the hands
of your customer and see the thework that you've done impacting
the way that they're able to dotheir work. So I'm always trying
to find ways to connect thatwhole thread and help the team
(08:42):
see the whole thread of thethings that they're working on.
Eveline Oehrlich (08:46):
Great. So do
you get you get feedback from
the folks saying, Hey, you,awesome. I appreciate this trust
you give me you could, I mean,that's rewarding, I'm assuming
for you as a leader as well,right?
Nickolas Means (08:59):
It's one of my
favorite things. And it's one of
the reasons that I I've, I'vesort of grown to lead teams this
way over time, because it is alot more satisfying for me to be
able to see my team build thatkind of satisfaction and to
achieve that kind of growth. Imean, one of one of the
challenges and risks of ofleading this way is you have to
be careful. You're giving peoplethe right amount of autonomy,
(09:20):
and you're not asking them tokind of you know, if they've
never been rock climbing before,you don't want to ask them to go
climb the Dawn Wall. You want aproblem that is approachable.
Eveline Oehrlich (09:28):
Yep, the sink,
sink or swim. Right. Thinkorswim
approach we've been through thatin old styles of leadership. I
remember leaders in my formerlife like that Excellent. Great
example. Great, great idea,storytelling and of course twist
and autonomy at the right at theright level. Yeah, this is a
situation with engineers beingall over the world practical.
(09:52):
just spoke to one of theengineers who is leading a dev,
a dev ops team, who moved toSome for an island because he's
a surfer and loves to work fromthere. And of course, his team
is somewhere completelydifferent in a timezone. And so
he said to me, yes, my, mymanager, my leader, trust me
completely I do. I feel great aspart of that team. So evidence
(10:17):
to that as well. Excellent. Solet's shift on to the challenges
leading teams of engineers, andnot just engineers, of course,
but we're focusing on engineersright now that's come without
doesn't come without challenges,right? Burnout, productivity
issues are just a few. But I'msure you've seen other
challenges. So what challengesor problems have you seen as
(10:39):
leader of engineering teams? Andthen of course, how you address
them? How do you solve them, andyou can pick one or two doesn't
have to be, you know, like Isaid, burnout or productivity,
I'm sure you have otherexamples.
Nickolas Means (10:55):
I actually love
that you mentioned burnout,
because that's been a pretty keyfocus of mine, for myself. And
for the folks that I lead overthe past couple years. The the
interesting dynamic thatemerged, sort of at the start
and through COVID, was life justgot a lot harder across the
board, there were a lot morethings to think about. I mean, I
(11:17):
distinctly remember at the startof the pandemic, going to the
grocery store and facing a lineto check out that stretched all
the way to the back of thestore. And that's something that
I had never seen before. Andeverybody on my team was doing
that they're like, Okay, I gottago grocery shopping, and it may
take me all afternoon to do it.I'm, I'm feeling slightly guilty
about missing work. And it'sit's sort of continued. I mean,
(11:40):
there's, even as the pandemichas waned, I wouldn't say it's
over. But as its waned, thereare other concerns that have
sort of stepped in, aroundgovernment. And you know, in the
United States, some of thechallenges around gender
affirming care that areexperienced in some of the
states. And so it feels likepeople just have a lot more on
their mind and are having tojuggle a lot more outside of
(12:03):
work context, in addition to thework that we're asking him to do
as part of our companies. And soyou know, that the challenge
with that is, or the solution Ifound with that is just to be
more comfortable with peoplebringing more of theirs
themselves to work. You know,it's, it's tempting to tell
(12:24):
people, okay, you're at work nowset that on the shelf, I need
you to be productive. But that'snot that's not how humans work.
And we all know it, we just liketo pretend that that's not the
way the way it actually is. Butthere's a lot of power in
welcoming those feelings,welcoming those struggles, being
able to talk about them in thework context, because they are
context for the work that peopleare doing. If someone's having a
(12:46):
particularly bad day, because ofthings that are they're seeing
in the news cycle thatparticularly affect them. That's
important context for theirteammates to know as they're
working with them that day, andnot having the mental friction
of having to put that down. Whenyou show up to work every day,
is a big part of avoidingburnout, I think of it being
(13:07):
okay just to be a human at work,and
Narrator (13:12):
skill up days and
scale up hours are the perfect
way to stay on top of the latestDevOps trends and improve your
skills from the comfort of yourown home or office. Our virtual
micro conferences and webinarsfocused on DevOps and the tech
industry and feature expertsspeakers from both the DevOps
world and top it companies. Atour skillup days, you will get
everything you'd expect attraditional conference,
(13:34):
including virtual sponsorbooths, competitions, and
networking opportunities withother attendees and speakers,
don't miss out, check out ourlineup of upcoming events on
DevOps institute.com. Andregister now.
Eveline Oehrlich (13:49):
You know,
this, this reminds me of again,
my earlier career, I started ita very large company, as a
support engineer. And I have toname them the company because
it's important Hewlett Packardat the time, and Dave Packard
and Bill Hewlett had a theme itwas for many, many, many things.
(14:11):
It's called I was called HP way.And part of the HP way was
actually exactly that. And thisgoes back to I started there in
83. So right so many, many yearsago, and I actually met both of
those gentlemen once and yeah,unbelievable. I still am very,
very few myself very lucky thatI have met those two gentlemen.
(14:33):
But in that HP way, it wasaddressed exactly that to bring
yourself into the company. And Ithink it was Dave, who was
telling a story at one of thosecoffee talks and he said he went
up to an engineer and he said,why'd you leave? I watch your
car. Every morning. I parkednext to your car and you leave
(14:55):
the car window open, slightlyopen. Why do you leave it open?
Because it's raining bydiscipline? Palo Alto it rains.
And then and a gentleman said,so that my personality wouldn't
suffocate in the car. Andeverybody was laughing about
that. But that individualobviously did not want to bring
(15:17):
his personality in the leftistperson is humanity in the car.
You know, I thought that wasreally funny. It meets in
matches really exactly what whatyou were saying having that
having that human and that's forus DevOps Institute is very
important. And that fitsactually with my next. My next
thought and my next topic.Again, in the research we did, I
(15:42):
still, I was blown away thatcollaboration and coordination
is still the biggest skill gapacross these organizations, who
answered all these individualswho answered? So from the
research, we found 35% When weask them, what are your top
three gaps in human skills, andthis the first one was
(16:03):
collaboration, cooperation, but35% The second one was
creativity and entrepreneurship.And then the third was diversity
and inclusion made, I'm notsurprised on the diversity and
inclusion. We have made a lot ofprogress, but collaboration and
cooperation after so many years,and after so much of work. So
here my question, in youropinion, why is it so difficult
(16:29):
to get people to collaborate andto cooperate? Because I mean, we
all are working on goals shouldbe thinking we're working
together and goals. But why isit so difficult?
Nickolas Means (16:42):
Yeah, I mean,
it's, it's fascinating, the
survey results that you justcited. I think a lot of a lot of
the reason all three of thoseare lacking in a lot of
organizations, kind of comesdown to the same root cause and
that's lack of safety. You haveto build for all three of those
things possible collaboration,ownership, inclusivity, there
(17:06):
needs to be a foundation of deeppsychological safety, that's a
part of any team that's going tohave those things as an as an
attribute those skills presentin the work that they do. It's,
it's really hard to collaborate,when you're also competing for a
promotion. And that's the thingthat's on the forefront of your
mind, there's the zero sum gamethat you're playing, you're
trying to climb a ladder, youdon't feel very safe, you can't
(17:28):
say I don't know, you can't askfor help, you have to always
look like you have it puttogether in order to keep
climbing that ladder. You know,it's interesting, you mentioned
the How to crash a plane talk,one of the fascinating dynamics
there. So that talk was aboutUnited flight 232, which was a
flight that sort of crashedlanded in Sioux City, Iowa, had
(17:51):
a lot better the the tail enginefan desk exploded, lost all of
its hydraulics. But they managedto get the plane to an airport
and onto the ground in arelatively controlled fashion
for a plane that had nohydraulics. And it had a lot
better outcome than then itprobably could have. In fact,
they, they tried to do it insimulators afterwards. And none
(18:13):
of the crews that tried to pilota plane that was set up in a
similar configuration on thesimulator could come anywhere
close to the outcome that thatflight crew managed to get. When
you start digging into why thatis. This was sort of right after
Crew Resource Management orcockpit Resource Management
became an important part ofaviation. And it's this idea
(18:34):
that that in the cockpit, you'rein a life or death situation,
because you have to pilot thisplane safely. And in that
situation, you should use all ofyour resources at your disposal
to do that. You know, prior tocockpit Resource Management
becoming a part of aviation,there were all these incidents
where the captain's word wouldgo. And the captain would sort
(18:57):
of shut down the rest of theflight crew or they wouldn't
feel comfortable challenging himeven when they saw a problem,
they wouldn't want to point itout. And I use I use the word to
him pretty deliberately therebecause most pilots back then
were men. And it's it's been,it's been a challenge for the
aviation industry to build CrewResource Management into the way
(19:19):
that they work. It's an ongoingthing that flight crews still
work on, still receive trainingon. But the key idea behind it
is that everybody in the cockpitgets a voice. Everybody that's
participating in the situationhas a right to speak up to talk
about what they see, to pointout what they're seeing. And the
same sort of ideas translate toengineering teams. You know,
(19:39):
it's pretty easy in anengineering team for one person
on the team, to have thedominant voice and to kind of
force their will upon everybodyelse on the team. They're used
to their voice being the defaulttheir viewpoint being the one
that that's the most important.And that's a really difficult if
you're in that situation. It'sreally difficult to Want to
(20:00):
collaborate or cooperate or evenfind the room to be able to do
it. Whereas if you have a teamwhere everybody is seeking to
make room for everybody else,everybody is seeking to empower
everybody else. Everybody wantseverybody else to succeed. And
as as a leader of that team,you're incentivizing that kind
of behavior, and you'rerewarding people for that kind
(20:21):
of behavior. Then you seethings, you see behavior start
to emerge from the team that youwouldn't see in the absence of
that safety and that invitationto participate.
Eveline Oehrlich (20:32):
Beautiful, we
should do, we should think about
a blog on that the lack ofsafety or actually the
inspiration, give inspiration toensuring that there is that
safety feeling. It makes methink of my two daughters, both
of them's just started theircareers. One is an architect,
the other one is an analyst, incustomer experience, and my
(20:56):
architect, she is in a even soshe's it's a women led company,
but there is a lot of, let'ssay, older architects and their
male. And so she just sent me atext yesterday, she's supposed
to do a presentation today onsustainability. And she is all
worried about because there'sgoing to be a whole bunch of
(21:17):
guys in the team. And they allare thinking, and are very
overwhelming. And I didn't knowwhat what to tell her. She said,
Mama, what how I, of course, Isaid to good, you know,
enforcing that she has theskills. And if you don't know,
then ask the questions. And ifthey ask you a question, and you
don't know the answer, say justyou don't know the answer. Don't
(21:37):
be asked them. But that wasshocking to me that, that she's
so scared even so she's notthere for a year and a half,
obviously, in that organization.They don't have that safety net,
or that feeling of safety. Sothat's that is that is a that's
a great blog, we shouldcollaborate on super great idea.
(21:58):
Great idea. Let's do that. Allright. We are lacking technical
skills. I'm sure you guys havechallenges finding good
engineers or skilled engineers,right. And we do know and see.
And again, this is from the sameresearch upskilling and, you
know, learning initiatives, andso on. But I'm curious on we
(22:22):
talked a little bit about thisat the beginning, I'm curious on
your thoughts around aneffective and a successful
upskilling or skill buildingpath. Let me share with you what
we found from our research. Sowe asked the question, what are
the top three upscalingframeworks? Or how do you like
to learn in the IT organization?So 48% said they'd like to do
(22:44):
virtual learning online events,conferences, classes, self
study, blah, blah, blah. Inperson learning kind of goes
along with that, depending onright where you are and how far
and how much budget you have.But then the next one is peer
learning, buddying, workflow,shadowing, pair programming and
things like that. That's 40%,then expert coaching, leader
(23:07):
coaching, manager coaching, andthen experiential learning. It's
about 31%. And then there were20%. I can't believe that as was
for doing fieldwork, maybe theydidn't think maybe I'm thinking
of fieldwork or somethingdifferent. I call it the sink or
swim model. But 20% A preferringthat I was like, what did they
(23:29):
not read the survey correctly?Anyway? My question for you,
what has worked for what youhave seen in terms of skill,
creation, and upskilling andlearning paths? In all of those
things? What do you guys applywhen you bring in new engineers?
Or what do you see with yourcustomers?
Nickolas Means (23:49):
Yeah, it's
interesting. Again, I think, you
know, the the shift to remotework that we're seeing
definitely plays into this andchanges some of the learning
modalities that work best for ateam. There's sort of this
common wisdom, that remote org,you can't be a successful new
engineer and in a remoteorganization. And I've not found
(24:10):
that to be the case. I'veactually seen some folks come
straight out of boot camp andremote organizations and do
great. But it was because thatorganization spent a lot of time
in that that third category thatyou talked about the peer
learning, buddying pairprogramming. You know, it takes,
again, going back to safety, ittakes a safe organization to be
(24:31):
able to pull that off forsomebody who's new to their
career to be able to come in andfeel safe enough, saying I don't
know over and over again. Andsitting with a more senior
engineer and letting that seniorengineer kind of be the
navigator in that pair. And letthem kind of fumble their way
around and unstick them everyonce in a while every once in a
while. And it can feel if youdon't think about it the right
(24:53):
way. It can feel like aninefficient use of that senior
engineers time. But if you thinkof it in terms of an invest
meant in upskilling. But theyoung, the newer engineer, it
makes perfect sense to spendtime that way. It, it's funny.
I've had a bunch ofconversations with folks that
are that are in that positionwhere they're the more senior
(25:14):
engineer, they're navigating ina pair, they're helping a newer
engineer come up to speed, andhelping them reframe what
they're looking for in thatpairing session. Yeah, of
course, you want to get the taskdone, you want to get the code
shipped. But you're also goingto have to find some
satisfaction or watching thatother person learn, or you're
going to get really impatient,and you're not going to let them
do the learning that they needto do. So that's probably my, my
(25:38):
biggest strategy in this regard.I don't know, I also, I think we
tend to overemphasize this alittle bit in the technology
world, the idea that thatsomeone is technically skilled
enough to do the job. I thinkmost people that gravitate
towards this kind of career aretechnically skilled enough and
(25:58):
sharp enough to figure it out.And if you give them the
resources, they're going to beable to navigate that. And we
don't spend a whole lot of timein the hiring process screening
for collaboration, screening forability to work together,
screening for ability to be agood peer on an engineering
team. And that's, that's part ofwhat creates that culture of
safety in the first place wheresomebody can learn and grow and,
(26:21):
and take advantage ofopportunities that are just
slightly outside their comfortzone.
Eveline Oehrlich (26:27):
I am sometimes
amazed looking at the different
job descriptions, because skillresearch is what I do, and
whatever, indeed, or LinkedIn,or wherever I look at many of
these job descriptions forDevOps engineers, automation,
engineers, developers, whatever.And I'm absolutely amazed at the
(26:50):
lack of this human skillsrequirements that put in there,
say, Okay, you have to knowPython, and you have to know
that, and all of that, and allof that I'm sure these these
these folks have, right thatthat's what they do. That's
where they are in the job, theylove this type of stuff. Why
don't they have otherrequirements. And I think until
it is that way, that we havethose types of things. As a Must
(27:15):
it, it will be a challenge. Andfor those who are here, like
yourself, leaders to look up to,it's hard work for you. It's
hard work to cast that shadow ofsuch a leader. But they're not
enough. And I think that's achallenge. And for us at DevOps
Institute, we need to shift intothat human upskilling as well.
(27:39):
But that's also hard, right?Because how do you do that? How
do you how do you do that?That's a question for next time.
Go ahead. It's
Nickolas Means (27:46):
it's really
hard. Yeah. I mean, I think, you
know, it sort of gets back towhat do we incentivize? Yep. You
know, are we are we rewardingpeople for shipping big marquee
features? Are we rewardingpeople for making an entire team
more efficient by the influencethey have on that team? We
should reward both. But we oftendon't reward the person that
does that second job.
Eveline Oehrlich (28:05):
Exactly.
Absolutely. Well said,
fantastic. Well, I have one morequestion and has nothing to do
well, maybe I'm not sure. Myclosing question. What do you do
for fun?
Nickolas Means (28:16):
It's funny I So
recently, I have been picking
piano back up, I played piano asa kid, and then quit in, I
think, when I was about 10, or11, and haven't played since.
And I've been learning to playpiano. And I've actually got one
in my office here sitting rightbehind me. And I love it.
Because I'm good enough now thatI've got some songs that are fun
(28:37):
to play that I enjoy playing.And I can go sit down at the
piano. And it sort of shifts meout of out of out of thinking of
whatever problem it is I'mtrying to think through. It'll
move that problem into mysubconscious because I'm
focusing on playing the piano.And I'll emerge from playing the
piano 15 or 20 minutes. And mybrain has figured out what to do
about the situation that I wasthinking about before I sat down
(28:58):
to play. Ah, I didn't expectthat when I started taking piano
backup. I just was I felt sadthat I didn't know how to play
piano anymore. But that's been areally fun thing to realize.
Eveline Oehrlich (29:07):
So double
double whammy double win for
you. Excellent. That isfantastic. I'm jealous. I'm too
old to learn it. I have aguitar. I played it. It's behind
me. Maybe I should take youryour advice and do the same
thing. Break. Stop the meeting,stop thinking play a few tunes
practice. I will do that. I willlet you know how it turns out
(29:30):
surprise deal. This has beengreat. Nick, thank you so much.
Thank you for your time. Thankyou for the great advice for
some great coaching and I hopeour listeners enjoyed that very,
very much what you had to say soagain, thank you we've been
talking to Nicholas means VP ofEngineering at sim sy M. Check
(29:51):
it out. And if you have achance, check out the How to
crush an airplane. Which youmentioned Nick. It's the Crew
Resource Management In a lot ofwar, a great story I loved I
love the YouTube. It's onYouTube on United Airlines. 232
DC 10. Crash, sad, but it's alsovery, very good because it has a
(30:11):
lot of things again, Nicholas,thank you so much for joining me
today.
Nickolas Means (30:15):
Yeah, thanks so
much for having me on everyone.
It's been a great conversation.
Eveline Oehrlich (30:19):
You humans of
DevOps podcast is produced by
DevOps Institute. Our audioproduction team includes Julia
pape, Daniel Newman, Schultz andBrendan Leigh. Shout out to my
wonderful colleagues who makethis sound even better when
they're done with it. I'm humansof DevOps podcast executive
producer Evelyn earlyish. If youwould like to join us on a
podcast, please contact us athumans of DevOps podcast at
(30:44):
DevOps institute that calm and Idid not make a mistake saying
that. I'm Evelyn early. I'lltalk to you soon.
Narrator (30:55):
Thanks for listening
to this episode of the humans of
DevOps podcast. Don't forget tojoin our global community to get
access to even more greatresources like this. Until next
time, remember, you are part ofsomething bigger than yourself.
You belong