My Mistakes and Advice Leading Engineering Teams

Gregor Ojstersek shares mistakes from his rise through engineering leadership: as a team lead, over-contributing and becoming a bottleneck; as a manager, procrastinating decisions and over-protecting teams; as a director, neglecting executive relationships and trying to fix everything at once. He advises delegation, faster decisions, and aligning with business goals at each level.
Chapters
There's a big difference between leading 1 versus 3 versus 5 engineering teams. The shift feels like going from player to coach, then to strategist. If you don't know me yet, my name is Gregor Ojstersek and I am the founder of Engineering Leadership newsletter. And in this video, I'll be sharing my mistakes and also my advice if you start leading 1, 3, or 5+ engineering teams. Now let's get straight into today's topic. Okay. Let's first start by going through a little bit about my career. So I started as a software engineer like a lot of you guys listening, and then I, over a couple of years, I grew to become a senior software engineer. Then I became a team lead leading one engineering team. After 6 months, I grew to become engineering manager. That's when I started leading 3 engineering teams. After a little bit more than a year, I became head of engineering. That's where I led 5+ teams. I think it was around 7 at the most when I also became an interim CTO, and that it was combined direct— directly and indirectly, it was combined 35 direct and indirect reports. And then I became VP of engineering and then also CTO. So I'll be sharing, uh, my real-world experience, uh, with you with you today and also my advice on what to do if I would, you know, roll back the time. Of course, that's not possible. Okay, so let's first start with leading one team. So let's assume that you have moved from, you know, being an individual contributor, from senior software engineer to team lead, and you're leading a cross-functional team of of software engineers. You also have a QA. There's also a product manager inside a team. You have potentially a combination of front-end and back-end developers inside a team, and so on. So, um, that, that's been the same kind of a structure of the team that I, that I managed as well when I first became a team lead. And the 3 mistakes I made here, uh, the first one is you know, growing from a senior software engineer then to team lead, I found it— I found myself, you know, trying to manage so many different things and also try to be the best, you know, individual contributor as well, trying to finish the most tasks, trying to finish and trying to get the most things done at the same time while also managing the team, while being also a manager, while also doing stakeholder communication, cross-functional team communication. Facilitating all the meetings and so on. They got me also close to burning out. And yeah, that was kind of like a sign to me that I need to start managing time a lot better. So when I, when I did start managing my time a lot better, that means that I did a lot less individual contribution. I started to delegate a lot more and trust my team a lot more. Then things became a lot better. I also focused a lot on things that weren't inside of my control because when I grew to become a team lead, I saw so many things that I wanted to make better across, across different teams, across the organization, across also different departments. But yeah, you know, I learned that I can't change everything. But what I can do is I can provide good suggestions and build good relationships with other people who have ownership of different parts of the organization. And then the third one is I wanted to be included in all the fine details. As I mentioned before, I tried to finish the most tasks. I tried to do, you know, also take the hardest tasks as well. And that was problematic because it's, you know, I became bottleneck. And, you know, over time you need to start trust your team, your people, to take on those tasks because you're going to burn out if you don't. So what I suggest, you know, is that delegate those less important things to your team and be involved in the things that are important for your team and also for the organization and for the business as well. Those are the 3 main mistakes that I made when I first became a team lead leading one engineering team. Now let's talk about my advice, you know, if you transition from IC to leading one team. So my advice here is to focus on the things that you are not so good at. Most of the time, you're probably— most of the, you know, first-time team leads are probably good at, you know, technical details because, you know, they grew from software engineers to senior software engineers and they developed, you know, a good understanding of certain frameworks, certain programming languages over time. So a lot of, a lot of first-time teammates are good at that already. But what you're not so good at is, you know, time management. That's what I struggled a lot with. Leading and organizing meetings, that's, that's a lot different than, you know, that, than actually creating features and building, building products. And also obviously managing expectations and good overall communication. That's something that you might not be used to before if you haven't been, you know, leading leading projects as a tech lead and so on. But you need to focus on all of these three things. And my advice would be also to, to put, to put your individual contribution, contribution on the secondary side, because if you still try to be the best, you know, engineer in the team, you're not going to be able to, you know, focus and get better in all of these things. But, you know, try to get better at things that you're not so good at. That's in a lot of cases, that may be, you know, communication. So yeah, that's my advice if you grow from engineer to team lead, first-time team lead. And yeah, also don't, you know, you're gonna make mistakes, it's unavoidable to a certain extent. I made a lot of mistakes and you're gonna make them as well. Learn from them, you know, as much as possible and, you know, just keep going. Okay, let's go to the next one, which is leading 3 teams. You move from lead to engineering manager. You know, in some companies, engineering manager is also kind of like a role that is leading one team, but for me, engineering manager is someone that is leading at least two or more teams. So that also means that, you know, team leads are reporting to you and you're managing a certain area inside the engineering organization. So the first— let's go first into three of the mistakes that I made leading, leading three teams, growing from team lead to engineering manager. And yeah, I remember this time to be very, very interesting time because it was like after 6 months after I became a team lead and I just, you know, I just gotten a grasp to the role. And then, you know, after 6 months I started leading 3 teams. So the first mistake I made here is that I procrastinated in a lot of the decisions and I thought that, you know, I tried to make perfect decisions, right? Because, yeah, you know, being a first-time engineering manager, I thought that, you know, I should not be making mistakes in this, in this, in decisions, right? But then the more I waited, the more problematic it has become. So, you know, certain things also, I thought that, you know, if I'm going to be waiting, they're going to get magically better as well. But, you know, things are never going to be like that. It's always better to make decision faster and then reverse it, you if you see that it's not working. So that was my first mistake here. I tried to also protect my teams too much. That was a second mistake. I remember, you know, stakeholders, my manager, and also leadership team, you know, having certain issues with the business, with the overall direction that we're heading, and so on. And I tried to I tried to leave that only to me, and I didn't try to involve my team into actually what's happening across, across the business, what kind of issues, what kind of things are struggling. I thought that I need to protect my team. But the problem with doing this is you're not giving— you're not being transparent and you're not giving the actual reality what's happening to your team, and your team will not be able to, to adjust and build and also do things in a way that are going to, you know, potentially resolve those issues. So the best thing what you can do here is to be transparent and share what's happening across the business. What challenges are we facing and so on. And also I remember my communication wasn't exactly on point, especially, you know, I'm being— I was very passionate. When I became the first time engineering manager, I wanted to again, you know, I still wanted to I haven't yet learned the full lesson about you can't change things that are outside of your control. I still wanted to make things better across different— across the organization, the whole engineering organization, different departments and so on. I remember, you know, doing things such as sending emails that were to different, you know, different, different leaders across the organization and also going a little bit above my manager as well. So yeah, lesson learned here that, you know, It's a lot better to provide suggestions for improvements, but don't expect them to be either immediately implemented. But yeah, you should just provide your best foot forward, but then don't expect things to change because, you know, you just said something would be better. You know, it's still up to the person who is responsible for that particular part. And yeah, also, you know, with the relationship with my manager also, wasn't on point because I went a little bit above, above them. So yeah, communication is really important when you, when you start leading 3 teams, becomes even more and more important. Now let's go to my advice if you're promoted from team lead to engineering manager. So yeah, you, you will now have team leads reporting to you, so you will not be working directly with the people who, who are doing hands-on work. So you need to focus a lot more on being a coach than actually a player coach. So you are now coaching managers, and the really, really important thing here is to really, really focus on delegating efficiently. You need to have a good prioritization, focus on what things are you going to either focus on or what things are you going to delegate. So you want to find good team leads that you can trust, that you can, you know, you can work with, you can also build up, that you can coach and mentor. That is one of the most important things, finding people that you're going to trust leading your teams. And yeah, we mentioned also, you know, you need to become a great coach and mentor and select the right people for team leads. Those are going to be really first really, really important decisions as an engineering manager. Is to really find the right people that are going to be leading your, your teams. And then also, yeah, obviously the focus should be on the process and good cross-team collaboration, uh, because, you know, you want to make sure that, uh, you, you, you are, you are making sure that your teams are efficiently communicating and collaborating within, between each other. Um, that, that is, for example, you hold like a cross-team meeting on a weekly basis and ensure that every, every, you know, with the team leads and ensure that every, every, every team lead of your team is aligned with what we are trying to do and so on. And you want to make sure that, yeah, everything is, you know, well become, you know, your process and also your organization becomes like a well-oiled machine. You want to also watch out for any kind of bottlenecks, any kind of people that can, you know, any kind of hero engineers inside teams, people that have excessive ownership of particular, particular domains of the codebase. And, you know, you want to think about what's going to happen if that person is going to either leave the company, you know, something happens to them, and so on. You want to think more strategically. Delegation is really key here. Provide business challenges to your teams. Prioritization of the focus. Also making sure that cross-departments, cross-organizational things are going to be, uh, well communicated. You're gonna be doing a lot more business and business communication than, than when you, you were a team lead. Okay, so let's continue with leading 5+ teams. That means that you are potentially a director, VP, or head of engineering. And yeah, I was a head of engineering leading 5+ teams with 35 indirect and direct reports. And the first mistake I made here is not focusing on building really good relationships with the executive team. I had decent relationships, uh, that was also, you know, one of the reasons why I got promoted to interim CTO when the existing CTO left. But if I would rewind the clock back again, I would focus to, to, to build the relationships even further, uh, you know, because That's one of the most important relationships that you need inside a company when you are at that level, right? When you're a head of engineering, CTO, VP of engineering, and so on, you need to really have good relationship with the whole leadership team because leadership team is actually your team. That is your first team. The second team is your team, you know, your engineering organization. So That was my first mistake because also, you know, when you have good relationships, you can get initiatives done a lot better. You're going to have people that you can trust inside different departments and things like that. And especially if you try to get cross different department initiatives to get done and to be aligned on it, you know, a lot comes down to how good of a relationships you have with different departments. And then also the third mistake, the second mistake, focusing on one issue at a time. You know, I remember at that time we had many different things, many different issues across the organization, not just engineering, but also across, you know, across different departments. We had issues with architecture, we had issues with tech debt, we had issues with misalignment between different departments and so on. And, you know, I was trying to be on all different places, trying to, you know, trying to make things better in all different fronts, right? But it doesn't work like that. You know, it's really hard to make everything better all at once. You need to pick, you know, what is the number 1 priority, number 2, number 3, and then focus just on that. And after you get that on a decent level, then you need to focus on another thing. But you also need to make sure that that other thing is not going to get, you know, back on the old tracks. And then the third mistake: if there are any issues inside the leadership team, that spirals down to all the teams. Yeah, that's very important to understand because, you know, we had a lot of people changing in the leadership team across the time. Also, you know, my manager left who was the CTO, then I became an interim CTO, and then also we had changes across other departments in the leadership team. And, you know, as soon as there are some misalignments, you know, miscommunication, misexpectations across the leadership team, things are going to spiral down then to all the other teams. Yeah, it's exactly like that. You know, Conway's Law is very real. You know, the overall structure of the codebase mimics the overall communication across the organization. And that is very true. It all starts with the leadership team. And, you know, you as a leader, you need to make sure that things are going well across different different teams, across also different departments. You want to put your best foot forward to make sure your relationships and, you know, you get along with everyone and you, you try to help each other. It should all be about everyone going into the same direction together, not all everyone trying to just, you know, focus on their specific department and trying to make that as best as possible. We should all be focusing on making sure that the business is doing as, as well as possible. Now let's focus on my advice if you're promoted from engineering manager to director, VP, head of engineering. And yeah, my number one thing is, you know, make sure to focus on implementing at least some level of metrics because you're gonna get— you're gonna have a much easier time than to manage expectations, you know, because they're objective. And also you're going to have a bit better overview of, you know, what's happening across the organization because you're not involved in, in all the teams' details, what they're doing on a daily basis. You're trusting your teams, you're trusting your people who are reporting to you to managing different parts of the business of the engineering organization. So at least, you know, at least some kind of metrics are important here. Start with 1 or 2, pick 1 or 2 metrics that makes the most sense. Sense to you and then start with that. You can also potentially add more metrics as time goes on. But yeah, that's, that's very important. The second thing is, yeah, focus on really understanding the business, the industry, and the overall organizational challenges because, you know, you are a translator between the business and the engineering organization and you need to make sure that everything that engineering does is going to be aligned with the business. And you are, you are that, that bridge between, between those two sides. And you understand the business as much as possible, the industry, and the overall challenges across the organization. You're going to make sure that, you know, all of your teams are focusing on the right things. And that can be, you know, quite seismic. You know, if your teams that, for example, you have 40 engineers, 7 different engineering teams, if all of those teams are focusing on the wrong things, then yeah, you have a big, big issue. And then, yeah, I talk a lot about building good relationships. And yeah, you know, I can't, I can't, you know, put, put— I have to put so much effort how important this is. The more you grow, the more important it is. If you have shallow relationships, if you have bad relationships with the rest of the leadership team, the whole organization is going to do, you know, quite, quite bad. So that is, remember, leadership team is your first team. And then a second team is your engineering organization. And, you know, if, if things are not going well inside your leadership team, then things are probably not going to go well inside the engineering organization as well. So yeah, I hope this was, this was helpful to you. Yeah, if you want to learn more, you can subscribe to my newsletter. It's called Engineering Leadership. Where I share 2 new articles every week. There are more than 165,000 people already reading it. And yeah, thanks a lot for watching, and I'll see you on the next one.
More from Gregor

How I Grew My Newsletter Engineering Leadership to 165k Subscribers in 3 Years









