Join Eveline Oehrlich and Nickolas Means, VP of Engineering at Sym, to discuss the best practices and challenges of leading an engineering team, collaboration, and more.

Nick is the VP of Engineering at Sym, 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’s also a regular speaker at conferences around the world, teaching more effective software development practices through stories of real-world engineering triumphs and failures.

If you are interested in a Sym demo, please visit: symops.com

The Humans of DevOps Podcast is incredibly grateful to be voted one of the Best 25 DevOps Podcasts by Feedspot.

Learn more about getting DevOps certified at devopsinstitute.com

Transcript

Narrator 00:02
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 00:13
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 00:33
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 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 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 02:33
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 04:03
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 05:49
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 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’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 09:28
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 10:55
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 13:12
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 13:49
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 16:42
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 20:32
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 23:49
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 26:27
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 27:46
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 28:05
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 28:16
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 29:07
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 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 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 30:55
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