Tom Cudd - Psychological Safety and DevOps

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah Hawrot Weigel: 00:14

Hello, and welcome to season two, Episode Five of the Virtual Coffee podcast. I'm Bekah, and this is a podcast that features members of the Virtual Coffee community. Virtual Coffee is an intimate group of developers at all stages of their coding journey. And they're here on this podcast sharing their stories and what they've learned. And we're here to share it with you. Here with me today is my co host, Dan.

Dan Ott: 00:40

Thanks, Bekah. Today we talk with Tom Cudd, a systems architect and 20 year veteran in technology. We talked about his experiences with DevOps and how it changed over the years about psychological safety. What that means to Tom and how important it is to build into your team and workflows, and about the dangers of hero culture in the workplace.

Bekah Hawrot Weigel: 01:02

We start every episode of the podcast like we start every Virtual Coffee, we introduce ourselves with our name, where we're from what we do, and a random checking question. Today's question is, if you could start a collection of one kind of item, what would it be? We hope you enjoyed this episode. Hey, I'm Bekah, I'm a front end developer from a small town in Ohio. And if I could start a collection of one type of item, one kind of item. I don't know what it would be. But when I was a kid, I used to collect tree fungus. And that's one type of item. So there you go.

Dan Ott: 01:52

Wow, I think a million guesses and I wouldn't have guessed though.

Bekah Hawrot Weigel: 01:56

Also, cicada shells. I had a collection of shells. Yeah. But tree fungus is very serious.

Dan Ott: 02:03

This year is one of the 17 year, cicadas years.

Bekah Hawrot Weigel: 02:06

I think it's missing us. So it's gonna hit like Pittsburgh, it's looking to go around, so...

Dan Ott: 02:15

Fair enough. Hi, I'm Dan. I'm a front end developer from Lakewood, Ohio. So if I could start a collection of one item, what would it be? And I feel like this implies that I can't I can't like, say anything that I've already collected, you know, that I have a collection currently have. And I like I said, so I'm going with something brand new, but I feel like I could get into like shoes, you know, like I could see, you know, again into the sneakers, you know what I mean? Like that, that I try to stay really far away from it so that I don't like, you know, accidentally get sucked into it. I can get carried away with like, collecting pretty much anything, you know, very easily. So I tried really, really hard not.

Bekah Hawrot Weigel: 03:01

Not trying really hard not to collect fungus.

Dan Ott: 03:07

Yes. Including that.

Tom Cudd: 03:13

So I'm Tom Cudd. I'm a systems architect in the Kansas City, Missouri area. Yeah, I'm a reformed hoarder, I think so like I have a lot of collections that I've had to like get rid of over the years. So I'll say something that I have not collected before. I would collect exotic supercars because, you know, oh, that'd be pretty awesome. Except, you know, you'd have to actually pay for them. But I do like cars. I I'm not like a car person. I just really think that fast cars are awesome.

Dan Ott: 03:47

Yeah, that'd be cool. That'd be cool thing to have a collection of for sure.

Bekah Hawrot Weigel: 03:53

Nice. Well, welcome, Tom. we're really, really excited to be talking to you today. So thanks for being here. And the way we normally get started is we ask all of our guests, kind of how they got into tech or where they are now. So if you can give us your origin story we would like to hear

Tom Cudd: 04:13

Yeah, absolutely. I think I took more of the traditional approach if you would call it that. To get into tech I graduated from University of Nebraska Lincoln with a computer engineering degree. That meant I focused a lot on like hardware and electrical engineering in some of my classes. But by the time I rolled around the end, I was like, I don't want to like design chips or anything like that. So I started looking around for for it was pretty bad job market when I when I graduated. So I just tried to find whatever I could that was remotely related to tech and ended up doing like desktop support and For a small mom and pop shop, which, which most people would actually call a startup now. So like we did like dial up internet for people in rural, we did wireless internet, like off of wireless towers to get more high speed and I fix people's computers I installed, you know, modems and desktops and sent people on their way. So I did that for a few years and eventually moved into sort of the more enterprise space. So now, after years of kind of building up moving on from desktops to data centers, now I'm, I guess, I work a lot in the cloud space. So I'm kind of a cloud engineer, cloud architect, right? I do work in Azure and AWS to build out infrastructure, with infrastructures, code, and whatever new technologies come about.

Bekah Hawrot Weigel: 05:56

Nice. So one of the things we wanted to talk about today was DevOps. And before I ask any questions, can you give us a definition of DevOps?

Tom Cudd: 06:09

Yes, there are many definitions of DevOps. It's sort of like asking people what agile is, you'll get a lot of different answers, depending on what people's experiences are. I look at DevOps from a cultural and professional perspective. So like, it's more about a culture and mentality, one where there's an emphasis on, on collaborating and working together with different parts of the organization. It's it's sort of misnamed, because DevOps implies that there's just two pieces that would be working together, we're really it's like, Bus, Dev, Sec, QA, Ops, you know, like, it's like, trying to bring everybody to the table. So yeah, I look at it from the perspective of it's a, it's a cultural movement, that encourages collaboration across what were previously known as silos within organizations or experiences.

Bekah Hawrot Weigel: 07:20

I think that's a really great definition. And when I was looking for a job, when I lost my job, at the beginning of the pandemic, someone reached out to me to apply for a DevOps job. And they asked me what my definition was. And it was, like, I had a very little understanding. And so my homework for the next interview was to read the Phoenix Project in the Unicorn Project, and then come back with a definition of what DevOps was. But I wish I could have just asked you then, but I don't think I knew you then.

Tom Cudd: 07:51

I would have gladly given the answer. Yeah. I mean, a lot of people think it's, it's like, I might apply for this like DevOps job, it's people who were--I call them reformed systems administrators often really have just titled change to kind of DevOps engineers. And so, a, there's a certain set of experiences around operational tools and techniques, like deployments, you know, Jenkins builds and, and doing releases, that's sort of traditional what used to be, when the developers are done coding, they throw a tarball over the over the wall and expect an operations person had to deploy it out onto the server. So that's sort of what many people consider the mechanics, the actual tactics of a lot of DevOps, folks, but it's, it's more than that. Now, it takes a little bit of experiences from all sorts of technology areas.

Dan Ott: 08:55

It's interesting, the rise of DevOps, and you were touching on this, it's been interesting to watch. Because I, my experience, for a large portion of my career was the same, right, like, I kind of finished my coding thing, and then I'm like, okay, make it so. Right. Like, you know, somebody put this up on the internet, you know, and, and there's so many tools now available, you know, that, like the cloud services and everything, you know, that some barriers have been lowered, right. But that means, but also, like, lots of times, somebody who traditionally would never have to even think about that sort of thing has to think about a lot of it. Now, as more with smaller, you know, with smaller outfits, probably, but I guess, I guess I was wondering if, like, if you talk more like how you've seen that, that's sort of like the DevOps, you know, things change and last, you know, however, a lot like last couple years, even, you know, as far as the definition or even the roles, you know, what kind of what kind of different interactions are using things like that.

Tom Cudd: 10:04

Yeah, I have seen changes over the last 10 years when I didn't know I was doing kind of DevOps work 10 years ago, really, I really read the Phoenix project, I think, six or seven years ago, which really introduced me to the methods of, of how we deliver code to the world.

Dan Ott: 10:25

Could--I'm sorry to interrupt--but could you...I don't know what the Phoenix project is.

Tom Cudd: 10:29

Oh, yeah, the Phoenix project. Yeah, the Phoenix project is a great book that really widely presented DevOps in a, in a story format, to to the world. I don't remember, all of the authors, there's couple authors that work with Jean Kim, who is the main author, and he he's an excellent speaker, and an excellent contributor to the DevOps landscape. And he, the book was a lot of people's first introduction to what DevOps is in, in how it can be used to correct problematic behaviors within an organization. And, and so when I read that, I like it, like blew my mind, I read through it in a day, I didn't sleep until I finished that book. And I came back to work the next day, and I was like, we have to do this for everything. And yeah, my boss was like, okay, chill for a second. And then let's like break this down and analyze what what it is that we can we can do. There are a few things that we learned right off the bat, we were already doing right, like emphasizing our ability to empathize with the people we're working with and understand the problems and meet people at least at least in the middle. And sometimes more than halfway, we would, we would try to reach across the aisle to get the problem solved. But what what's really changed, I think, over the last five years is that we've seen other areas of technology developer is QA, infosec, they all have kind of embraced more of an emphasis on on that empathy with other parts of the organization. Mainly, because I think people are realizing there's only so many abstractions about technology that you can hold in your head at the same time. So what I mean by that, like, I have an understanding of hardware, and then how the cloud you know, system sit on top of that hardware, and then how we present that clouds systems to the the developers and to the end users. If you have to understand like, at some point, you have to go, Oh, I need to understand what exactly is happening in the networking layer here. If you have no familiarity with that, you're going to have to ask somebody. And so what is the the abstractions that people are understanding kind of overlap? It's like a Venn diagram of DevOps is really like the intersection of, I'm working with a developer who understands how a Spring Boot application works on top of an application server. And I understand how an application server worked on top of an OS. And so we're meeting in that. That middle, it used to be, there was a job title, a lot of people had called middleware application developer. And they had, that was sort of like, instead of finding a way to collaborate, they just found someone who understood both parts of those abstractions. And that making another team for something where you really shouldn't have just found a way to collaborate and work together isn't the way to solve the problem.

Bekah Hawrot Weigel: 13:48

Yeah, that's, you keep saying the word collaboration. And I think that's great. And I also think it's, it can be super hard, right? Especially when you have two teams that are two or more used to communicating in certain ways with each other. And I imagine that sometimes there can be friction or challenges to, you know, make it a space where everybody can talk together.

Tom Cudd: 14:13

Yeah, in, in, like the enterprise 10 years ago, in sort of larger enterprise organizations. The needs of developers and the business working with developers was different than that of the operational groups. developers were tasked with releasing features and getting code pushed out. And operations groups were put into the place where they had to ensure the stability of an application, make sure that things stayed running, the safety and security and stability was of utmost importance. You know, uptime was a big deal. For operational groups and developers were like, you know, I don't care about uptime, I have a new feature that has to get out to the end users. And so that collaboration wasn't happening, because we were all coming from a different place a different perspective of, we had to figure out how to align the needs of each organization, to to solve problems.

Dan Ott: 15:27

Did that sort of, you know...like, everything you said, may made sense, and so trying to, like, where were you in that process of trying to, like figure that that out, like, figure out how to make new communication channels or new, you know, decision making processes, stuff like that?

Tom Cudd: 15:46

Well, it, it's kind of fun to talk to people. For me, I love talking to people. And I had been working or I'm at now, I've been there for 10 years now. And when I started to take some of these DevOps approaches, I had been there for about four years. So I had inroads. I had trusting relationships built with certain people in the organization, because you know, you get, you're getting a cup of coffee, and you talk about, oh, hey, this person also plays the electric bass like me. So like, let's talk about that. One, one person on my team said a couple years ago, they're like, trust takes time. It takes time, you can't I couldn't have just come to a new person and come into a new job and go, Okay, we're gonna DevOps everything around here. And I'm gonna do things this way. And you're just gonna have to deal with it. Because I think I know what's best. No, it doesn't, it doesn't work, I got to know the people that I was working with certain trusted, valued partners in the development organization that realized, hey, nobody wants to be up at 3am trying to press a button to make this code end up on production. So let's work together to it. It started with we created custom scripts that people would just be able to trigger with a, you know, a new code build would be triggered by a commit. So something like that kind of opened up a whole new world of realization that no one has to throw code over a wall, we can actually work together to automate systems can do what systems are good at, which is save people time to do more deep level thinking about problems. Because that's what we that's the ultimate goal, you pay people to solve unique and interesting problems not to press buttons all day that an automated system can handle.

Bekah Hawrot Weigel: 17:56

Yeah, so it sounds like a lot of the job too, is creating an environment where there's psychological safety, right, where you have this trust, where you are thinking about the people who are working? And is that something that you're consciously thinking about as you're creating these relationships? Or I don't know, how does the role of psychological safety fit in there?

Tom Cudd: 18:25

For a person who's a team lead or manager or supervisor like myself, and also doing the technology work, it's the most important thing to me is to create a, you know, trusted, safe environment. The big thing I found, started doing research after reading Phoenix project, a couple other books, Lean Enterprise and Accelerate are two other books that I found very powerful in, in my journey to to optimize our DevOps, DevOps experiences, and our team capabilities. Google did a, a huge research project on what made teams successful. And they found that optimizing for like individual contributions to be better, didn't ultimately bring about success. So you can you can train people individually as much as you can, but that, that only unlock so much potential. When they, when they figured out what made certain teams more successful by doing you know, observational analysis and surveys across their whole organization, they found that the idea of psychological safety was the most important factor to successful teams. So that means giving everybody an opportunity to speak knowing that you can take risks without the, you know, embarrassment of things failing, like, I have a person on my team that they deployed a config that accidentally broke prod one time and it was there. They're a junior person. And there's the first time they did something that broke prod and another person on the team went out and bought champagne and brought it back to the office and was like, congratulations, it's your first time breaking fraud, it won't be the last. So let's celebrate it and learn from it. So knowing that, that you can do risky things without penalty, in order to try and learn it's, it's, it's how we learn from the mistakes, that's important. And so making a safe environment for your team to be able to try new things and have that growth and learning mindset is, I think the only way that we're going to make our teams better and our organization better. So that's, it is really important to me to create that kind of safe area to do that work in it.

Dan Ott: 21:07

Can you talk a little bit more about some specific techniques you use to foster psychological, psychological safety within your team? you'd mentioned that, you know, making failures explicitly. Okay, right, and risk. But what are some other like techniques that you use to help your team feel safe all together.

Tom Cudd: 21:26

So I, as a person who has been technology person most of their life, and who's been mainly focused on development and experiences like that, I had to kind of learn a little bit more about what it is to be a manager and to manage people. So I know this month that Virtual Coffee, were reading Radical Candor, which is a really excellent book for learning how to have conversations with people that are helpful to them. I used to be, if you've read that book, you'll you'll understand the term ruinous empathy, like I felt bad for people, all the time, people that I worked with that I you know, that were having troubles with things. But instead of politely and directly giving them the feedback and criticism that they need, I would just be saying, "Oh, it's okay. Well, we'll try to, we'll, we'll try to fix it together." And then I'd go back and fix their, whatever was broken, that didn't help them improve. It didn't give them the opportunity to to learn. It was it was, it was a problem for everyone to kind of cover that pain. And that that goes back to like DevOps is an important part of DevOps is that shared pain, like you don't hide the pain, that one process or area or effort brings you, you expose it and bring it out, bring it up and say, Hey, this is something that's causing people problems, let's work together to fix it. We have to have to be professionally direct in those times. Because if we're if we're not, we're not improving the space that we're in. I mean, I work at an ad agency. So it's, it's it can be hectic at times, and it even 10 years ago, it used to be like, hey, we'd get a project started on Monday might have to have something launched by Saturday night, and it would just be work all hours until it's done. Bringing up those types of things is difficult. But we built up the trust with people to recognize, hey, maybe a 40 Hour Workweek is better for us in the long term. Well, how do we get to that point? Well, for one thing, we can automate more so that we don't have to keep wasting two hours rolling code, we can press a button and go to sleep, or press a button and give the output to someone else. So working, working together in that space, is how we got there. And the only way to do that is to just say, Hey, this is a problem. We need to fix it together. And say it over and over again, in as polite and professional manner as you can and hopefully, someone will eventually pay attention. And if if they don't, you know, maybe it's not the best culture or the best place. There are things you can do to help improve it, but for some, some places, there's only so much you can do. I'll I'll tell you that.

Dan Ott: 24:29

Yeah, I'm sure that's true. I was going to ask like how, how, I mean, this sort of thing has to come down from you know, like, has to have support, you know, further up the management tree, for instance, you know, I was just like wondering how far up you feel like this, this sort of approach, you know, is directed in your organization.

Tom Cudd: 24:54

Now, at this moment, yeah, everything around the idea of DevOps is embraced And Heck, it's used as a selling point for clients that we're, we work in this manner. And it's to the benefit of everybody, including the teams we're working with. And, and eventually, the end user and customer that we're dealing with. We took it as a bottom up kind of approach, I didn't ask for management buy in to start doing these things, we found areas where we could eke into improvements. I've always leaned towards the ask for forgiveness rather than permission. When I when I'm doing work, mainly because I, I figure, the worst that can happen is someone just fires me and I go find a new job. But I have that kind of like risk. I'm normally risk averse in my personal life. But like, in my professional life, I'm like YOLO pride, you know, let's, let's go, let's go get this done.

Dan Ott: 26:04

So an example of something like that would be, you have a project and you could like power through it quickly. But if you spend a little more time, you know, working through some automations, or some some of the things like that, the product will be different, like, it might take a little bit longer to get out the door, like the first time or something, but then the full product will be much more valuable. Right. Is that? Am I mistaken? That kind of correctly?

Tom Cudd: 26:30

Yeah, that's exactly what I mean. Investing some time up front to save you long run. Time is the way we mentally operates. Right now. I'm thinking of my future self is my future self going to be happy that I created this build pipeline, so that I can give developer a button to press when they need it? Yeah, my future self is going to be really happy that my past self did that, that work ahead of time, it does take you know, I talked about building those relationships up, I had to start making sure that people who were going in on like, client pitches and people who were working directly with clients and creating scopes to work off of understood the lead time we needed in order to make the project successful. That also took that kind of like, hey, let's have a cup of coffee. And I can explain, this is how we work. And this is what we're trying to do. And if you you know, redline this line item in the scope, you're actually going to cost yourself more money in this time period in the future, because you didn't invest this time up front. So you can either invest front heavy on our sort of building the automated processes, or you're going to pay more over the entire life of the project to have someone available all hours of the day to get this work done. So it does require a little bit of storytelling to make sure people understand, hey, this, this is why we're doing this. You can't build the landing gear while the plane is flying. You should have done that, you know, before you even took off, right?

Bekah Hawrot Weigel: 28:18

Yeah. So it sounds like you are also investing time in the people, right? Because you have to have those relationships, and try and get people to trust you. And that's gonna save you time in the long run, right? Because I find that, you know, avoiding hard conversations are trying to work around them, they have a way of coming back and creating something that's much more challenging to deal with rather than, like, okay, let's get this out now, or let's talk about this, or let's grab a cup of coffee and get to know each other a little bit. Because then you have a relationship where you can be more honest with that person.

Tom Cudd: 28:57

Absolutely. It's, it's the part of the job that I like the most is to, to foster that kind of friendship, work, friendship with people to understand what they're doing, and how it applies to the problems I'm trying to solve. And then and in telling them how look, Okay, I see I see here, when you're when you're selling the client this, here's what you want to tell them so that they don't like cross off this line in the scope thing. I'm not paying for that. Like No, it's built in to the kind of agile work that we're doing in order to save you like how we used to sell agile and working in Sprint's to clients is completely different now than it was even a couple of years ago. How many clients wanted to say, oh, you're going to pay for a team of this size for this long and we're not going to commit to saying we'll get this done. We're just going to say how many points during this sprint, we're going to get done, and then this sprint, and then this sprint, but we can't exactly tell you what releases are going to be out the door, like, what features are going to be done, you, you're buying out a team for this loan, that didn't work, even three or four years ago, no one, no one would buy out a team to work on projects like that. I mean, a handful of larger organizations may have understood the value. But DevOps is sort of like that, it's like, oh, you're going to pay for this up front, so that you save yourself, the time and the money in the long run, being able to tell that story through, you know, creating slides and visualization for teams, you know, selling our services, that's, that's an area where I've had to learn, you know, some new skills. But again, I fostered the right kind of friendship inside the office to say, hey, this person actually works in the creative department and has a bunch of slides that we can use, and then I can just layer some stuff on top of so that Kismet of like randomly running into people in the office is still something that I hope I eventually get back to, so that I can still foster those relationships a little bit more challenging. In a kind of remote world, but I it's, it's still important, there's ways to do it. And we're still trying to reach reach the reach the parts of the organizations, we're still trying to learn more about how to interact with and how to engage with, even in the even in the remote sense.

Dan Ott: 31:33

That's cool, it's cool that you have, I don't know that the freedom to be able to do that, right, that you're not like stuck and stuck in silos or being told to you know, stay in your, your zone or whatever, you know, in your organization.

Tom Cudd: 31:47

I've been told to stay in my zone a couple of times and stay in my lane a couple of times.

Dan Ott: 31:51

Well sure, but, but you didn't get fired, right. So...

Tom Cudd: 31:57

no, I did not.

Dan Ott: 31:59

I think that's really cool.

Bekah Hawrot Weigel: 32:01

So how do you deal with challenges or pushback on the things that you're trying to do? I guess, like, Is there an approach to? Well, I guess I don't I don't want to lead the question. So if you...

Tom Cudd: 32:16

Oh, how do I deal with the challenges of it? Well, there are, there definitely is pushback. And there's some I want to say Old Guard mentality, I think that's probably the closest way to describe it. People who are coming from their industry experience was 1520 years ago. And that's kind of what they stuck with. Changing that kind of mindset. As proven to be very difficult. I, we sometimes bring in senior engineers, for a specific client project technology stack needs, and changing how they think has been more challenging than then maybe hiring more junior entry level boot camp type grads, so we have a tech apprenticeship program now that we're, we we've brought in some apprentices that are coming from, you know, career switching and their the fact that they're learning something like technology, after another career has proven to be invaluable to, to bring in and they're more flexible and understanding Oh, well, this person, just, you know, they don't want to do it this way, that's fine. We'll just we'll do it their way, and then show them and explain to them and train them. It's it's a more patient approach. It's what I end up doing. A lot of times when I get pushback of I want to spend the time upfront to automate this, I want to build this infrastructure using terraform, or something like that. I, I actually show and explain. If I build it with terraform versus build it by hand, it's going to take this amount of time for this amount of time. But if I need to scale up this environment, to like 10, times the number of systems very quickly, because you said there was a possibility, this may have to scale very quickly. I just changed, increment this number, and boom, we have 10 systems. Whereas here, I would have to do that one time, effort 10 more times. So like being able to like just instead of getting frustrated and saying, No, you have to do it my way. Why are you arguing with me? I tried to understand, like, it's really hard to just sit and go, Okay, what is it that you're actually complaining about? are you complaining because it's going to take me two weeks longer? Well, okay, let's bring in another resource. I can borrow one of your developers, I can a developer can learn you know, some YAML configuration based language like terraform and and help me out here. So We try to find, you know, unique solutions that way. It's it's active listening, you know that the whole, like, back to thinking about communication studies being an active listener and actually trying to Okay, let me let me rephrase what you're telling me. And sometimes that's the simplest way to get back to the solutions where people are. People are really pushing back against you.

Dan Ott: 35:27

Yeah, I like that. Colleen's podcast, social, man. I'm blanking on the name. Colleen has a podcast--Yeah, yeah--Software Social sorry, she, she has a podcast, and they just did user interview with it. Like they did a two parter where they interviewed Drew actually from Virtual Coffee, but for Colleen's app, and then as the host, Michelle, is that her name? Yeah. So she did the interview. And then the second part was, Colleen, like, reacting to it or whatever. And Michelle was talking a lot about that active listening, and that technique of rephrasing something that somebody said, or like, to get them to, you know, sort of talk more about it. And she said, she actually will do this, or maybe she used to because she didn't use her interviews for like, you know, for work and would rephrase something, but Excuse me, but, um, intentionally mess it up a little bit, you know, and to get them to get a person, and this wasn't even tech, this is like, any, any user, you know, but like to get them to talk up, like, explain why, you know, like, talk more about their, their, whatever was, you know, their farm or whatever it was, you know, that she's interviewing, I thought that was a cool, cool idea.

Tom Cudd: 36:45

That is a really good technique. I'm gonna have to remember that. Yeah, yeah. You mean to say sort of like a really annoying clipping like, Did you mean to? Did you mean to say this? No, that's not what I said at all. Let me explain it better. Oh, that would be great. I would love it, if you would explain it better.

Dan Ott: 37:01

Yeah, yeah, exactly. That's pretty much exactly it. You know, she, I mean, she, she was talking about how she would lean on because she was younger, I think and would lean on, you know, people's, she's interviewing men and would lean on the assumptions, you know, sort of, of talking to a young woman, you know, we're like, and, like, let the but like, but her job was at the time was getting the person to talk, you know what I mean? And so she would sort of make mistakes on purpose. Just to get them to do exactly what he said, No, no, that's not it at all. Let me explain it. I thought that was really great.

Tom Cudd: 37:35

I seen that technique in action. My wife is actually a broadcast journalism major, and was in the field for a few years. And I'm like, every once in a while, like, Are you trying? Are you trying to get me to say more about what I mean? Like, like that, that's a pretty interesting technique right there. So yeah, it's, it's a good tool in the belt to have in the building relationships with people that you work with. So I love it, I need to use it more.

Dan Ott: 38:08

That's awesome. I like I like coming to it with that, that sort of attitude, right? Like that. You know, I mean, I think of active when I hear active listening, I think of interviews and stuff like that, but you know, even doing it with your with teammates, and trying to try to just like dig into, like, what problem we're trying to solve, you know, like, or why we're trying to, like, somebody comes and asks you for some pipeline or, or whatever, but digging in and finding like, what the root of the thing that they actually want is, you know, is, is like an interesting skill, it's something I'm always trying to practice by Vince, the, the guy I work with, is like a master at that, of, of like, somebody will come and one of our one of our clients have a long term client. They are they do deck construction, and came in and said, they want a website, you know, and they had gotten quotes around other places or whatever, and then talked to the owner for like, a solid day. And out of that came a contract to redesign their logo and not nothing about websites, redesign their logo and and create truck decals, you know, because, like, they're, like, they had some small website, like some, you know, whatever website, you know, but like, their main thing, it wasn't that they needed a website is that they needed more customers, you know, like, and like, they're, like prospective customers for them are people like next door to the brand new deck that they just installed for, like the neighbors and you know, things like that. So it's like getting a website that can serve all the world not very helpful for a local construction company, necessarily. You know what I mean? At least that is step one, you know,

Tom Cudd: 39:46

yeah, I see that happen a lot. Like, I get a lot of JIRA tickets handed over to me or the people on my team that are Hey, can you put this config out on this server for us. And I see those types of things right away. And I go, No, no, no, no, tell me what to do, tell me what it is you're trying to accomplish, and I'll be happy. If it ends up being that all I have to do is put that config out there, that's great. I can also provide you the system for you and your team to do that yourself, rather than handing a ticket over to me. But if if all you need is the config, great if what you're needing is a method to deploy that config regularly. Let's talk about that. If that's not what you're meeting, needing at all, if, if you're just having a troubleshooting session, because you're running into a problem, we'll just invite me to that, and I'll help you figure it out. I'll get online with you and help you solve the problem. So getting other people to recognize that sort of that same sort of issue that pops up in a ticketing system or request where, or someone who may not be familiar with, like the abstractions I talked about earlier, if they're, they're not familiar with that, they may say, Hey, can you do this one thing for me? But really, it's what is it that you're actually trying to accomplish? What What is it you want to solve here? And let's work together to do that.

Dan Ott: 41:17

Totally. There was an anecdote in our latest developer tea podcast actually, for and I didn't really look up, this is true or not, but Henry Ford was saying, you know, if, you know, it's the, if he just did what users asked, they would have just made like a faster horse, you know, instead of like building a car, you know, like,

Tom Cudd: 41:36

that's a good paraphrase of that. Yes.

Dan Ott: 41:39

Whatever it was sorry. Yeah. I don't know what the quote is

Tom Cudd: 41:41

It is Henry Ford, though. I I've worked a lot with that particular client for years. So I've heard a lot of the Henry Ford quotes.

Dan Ott: 41:49

Well, there you go. But yeah, right. So I mean, like that, the what they want is to get to another place faster, you know, or easier, or whatever. I guess in that situation, you know, digging into, like, what people are really like, wanting is, is a skill, but also is like, going to be much easier if people feel safe, you know, communicating and like, both ways, right? Like, the person asking feels safe. And the person, you know, on the other end feels safe digging in, you know, I mean, I do it all the time. And I like it work. And I know that I bother some people sometimes. I mean, I'm not like being annoying, but like, I know that some people are like, why can't Can you just Could you just do the thing? I'm like, Listen, you know, it'll be it. I promise. It'll be better this way. Like, let's just talk a little bit, you know? I don't know, it's, I like talking about it. It's a cool, it's a it's a cool way to approach you know,

Tom Cudd: 42:46

I sometimes get like people send me the GIF of like, why are you the way you are? I get it. I'm like, I'm stubborn. And I'm like, I really should do it. This we should really should do it. There's no we should really like, like trying to get more. I can't just yell louder at at people to try to get them to accomplish what I want it. It requires a little bit more effort on my part to try to understand and then maybe, maybe I didn't do a good enough job educating or training or explaining like, what, what happened that broke down in what I thought we all agreed upon was the right way to do things and then suddenly isn't so totally, totally understand that a digging in the heels. situation.

Bekah Hawrot Weigel: 43:39

Yeah, I think that's so important. And so overlooked, especially because things move so fast. And there's this sense of urgency like everything has to be done, right. So let's find the quickest path there. But it sounds really methodical and deliberate. And this this process that gets developed, but I'm definitely something that that pays off in the end.

Tom Cudd: 44:06

It does it, trust me, it does pay off in the end. I mean, I could have said, you know, four or five years ago, well, this Job's never gonna change, I go find something else. And the problems that I had with myself and how I worked would have followed me there. This was I really, let's see, what's the Tolstoy quote? It's like everyone thinks of changing the world, but no one thinks of changing themselves. That's that's sort of what hit me that, okay, maybe I can make some changes in how I operate around people and how I work with people. And that will help more than just the work. They'll make the work environment better, because there are some places where the culture may be irredeemable.

Bekah Hawrot Weigel: 44:59

Yeah. That's it was gonna be my next question like, where do you draw the line? Right?

Tom Cudd: 45:05

Where do I draw the line is probably different where other people draw the line. I, like I said, I dig my heels in, I see, oh, we can, we can change everything about this place. I'm more patient than others, I jokingly tell some of my co workers, I will outlast all my enemies. So like, if there's someone I don't like working with, I'm like, well, maybe maybe I should change how I work with this person not expecting the other people to change. And it goes back to, you know, you mentioned earlier, like, how much buy in do you get from management and upper management on DevOps? Well, sometimes you may not get any buy in. But that doesn't mean that you shouldn't adhere to some of those like positive practices. In your own experience, there are things every individual contributor can do to improve their working situation. And sometimes you can't change the culture, just like expecting the culture check, like, hey, this culture should change. Well, what brings about cultural changes is specific behavioural change, you have to actually change what you're doing. in your day to day how you work, how you interact with people, we used to have a huge problem with, I call it hero culture, where people just work themselves until they collapse. And burnout and fatigue were really big problems. I started setting a good example, I worked 40 hours a week, I'm not doing that right now. But I know I have a specific, like deadline. And once I'm, once I'm past that, I know I'm gonna have some like, some time to relax some time to take it easy. Back to my like, sort of 40 Hour Workweek, I was really strict about making sure that I put in just the amount of time that I needed, I used my vacation time accordingly. If I didn't feel mentally well, even, we would use sick days for like mental well being days like and that was totally fine. And by being a good example, other people on the team started doing that same thing. Now, some people were sort of addicted to that superhero culture and didn't like some of the changes that were happening, and they left and that's their prerogative. But more people stayed, then left when I started saying, hey, maybe we should work only 40 hours a week, for the most part. That seems like a reasonable thing to do.

Bekah Hawrot Weigel: 47:46

Now, what if somebody higher up in your company said no, that's not acceptable, you need to put in at least 50 hours a week?

Tom Cudd: 47:52

That's a good question. And like I said, I, I am more willing to take risks with my professional career there my personal life, my mentality is I'm going to work what I think is going to be best for everybody in the long run. And that means I'm going to put in a 40 hour a week for the most part. And if that led to people realizing, hey, maybe this is a good idea, or maybe we should get rid of this guy, the the cultural things are going to take care of themselves one way or another. And if and if it led to my having to go find someone else, I would have done that. But it led to a lot of people realizing, hey, when this team works, sane, solid hours, they do high quality output of work. And so it was encouraged. And it was celebrated, that we were doing the right thing, kind of like we accidentally broke prod, hey, that's a that's a behavior, because we took took an acceptable level of risk and recovered from it quickly. Because we had built all the right things, let's celebrate that not, you know, harass somebody about the fact that they broke prod.

Bekah Hawrot Weigel: 49:07

So do you think that you would say if you were in a working condition where you felt like psychological safety was something that wasn't valued? At what point do you walk away from that? Right?

Tom Cudd: 49:22

Um, that that's a really good question to me. I may have mentioned it already. It's number one, for me the psychological safety, being able to feel safe in a work environment. I don't tolerate low psychological safety very well, like the one of the jobs I left a long time ago. This was like I think I wasn't even graduated college. I was like building computers on a line for a company that doesn't even exist anymore. They asked me to, I had already worked 70 hours a week they asked me to come in the next day, which was also my birthday, which my girlfriend was coming in from out of town, who's now my wife, but she was coming in from out of town. And they were like, No, you have to come in tomorrow. I'm like, No, I'm leaving right now. I never and I'm just like, you can mail me my last paycheck, I'm done. I don't tolerate that. But like I said, I'm also have a high threshold for what I consider safe and unsafe. But you know, something like that. I just, I'm not going to just don't understand. I won't put up with kind of the BS that sometimes happens when people think that their, their method of working people to death is the only way. I'm trying to dance around the issue that I know, we've heard people in Virtual Coffee have very specific problems with bad bosses and bad behaviors. And it's like, I would have left a long time ago, you have more power and will then I do it. And that's amazing. But yeah, I bosses yelling aren't exactly my favorite thing. But I I've been able to put up with that because I can kind of get around it and get to the point of it. And you know, it's, it's, it's something that happens every once in a while, like I said, I worked in a mom and pop shop, I saw a husband and wife team yell at each other every once in a while and maybe sometimes yell at the staff. And I was like, when that started getting directed towards me, I was like, I'm out of here. So like, you know, I don't you know, if it's abusive behavior and bordering on, like, hey, this might be something that people could get sued for. I'm usually out the door.

Dan Ott: 51:48

That's actually an interesting part about radical candor. Was was some of the, some of the examples she talked about where people would get like, he did indiscretions. Like, like, like, yell, you know, but it was, you know, it was not unsafe, you know, if that makes sense. And like, that was kind of a revelation for me. Because, you know, I don't know, I'm not like, I don't, if I'm yelling, I'm probably like, upset, like, not, you know, like, probably not feeling very good. You know, I mean, but there there are definitely times where I have with people I work with, and, you know, respect, like, we have, like, gotten heated at about because we're like, it's not like we are yelling at each other, you know, we're like yelling to each other about a thing that we're arguing about, you know, like, an approach or something. And it's an interesting like, that the the raised voices sort of situation is like, it's always an interesting topic for me, because I don't do I don't do pretty well with confrontation. Like, I also would, like, just be peacing out as soon as somebody was yelling at me, like a boss was yelling at me, you know, I mean, my personal experience was with a colleague, you know, it wasn't like, it wasn't like, a higher up dealing, you know, so. I don't know.

Tom Cudd: 53:02

I mean, arguing is something I'm fine with, but like the actual, like, directed, like, we're, it's just, it doesn't even make sense. If people are just yelling to yell, that's no good. I have like a one situation where like, I got really mad, or call. And I like, like, slant, like, I picked up my keyboard and I just slammed it down, and like, broke the little like feet thingies off of it. And I'm like, Okay, well, that violence in the workplace is never accepted. Like, I came back an hour later, like, Okay, I'm sorry, everybody for doing that. Like, like, I actually still have that keyboard. Like, that was eight years ago. And I taped it back up, and I still use that keyboard as a reminder, don't slam stuff in the office. Like, that's just not okay. Like, there's some lines that you know, I my boss likes to joke, everyone so well, he tells people you know, we broke Tom once. Because he was it was like three in the morning on the day, something was supposed to launch and it just completely collapsed. And nobody else was online. And you can just see his frantic messages in slack getting more and more until he was like, I'm done. And, you know, I felt safe enough to go, I just give up. I'm gonna go to sleep for eight hours. And whatever happens over that next eight hours, I leave it to the rest of you to deal with so like, it's, it's sort of you have to know, I may not have known my break point then. But like, I know now what my limits are. And I I'm do a good job of staying within that. And understanding that about yourself is important. But when you start to understand yourself, you can say, Okay, I'm seeing where this person on my team has a limit that they don't even recognize and I'm like, you need to go home. Well, I know you are home, you need to turn off your computer, or I'm going to send it a message to change your password without telling you so like, so you can't log in until it's Till I say it's okay. It's, it's, as a manager team lead, you sort of become a little bit of a psychological safety net for the people that are around you. And it's a, it's a different skill. But I like doing it, I like helping the people that I work with and hope that I'm doing a good job.

Bekah Hawrot Weigel: 55:21

I think too knowing the people and having that relationship also can determine how you're communicating with them, right, and understanding what their limits are. Because sometimes, I always like to think about this, even in terms of what a good trainer is, right? Because a good trainer knows how to motivate each person there, because they have some type of relationship. So sometimes you might need them to say like, okay, you need to stop, it's time to do something else. Or sometimes you give gentle encouragement. And then there is times when, when you know, some people need a specific type of encouragement, and maybe that's going to be loud. Or maybe it's going to be a different approach that you take with someone else. But recognizing how to motivate that person. And that it's not a blanket approach for everyone is what's going to create, like a solid culture of respect, and a place where somebody can grow and take risks, like you're talking about.

Tom Cudd: 56:20

Yeah, I have learned a lot from the manager, manager, tools, website and podcast, about some of those communication methods, I do one on ones with the people on my team, that's a good way to build up rapport and build up that kind of that all that relationship building that I talked about happens in there, especially now virtually, like the one on ones are the way I can engage with people on a regular basis. I've learned a lot of skills from that in terms of I, like I said, I have true, I have had trouble giving direct criticism and feedback to people that I'm working with in the past. So like that, some of those tools gave me techniques like, find a very small thing that you want someone to do that you need them to do directly. And you may know they're not going to do it, even though you may ask them directly so that you keep following up and like you sort of show how you're going to escalate through the like, okay, I asked you to submit this report last week to this thing. What prevented you from doing that? And then the next time you can you just add more emphasis and say, Look, this is a part of your job. And this is a job expectation that I expect from you. So learning some of those techniques is, you know, like I said, I'm a individual contributor, technologist in training, but like, retooling my sort of managerial capabilities and team lead capabilities over the last like two, three years, has been a new and interesting set of challenges. It's also interesting to see how many of the same lessons in tech apply to dealing with people and systems of people. So it's not it's it's more one to one than I think most people realize doing that the tech to lead kind of sideways shift.

Bekah Hawrot Weigel: 58:11

Well, I feel like I could talk to you about this stuff for at least another hour.

Tom Cudd: 58:19

I probably could too,

Bekah Hawrot Weigel: 58:20

I mean, this hour is gone by so fast. I just looked up like wow, we've been doing this for a while. But this has been really, really great. So thank you so much for being here with us today. If there's like a top Do you have a top resource that you recommend for people to get started?

Tom Cudd: 58:36

So if it's for DevOps, I would definitely start with the Phoenix project, or the unicorn project as a follow up that has like additional learnings from over the years, one of those two is a good way to really focus on that kind of DevOps. What DevOps is culturally? And what can can it do for the actual technology that you're working with and the teams that you're working with. So Phoenix project is sort of the big unlock there. If, if you're looking for how to be dealing with people and fostering that psychological safety, radical candor is still my favorite resource for that. I have got a copy from the library because I think I load my copy up to someone back when we actually were in offices, so have to dig that up eventually. But yeah, radical candor is just an excellent resource for that. Fostering those good relationships and trusting relationships in a safe way.

Bekah Hawrot Weigel: 59:38

Great. Well, thank you so much for sharing that and everything else with us today. This has been a really great learning experience for me. Thanks for being here.

Tom Cudd: 59:50

Glad I can join.

Dan Ott: 59:52

Thanks, Tom.

Bekah Hawrot Weigel: 59:55

Thank you for listening to this episode of the Virtual Coffee podcast. This Episode was produced by Dan Ott and Bekah Hawrot Weigel, and edited by Dan Ott. If you have questions or comments, you can hit us up on Twitter at Virtual Coffee io. Or you can email us at podcast at Virtual coffee.io. You can find the show notes plus you can sign up for our newsletter to find out what Virtual Coffee has been up to on our website at Virtual coffee.io.

Dan Ott: 00:24

Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week.

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.