 Hey, everyone. Welcome to How to Be an Ethical Engineering Leader. I am super happy to have you join me here today. Now, before we get started, I'm going to tell you a little bit about me. My name is Adriana Volella, and I am from Canada. I'm from Toronto, Canada, so I'm super excited to be talking on Canadian soil. I love solving hard problems, whether it's as part of my day job as a senior developer advocate at LightStep, or on a rock wall, which is where you'll find me blowing off steam when I'm not at work. I am also a CNCF ambassador, newly minted just in April. I am a HashiCorp ambassador, second year in a row. I co-host a podcast called On Call Me Maybe, which I totally recommend you check out. It's a fun, slightly biased, and I've been doing computer things for about 30 years, if you count the fact that I've been coding in basic since age 10. I guess that dates me a bit, alas. All right, so that's enough about me. Let's get started. Now, picture this. I'm sitting at lunch one day with my husband at home. Now, we both work in tech. We both work from home. And he is super frustrated because he's like losing sleep over the fact that he is being asked to cut corners on his project. And the thing is, these types of things keep happening all the time. It's not the first time it's happened to him. And goodness knows, it's happened to me a bunch of times. So it's super frustrating. And I get his frustration. I mean, how many times have we been asked to cut corners? Do things that don't feel, you know, you're trying to do right by the organization, trying to do right by the work. And you're asked to cut corners, and then you're told by management. Well, that's not how it works in the real world, which honestly is nails on chalkboard to me. And it's super frustrating. And I think, well, why can't it be how it works in the real world? Like, why can't we just change the conversation around that? So today, I'm going to give you not one, not two, but eight tips on how to be an ethical engineering leader. And it doesn't matter if you're managing a team of engineers, or if you're an individual contributor, because we are all leaders in our own right. So let us get started. All right, tip number one. Don't take your developers for granted. Now, I don't know about you, but it feels like in the last 20 years or so, development has been commoditized. People think that you can just swap one developer for another. You know, Sally is a great Java developer, but she's a little too expensive. So let's swap her out for Jimmy, because Jimmy is a little less expensive. Well, newsflash here, developers are not clones of each other, I know, right? Shocking. We are individuals. We all have our strengths and our weaknesses. We bring different things to the table. So thinking that you can just swap one person for another and expect the same results, guess what? It's not going to give you the same results. So treat your developers like humans. They're not clones. All right, tip number two. The POC is not the final product. Now, hands up, if you've worked on a POC and put all your heart and soul into it, cut the approval to move on with the project and then management goes, hey, and by the way, you're going to build the final product off the POC. This has happened to me so many times. It is so freaking frustrating. And I mean, what's the problem with that? When you're building a POC, you are essentially taking some shortcuts. You're learning as you're going along. Maybe you're not following best practices because you've got to do this thing quickly or maybe you're not familiar with the language, with the technology, et cetera. So as you go along, if you get the approval to do the final project, you think, okay, well, these are the things where I cut corners in the POC and this is where I'm going to improve. So this is doing the final product as the opportunity for improvement. But when you're told build directly off the POC, you're essentially introducing technical debt into your beautiful pristine project, which is never a good thing. Recipe for disaster. So my advice, always, always push back. Whether or not, I mean, sometimes you might not win the battle, but push back, right? Because you never know. You might get somebody to listen to you on that one. Okay. Tip number three, don't be afraid to reset. Now, I had in a previous job a situation where I was leading a team of developers and the lead developer on the project, now, this was an inherited team. And I'll tell you, like, this comes into play later. So this was an inherited team. So I did not, like, I chose the developers. And so I got this one developer who was in charge of doing the final, the biggest feature of our release, right? And he's working on this. And, you know, we were working in an agile manner. So giving continuous feedback loop from the business side of things and all that. Well, this guy did not understand the requirements. The business was constantly pissed off with his work. It was just no good. And on top of that, his code was crap. So panic, right? I mean, like, we're ways into this development. Nobody's happy. I'm unhappy. Business is unhappy. So I did what I thought needed to be done. I pulled them off. And I got someone else who was actually more junior to do the work, but they got what was going on. See, this goes back to, like, your developers are not swappable. They're different, right? And like, this guy got what was going on. And we ended up, like, delivering something successfully, albeit a little bit late. But can you imagine what a disaster it would have been, like, trying to clean up this other guy's mess? Like, we had to start from scratch. But I much prefer starting from scratch than trying to clean up some guy's mess into production and beyond, right? Like, the technical debt just follows you forever. So the moral of the story is you have to take a few steps back to be able to move forward. Okay, tip number four. Embrace the paradigm shift. Now, if you've been in tech long enough, you've seen all the paradigm shifts, right? We have seen the paradigm shift of Agile, DevOps, SRE, Platform Engineering, Cloud. Now, these paradigm shifts are all great in their own right. Absolutely. But where a lot of organizations fail is to embrace the paradigm shift. They think they can just keep doing things the way that they were doing. And of course, you don't get the good results. So, for example, I worked in this organization that was in the middle of a DevOps transformation. And they had this ops team that they loved checking their emails in the middle of the night for servers that were down that needed to be restarted. And they loved this because every time they restarted a server, they got the overtime pay. So they were caking it in the overtime pay, right? So they had zero incentive to improve how they were doing things, right? Because, I mean, this was working pretty well, making money, right? And to make matters worse, their managers, they weren't trying to embrace the paradigm shift. They should have gone to them and said, you know what? Why are these things always going down? We need to dig deep, understand, maybe we can upskill and help you automate processes better so that the servers aren't always going down. What's the root cause? There's so many things that they could have done. And what did they do instead? They decided to protect their folks. They're like, oh, no, no, the ops folks are unhappy. We can't keep them unhappy. And to keep them happy, they had to effectively just agree to letting things continue that way in this like, untransformation-y approach, right? And as a result, they never got to reap the benefits of this DevOps transformation. So it was their loss. So my advice is, you know, as managers, you need to help your folks understand the reasons behind these paradigm shifts, right? How it's going to benefit them. And you have to sometimes give them a little nudge, right? Because otherwise these things aren't going to happen. But pandering to their whininess is not going to do you any favors. All right. Tip number five. Take ownership of your code. So, you know, as a developer, I was a developer for many years, nothing pleased me more than to finish a piece of code and to throw it over the wall and say, done with it. No more. I don't care about this thing. It's somebody else's problem now. And of course, that's a problem because in doing that, then you're less invested in your code, right? Because, well, if it breaks, it's someone else's problem. So you're less incentivized to like make sure that it doesn't break. Now, this fits in quite nicely into our world of observability, where basically our applications, our infrastructure emit enough information so that we can follow the breadcrumbs to explain why is this happening. So in our observability world, as part of our troubleshooting, we want to make sure that our applications emit that information. And traditionally, it would be through logs. In an observability world, we want to add traces to our code. Regardless, it means that developers also need to ensure that they are instrumenting their own code so that it can help them troubleshoot things when they go into production. But where the problem lies is that as companies start embracing observability practices, there's this tendency for legacy code, for example, for them to not get developers to instrument their own code. So for instance, I worked at a company where I was running an observability practices team. And we were there to teach best practices around observability, instrumenting code, teach them how to search things through their traces, et cetera. But the CTO had other ideas and he said, your folks should go and instrument the dev team's code. Like what? Ain't my code. I don't know anything about this code. I don't know what's important. I have zero context. It's like somebody asking you to go write your unit tests for you. Let somebody else write your unit test. Let somebody else comment your code. That's absurd. So why would it be okay for somebody to ask another team to instrument somebody else's code? And to further reinforce this, I will leave you with a lovely quote from Liz Fong-Jones, who was on the on call me maybe podcast. Like full grown up software engineer, write your own damn tasks, right? So write your own damn comments, write your own damn observability annotations, right? This is what will help you understand your code later. Someone else writing it for you achieves very little of the value. Well said, Liz. All right. Tip number six, create a safe space. So remember how I said I'm Canadian. If you live in Canada, it means that you have to take French up until a certain grade in Ontario, problems where I'm from, you have to take it up until grade nine. Now, I'm originally from Brazil. My first language is Portuguese, French for me, no problem. My daughter, born here, speaks English as her first language, hates French. And she started grade nine this year, last year, French, like, oh, I'm like so close yet so far, does not enjoy French, doesn't get it. And so she was dreading it, especially like if you're learning a new language, and you're fumbling around with it. There's nothing more annoying than trying to clarify something in class and then be have being told by the teacher in French, if you play, you're like, but I can't, that's why I'm asking you in English, right? So she gets this new teacher for grade nine English, sorry, grade nine French this year. And her teacher comes in, she's like, you know, I've taught grade nine French before. But I haven't taught it for a while, I'm actually mostly an English teacher. So we'll be learning together. Oh my God, what a huge difference this made to her, right? Because she all of a sudden my daughter who hated French was like doing well in French, she got like 96 in French. She almost considered taking it in grade 10, if it had been with the same teacher. Now, why did her attitude change? Because she was in a welcoming inclusive environment. Her teacher was vulnerable. And so made it a safe space for them to learn. So, you know, if you translate this to the world of tech, imagine you're in a team where you feel welcome and your manager is open and vulnerable and your teammates are open and honest with each other. There's a difference. You all of a sudden, you will do everything for them, right? Because you care about the team's well-being. You care about your manager's well-being. Versus being in an environment where like, it feels like a struggle every day. And if somebody were to ask you to like work overtime because there's like some extra work to do, you're like, hell no, you're kind of a dick to me. So I totally do not want to help you out. Versus like, you work in a nice inclusive team, they asked you to help out. Yeah, no problem. I got your back. Different attitude, right? So, create a safe space. Tip number seven. This is related to tip number six. Be kind. So, as I mentioned, I love rock climbing. I actually, every time I go to a new city, I check out different climbing gyms. I checked out the hive in Vancouver, awesome gym. Now, one thing that I've noticed about checking out different gyms across the world is that no matter where you go in the world, rock climbing, it is such a lovely and inclusive and kind environment. Because you'll always find people who are cheering each other on and perfect strangers. I mean, it's such a lovely community. And you see that in the professional circuit as well. So the only professional sport I watch is professional rock climbing. And it's funny because like, all the professional climbers know each other. They're all friends. Even though they come from different countries, they're competitors. And at the end of a competition, you know, the competitors will go and hug the winner and congratulate them. And it's a genuine, genuine, like, you know, congrats, right? It's not fakey-fakey. And so we need to bring some more of this kindness into tech, right? Let's be kind to each other. Being kind to your co-workers, random acts of kindness, whether it's, you know, a thank you or you got donuts for the team if you're working in this, if you're working in person. Like, just little things like that that show you care, right? Like, just like with your friends, you do little things that show you care and doesn't it brighten your day, right? So we need to bring more kindness into software. And finally, tip number eight, don't let pride get the best of you. So as an example, I once worked on a team where I was running an application support team. And the manager of this application, who I reported to, he had this pristine record, right? Always delivering on time and on budget. But under the covers, this thing was running on band-aids and duct tape. It was, like, utter crap. And as the application support team, like, we bore the brunt of it. It was horrible because, like, we're always chasing down, like, the bugs left by the developers. Again, you know, developers take ownership of your code. And so, you know, we were constantly in this, like, state of, like, heightened alert trying to fix these bugs. And so I thought, you know what, like, I can't take this anymore. I'm stressed. My team's stressed, like, so I decided to schedule a meeting with the manager and his counterpart on the business side. And I said to them, all right, like, this thing is broken. Like, we were constantly, like, having to chase down these, these bugs and fix them. And it's, like, always these emergency fixes. Like, this is exhausting. Like, we need to do something about it. And so, you know, I'm not one to just, like, complain and then go away. Like, I gave some suggestions on what we could do to improve it. Holy crap. I seriously thought I was going to lose my job that day. They were so offended because, like, to admit that there was a problem meant to admit that, you know, manager's pristine record was, like, not as pristine as, you know, it was perceived to be. And so, as a result, they obviously didn't improve the product. I got frustrated and ended up leaving. And, you know, they missed out on a perfectly good opportunity to improve the product. Like, yes, it would have meant admitting that there was a problem. And I get it. Like, sometimes when I get feedback, like, my first reaction is, like, screw you, you know nothing. But then, like, at least, like, I try to percolate on it, you know, it never leaves my brain. I'm like, was that person actually saying something useful? Yeah, you know what? They actually had a point. So maybe, like, let's do something about it. And I think we need to take, we need to take a step back. Like, it's perfectly fine to have that visceral reaction when someone's, you know, giving you feedback. But take a minute and absorb that information and see if it's something that's worth acting on. So don't, and don't be like this guy. Don't, like, probably get the better of you because he basically missed out on an opportunity for having an application that actually ran properly. So that is it for our eight tips. Let's do a little quick review. So first, your developers are not commodities. They're not clones of each other. Secondly, POC is not the final product because when you do that, you're introducing technical debt into your work from the get-go. Don't be afraid to reset. Taking a few steps back to move forward is going to save you so much in the long run. Embrace the paradigm shift. Paradigm shifts are hard, right? But let's, let's all, like, we're in this together. This is new for everybody. So making sure that people understand why you're doing the paradigm shift will hopefully make them less and make them more amenable to that shift. Take ownership of your code. Don't just throw your code over the wall when you're done, right? Because then it'll make sure that you're writing better code. Because you're the one who's in charge of, like, troubleshooting and prop. Create a safe space. When you create a safe space, everybody's happy. And it leads into being kind, right? We're kinder to each other when we're in a safe space. And finally, don't let pride get the best of you, because otherwise you lose opportunities for improvement. So if you like what you hear, I have a whole blog post that this talk is based on. That was posted on Leave Dev earlier this year. Also, I blog a lot. I like to do thought leadership pieces and also technical pieces, like super technical deep dive tutorials. So if that's your jam, check it out. You can also see my talks on YouTube if you like how I talk. Now, at the end of all my blog posts and my presentations, I always like to reward my audience with cute pictures of my rats. So this is Phoebe. She's named after the friend's character. She's two years old, and she is very adorable. Rats make awesome pets. I do want to give a shout out to Dolly, our AI overlord, who created the lovely Capybara images that you saw in this presentation. I am just the very skilled prompt engineer, and Dolly created the images. So shout out to AI. I do suggest that you check out the On Call Me Maybe podcast. I'm obviously slightly biased, but do give us a listen and a follow. And if you like what you hear, I would love to connect on all the socials. Until next time, peace live and code. Do we have time for questions? I guess we do right? Questions from anyone? Yeah, it was a little hard trying to figure out the right combination of words to get it to generate a consistency in the images. So yeah, that's really tough, because it's so tempting to follow the new shiny things. I think you have to be very methodical about it. You do have to sit down and start looking at pros and cons of these things. I think if you work in a large organization, it kind of becomes a little bit easier because there's so much red tape around it that it's almost designed for you to not follow the new shiny things. But I think it's a matter of sitting down, making a list, looking at the pros and cons. I think at one point you kind of have to draw a line in the sand as well, because if you're constantly chasing the new shiny things, you're never going to start anything. So yeah. I think in my ideal scenario, I think that to be able to do that, you almost need two separate teams. You've got a team that maintains that product, and then you've got another team that starts developing the new stuff from scratch. The challenge, of course, becomes most companies don't want to fork over the dough for that. So it becomes a near-impossible task, and all I can say is nag people to death, because I do find if you nag the right people enough times, they will start listening to you. And I do feel like part of leadership is knowing who to nag, and how often to nag them. I assigned him to something that was like that he could handle better. Yeah. I mean, it's definitely really tricky, and I think part of it, especially when you're a manager leading people, part of your job is kind of shielding them from the stuff. I used to joke with one of my managers when I was more junior. I'm like, you're a great shit umbrella. We're always shielded from most of the nasty stuff. And I think in doing so and providing that shielding, it kind of puts people more at ease. I think and also I feel like it's one of those things where if you just keep doing it, keep showing them kindness. I don't think there's an overlap. It doesn't have to be one or the other. For example, two jobs ago, I came onto this job where I was managing two teams, and it was 13 people working for me. I had not picked the teams. I inherited them. So it was really scary because one, it was remote. And two, I knew nobody. I was new to the company. They were used to working a certain way. Who was she to tell me what to do? But I tried to develop relationships with each one of my direct reports. And I think one of the important things, especially if you're managing a team, is making sure that you make time for those one-on-ones. It was very draining. My Thursdays were always all one-on-ones. It was extremely draining, but I think it was extremely helpful because it gave me an opportunity to get to know my engineers better. It gave them an opportunity to know me. It built that trust. And even though we all had busy schedules, there were days when I'm like, well, I've got a bunch of work to do. I'd rather not do this one-on-one. But making sure that you carve the time to do that, I think was extremely invaluable because it did develop that relationship of trust. And so no matter how busy we got, like in general, we tried to stick with the schedule. And if we couldn't make it on that day, we'd try to reschedule for another time. Hope that answers your question. Any other questions? Well, cool. Thank you, everyone, for coming. Really appreciate it.