Become an Engineering Leader Everyone Wants to Work With

Hey, in today's video, you can expect to watch a recording of the recent lightning lesson we did together with David Weiss, lead software engineer and also author of Besides Code newsletter. We shared a lot of our personal experiences from growing as engineers and also engineering leaders, and we also shared 6 traits that make an engineering leader someone everyone wants to work with. Let's go straight into it. Hello. Hi everyone.

Hello. How you doing?

Hey, I'm doing great. Please just confirm that you can hear me the right way.

Yeah, I can hear you. Can you hear me?

Awesome. I can hear you as well. Perfect. Okay. Welcome everyone to the session, Become an Engineering Leader Everyone Wants to Work With. I'm always curious on these sessions from which country are you guys calling from. If you can write a message in the chat, just make sure to write your country because that's always very interesting to get to see from which country, you know, and also like which is the most frequent country that you guys are from. Okay, we have from Barcelona, we have from Canada, Andrew, awesome, from the UK, George, Muhammad from the United States, awesome. We have different countries, every person from a different country, also Nigeria. UK, another one from UK, Berlin, Lisbon, Reykjavik, Iceland. Amazing. Iceland is a really nice, nice country. We need to, we need to get there somewhere. What do you think? Sometime. What do you think, David?

Sorry, just coming off mute. Iceland. Yeah, I've never been. I've always wanted to go. So it's kind of a bucket list country for me.

So definitely, definitely. There's a— I think it's called Northern Lights. I think that is very popular in Iceland. Alright, welcome everyone. There's still going to be some more people joining, but we have enabled the waiting room so everyone can join now the meeting immediately. So before we go into the actual session, let's do first an introduction. So I'm going to go first and then also David is going to introduce himself. So my name is Gregor Ojstersek. I'm a fractional CTO advisor, consultant, and also coach and mentor. I have over 12 years of experience, both an engineer and also engineering leader. In my full-time career, I grew from engineer to senior software engineer, team lead, engineering manager, head of engineering, VP of engineering, and then CTO. I also write a weekly newsletter, it's called Engineering Leadership, where I help people or where I help engineers to become great engineering leaders, and I also teach a course as well. David, over to you.

Hey everyone, I'm David Weiss. It's great to be here with all of you. I help software engineers lead and grow by elevating their people skills and personal brand. I'm a lead software engineer by day, and then nights and weekends, I'm a solopreneur. I'm a writer and content creator for LinkedIn as well. Gregor and I got connected last year, and on Substack and some other places like that. I'm the author of Besides Code on Substack. That's my newsletter there. So yeah, excited to be with all of you today.

Yeah, definitely check out David on LinkedIn. He's regularly doing some cool projects. So Yeah, definitely, definitely check that out and also his newsletter as well. Okay, so a quick agenda. What are we going to be talking about today? Obviously, we are doing an introduction that is already in progress. Then I'll be sharing a quick story from my experience growing from engineer to the first-time team lead. And then we'll be jumping straight into 6 traits that make an engineering leader a great person to work with. And then at the end of the session, you guys will also receive a gift, basically a bonus, which is going to, going to be an infographic on 8 signs that you have a great manager. So there's, there's going to be 8 different signs on how you can identify a great manager. And then of course, we also have a Q&A at the end. So make sure to share any questions you have in the chat. And the reason why you should do this is also because we're also going to be giving away a free t-shirt to one of the person who is going to be asking a question. So make sure to post a question on chat and we will, we will go through the questions at the end. And also, if you, if you see a great question like from that someone asks a great question, you can also upvote it in the chat because you know that that's how we will know that that question needs to get prioritized. So yeah, make sure to, make sure to do that. Any question you guys have, and at the end of the session we will also pick one person to get a free t-shirt as well. Okay, so let's start with a quick story. And obviously many of you guys here are either engineers or already engineering leaders, and you may know how hard it is to do a transition going from engineer to leader. And one of the things that I used to believe, and now I'm remembering this, is feeling like a little bit, you know, how could I actually believe this? But I believe that in order to be a leader, you needed to do everything like yourself. You needed to, you know, take on the hardest tasks. You needed to finish the most tasks as well. And I tried to do that when I grew from senior software engineer to team lead. I tried to finish the most tasks. I tried to be the best manager. I tried to have, you know, complete control of all the projects. And I tried to work on the weekends as well. Well, this may work for a certain period of time, but it doesn't really work for longer, long periods. So yeah, I was close to burning out and that really didn't, didn't work well for me. So I needed— I was forced to make a change. I was forced to make a mindset shift and delegate more and helping more my team, trusting my team more. I was forced to make this decision. And after I did that, I saw that things started to turn to be a lot better after that. You know, being an engineering leader is not about how much individual tasks are you finishing, but it's all about how many projects, the success of the projects and the success of your team. That is, that is what you are judged by as an engineering leader. So it's all about making others around you better. This is one of the important things to remember. And, you know, it's really important to know and realize that when, when you are in a lead role,. And if you do that, you know, you're automatically going to be a great engineering leader to work with, you know, your manager, the leadership stakeholders, and your team, and you also, your peers are going to be, you know, are going to be happy with the way you work if you do that. Yeah, so that is, that is a quick introduction to what are we going to be, to be going through today. So obviously, David, we could talk about this for hours. This is a topic that, you know, is very broad, and we could, we could We could potentially extend this session to be 2 hours, 3 hours, and we wouldn't get to the bottom of all the traits and every particular details that make a great engineering leader. But yeah, so what we did together with David, we picked— each of us picked 3 of the traits that we want to point out that make you a great engineering leader to work with. So yeah, David, over to you with the first one.

Awesome. Thanks so much, Gregor. Yeah, you know, I wanted to kind of circle back to what Gregor just said about that mindset shift. For me, when I was transitioning from individual contributor to leader, yeah, I had to do that exact same thing, really take on that mindset shift and realize that it's not just about, you know, the code I write, the features I work on, my individual efforts, but it's really about the team as a whole, right? And what the projects that we're trying to work through, the goals that we're trying to reach. And I think one of the best ways you can be a team player is to put your team's success first, right? You have to kind of take a step back from the work that you're normally doing as an individual contributor, and you have to look at the team and think, okay, you know, what can I do today to unblock my, you know, fellow teammates? Is somebody stuck with something and they need some help. Maybe I need to, you know, schedule a meeting with them. Maybe there's a leader ask, a senior leader asking about statuses on projects and I need to kind of go in and look at the board and, you know, take stock of things and get back to them, right? Maybe there's this really nasty bug that has been lingering in the backlog or some tasks that the other developers don't really want to take on. And as a leader, being a team player means, you know, doing those things, right? And kind of putting that team success first. The other thing I want to mention is it's super important as a team player to just check in on your teammates on a regular basis, right? Whether that's through one-on-ones or a couple minutes at the beginning of a meeting, just being able to see how they're doing with their tasks and their tickets, the progress they're making on their work, not only both like professionally but also personally. Ask how they're doing and, you know, if they went on a recent trip with their family, ask how the trip was, ask how their weekend was on a Monday morning, right? Because, you know, as a team player, when you can, you know, kind of check in on your team and make sure that they're all doing well and they're supported, then you can help support the team even better, right? And then lastly, I'll say, you know, it's really important to learn and grow together as a team, right? You want to avoid knowledge silos. You want to avoid, you know, only one person kind of knowing how to do something and not the rest of the team, right? So this is a great opportunity as a leader to to, you know, really have that time in meetings and even in Teams channels and Slack channels, right? Have those opportunities to share what you're learning. You know, if somebody kind of uncovers a new feature within a specific library or framework, have that person talk a little bit about it, share some code so that everybody can benefit from that, right? And lastly, you know, it's really important to grow as a team together. And, you know, if somebody, if one engineer makes a mistake or if you miss a deadline on a project, it's really the whole team that is responsible for that, right? It's not just one person or one particular task, right? You think of a sports game, right? And sometimes, you know, the game is lost in the last play by one player. But if you really rewind and you think about the whole game, it's really the whole team effort, right, that resulted in that win or that loss. So super important to really learn and grow together as a team. And I think these are some ways that you can be a successful team player. On your team.

Yeah, well said. You know what I like to say is if you can't go on a 2-week vacation and things are not going to be normal, then you're doing something incorrectly, right? So you're either not sharing enough knowledge with everyone or you're keeping knowledge to yourself or maybe you're not growing and maybe you're not helping your team to progress, right? So as a leader, you want to create leaders and you want to grow people inside your team, right? And if you can't go on vacation, on a 2-week vacation, you're probably going to be burning out soon as well because you're trying to handle so many different things yourself and you're trying to be in all different places trying to handle things. And maybe like also maybe you are the go-to for confirming things like for every specific decision that you and your team is making and everyone is waiting for you to confirm that decision, right? But instead you want to delegate that responsibility and ownership that, you know, your team can make decisions even if you are not there. Yeah, very important. I like to say also that great teams build great software, and you know, you made that connection with team sports and also with, you know, any kind of sports teams. It's similar, very similar in software development. You know, we have different roles. We have QA engineers, we have frontend engineers, we have backend engineers, we have engineering leaders, we have managers, we have staff engineers, we have architects, and so on. Everyone has a certain role, right? So with what kind of role are you playing, right? And as an engineering leader, you are more a coach than actually a player. You can be a player coach, but you should be the one who is actually making people around you better, everyone around you better. So yeah, very, very important to have that in mind. Do you want to add something to it, David, or we go to the next one?

Yeah, I mean, the last thing I'll say, just going back to something you said about, you know, making sure that things are documented, that people know what's going on, status, you know, the status of projects and tasks are visible, you know, transparency and visibility is super important on a team, right? Because like you said, Gregor, you know, you want to be able to take PTO, take vacation time, people get sick, there's family emergencies and things like that that happen sometimes. So You know, being very clear and visible as to the current status of projects and tasks, whether that's in Jira or some other tool like that, is super important. Also a very strong documentation process on your team and, you know, ingraining that into the culture of the team so that, you know, knowledge is there if somebody needs to find it, right? It's not like, oh, well, I don't know how to set up my dev environment because Engineer X is out on vacation. No, it's in a document. Everybody can go there and figure figure it out, and you can get help. It's not just, you know, the team is not going to suffer just because one person is not there.

So yeah, exactly, documentation is really huge. And one of the things I like to say, like, if you guys may know the concept of a go-to person, like if you're the go-to person for a certain domain or a certain project or a certain technology, you should not be the one who is actually hoarding the knowledge to yourself. But the concept is that you are making sure that everyone can easily get onboarded to the project, to the technology, to the framework, to the domain. And you are creating like the environment where everyone can get started with it in the as easy way as possible. That means documentation, FAQ documents, any kind of tutorials, any kind of learning sessions, stuff like that. And that's really what kind of like That's really valuable for any team organization if you have that in mind. Awesome. By the way, any questions, anything you guys have in mind, just put it in the chat anytime. We will have a Q&A session after we are finished with our top traits. Okay, so let's go to the next one. Yeah, they know how to manage both up, down, and sideways the right way. Yeah, this is, this is very important to keep in mind because maybe, you know, we can, we can mistaken, uh, for engineering leader that is great, being great to work with, we can mistaken that as just being a person that is, that is great, uh, managing down. That means managing their team. But, you know, there's a lot more to being an engineering leader than just managing your team. And in order to be considered a great engineering leader, you need to be able to manage both your manager the stakeholders, leadership, and also, you know, your team as well, and obviously your peers, other, for example, team leads, engineering managers, product managers, any kind of other people, let's say also maybe compliance managers, finance, finance directors, and so on. You need to be focusing on having good working relationships across the organization. It's not only about your team because if you focus, if you're not focusing on one on one thing, and if you neglect the one part, then the other parts are going to be, unfortunately, be less great. So for example, if you don't manage your manager, the leadership, and the stakeholders correctly, then your team is going to be feeling the pain as well, because there's going to be a problem with the project, there's going to be the problem with the deadlines, there's going to be a problem with aligning business and technology. There's going to be misalignment between leadership stakeholders. There's going to be misalignment with the peers, with other teams. For example, if there's a certain task that is dependent on some other team, if, for example, you as an engineering leader, you have— you don't have a good relationship with the team lead of another team, it will be much harder for your team to be able to get that finished in the time that you would be able to finish your specific project. So very, very, very important to understand that. And I made a lot of mistakes, especially like as a first-time manager, as a first-time team lead, as a first-time engineering manager as well. I tried to, you know, make so many changes around different places. I tried to, you know, even make changes on the things I don't even have control of. And also I tried to provide suggestions to many different departments, to many different things, because I thought that, you know, as a manager, as an engineering leader, you can just change a lot of things around you. But instead, you should be looking to build good relationships with everyone. For example, like one of the mistakes I made was I was so passionate about changing a certain thing. I sent an email to my skip-level manager and also to a lot of others who were involved with that particular change. And the reason why I did that was that I told my manager a couple of times that this particular thing would be great to do. But unfortunately, there wasn't like a lot of initiative from my manager to do that. So I decided to send an email to my skip level and a lot of other managers, a lot of other people involved in that specific part. And that didn't go so well with my manager. My manager was furious I did that. And basically because of that, I was able to, I'm not able, but the working relationship suffered because of it. And because of that, then also a lot of future decisions, a lot of future things went sideways because I didn't have such a good working relationship with my manager. The key, the key things here is, and also like my top 3 tips, is to build good relationships as much as possible and focus on good communication. And also, you know, try to proactively find out the problems that maybe your manager, maybe people around you are facing, and try to put your genuine efforts to resolve them. For example, like one of the great things that you can do as an engineering leader is if maybe one team that has a certain problem, you put effort in trying to resolve that problem and then they will do the same thing for you as well. So it always, it always works like that. If you do something great for someone, that other person is going to do something great for you as well. And also, you know, with your team, you want to be transparent, you want to give feedback, and you also want to ask for help when you need it. You want to ask for help like your manager, other people, you know, your peers and so on. And you can only do that if you're, if you're able to build good relationships with, with everyone. All right. David, you want to add something to this?

Yeah, I mean, I think it's just very well said, Gregor, and I agree with you about, you know, managing up and just kind of, you know, having a really strong relationship with your manager and being honest and open with them. You know, I think your manager is very likely going to be, you know, making bigger decisions than you. They're going to have more visibility into you know, what's going on in the org and your team, and they're going to be responsible for those decisions, right? So if something needs to improve or get better on your team and that decision needs to come from your manager, you need to be open and honest with them, talk to them about it, right? So yeah, it's certainly not just about managing down, but also up as well, like you said, Gregor.

All right, awesome. Let's go to the next one. And that is— yeah, go ahead, David.

All right, so yeah, when I look back in my almost 20-year career in tech and I think about the really great managers I had, the leaders I worked with, one thing that they all had in common was they kind of avoided gossip and drama. And I think it's pretty normal when you work at a company, no matter the size, there's going to have— those conversations are going to work their way into meetings and into chats and things like that. You know, people might complain about a change in a company policy or a roadmap change, or they might say, you know, oh, did you hear what this person said or this person did? And really, I think when you harp on gossip and drama, that it promotes stress and anxiety on the team, right? And it makes people worried about their job and, you know, just not confident in what they're doing. So the great leaders that I've worked with and what I try and do myself is really foster that positive work environment by not really paying attention to that and not letting that kind of enter my, you know, my sphere, right? Another important thing that I believe in is, is really just encouraging your team on small wins and, you know, little victories that they've made, right? Like a lot of times managers and leaders do a great job at at giving kudos and praise when a project is finished. But what happens if a project takes several months or even a quarter to complete, right? Like you're going a long time without giving that positive reinforcement. So even just saying, you know, hey, great job on this ticket or this task, or leaving positive feedback on a code review is a great example of doing this as well. Or just, you know, just a small like encouraging message at the beginning of a meeting or at the end of a meeting, right? I think it goes a long way. It helps show your team that you're paying attention to what they're doing and that you care about the work that they're doing and that the value that they're adding to that particular project. And then, you know, the other thing I would say is just, yeah, finding ways to spread positivity, you know, like just showing up to meetings, you know, with your camera on if you're okay with that, smiling, asking people how they're doing, you know, asking how their PTO or their vacation time was or their weekend was. You know, there's, there's so much, there's so much like just negativity at jobs sometimes and in personal lives and in the world, right? There's a lot of things going on in the world that are very troubling and are kind of hard to process. So anytime you can be a little positive, be a little encouraging at work, I think it just goes such a long way. And, you know, like like, like, uh, this image here that Gregor Ojstersek put of the glass half full, right? I mean, we, we, we have the, um, you know, we can make that decision to be negative and look at the glass as half empty, or we can look at it as glass, as half full, and really focus on that positivity and, um, and, and really try and foster that work environment. And I'm telling you, I, I've been in on teams where leaders have done that, and it is just filled me with so much optimism and inspiration to work harder and to like communicate better and to collaborate more effectively. All because, you know, there was a leader on the team who, you know, decided to kind of look at that glass as half full. So yeah, that's what I have to say about that. Gregor, do you want to add anything about this?

Yeah, yeah, awesome, awesome. You said a lot of great stuff here. I would just like to add, you know, one of my first student jobs I was working, I really had one of the managers who was always in a bad mood, and I was blamed for something every day. Every day was something either going wrong or something I didn't do correctly or something was, you know, not the way it should be. And, you know, a bad experience is what what gives you benefits when actually there's a good experience, right? What actually shows you what actually a good experience looks like. So you learn a lot when you have like a manager who is not like that, who is, you know, very the other way around. And I still remember this like yesterday, how it was, you know, every day I felt like, okay, I'm gonna be fired, I'm gonna be let go. And I'm not sure tomorrow is going to be, you know, the next day for me coming into the office. So, yeah, luckily after a month I've gotten a new position, a new student job, which was really, really great for me. It was really a big difference when I had like a really good mentor who helped me a lot in progressing as a software engineer. So that was a huge, huge change. And, you know, also as I grew in my career, I had like a lot of different managers. Some were really, really amazing and some were like very similar to what I had as in my student job. And it's hard to navigate that case when that happens, when you have that kind of manager, because the whole team feels that. But the best thing you can do is to manage up as best as possible and try to make it, to try to make it, you know, because You can't control the way they operate and the way they are, right? But you can make the most out of it within what you have in your control, right? So you can help them as much as possible. You can provide potential, you know, help. You can potentially find some problems, some issues they might be facing, and you help resolve them. Maybe, maybe they will become different after some time. But yeah, it's a big difference if you have like a bad manager versus a good manager. And so on. Yeah, awesome. And also a good, good comment from Muhammad. Yeah, you know, sensing problems proactively is one of the biggest, biggest things as an engineering leader because a lot of challenges we are facing are ambiguous. A lot of things are something that we will not be tasked, but we need to find the challenges, we need to find the problems ourselves and then propose solutions to such problems. Okay, let's go to the next one, which is blaming. Obviously, you know, Blaming is something that probably many of us have done in the past, but yeah, good engineering leaders, they don't blame, rather collectively look to improve things. And blaming is really one of the worst things you can do because, you know, it decreases motivation, psychological safety, and also, you know, the overall culture inside a team is a lot worse because of it. Growing in my career as an engineer and also engineering leader, I found myself, I, you know, I'm a person that likes to get, I become very passionate about projects, about the work that I'm doing. And I naturally found myself trying to blame a certain person or a certain team to make a certain mistake. You know, running a git blame is so very easy and you can find a person who is responsible for the most changes in that particular file. But what I wasn't aware is that it creates more issues than actually solutions. Instead of finding out who is actually responsible for that particular thing, you could already solve this issue if you would focus on actually solving it, right? So yeah, and also there's no such thing as one person mistake. And there's no such thing as just one person making a mistake, because in software development process, we normally have a code review process, we have a QA process, we have tests, we have user acceptance testing. There's like so many people who are part of the process. And what I like to say is if someone makes a mistake, for example, like deploying a release which is going to break something, or maybe dumping the full database, maybe deleting the full table and so on. It's a problem somewhere in the process. Maybe there were not enough constraints for a certain person to get the credentials to get to the production database. Maybe there's been a code review process that has not been good enough. Maybe the user acceptance testing has not been good enough and so on. So anytime there's a certain problem, there's a certain mistake, there's a problem inside a process and we should never look to blame an individual for it.. It should be always as part of the team and how can we improve as a team to make it, to make it better. That's, that's where like blameless retrospectives are really, really great thing. Incident retrospectives, they need to be also blameless and so on. Those are very, very important things to do. And yeah, remember, don't, don't try to find that person who is responsible because it will only decrease their motivation, their drive. They will be less prone to making mistakes. They will be less, they will be just, you know, in the safe zone. They will, they will be inside their comfort zone, they will be afraid of making mistakes, which is, which is a big, big problem. So, um, yeah, um, Alfredo, yes, this call is being recorded, so the record, the record, the recording is going to be also shared after the session as well. Um, yeah, Ronnie mentioned when you run git blame and you're the only one who wrote that hacky code. Yeah, exactly, it happened, it happened a few times, you know, because after, after you get get, uh, maybe you forget about that, that you, you have actually written a piece of code maybe like 1 year, 2 years ago, and then you get back to it and you see it like, okay, what, what is that shitty code, right? Who wrote that shitty code? But you see that actually it's been, it's been you. So it happens. It happened to me as well. Um, so, um, yeah, David, you wanna, you wanna add something to this?

Yeah, no, I just really agree, Gregor, with what you were saying as far as focusing on the solution and figuring out what, you know, what the problem is and getting things back to status quo and normal, right? So especially if there's, you know, something major happened with the database or the production environment is down, right? Like focusing on blaming a person and, you know, kind of like scolding them in public is not going to help you solve that solution faster. So I think just getting all hands on deck to solve the current issue and problem is is really like top of mind what you should be doing. And to Aditya's question about balancing blamelessness and accountability, I think certainly if you can certainly talk to that person afterwards in a one-on-one setting. If it's a major kind of mistake that was made and you want to make sure that that person is learning from it and understands maybe the severity of it, you can certainly have that conversation in private and, you know, talk to them. But yeah, public blame is really detrimental to the team, like you said, Gregor.

Yeah, I like to say that giving feedback is very important as an engineering leader. You should give feedback very, very quickly, especially like if it's feedback that is regarding behavior or any kind of feedback that is very crucial. And yeah, you want to give it privately, as David mentioned. Any kind of public feedback is really, really Feedback for improvements I'm talking about is really problematic. And accountability happens on one-to-one meetings. And also you can ask that person to jump on a call with you and you give them feedback. Hey, this is something that, you know, this is something that could be better. Maybe think about it, do it differently in that particular way. And so when you want to give feedback so they can actually learn something from it and so on. And I also recommend, you know, to give feedback on every one-to-one meeting. That is something that is that worked for me very, very well. So if there's something that you see that someone can improve in certain thing, you want to give that feedback because it's not only about improving, it's also about how they are doing in their role. Because the biggest problem that I see with a lot of people is they may be doing really great in their roles, but they actually don't know that they are doing a great, great job in their roles. So if you're giving them feedback that they're doing a great job, then they will be actually knowing that. And yeah, this is very, very crucial. Okay, let's go to the next one. They coach and mentor teammates. Go ahead, David.

Yeah, you know, I think back to, you know, several years ago when I was making the transition from individual contributor to leader. And, you know, I started having regular one-on-ones with my direct teammates and then some other junior developers that were were, you know, in the engineering org. Nobody asked me to do this. My manager didn't ask me. It wasn't in my job description. It was just something that I wanted to do because, you know, I knew the importance of one-on-ones and I knew that if I was gonna grow into a team lead or an engineering manager role someday, I would have to be doing these one-on-ones either with teammates or with direct reports. And what I discovered is it's just, it's such a wonderful opportunity to coach and mentor your teammates when you have that dedicated one-on-one time with them. And, you know, it's really like, it's just a, it's a very positive and kind of really bright signal to that person that you value their time and that you want to help them and you want to support them, right? The other thing I found with one-on-ones and other opportunities to talk to people is just the importance of teaching soft skills, you know, I think I think when it comes to technical skills, learning how to code, improving your technical skills, you know, people can do that on their own time. They can do that through courses, through books and other things like that. But being able to coach and mentor your teammates, you can really have a big impact on teaching them soft skills, how to communicate better in meetings, how to collaborate effectively with, you know, maybe designers, product managers, how to give feedback to their teammates, to their manager, maybe how to, the correct way to kind kind of, or the ideal way to do code reviews and how you should be kind of handling that as well. So soft skills can be just a great way, a great thing to include in kind of your one-on-ones and something to focus on to help your teammates out. And then the other thing I want to say is, you know, when I look back on some of the more memorable one-on-ones and meetings I've had with leaders and managers they've shared personal stories with me. You know, they've talked about not only their wins and their successes in their career, but they've talked about mistakes they've made, failures they've had. They've opened themselves up and they've, you know, been a little bit vulnerable in front of me and said, hey, at one point at this job, I faced this obstacle. I wasn't sure what to do and I got help. Or, you know, I was working on some task. I had no idea what to do., and, you know, eventually I figured it out, or I did this to, to get unblocked, right? And so, you know, you can, you can learn about leadership in books and courses and, and, and things like that. But, you know, you can also learn about it through these personal stories and when you, when you meet with other leaders, right? And I mean, that's, that's really what Gregor and I are doing today with all of you is, you know, we're sharing of our personal stories with you and different times during our career where we've learned and where we've grown, right? So don't underestimate, you know, the power of storytelling and how impactful that can be as a coach and as a mentor to your teammates. You know, just like I said, opening up a little bit and sharing about things that you maybe struggled with earlier on in your career or, you know, mistakes you made made, not only is that going to teach, you know, your teammates, but it's also going to strengthen that relationship and that bond you have with them, right? Because they're going to realize like, wow, like, you know, Gregor Ojstersek is being, you know, very vulnerable here. They're opening up, they're sharing something personal, and that, that must mean they really want to help me and they really trust me, right? So don't underestimate that. And, and, and yeah, I think, you know, really just strong leaders find different ways to coach and mentor their teammates, whether that's through one-on-ones or through meetings or through, you know, delegating responsibilities. And, you know, it's a really great way to lead a team by thinking about how you can uplevel their skills.

Yeah, you mentioned a lot of great stuff. And yeah, I still remember like when I was a senior software engineer and I had regular one-to-ones with my manager, and it was more talk about status reports, status about certain projects, than actually about how could I, you know, improve in my career, or how can I grow as an engineer and also as a leader. And now thinking back, you know, it was also like part of me was also the mistake on my side, because I would need to kind of like more move the discussion more into the direction of how could I, you know, be growing more, how could I get better as an engineer, and kind of proactively find ways to, you know, to get coaching and mentorship, especially if you have like a manager that is not like that, right? But there's been a whole big difference when I became like a team lead and also engineering manager, when I got a different manager and that, that manager like offered me a lot of advice, personal experiences. As you mentioned, David, that's also like what I like to do as well. Personal experience is something that is, that is the most valuable, I think, you know. But when you, when you say to someone, hey, this is what has worked for me, this is something that didn't work for me, this is something that I would do in this, this particular scenario because this, this reason, this particular reason, you just, you, you understand the mindset behind it a lot better. And this is invaluable. And then also after that, my manager left, I got a different manager who was again a totally different person who was just giving me, you know, what I need to do over email and we actually didn't get to talk anything about any kind of, you know, career progression, any kind of career development and so on. So yeah, I think, you know, if you have a great manager you should You should, you should treat them well and you should, you should be happy with it. I don't think there's like, there's not a lot of really, really great managers, but if you have a great manager, make sure to be, to be grateful for them. We have some questions we will answer. We will answer them in our Q&A session shortly, but we want to make sure we get through the last, the last, the last trade., which is to empower and uplift the team. Obviously, as you could notice from my story in the beginning, I didn't delegate and I didn't uplift the team when I first became a team lead. I was rather focusing more on solving things myself, which got me close to burning out, right? But make sure to don't make this mistake if you are in that position yourself. You need to understand that as an engineering leader, you are a multiplier for others. Think of it like that. If you make 5 people 20% better, you're delivering so much more value than if you're getting 20% better in coding. It's exponentially so much bigger value. And what— and that's also scalable. What if you help like 10 people, 15 people, 20 people, 30 people, 50 people to get 20% better? This is crazy amount of value to any team, to any organization, to any— to the whole business, to the whole company. Company. So always have this in mind. Don't, don't focus just on code first, but focus on business first and people first. How can you improve the business and how can you improve the people around you? Uh, good engineering leaders know that they can't do everything themselves, and you know, you can't be included in all the fine details as well. You need to pick, pick up your battles. You need to pick up where do you delegate versus where do you take more ownership.. And my rule of thumb is to— I try to delegate like less important decisions to others. And when it's like really important for the business, for the, for the project and so on, I step in and I try to be a lot more involved. But when you delegate ownership to people, people are going to be much more motivated and driven to actually solve that particular challenge, solve that particular problem in a lot better way. So don't, don't forget that you can be positively surprised by how motivated, driven, and how creative those solutions are going to be. Be when you trust your people, you trust your team, and you give ownership, you delegate ownership. You don't just delegate tasks, but you actually delegate a certain problem, a certain challenge, and then you let your team or specific person to find the best solution to it. All right, anything to add, David?

No, nothing to add here. Thanks so much.

Awesome. All right, so we don't want to leave you empty-handed with anything, so what we, what we prepared for you guys is, uh, you guys can download the 8 Signs That You Have a Great Manager infographic. So this is kind of like a quick checklist to see what kind of manager, uh, you have. And, uh, this is, this is free, free for everyone who is attending this session. Um, so you have a 100% discount code applied, applied. So you just only need to add it to, to, uh, the basket, and then just you will be getting a downloadable available after that. So you have a link in the chat, and, uh, yeah, make sure to, to use it, uh, and then also look, look at it whenever, whenever you feel like it. Okay, let's get back to, let's get back to, to the slides. So yeah, key, key takeaways, uh, we, we, we went over 6 of the main, uh, traits, uh, that we believe that make great engineering leaders to be, to be great people to work with. Obviously, we could talk about it for, for hours We also have some questions to, to answer. We will do that shortly. But yeah, I want to make sure to also, if anyone would like to learn more, I teach a course. It's called Senior Engineer to Lead, Grow and Thrive in the Role, where we go through different, different modules on how to be a great, great engineering leader, how to become a great engineer in order to grow to become also a great engineering leader. Leader, and so on. We go through models such as, you know, defining your career path, how to be a go-to person, how to be, how to build good relationships inside your team. Then we also talk about how to thrive in the lead role as well. So everyone attending this session, you guys are getting 25% off. And yeah, we will also, I will also share the link to the, to the, to the, to the course after this session. Okay. Thanks everyone for joining this session. We also have some time for Q&A, and also we need to pick a winner for the t-shirt. So let me see who is, who was the first one. Okay. What do you think, David? We give the t-shirt to Aditya Kotla. He was the first person asking the question, how do we balance blamelessness and accountability at the same time?

Yeah, sounds good.

Awesome. So Aditya, just make sure to add your LinkedIn LinkedIn in chat. So I will add you and I will contact you and we will give, we will exchange all the information. So yeah, just make sure you send your LinkedIn in the chat and I will connect with you later and you'll get a free t-shirt. Okay, you see any question? I need to get over all of the questions. If your manager leader is not providing mentorship for your career when you ask, you need to find someone. Uh, it's not providing mentorship for your career when you ask. You need to find— yeah, you need to normally find someone who is, uh, who is going to give the right mentorship for you. That is, that is very important. You want to find mentors. That was also like one of the mistakes I did when I grew, when I was growing in my career as an engineer, is I was trying to do everything myself. I was trying to learning everything myself, and instead I should be looking for mentorship. That is, that is very important. It's always better for the manager, leader to take the initiative to talk about career growth and progression because a lot of times a team member might not be as open and comfortable. Yes, that's very true. It's important to set a tone and make them comfortable going forward, which is way more effective. Yeah, I couldn't agree more. You want to create an environment where like your report is, can open freely, can fully talk about anything.

Everything.

That is, that is very, very crucial. Um, thanks for an insightful session. Yeah, thanks a lot, Subha, for, for being here. Um, and, uh, expensive for me being in India. Okay, I think you mentioned, uh, for, for the course, um, we can, we can— please, uh, Subha, make sure to, to send me an email. Send me an email and we can go over, uh,, we can go over the email. So make sure to send me an email, uh, and yeah, let's also leave 5-star reviews on the 8Science. Appreciate it, Lucius. Appreciate it. Appreciate that. Um, next we have a question from Mohammed. With the seismic changes in the industry, the focus on reducing management layers, how do you see the role of the engineering leader evolving? You want to answer this one, David?

Um, yeah, I Paul, do you have any thoughts on it? I can chime in.

Yeah, yeah, yeah. I think, you know, there's many, there's many different, uh, things that I'm seeing across, across different companies. Especially, you guys know about the, the things that Amazon is doing. Amazon has, has decreased the amount of managerial roles. So similar thing also Meta did, and similar things also some other big tech companies are trying to do. And I'm hearing this from some other people as well. But that doesn't mean that, that managers are going to be less needed. That, that means that the role of a manager is evolving a little bit differently. And how I see it, the way things are going to be going in the future, is the role of especially like staff engineers, architects, and managers is going to get a lot more closer together. And, um, there's going to be— what I expect to be happening is that, for example, like middle managers, like engineering managers, team leads They would be expected to be able to take on a staff engineer role if needed, and also staff engineer roles, people that are staff engineers would be then expected to also be able to take on managerial roles if needed. I think that is where things are going, and more like in the way that there's going to be less closely defined like roles inside a team, but more like what is actually needed, what is the most needed and what is the most pressing thing for the team. Team. Okay, let's take care of that particular thing. Okay, we need more builders, we need more people that are going to get stuff done. Okay, let's do that. Or maybe we need more people that are going to be focusing on communicating with other teams, with stakeholders, with the leadership team. Okay, we need more people to do that. So I think, you know, staying technical is really, really important as a manager. And that's also what I recommend to a lot of managers because you're having career options reality because of it. And that's what I believe also is going to be in the future, is kind of like the roles getting closer together. And with tools getting better, better, and better, I think there's going to be less need for having like so many different, you know, so many different types of people working, for example, in an engineering team.

Yeah, those are great points, Gregor. And I mean, I think it's always good to really just be aware of you know, what the team needs, what the company needs and how you can support that at any time, right? I also think, you know, with AI and with all these like automated tools coming out now, I mean, you know, coding is becoming less and less of like a, you know, even a necessary or required skill, right? Because a lot of engineers and teams are starting to use, you know, AI for code and things like that. But I think at the end of the day, you know, software engineering is still a very human, you know, process. And especially if you're working at an organization or a company that, you know, has a product or has a SaaS app or software that other humans are using, real users are using, you know, you're gonna need, you're gonna need leaders that are gonna be able to keep those teams together, you know, and work effectively together, whether that's engineers and designers or engineers and product managers. And also being able to like, you know, focus on user feedback and really understand the importance of, you know, just kind of connecting with other real users to get that valuable feedback for your product, for your app, for your business, right? So yes, you know, AI is here and it looks like it's here to stay and there's a lot of automated tools, there's a lot of ways to write code easier, but software engineering is still very much a human operation, right? And so being able to find those ways for you to, you know, work on those human tasks and make sure that the team is still functioning and thriving, I think is still important.

Yeah, I think the way things are going, especially with AI, there are two 2 different things that I like to recommend to people is the one is focus on developing your human-related skills, and then the second one is focus on developing your problem-solving skills. And that is, those are the 2 categories that are going to be more and more important. So what I mean about human-related skills is good communication, empathy, being a great, you know, being a team player, all of the things we talked about today. Those are all the great things that are going to make you a better human being and a great person to work with, better team player, because that is going to be more and more important when things are becoming more and more robotic around us. And then the second thing is, you know, problem-solving skills. Problem-solving skills is, you know, you want to be resourceful, you want to have a good network of people who you can talk to about certain things. You want to use any kind of tools that make you more productive, any kind of AI tools that are going to make you more productive. That's very important. And so when you want to also understand fundamentals well, because it's going to be hard for you to develop anything meaningful without understanding good fundamentals. Because also the thing what I see happening is like new junior engineers coming to the industry, they're having a lot more shallow knowledge of engineering fundamentals than, for example, people coming to the industry like 10 years ago, 15 years ago, maybe, you know, 20 years ago, people were also like having a lot better fundamentals than people 10 years ago. And that's also going to be getting worse and worse as time goes on. So if you're a person that has good engineering fundamentals, great person to work with, you know, you're also a leader, you can lead projects, you're a good problem solver, you can take on an ambiguous problem and find the best solution to it. There's going to be unlimited amount of opportunities for you. So yeah, the, the beauty the future is bright for people that are not only going to be focusing on the code, but also on actually solving the problems for the business, for the people around you, making people around you better, and also being a great person to work with. That's very, very important. Okay, I think we answered all of the questions. And yeah, Mohammed, thank you. Thank you for joining. Yeah, thanks everyone. Everyone for joining. We went a little bit over time. It was meant to be 30 minutes, but yeah, happy, happy to— I mean, the time flies when we're talking about engineering and engineering leadership topics. Uh, you know, 1 hour, 1 hour went through like it was 20 minutes. But, um, yeah, thanks everyone for joining. Uh, David, you want to say anything, uh, to, to everyone?

Uh, no, thank you, Gregor, for having me. It's been a pleasure. Um, great to talk about these topics and, and meet some new people in the world. I still read your newsletter all the time, love it. Hope everybody checks that out. And again, mine is on Substack as well, Besides Code. And yeah, please connect with Gregor and I on LinkedIn. Shoot us a message anytime if you want to chat. And yeah, great to be here. And please check out Gregor's upcoming course because if you learned anything today, then I'm sure you're gonna learn a lot more in that.

So really, really appreciate that, David. And yeah, thanks, appreciate the kind words. Yeah, thanks everyone for joining. Have a great rest of the day. And yeah, thanks, thanks once again.