Narrator: You're listening to the humans of DevOps podcast, a
podcast focused on advancing the humans of DevOps through skills,
knowledge, ideas, and learning, or the skil framework.
Nickolas Means: If someone's having a particularly bad Day,
that's important context for their teammates to know as
they're working, and not having the mental friction of having to
put that down, when you show up to work every day is a big part
of avoiding burnout. Have it been okay just to be a human
network?
Eveline Oehrlich: Welcome to the humans of DevOps Podcast. I'm
evolutionarily Chief Research Officer at DevOps Institute.
Today, we have a very special guest, I'm very excited to
introduce to you Nicholas means, and he gave me the permission to
call him Nick. So that's what actually I will do during our
call, and during our podcast. So let me introduce him quickly. So
Nicolas is the VP of Engineering at sim S, Y M. That's how it's
spelled. That's the adaptive access tool built for
developers. He's been an engineering leader for more than
a decade focused on helping teams build velocity through
trust and autonomy. He also is a regular speaker at conferences
around the world, teaching more effective software development
practices through stories of real world engineering triumphs
and failures. And I was just listening to one of his talk,
which we'll come to later on. So welcome, Nick to our podcast
today.
Nickolas Means: Thank you so much for having me on everyone.
I'm so excited to be here.
Eveline Oehrlich: Yes, I am excited to talk to you. And of
course, we'll try to make it short and sweet. So that our
listeners can enjoy some of the learnings from you. Because you
have been like, in my introduction, a thought leader,
and a engineering leader. And that's really what the title
today of the podcast is. It's leading an engineering team
today, which I think is not easy. I'm sure it's fun. But
that's really kind of at the core. But before we go there,
let's start with SIM digging into sim solution, I found this
very interesting sentence infrastructure needs to be
secure. It's something we all can agree on. But how to make
that a reality is different. It's a very different hat. And
this is where you guys sim have done some great invention and
innovation. So tell us about sim and what it does.
Nickolas Means: Yeah, absolutely. So sim at its heart
as a platform for creating access 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, lets you customize the logic using
Python and then execute those workflows in Slack. And it's
probably easiest to understand, if I just tell you how we use
sim at sim we're still a small team, a lot of teams our size,
we would probably still have pretty wide open system access.
But because of some of the the customers that we sell to and
the kind of product we're building, that's not really an
option for us, we're actually already sock two type two
compliant. So part of how we accomplish that is putting a sim
workflow in place for accessing our own production
infrastructure. So if an engineer on our team needs
access to something in prod, they make that request in the
Slack channel using the sim bot and then any of the other
engineers on the team can peer approve that access for them. So
it's kind of a two keys to launch the rocket approach to
production access. And it works great, except in the middle of
the night, because you don't want the on call engineer to
have to wake somebody else up just to get the access, they
need to troubleshoot. And so the way we've solved that we have an
SDK integration with pager duty. So we can tell if the person
that's requesting that access in the middle of the night is also
the on call engineer. If they are the system will
automatically approve that access for them and let them
access to production systems that they need. So they don't
have to wake anybody up in the middle of the night to do it.
Very
Eveline Oehrlich: cool. Wow. That is very cool. Super duper.
I used to be a three on this night call in many years ago.
And of course, that is a great appreciation on for my angle, if
I would not be have to be waken up but at that time, we didn't
have things like that. Super. Excellent. All right. So we do
four or five years now we have done research around skill skill
building, or upskilling, as we call it, and from this recent
work this we call the upskilling. It 2023 research.
It's based on survey of over more than 1500 folks across
different roles, developers operations, etc, etc. We see
significant gaps across a variety of skill domains, right
there are skill gaps, of course around process skills. And
again, is it DevOps, isn't it Till Is it safe? Is it agile or
lean it for at all different kinds of process skills, or
technical skills, those are the two top must have, or the areas
where we see the biggest skill gaps, but also leadership and
human skills right behind that. We also know that there are
significant gaps across those leadership and human skills
categories. And as you've been an engineering leader for more
than a decade, I would love to quiz you on some of these
different skill domains in specific leadership and human
skills. So my first question is really around leadership skills
in today's organizations and teams. What would you say are
some best practices you have applied to lead a team of
engineers today?
Nickolas Means: Yeah, that's a great question. You know, today
is doing a lot of work in that question, because it has
changed, leading engineering teams has changed a lot,
especially over the last, I don't know, year, year or two.
Probably the most interesting trend is the shift to remote
organizations that used to be an officer or remote. Now, new
companies that are forming are sort of remote by default. And a
lot of cases, just because of the the shift and work practices
that happened during the pandemic. And things that would
be good leadership practices, and in an office setting become
essential, you know, when you're, when you're in that
distributed context, and one of the first things on that list
for me is, is trust. You know, when your engineers are spread
out all over the place, they're not in an office together, you
lose the ability to kind of do the button seat management
thing, you can't look around the office, see who's there, see who
looks busy, and assume that you know what's going on with your
team. And I think this is a good thing. But it's also a hard
shift to navigate. As a manager, if you've been used to managing
teams in in an in person setting, you have to be able to
trust the people on your team to do work, and you have to be able
to show them that they're trusted. Because, you know, a
distributed team is by default, going to have to operate in a
more independent fashion than a team in an office, they're going
to spend more time kind of on their own doing work. And then
when when you have a team of engineers that are working more
independently, you have to spend more time as a leader building
context. You know, I You mentioned in the intro that I do
a lot of speaking at my talks are a little different than most
in that they're primarily storytelling, I spend about 20,
or 30 minutes telling a story and then draw a conclusion from
it at the end. But most of its storytelling, and that crosses
over into my day to day work a lot as well. It's a, it's a
pretty key tool in my toolbox, around setting context for
engineering teams. And being able to tell the story of the
organization, the story of our customers, the story of the
feature that we're trying to build in a way that the
engineers on the team can connect with it, and work from
it in an independent and autonomous fashion. And then,
you know, I mean that trust and autonomy, I think it's important
because it goes a long way to helping engineers be happy and,
and more satisfied in their work. You know, it's one thing
to pick cards off of an engineering backlog and do them
and ship the code and that satisfying. But it's a whole
different kind of satisfaction, when you're able to take a
problem that one of your organization's customers is
experiencing, go from that problem statement, to figuring
out what the right solution in your platform would be. And to
build that solution. And then to be able to put it in the hands
of your customer and see the the work that you've done impacting
the way that they're able to do their work. So I'm always trying
to find ways to connect that whole thread and help the team
see the whole thread of the things that they're working on.
Eveline Oehrlich: 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: It's one of my favorite things. And it's one of
the reasons that I I've, I've sort of grown to lead teams this
way over time, because it is a lot more satisfying for me to be
able to see my team build that kind of satisfaction and to
achieve that kind of growth. I mean, one of one of the
challenges and risks of of leading this way is you have to
be careful. You're giving people the right amount of autonomy,
and you're not asking them to kind 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 a problem that is approachable.
Eveline Oehrlich: Yep, the sink, sink or swim. Right. Thinkorswim
approach we've been through that in old styles of leadership. I
remember leaders in my former life like that Excellent. Great
example. Great, great idea, storytelling and of course twist
and autonomy at the right at the right level. Yeah, this is a
situation with engineers being all over the world practical.
just spoke to one of the engineers who is leading a dev,
a dev ops team, who moved to Some for an island because he's
a surfer and loves to work from there. And of course, his team
is somewhere completely different in a timezone. And so
he said to me, yes, my, my manager, my leader, trust me
completely I do. I feel great as part of that team. So evidence
to that as well. Excellent. So let's shift on to the challenges
leading teams of engineers, and not just engineers, of course,
but we're focusing on engineers right now that's come without
doesn't come without challenges, right? Burnout, productivity
issues are just a few. But I'm sure you've seen other
challenges. So what challenges or problems have you seen as
leader of engineering teams? And then of course, how you address
them? How do you solve them, and you can pick one or two doesn't
have to be, you know, like I said, burnout or productivity,
I'm sure you have other examples.
Nickolas Means: I actually love that you mentioned burnout,
because that's been a pretty key focus of mine, for myself. And
for the folks that I lead over the past couple years. The the
interesting dynamic that emerged, sort of at the start
and through COVID, was life just got a lot harder across the
board, there were a lot more things to think about. I mean, I
distinctly remember at the start of the pandemic, going to the
grocery store and facing a line to check out that stretched all
the way to the back of the store. And that's something that
I had never seen before. And everybody on my team was doing
that they're like, Okay, I gotta go grocery shopping, and it may
take me all afternoon to do it. I'm, I'm feeling slightly guilty
about missing work. And it's it's sort of continued. I mean,
there's, even as the pandemic has waned, I wouldn't say it's
over. But as its waned, there are other concerns that have
sort of stepped in, around government. And you know, in the
United States, some of the challenges around gender
affirming care that are experienced in some of the
states. And so it feels like people just have a lot more on
their mind and are having to juggle a lot more outside of
work context, in addition to the work that we're asking him to do
as part of our companies. And so you know, that the challenge
with that is, or the solution I found with that is just to be
more comfortable with people bringing more of theirs
themselves to work. You know, it's, it's tempting to tell
people, okay, you're at work now set that on the shelf, I need
you to be productive. But that's not that's not how humans work.
And we all know it, we just like to pretend that that's not the
way the way it actually is. But there's a lot of power in
welcoming those feelings, welcoming those struggles, being
able to talk about them in the work context, because they are
context for the work that people are doing. If someone's having a
particularly bad day, because of things that are they're seeing
in the news cycle that particularly affect them. That's
important context for their teammates to know as they're
working with them that day, and not having the mental friction
of having to put that down. When you show up to work every day,
is a big part of avoiding burnout, I think of it being
okay just to be a human at work, and
Narrator: skill up days and scale up hours are the perfect
way to stay on top of the latest DevOps trends and improve your
skills from the comfort of your own home or office. Our virtual
micro conferences and webinars focused on DevOps and the tech
industry and feature experts speakers from both the DevOps
world and top it companies. At our skillup days, you will get
everything you'd expect at traditional conference,
including virtual sponsor booths, competitions, and
networking opportunities with other attendees and speakers,
don't miss out, check out our lineup of upcoming events on
DevOps institute.com. And register now.
Eveline Oehrlich: You know, this, this reminds me of again,
my earlier career, I started it a very large company, as a
support engineer. And I have to name them the company because
it's important Hewlett Packard at the time, and Dave Packard
and Bill Hewlett had a theme it was for many, many, many things.
It's called I was called HP way. And part of the HP way was
actually exactly that. And this goes back to I started there in
83. So right so many, many years ago, and I actually met both of
those gentlemen once and yeah, unbelievable. I still am very,
very few myself very lucky that I have met those two gentlemen.
But in that HP way, it was addressed exactly that to bring
yourself into the company. And I think it was Dave, who was
telling a story at one of those coffee talks and he said he went
up to an engineer and he said, why'd you leave? I watch your
car. Every morning. I parked next to your car and you leave
the car window open, slightly open. Why do you leave it open?
Because it's raining by discipline? Palo Alto it rains.
And then and a gentleman said, so that my personality wouldn't
suffocate in the car. And everybody was laughing about
that. But that individual obviously did not want to bring
his personality in the leftist person is humanity in the car.
You know, I thought that was really funny. It meets in
matches really exactly what what you were saying having that
having that human and that's for us DevOps Institute is very
important. And that fits actually with my next. My next
thought and my next topic. Again, in the research we did, I
still, I was blown away that collaboration and coordination
is still the biggest skill gap across these organizations, who
answered all these individuals who answered? So from the
research, we found 35% When we ask them, what are your top
three gaps in human skills, and this the first one was
collaboration, cooperation, but 35% The second one was
creativity and entrepreneurship. And then the third was diversity
and inclusion made, I'm not surprised on the diversity and
inclusion. We have made a lot of progress, but collaboration and
cooperation after so many years, and after so much of work. So
here my question, in your opinion, why is it so difficult
to get people to collaborate and to cooperate? Because I mean, we
all are working on goals should be thinking we're working
together and goals. But why is it so difficult?
Nickolas Means: Yeah, I mean, it's, it's fascinating, the
survey results that you just cited. I think a lot of a lot of
the reason all three of those are lacking in a lot of
organizations, kind of comes down to the same root cause and
that's lack of safety. You have to build for all three of those
things possible collaboration, ownership, inclusivity, there
needs to be a foundation of deep psychological safety, that's a
part of any team that's going to have those things as an as an
attribute those skills present in 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 thing that's on the forefront of your
mind, there's the zero sum game that you're playing, you're
trying to climb a ladder, you don't feel very safe, you can't
say I don't know, you can't ask for help, you have to always
look like you have it put together 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 about United flight 232, which was a
flight that sort of crashed landed in Sioux City, Iowa, had
a lot better the the tail engine fan desk exploded, lost all of
its hydraulics. But they managed to get the plane to an airport
and onto the ground in a relatively controlled fashion
for a plane that had no hydraulics. And it had a lot
better outcome than then it probably could have. In fact,
they, they tried to do it in simulators afterwards. And none
of the crews that tried to pilot a plane that was set up in a
similar configuration on the simulator could come anywhere
close to the outcome that that flight crew managed to get. When
you start digging into why that is. This was sort of right after
Crew Resource Management or cockpit Resource Management
became an important part of aviation. And it's this idea
that that in the cockpit, you're in a life or death situation,
because you have to pilot this plane safely. And in that
situation, you should use all of your resources at your disposal
to do that. You know, prior to cockpit Resource Management
becoming a part of aviation, there were all these incidents
where the captain's word would go. And the captain would sort
of shut down the rest of the flight crew or they wouldn't
feel comfortable challenging him even when they saw a problem,
they wouldn't want to point it out. And I use I use the word to
him pretty deliberately there because most pilots back then
were men. And it's it's been, it's been a challenge for the
aviation industry to build Crew Resource Management into the way
that they work. It's an ongoing thing that flight crews still
work on, still receive training on. But the key idea behind it
is that everybody in the cockpit gets a voice. Everybody that's
participating in the situation has a right to speak up to talk
about what they see, to point out what they're seeing. And the
same sort of ideas translate to engineering teams. You know,
it's pretty easy in an engineering team for one person
on the team, to have the dominant voice and to kind of
force their will upon everybody else on the team. They're used
to their voice being the default their viewpoint being the one
that that's the most important. And that's a really difficult if
you're in that situation. It's really difficult to Want to
collaborate or cooperate or even find the room to be able to do
it. Whereas if you have a team where everybody is seeking to
make room for everybody else, everybody is seeking to empower
everybody else. Everybody wants everybody else to succeed. And
as as a leader of that team, you're incentivizing that kind
of behavior, and you're rewarding people for that kind
of behavior. Then you see things, you see behavior start
to emerge from the team that you wouldn't see in the absence of
that safety and that invitation to participate.
Eveline Oehrlich: Beautiful, we should do, we should think about
a blog on that the lack of safety or actually the
inspiration, give inspiration to ensuring that there is that
safety feeling. It makes me think of my two daughters, both
of them's just started their careers. One is an architect,
the other one is an analyst, in customer experience, and my
architect, she is in a even so she's it's a women led company,
but there is a lot of, let's say, older architects and their
male. And so she just sent me a text yesterday, she's supposed
to do a presentation today on sustainability. And she is all
worried about because there's going to be a whole bunch of
guys in the team. And they all are thinking, and are very
overwhelming. And I didn't know what what to tell her. She said,
Mama, what how I, of course, I said to good, you know,
enforcing that she has the skills. And if you don't know,
then ask the questions. And if they ask you a question, and you
don't know the answer, say just you don't know the answer. Don't
be asked them. But that was shocking to me that, that she's
so scared even so she's not there for a year and a half,
obviously, in that organization. They don't have that safety net,
or that feeling of safety. So that's that is that is a that's
a great blog, we should collaborate on super great idea.
Great idea. Let's do that. All right. We are lacking technical
skills. I'm sure you guys have challenges finding good
engineers or skilled engineers, right. And we do know and see.
And again, this is from the same research upskilling and, you
know, learning initiatives, and so on. But I'm curious on we
talked a little bit about this at the beginning, I'm curious on
your thoughts around an effective and a successful
upskilling or skill building path. Let me share with you what
we found from our research. So we asked the question, what are
the top three upscaling frameworks? Or how do you like
to learn in the IT organization? So 48% said they'd like to do
virtual learning online events, conferences, classes, self
study, blah, blah, blah. In person learning kind of goes
along with that, depending on right 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
coaching, manager coaching, and then experiential learning. It's
about 31%. And then there were 20%. I can't believe that as was
for doing fieldwork, maybe they didn't think maybe I'm thinking
of fieldwork or something different. I call it the sink or
swim model. But 20% A preferring that I was like, what did they
not read the survey correctly? Anyway? My question for you,
what has worked for what you have seen in terms of skill,
creation, and upskilling and learning paths? In all of those
things? What do you guys apply when you bring in new engineers?
Or what do you see with your customers?
Nickolas Means: Yeah, it's interesting. Again, I think, you
know, the the shift to remote work that we're seeing
definitely plays into this and changes some of the learning
modalities that work best for a team. There's sort of this
common wisdom, that remote org, you can't be a successful new
engineer and in a remote organization. And I've not found
that to be the case. I've actually seen some folks come
straight out of boot camp and remote organizations and do
great. But it was because that organization spent a lot of time
in that that third category that you talked about the peer
learning, buddying pair programming. You know, it takes,
again, going back to safety, it takes a safe organization to be
able to pull that off for somebody who's new to their
career to be able to come in and feel safe enough, saying I don't
know over and over again. And sitting with a more senior
engineer and letting that senior engineer kind of be the
navigator in that pair. And let them kind of fumble their way
around and unstick them every once in a while every once in a
while. And it can feel if you don't think about it the right
way. It can feel like an inefficient use of that senior
engineers time. But if you think of it in terms of an invest
meant in upskilling. But the young, the newer engineer, it
makes perfect sense to spend time that way. It, it's funny.
I've had a bunch of conversations with folks that
are that are in that position where they're the more senior
engineer, they're navigating in a pair, they're helping a newer
engineer come up to speed, and helping them reframe what
they're looking for in that pairing session. Yeah, of
course, you want to get the task done, you want to get the code
shipped. But you're also going to have to find some
satisfaction or watching that other person learn, or you're
going to get really impatient, and you're not going to let them
do the learning that they need to do. So that's probably my, my
biggest strategy in this regard. I don't know, I also, I think we
tend to overemphasize this a little bit in the technology
world, the idea that that someone is technically skilled
enough to do the job. I think most people that gravitate
towards this kind of career are technically skilled enough and
sharp enough to figure it out. And if you give them the
resources, they're going to be able to navigate that. And we
don't spend a whole lot of time in the hiring process screening
for collaboration, screening for ability to work together,
screening for ability to be a good peer on an engineering
team. And that's, that's part of what creates that culture of
safety in the first place where somebody can learn and grow and,
and take advantage of opportunities that are just
slightly outside their comfort zone.
Eveline Oehrlich: I am sometimes amazed looking at the different
job descriptions, because skill research is what I do, and
whatever, indeed, or LinkedIn, or wherever I look at many of
these job descriptions for DevOps engineers, automation,
engineers, developers, whatever. And I'm absolutely amazed at the
lack of this human skills requirements that put in there,
say, Okay, you have to know Python, and you have to know
that, and all of that, and all of that I'm sure these these
these folks have, right that that's what they do. That's
where they are in the job, they love this type of stuff. Why
don't they have other requirements. And I think until
it is that way, that we have those types of things. As a Must
it, it will be a challenge. And for 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 of such a leader. But they're not
enough. And I think that's a challenge. And for us at DevOps
Institute, we need to shift into that human upskilling as well.
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: it's really hard. Yeah. I mean, I think, you
know, it sort of gets back to what do we incentivize? Yep. You
know, are we are we rewarding people for shipping big marquee
features? Are we rewarding people for making an entire team
more efficient by the influence they have on that team? We
should reward both. But we often don't reward the person that
does that second job.
Eveline Oehrlich: Exactly. Absolutely. Well said,
fantastic. Well, I have one more question and has nothing to do
well, maybe I'm not sure. My closing question. What do you do
for fun?
Nickolas Means: It's funny I So recently, I have been picking
piano back up, I played piano as a kid, and then quit in, I
think, when I was about 10, or 11, and haven't played since.
And I've been learning to play piano. And I've actually got one
in my office here sitting right behind me. And I love it.
Because I'm good enough now that I've got some songs that are fun
to play that I enjoy playing. And I can go sit down at the
piano. And it sort of shifts me out of out of out of thinking of
whatever problem it is I'm trying to think through. It'll
move that problem into my subconscious because I'm
focusing on playing the piano. And I'll emerge from playing the
piano 15 or 20 minutes. And my brain has figured out what to do
about the situation that I was thinking about before I sat down
to play. Ah, I didn't expect that when I started taking piano
backup. I just was I felt sad that I didn't know how to play
piano anymore. But that's been a really fun thing to realize.
Eveline Oehrlich: So double double whammy double win for
you. Excellent. That is fantastic. I'm jealous. I'm too
old to learn it. I have a guitar. I played it. It's behind
me. Maybe I should take your your advice and do the same
thing. Break. Stop the meeting, stop thinking play a few tunes
practice. I will do that. I will let you know how it turns out
surprise deal. This has been great. Nick, thank you so much.
Thank you for your time. Thank you for the great advice for
some great coaching and I hope our listeners enjoyed that very,
very much what you had to say so again, thank you we've been
talking to Nicholas means VP of Engineering at sim sy M. Check
it out. And if you have a chance, check out the How to
crush an airplane. Which you mentioned Nick. It's the Crew
Resource Management In a lot of war, a great story I loved I
love the YouTube. It's on YouTube on United Airlines. 232
DC 10. Crash, sad, but it's also very, very good because it has a
lot of things again, Nicholas, thank you so much for joining me
today.
Nickolas Means: Yeah, thanks so much for having me on everyone.
It's been a great conversation.
Eveline Oehrlich: You humans of DevOps podcast is produced by
DevOps Institute. Our audio production team includes Julia
pape, Daniel Newman, Schultz and Brendan Leigh. Shout out to my
wonderful colleagues who make this sound even better when
they're done with it. I'm humans of DevOps podcast executive
producer Evelyn earlyish. If you would like to join us on a
podcast, please contact us at humans of DevOps podcast at
DevOps institute that calm and I did not make a mistake saying
that. I'm Evelyn early. I'll talk to you soon.
Narrator: Thanks for listening to this episode of the humans of
DevOps podcast. Don't forget to join our global community to get
access to even more great resources like this. Until next
time, remember, you are part of something bigger than yourself.
You belong