Dagna: [00:00:00] It’s important to realize that at the end of the day, we’re people working with other people to create products for other people.
Matty: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton. Have a fantastic and really interesting and insightful show for you today. But before we get into that, as always, let’s hear from our lovely sponsors. Do you ever start a query going in your log aggregator, go get a cup of coffee while you wait, and by the time you get back, it’s not the answer you needed and you’ve started to forget what you were looking for to begin with? You don’t have time to waste like that when you’ve got issues that need fixing now. Whether you need to understand your entire overall system or drill down to the individual user level with traces, get the right answers fast when you need them with Honeycomb. Go to honeycomb.io/arresteddevops to use it for free. Do you want to improve your software team’s productivity but don’t have the information or visibility to know where to start? Zenhub helps teams build better code faster. With a developer-friendly productivity management platform. Zenhub empowers startup and scale-up teams to get more done in less time wherever they are. With the best-in-class GitHub integration, team productivity insights, and AI-driven automation, Zenhub helps you plan work, track progress, and see the big picture across any team. Automate your agile and get hours back each and every week from for building features your customers want. Get started for free at go.zenhub.com/arresteddevops and enjoy 10% off your first-year subscription of Zenhub. Kolide sends employees important, timely, and relevant security recommendations for their Linux, Mac, and Windows devices right inside Slack. Kolide is perfect for organizations that want to move beyond a traditional lockdown model to one where employees are educated about security and device management while they’re fixing important problems. Visit kolide.com/ado to sign up today. That’s kolide.com/ado. Enter your email when prompted to receive your free Kolide gift bundle after trial activation. You can try Kolide with all its features on an unlimited number of devices for free for 14 days No credit card required. Try it out at kolide.com/ado. I am really looking forward to this conversation today. There’s, uh, we’re not sure exactly where we’re going. We’re gonna kind of weave around in a bunch of different topics and we’ll see. But if you’ve listened to this podcast before, you’re saying, Matty, that’s all the time. So enough of me. I’d like to introduce, uh, my guest. Dagna, would you like to tell our audience a little bit about yourself?
Dagna: [00:03:13] Yeah. Hi there. My name’s Dagna Bieda and I’m a software engineer turned career coach. I’ve been coding for over 10 years and coaching for the past 3+ years. And I am the tough love, I’ve been in your shoes kind of coach. I worked with incredible range of clients thus far, some from big brand names such as LinkedIn, Amazon, Google, even Disney. As well as much smaller businesses, and their experience ranging anywhere from 2 to 20 years of experience and education ranging from self-taught through career-changing bootcamp grads to college grads, some with a military background. And what I did, I’ve helped them reach for their potential. I am so excited to be on your show today, Matt. Thanks for having me.
Matty: One of the things we talk about, you know, when we think about DevOps, we think about So much of it is whether we call it breaking down silos or building bridges, collaboration, cross-functional, all these kinds of things. A lot of this really comes down to communication, right? Like when we collaborate, communication is really key. And when we kind of think about that, you know, what are some of those Like, how can we be better at this? Right? Like, and maybe engineers specifically, not to stereotype, we don’t like to do that. Maybe a little bit. I don’t know. Like, what do you see where areas, especially around maybe collaboration and then specifically the communication that people could do better at?
Dagna: [00:04:50] Ooh, I’m so glad that you asked that question because there is so many areas of improvement. Well, first of all, whenever we’re talking to each other, We often don’t realize that everybody comes to the conversation having certain assumptions in their mind, like how things were done in their family, how things were done in the culture they grew up in, like what’s acceptable, what’s not. And it’s very important to have the awareness, being mindful of those assumptions that we bring to the conversations. And in order for us to be able to communicate more effectively, Being able to clarify assumptions, it’s one of the key skills that I work with my coaching clients. So that’s one.
Matty: I definitely don’t want, you know, you to, you know, give away what you do. You know, it’s sort of like in Batman, he said, if you’re good at something, never, you know, give it away for free. So maybe we’re not giving the full coaching session here, but like maybe an example of like clarifying those assumptions, right? So if we’re in a conversation, is it just as as straightforward as just sort of saying, I have this assumption, you know, or like, could you give maybe an example of how that might happen in a conversation?
Dagna: [00:06:03] Absolutely. So there are 2 types of assumptions, the ones that we have and that guide our thinking, but there are also things that we assume about other people assuming things, right? So the first one is whenever you’re communicating, let’s say you have a feature to build, you’re saying, okay, I am assuming this to be true, that we have this amount of people committed to the project, this amount of time, and these are the limits and boundaries that we’re working with in order to get this project done, right? And then you can also, you know, whenever other people are assuming some things and you’re not fully understanding, you think you get the idea, but you’re maybe not fully clear about what it is that what they’re really saying, it’s always better to ask, to overcommunicate, right? And there are no stupid questions, right? If you didn’t get it, then that’s exactly what it means. You didn’t get it. Perhaps the person didn’t communicate it the best way they could, or maybe you just woke up on the wrong side of the bed today and, you know, maybe you’re a little slower because your dog was, you know, upset the whole night and was barking or something. You know, things happen and these assumptions that we have with us, that’s what’s gonna keep us miscommunicating, right? So if you’re not getting the point that someone else is trying to get across, or you think you’re getting it but you’re not quite sure, not quite there, the best way is to just say, you know what, I’m not sure I’m getting the good picture here. Like, would you mind explaining a little bit more? And with clarifying assumptions, it’s really important to start with an I sentence to kind of create a safe space, right? Whenever we’re having a conversation with someone and we’re not getting their point, it’s very important to say, hey, I am the one who’s not getting it. I’m not trying to say that you’re a bad communicator because people, whenever they feel like, oh, you know, they start getting defensive if they feel that we’re communicating with that, you know, assumption, hey, you did something wrong because I didn’t get it. We want to phrase it as, I didn’t get it. Why don’t you give it another go? Kind of like creating that safe space in communication.
Matty: [00:08:16] It’s interesting because I think it goes in all directions, which is always sort of trying to be collaborative is taking a little accountability onto yourself, even if it’s not necessarily. And one of my favorite episodes of the show that we did a long time ago, and it’s at restdevops.com/culture-change. We had Bill Joy on and we were talking about culture change. And this is a quote I use from him all the time when I’m trying to, and I said, it’s something, I’m going to get it not quite exactly right, but that’s okay. But something to the effect of like, if you’re trying to get someone to understand an idea and you’re just, and you keep saying they just don’t get it, that’s really more on you as a responsibility. Now, again, there are exceptions. Absolutely. Sometimes people have their ears shut and there’s, you know, we’re not necessarily talking about getting into like fights on Twitter or things like that. But when you’re, you’re trying to explain an idea, right? And the other person has an open mind to it, right? You know, like you’re in a position of collaboration, right? And, you know, I’m here and I’m like, Dagda just isn’t getting this. Like, it’s on me. Now, that being said, you of course can still sit there and say like, I will take some responsibility for not doing that. But the gist is, right? You can’t, the only thing we can control is our own actions. So if we want to get somewhere, we can only do the things to take the responsibility for them there.
Dagna: [00:09:39] Well, we cannot control everybody else’s actions. That’s very true. But we definitely have an impact on how people behave around us. You know, what’s the energy that we’re putting out there? How we communicate with people? Do we respect them? Do they, you know, get that vibe from us? Because, I mean, if you walk around thinking, oh my God, I work with idiots, you know, people are going to sense that energy and, you know, communicating is going to be really hard because they will pick up on it. Because if you subconsciously, if that’s something that you believe, that’s going to seep through in your communication.
Matty: And one of the things we talk about a lot in DevOps, to the point that for a little DevOpsDays history, I think the year of 2014, every single talk at every single DevOpsDays that year was about empathy. But it still comes into it as a core, right? And that’s a little bit of kind of what we were talking about, right? Like, when you’re thinking about where assumptions come from, like, we talk about empathy being really core to DevOps, right? Because you’re trying to be collaborative, you need to be able to see that. And one of the things I remember, I think it was Kevin Baird, it had said around that time, he said, I don’t want to see another talk about empathy at a DevOps Days without talking about how to do it. You know, and I gave a talk a while ago called You’ve Convinced Me We Have to Collaborate Now. How the Hell Do I Deal with People? So I kind of want to talk about that. Like, I, you know, we talk about empathy, but like, how do you operationalize empathy? Like, like, like we understand it’s a state we want to have, but like, what are some actionable things that maybe we do or we don’t, that we do, maybe some things we don’t do that prohibits us from being in an empathetic situation with our colleagues and our collaborators or things we could be actively doing?
Dagna: [00:11:26] Okay. So I feel like empathy can be misunderstood, right? If you are hearing the word empathy and you’re thinking, oh my God, now I have to be feeling what this other person is feeling. And I don’t really care. You know, this is the wrong understanding of empathy in the workplace. The understanding that really works for the workplace is understanding the priorities of other people, right? The people that you work with. I mean, for example, a software engineer, what are their priorities? Fix bugs, implement new features, learn new stuff, and, you know, have fun, right? What are project managers’ priorities? Well, they don’t really care much about refactoring the codebase if it doesn’t produce a tangible, you know, change in maybe the visual or like adding a button, adding an action. Like for a project manager, they’re going to have a priority of, if it ain’t broken, don’t fix it, right? And for developers, it’s kind of like, oh, but I really have to refactor it because, like, the way it’s written, spaghetti code, it’s horrible, it’s going to crash in 2 years’ timeframe, it’s going to be so bad. And on the project management side, like, that’s just not relevant because they have other priorities. They have to take care of, you know, making sure that business delivers business value that was promised to their clients, that it happens on time and that there are like no major disruptions to the users being able to use the product essentially, right? So having that understanding is really key here. That’s the empathy. And I have like a whole worksheet that I go through with my clients whenever we work together to get the understanding of all the stakeholders that we work with, getting understanding of their priorities. So whenever we also come to a conversation with them and we have this genius idea that we wanna pitch to them as an engineer, guess what? If we’re able to tell them, hey, I get where you’re coming from, I understand your priorities, here’s my idea and how my idea fits to your priorities, that’s how we’re heard. That’s how people listen to us. And that’s how brilliant engineering ideas get actually implemented. We have to have that buy-in And that’s something that, you know, a lot of engineers kind of don’t necessarily know, which is great because, I mean, that creates a space for me to have my coaching business.
Matty: [00:13:53] I remember years ago, a CTO that I worked for, you know, like our architects and stuff, software architects would come up with these ideas and she would say, okay, great, I need you to write me the case, write me the business case in there. I didn’t want to do that. I don’t want to do that. I don’t want to do that. And so this stuff doesn’t happen. And I have a talk called The 5 Love Languages of DevOps, which, you know, kind of is a little— it’s a little bit like what you just said, which is like, you have to meet people, not necessarily meet them where they are, but speak their language. And like, there’s stuff in The 5 Love Languages that’s like sketchy, right? But like the idea, which is like, I need to find like what my priorities are. So, whatever thing I’m trying to implement, whether it’s technical, whether it’s cultural, whether it’s whatever, the change I’m trying to make, it might resonate to me in a certain way because of my context, because of my priorities. But to you in a different role, you won’t see why that matters, right? You’re like, I don’t understand why that matters. And I could spend an awful lot of time trying to get you to understand my point of view, or I could spend a little less time getting what your priorities are and figuring out how that aligns, right? Like, something that to me, I’m like, well, of course, it makes a lot of sense because this way, we’ll, you know, have a more effective, you know, way that this gets serialized. You’re like, I don’t understand. What do you mean? I’m like, oh, but in this case, our customers are gonna get a response time that is 30 milliseconds faster.
Dagna: [00:15:22] Oh, cool.
Matty: Yes, I care about that because I have an SLA, right?
Dagna: Got it.
Matty: So I speak that language. But I think you’re right. It’s a tricky one with that word empathy because it can easily get kind of not put down, but dismissed as like, oh, it’s about being in our feelings and it’s all hug ops. And I’m a big believer in hug ops, but that’s not— hug ops is a form of empathy, right? Which is we’re being empathetic with other people in a hard situation. But really, you said it’s priorities. And we look at, you know, all this stuff. I always say, people say, what’s the most important DevOps book to read? And I said, Freakonomics, go learn about incentives. And you’ll understand DevOps, right? So understand people’s incentives. So what are some of the other skills around communication or collaboration that you think people have, you see gaps in where we could be doing better?
Dagna: I can tell you one off the bat that like really kept me stuck in my own engineering career, right? And I, it was a huge hoop for me to jump over. And when I finally did, I was like, oh my gosh, this is incredible. I cannot believe that people like that, this is not common wisdom and that we’re not taught at school, you know, and that’s really what set me off on my coaching journey, right? So essentially, it’s really about how you communicate to other people and being assertive. So I’m Polish and, you know, moving to United States, working in the United States has had some challenges, you know, I am more of a direct person and that’s part of the culture that I grew up in, and, you know, there’s been some funny situations that tied to me being a senior engineer, very confident in my skillset. You know, I would come across as sometimes an aggressive communicator, right? And there’s this situation that I really want to share with you and your audience today, because I think it’s hilarious. There was this meeting in my company. It had about 300 people and we had like a company-wide at the end of the day where some people were let go. It was a really difficult time. And, you know, when we were coming to that meeting, I wanted to express my concerns and let like the leadership team know about some things that I thought maybe they were not aware. I was coming from a good place, you know, my intentions were like really coming from, from my heart and caring about the company. And I was like, maybe they just didn’t get it, like how those decisions, you know, affect now the engineering team, right? And so what happens is my boss comes to me and he’s like, Dagna, why did you call our entire leadership team a bunch of idiots? And I’m like, what?
Matty: [00:17:59] You’re like, well, they were being a bunch of idiots.
Dagna: But you know, this is not what I said. I never called them out like that. But you know, I said some things that came across as if I was, you know, being derogatory, negative, and, you know, very kind of like aggressive in my communication. So this is not something I would have ever thought about myself because again, I came to this conversation with really good intentions. And then when I got that feedback, hey, this is how you actually came across, you know, that was like mind-blowing for me. It was like, okay, so there are my intentions here, but then there’s how I come across. And these two can be completely, totally different. So what assertive communication does as a skill, it really teaches you how to, first of all, you know, talk about your needs, wants in a way that’s respectful to other people and in a way that, you know, makes other people feel like they’re, they’re being heard and understood as well. So assertive communication is so key for any engineer out there, because I can bet with you for, well, I can bet with you on something. I don’t know what, but we can have a bet that every probably other engineer out there who’s a senior engineer sounds like a total asshole every now and then, right? Just because they’re too direct, too harsh, too like, you know, not beating around the bush, because as engineers, we want to lay it on the table, right? These are the facts. Let’s look at the facts and let’s make a decision. But human beings are not, you know, rational beings that only look at facts. They, you know, bring those assumptions to the table. They might feel, you know, judged, or the tone of the conversation is important. You know, being able to communicate a certain way is really a critical skill.
Matty: [00:19:59] And I think even beyond When you talk about, like, well, we just want to look at the facts, like, another thing I think that people should understand where it seems like, because you have that context, but especially these days, we’re dealing with such complex systems that there’s nuance to everything, right? Like, it can look so cut and dried within the microservice that I am responsible for that, of course, we have to do it this way. But just even staying within the technical, it’s like, but look at the complex system of all the things. There’s ramifications. Then we bring in the complex system of the business, which is, well, why wouldn’t we just do this? Well, but you know what? There’s a revenue impact when, you know, it’s like, so that’s sort of the thing. But again, like you said, when we spend most of our day with our engineering hat on where we’re solving problems that are compartmentalized, that are based on this, you know, it’s like that, but it’s like we, and so I, one of the ways I found that’s helpful is because people do understand distributed and complex systems and we’re like, You know, we don’t live in a world, we don’t build systems that are cut and dried. That there is one decision that will not— that will only impact that particular framework where you’re talking about it.
Dagna: [00:21:13] That’s very true. And I think it’s good to practice that mindset of kind of like stepping outside of the forest, so to speak. You know? Like, as engineers, we’re like so deep into the woods that what we see is that one tree right in front of us, that one project, that one microservice, that one feature that we’re working on. And what happens is we don’t realize like how the forest as a whole needs to work together for the company to be able to work. You know, I like to compare the engineer to being kind of like a forest wizard, if you will, that has just like a, you know, some magic wand and they can like just tap the tree and boom, a new branch just happens, right? And they can, you know, tap on a tree and, like, figure out where the bug is and get rid of it so the tree is healthy, right? But then, you know, stepping outside, we kind of forget that our manager’s perspective is to make sure that the project is healthy and all the people that are working on the team are able to, you know, do the work. And then, you know, if they step more out, then they see that there’s, you know, a couple trees grouped together because of, you know, and that’s kind of like the director level. And the director has to look at different multiple products and how they work together, what’s the business impact. And then, you know, at the C-level, it’s really about the whole forest and, you know, where to grow, where to cut, where to expand, stuff like that. You know, being able to step out of the forest, it’s a really critical skill if you want career advancement. If you’re happy where you are, you know, just carry on, keep doing what you’re doing. But if you’re interested in growth, then you know what got you to that senior position is not going to get you past that position and advance further because you’re going to always have to change something, right?
Matty: [00:23:07] Your advancement may not be, I want to be able to get to executive level and I have to understand how sales works and all this other stuff. You may say like, I want to get to principal or distinguished or whatever, but you’re still gonna have to continue to think bigger and think differently and continue to grow in that. It’s not just get better and better at the— you’re not just scaling yourself by being more effective at doing the same thing, right? And looking in the same way.
Dagna: The essence here, right? So it’s really about kind of like, once you’re at a senior level and you have your technical foundation and it’s solid, like, obviously you want to you know, stay on top of the new stuff coming up, new technology, maybe new frameworks and languages. But once your foundation, technical foundation is solid, it’s important to realize that at the end of the day, we’re people working with other people to create products for other people. And those people skills are going to keep you stuck if you keep ignoring them. And if you keep just overvaluing the technical skills, Once the foundation is there, there are other skills to focus on, the soft skills.
Matty: [00:24:19] We had an episode a couple of years ago where we had Sylvia Botros on, and we were just talking all about the ideas around being a principal engineer and what that meant. So, if you go to restdevops.com/principalengineer, and I’ll put a link in the show notes. You may find even more things to, to dig into there. This again, it’s all that squishy people stuff, right? That everyone’s like, that’s why I became an engineer. But is it though? Like, even that sort of thing, people, you hear this a lot, right? Which is like, well, I became an engineer because I didn’t want to have to deal with people. But everybody actually does deal with people. There’s just like, deal with people the way that you want to, right? You know, that’s why there was that You know how there’s like, people will do those, would you be willing to like live in this cabin in the forest for a year with no connect, with no social, you know, no internet, like for $1 million and all these things. And then there was one the other day, which was like an empty white room. And it was like, you get $30 billion, but you have to stay in, you have nothing. And it’s just that number’s like, I could totally do that. You’re like, no, there’s a reason that’s like torture, right? No, I don’t care who, how introverted. Or anything you are, you cannot deal without human interaction. So the human part of this is, right, like, like our software means nothing without people. And I’m fascinated by human factors in software, both in the way that we build software and that the people that consume them and everything. Like, so how does this, how do we, I don’t wanna say how do we deal with the squishy human stuff, but like, what, How do we sort of reconcile this, like this sort of common— I don’t want to say common, this, you know, this statement that like, I don’t want to have to deal with the people, but you’re building software for people.
Dagna: [00:26:07] I’m going to, I’m going to, you know, take from Simon Sinek here and say, let’s start with why, you know, why is that, you know, how you’re feeling about other people and something that I work with my coaching clients that’s super critical. Is analyzing the limiting beliefs that you may have, right? Because the way you think is impacting how you act. So it’s very critical to understand what are the thought patterns running on in your brain. And essentially, if you think about subconsciousness, it’s, you know, the operating system having the UI programs that are kind of like running in the forefront. You see them, you can interact with them as a user, and that’s your consciousness. But then you have those programs running in the background, right, that you don’t know are running, but they’re there and they’re really running the show. That’s what the subconsciousness is, right? And it’s really, as you were growing up, you know, people who you were surrounded with, whether by choice or not, and most of us did not have that choice, they went into your brain and they just, you know, play the sudo command, install beliefs. So you have a certain set of beliefs coming from how you grew up, people that you were surrounded with, that can either serve you or can hold you back, right? So these are some limiting beliefs. And for engineers specifically, so many engineers have this limiting belief of believing that their work speaks for itself. And it doesn’t, right? One of the communication skills that I work with my clients is marketing themselves, marketing their job. And it’s very critical because if you’re a software engineer coding, unless someone literally, you know, pulls the repo, looks into what you did, they have no idea. They don’t know. And they don’t understand how that trickles down to business because they may not have all this techno wizardry in their own mind because, you know, they have a different kind of expertise, right? So it’s very critical to, you know, when you say, hey, I just want to be hidden behind my screen and I don’t really want to deal with people, where is that coming from? Did you grow up in a place that you believe you had to make yourself invisible? Did it make you safe at the time? Is it, you know, something that is serving you still, or is it something that you’d like to change? Because there’s another thing you know, that I want to share with you here today, Matt, and with your audience is that as human beings, we constantly change, we constantly evolve. You know, if you think about yourself, who you were before you learned to program, you were a completely different person than you are now knowing how to code, right? Your reality changed, who you are, how you think, what you do, all that changed. So we have the ability to make a conscious choice And, you know, if we still want to be hidden behind the monitor, stay as it is, that’s fine. Totally fine. But if we want to change that, we can absolutely change that.
Matty: [00:29:19] Yeah. And I think there’s, just like you said, you have to be able to promote it. You have to be able to push it because people are not necessarily aware of that particular engineering effort. We see that happen like even more in like operational roles or system engineering roles or things like that. And, you know, I’ve said before that, you know, being a sysadmin or ops or whatever we’re calling them these days, that’s my background, by the way, so I can say that. It’s sort of like being a corporate lawyer, right? Nobody in the organization knows what you do until you fail, right? Until you don’t do your job, right? Like, you know, like, you know, the corporate lawyer that keeps the company from being sued all the time, nobody knows that. You only know about it when they didn’t keep you from getting sued, right? And so it’s interesting, like, yeah, you have to be able to be a little bit, like you said, like you have to be able to market yourself, promote the work you do. But, and that goes back into those contexts and into those assumptions and into the empathy of, but how do you express it in a way that makes sense to the people you’re trying to market it to, right? Because again, you’re like, well, it’s amazing. I refactored this thing and did whatever. And they’re like, don’t know what that means. That sure sounds like you did something cool, but, you know, which goes back to one of the things I, you know, say in almost many of my talks. I’ll sit there and I’ll say like, hey, do you know how your company makes money? If not, go find out. I’ll wait, right? And obviously nonprofit, different thing, but like, how does your company see value? Because that is how you can connect your work to that. And that’s the thing that will make sense to everybody in your organization. And sometimes we have a challenge with that, right? Because we like to feel that we do it for the purity of the code, or, you know, I work in developer advocacy, so we like to say, you know, we’re not connected to filthy sales or dirty marketing or whatever. We fight for the users like Tron. But it’s like, no, like, yes, you can do that, but you also want the company to be successful. Not even just for your own particular, like you’d like to continue to be employed and get a paycheck. But even if it is saying that you’re like, well, I only care about my users having a great experience, they will only continue to have a great experience as long as your company is in business and able to provide that to them. Right. So it still does. I’m sorry. The root cause is capitalism. That’s, we’re there. Right. Okay. That’s a different podcast. So Do you see like that challenge of like being able to, yeah, like as a software engineer, especially someone that’s maybe not working on like really exposed features, like how do you market your efforts? Like how do you, you know, again, not giving everything away for free. If you want to know for sure, we’ll have links and how you can, you know, get to it.
Dagna: [00:32:14] I’m happy to share because, you know, when I coach someone, it really goes deep, right? We really get into personal details and dig and dig until we find the gold or the oil fields, so to speak, right? Because, you know, like us talking on that podcast is kind of like your listeners going on, you know, Stack Overflow’s blog and just reading through the articles. Reading the articles is great, and it can help you expand your mind, mindset, but unless you’re getting feedback that is tailored to your custom situation, you know, those articles are just, you know, fun to read. So the coaching goes way beyond that. So I’m not worried to share more and more. So essentially, you know, going back to seeing the business value, we again go back to the human factor and having conversations. Right? And let me share with you a story here to paint the picture here. There was a moment that I was working for my company, I had 2 features to work on, like, very closely to each other. One of them, I was super excited about. It was very technical. I had to refactor how we were building this mobile app. And I cut down the build time from like 4 minutes to 20 seconds. I was like, damn, cool girl. Yes, you know, it was so intellectually stimulating, very rewarding. But at the end of the day, it affected my life and one other engineer. So 2 people, right? And then like right after that, I had to work on a feature that was kind of boring. It was cutting a build for a new client, but it was a huge client. It was kind of copy pasting and setting things up, you know, and the moment that we shipped it, I got pats on the back from my boss’s boss, the sales rep, the client rep, you know, everybody in the business was affected even though it was not fun stuff. So when it came to me and my manager talking about, you know, my progress throughout the year, he was pointing it out like, hey, Dagna, like what you did with, you know, creating it so quickly, the client was happy. We were before the deadline. Like, it’s incredible. And I’m like, okay, engineering-wise, it was like, Meh, you know. So if I wouldn’t have had that conversation with my manager who was able to provide me that feedback and saying, hey, what you did there was so impactful for the business, I don’t think I would be able to see it for myself. You know, it goes back to communicating, to talking to people and saying, hey, these features that we’re rolling out, you know, what’s the impact on the business? Can we have a conversation? That’s for you to be curious, because if you’re going to be like, oh my God, It’s not a meeting. I don’t really care. And rolling your eyes, you know, that’s not going to help. It’s really important to be curious, to ask those questions, to communicate and talk with your coworkers.
Matty: [00:35:12] I think that’s a really good point because, you know, I’ve, I tend to gloss over that and I say like, you know, find out how your company makes money. Like, you know, do all this stuff. And like, that’s a little bit like a little overwhelming, which again, depending upon I will also say that a lot of times what you think is how your company makes money is not, because it’s not necessarily the thing that you sell.
Dagna: Oh, true. Very true.
Matty: Or what has a value, but most leadership of any merit is never going to take a question like that, especially from someone outside of that and be dismissive and be like, why do you care? That’s highly welcomed. The only thing that I would say I would have empathy for someone not wanting, like being uncomfortable to ask is if they feel like they should know. You know what I mean? Like I could definitely see that being a scary question. Like if you’re feeling a little uncomfortable, like going to your manager and saying, you know what, I don’t really understand how this valued, how this project brought value to the org. You know, I, I, don’t imagine most managers of any, you know, value would, even if they, you know, would say, well, why didn’t you know that, you dummy? But I can appreciate how you’d be scared of that. So there’s probably ways you couldn’t.
Dagna: [00:36:35] You did say you dummy, but I’m thinking, you know, let’s go back a little bit. And first of all, there’s no stupid questions, right?
Matty: Oh, that’s what I’m saying. Like, I’m not saying that it’s gonna happen, but I understand the Oh, this is what I mean. Yeah.
Dagna: But the second thing that I want to share, if you’re in a company that you cannot ask your manager that, run. I mean, there must be some shady stuff going on right there if they’re not willing to share it.
Matty: Generally speaking, the only way that, like, if I know, if I went to my boss and said, hey man, like, I’m trying to understand, like, why we do this particular thing, unless he literally told me that yesterday, he’s not going to be upset about it, right? You know, I mean, that being said, if your boss told you the answer to that question yesterday, then yes, you should probably be afraid to ask it again the very next day because like that meant you weren’t listening. But yeah, be curious or maybe ask a coworker, you know, if you’re concerned. But the, it is interesting because again, as our organizations become where, you know, the, the bigger they are, the more complex they are. I’ll just give one, one interesting example of how— I don’t want to say how bad I used to be about this, but years ago I was doing, you know, system engineering at a bank, at one of the largest banks in the world. And I really didn’t understand what the line of business I worked for did. I just built systems, right? Like, I just built them out and did, you know, achieved requirements. I knew I was in some line of business called treasury services. I was like, okay, I don’t know what that is. And then when I was looking for a job and was updating my resume, I was like, well, I want to write a little bit about this in my resume. So I went on like our internal website, you know, like, because it was a big enough bank, there was like an intranet where there was basically a homepage for every line of business. And it was like, you know, treasury services processes, you know, $1.2 billion of wires a day or something, or trillion. I think it was trillion. It was a, I was like, oh shit. And then I was like, I was a little more comfortable when I didn’t know that, right? Like, but it was, I was like, I had no idea what we even did, right? And the funny thing is, when you think about it, it’s kind of funny, a story, but also it’s like, I really, that impacted my ability to be good at my job, right? Like, if you don’t know what matters, like, to your organization, you— it’s harder to make effective decisions, right?
Dagna: [00:39:12] Yeah. Prioritize, you know, moving to a direction that you don’t know where you’re going, right?
Matty: I had a friend who told a story before about— she was working in ops for a major retailer. And it was a scenario where the, you know, like she was basically shutting down, you know, the business was like, you know, we need to make this change and this thing happened. She’s like, no, because I have a stability goal and all this stuff. And, you know, our boss said, hey, your job is not to provide the stable system. Your job is to help us sell things. Like, again, like we have, I understand we have micro incentives and macro, but like we still always go back to like, we don’t build systems because they’re fun to build. We build systems to sell shoes. Right, you know, or whatnot. Always.
Dagna: I love that you mentioned that because I— a lot of entrepreneurs, I mean, a lot of engineers that want to leap into entrepreneurship that I see is, oh, I’m an engineer, I found this awesome framework, and I built this app. Let me see if I can sell it and if someone buys it. And that’s not how the world works, right? But a lot of people think that way. Now I want to go a little bit back to when talked about like things that matter. And that’s actually some super important thing that you mentioned there, and I want to talk about it a little bit more. The very first step that I take on with my clients whenever we do coaching is figuring out their values, right? And then the last step that we take is figure out what companies out there support those values, right? So instead of kind of like being reactive and looking into like what jobs are out there, what I do with my clients is figure out how do you find fulfillment in life? How do you create a life for yourself that just, you know, sparks you on fire? That every day that you wake up, you’re excited and you want to do the things that you do for work. And then what kind of companies fit that profile? And having value alignment is super critical there.
Matty: [00:41:21] I think that’s really interesting and important, and it can feel challenging because we do, we have this reinforced by people who don’t know how to interview people well, because that’s a whole other conversation is that most people giving job interviews have never been trained on how to give interviews. But people always forget that like a job interview or the entire process of recruiting and back and forth whole thing is, it’s, it’s full duplex, right? It’s bidirectional. You are not just— I’m not just interviewing you to see if I will deign to allow you to work at my company. I’m also needing to prove to you that you should want to, right?
Dagna: That you fit in.
Matty: Yeah. And that’s— it’s kind of funny if you think this is a whole talking about everything about recruiting, how it really does flip, right? Because you’ll get, because you recruit, recruiters understand that, you know what I mean? Like generally speaking, so you get quote recruited, right? They’ll reach out to you, Dagny, and be like, hey, are you interested? Would you come in? Here’s why we think this would be great for you. Actually, usually they still say it. If I think about it, this is interesting. Maybe any recruiters listening, because I right now was a super hot market for DevRel. So like every single startup in the world wants to hire a DevRel. So I’m getting like 7 LinkedIn messages a day from everybody in the world. But it’s always about your experience would make you great here, would make you a great fit for us, blah, blah, blah. And it’s always, no, you’re trying to sell me, friendo, right? Why do I want— and sometimes they get that. But my point is at the recruiter level, they’ll be like, this is what— a lot of times they will be like, you should come here. Here’s why we’re great. And then you come in and then you interview. And everybody they put you through, it’s a one-way conversation, right? It’s like, okay, prove yourself, do a whiteboard, do an algorithm, do a sort, do a thing. And so I’ve got 2 things. One is to people, if you are on the interview side and you’re doing the interviewing, please remember that. Like, you know, but on the other side, as someone who’s interviewing, remember you should have, you know, it’s sort of, they always say like, you know, you always should have questions to ask, but not just to show you’re interested. Like you, To Dagny’s point, like, you know the things, right? Like, so you’ve defined your values, you know the things that are important to you, you need to ask questions that will— because maybe they’re going to tell you and not tell you directly sometimes, right?
Dagna: [00:43:56] Let me tell you, Matt, that whenever I was on the interviewer side and I was able to interview someone who asked questions to me back, I was like, I want to hire them. You know, because again, we’re going back to communication, to the human factor, right? You want to work with someone who ramps up really quickly, who understands. For them to get that understanding though, they need to ask questions. So I totally agree with you. It’s a two-way street. Now with a lot of engineers, what happens is whenever they’re going through round of interviews, if they don’t feel confident in their skillset, the engineering skillset, You know, that might prevent them from owning that power to ask the questions and being like, okay, here’s what you’re offering, but this is what I want, right? Can you give that to me? It’s interesting. There’s an interesting story I want to share with you here. There’s a startup I worked for and 4 months into the work, I was able to negotiate a sabbatical. And for those who don’t know, sabbatical is, you know, a few months leave. I was able to negotiate 6 months because I was very set on leaving, but I was able to make the ask because I was so confident about my skills. I knew I was the shit, and if you would throw me a project, I would get it done. So if, you know, if they wouldn’t have granted me the sabbatical, I would be like, okay, I’m just gonna do my thing for those 6 months, and it was traveling across Southeast Asia, and it was just spectacular, amazing, and I would do it all over again. I loved it. But I was so confident that after, you know, even if I asked and they said no, I’d be fine because I’d go and travel, come back, and I would find a job in an instant. That wouldn’t have been a problem, you know. Here we’re kind of like trickling back to the confidence, and I mean, Matt, I’m gonna say it, I feel like we need to do another episode because there’s like, we barely scratched the surface here. There’s so many things that we could dive deeper into and, you know, confidence could definitely be our next topic.
Matty: [00:46:05] No, I agree. I think we’re gonna, we have a lot more to dig into, so we will definitely have a follow-up episode. And longtime listeners know that I say that all the time and we do eventually always get to our follow-up episodes. Sometimes it takes years, hopefully not years this time. But that said, like, if there’s, as we’re kind of coming to wrap up, because I think we’re at a good place for that. What’s one thing? So anybody who’s listening to the podcast, what’s the one thing you would recommend they could do to help their career today or tomorrow? And the reason I say today or tomorrow is maybe they’re listening at night. But I didn’t want to say tomorrow, because maybe you’re listening in the morning, and you got the whole day ahead of you. So like within the next 24 hours, next 24 business hours, what’s one thing they could do to help their career?
Dagna: The one thing that I would absolutely recommend is to ask more questions and be more open to putting the assumptions they might have on the table. You know, the more we communicate, the more information we can gather, the better our decisions, right? So that’s definitely, uh, one step. The second step is that they can just hire me and work with me as their career coach. In order to do that, they can go to themindfuldev.com/podcast, and that link will redirect them to watch a case study video that explains exactly what it is that I do with my clients.
Matty: [00:47:39] Awesome. So remember themindfuldev.com/podcast. If you go to arresteddevops.com/itunes and leave us a review in the iTunes store, That will help other people find the podcast. I know it hasn’t been called iTunes in years, but I refuse to change that redirect because, you know, I’m lazy and, and stuff. But you can also listen to us.
Dagna: 5 stars.
Matty: 5 stars. Yes. You know, it does. Apparently it does help people find the podcast. And sometimes we read the reviews on air, so to speak. I don’t know if we— if on air is the right term. We’re not really broadcasting. But that, but you, if you want to pretend that we’re on the radio, you can listen to us on iHeartRadio or on Spotify. And we’re also available on Audible. So pretty much everywhere fine and less fine podcasts are available, you can find Arrested DevOps. Dagna, thank you for joining me today. This was an amazing conversation. We will absolutely have another episode because I think there’s so much more that we can dig into.
Dagna: [00:48:40] Oh, absolutely. I, and I love being here.
Matty: So this has been Arrested DevOps, and remember, there is always DevOps in the banana stand.
