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