Why Senior Engineers Struggle as Tech Leads: The 3 Mindset Shifts That Fix It

0:00The main reason that I see people struggling to let go is because of fear. Coding, it's safe. I've been doing this. I know how to do it. You get the instant gratification. It's fully in your control. The other side, it gets crazier. Today's guest is Anemari Fiser, author of Leveling Up as a Tech Lead. She's trained over 400 tech leads worldwide and distilled the most common struggles into a framework that works. I suffered a bit when I started out because there is a lack of resources specifically focusing on this role and on this transition from senior to lead.

0:27Becoming a tech lead is one of the main challenges for any software engineers who want to move to the next level. So tell us why? First of all, it requires a mindset switch. Going from the I mindset to the We mindset. You cannot be a successful leader if your team is not successful. The second stopping to think result and start thinking about value. And third, it's the transition from the short-term thinking to long-term thinking. In your book, you mentioned tech people problem. Every time you jump into a what it seems to be like a technical problem, it's usually someone not talking to someone with someone, even if they think they are.

1:03A lot of tech leads challenges What are some observations Regardless of where you are on your journey with AI, your responsibility as a leader is to at least be aware of what's happening and what are the tools out there and what do they do, how they can help you, how they can hurt you. It still comes back to the people. How do you align? How do you make sure you move forward? What do we agree on? It always comes back to the people. Hey, quick pause. My goal with Tech Lead Journal is simple. Learn from the best in tech so we can all grow together. If this resonates with you, hit subscribe to follow the channel.

1:52It's the biggest way for you to support the show and help us keep bringing great guests and insights to you. Thanks for being here, and let's get back to it. Hello, everyone. Welcome back to another new episode of the Tech Lead Journal Podcast. Today I have with me Anemari Fiser. So today we are going to talk about her new book, which is about tech lead, Leveling Up as a Tech Lead. In my memory, I haven't covered this topic since Pat Kua came so long time ago. I think it's quite refreshing to have another topic about tech lead in this episode.

2:26And also another book that you all can refer to whenever you wanna find out about how a good tech lead should be. So Anemari, welcome to the show. Really looking forward for our conversation. Thank you so much for the invite, Henry. Really a pleasure to be here today. Yeah. So Anemari, let's start with this topic itself that I mentioned, right? So we haven't been hearing a lot of resources lately about tech lead. Of course, AI is kind of like news about tech recently. So maybe in the first place, what motivates you to actually come up with this book?

3:00Well, first, my motivation comes lead. I have to say I've suffered a bit when I started out because there is a lack of resources, specifically focusing on this role and on this transition from, from senior to lead. And so yeah, that was the first motivation. And second, since then I, in the different, like people from different culture, from different environments that are in the tech lead role. I think I reach over 400 people now that I've worked with, training them on leadership skills.

3:39And I've seen the daily struggle that I felt some years ago when I started are still active and they're still repeated. And now with AI, I think They have even a bigger impact on people. And so I, yeah, I find it very needed to start creating these resources and this support for people. Because I think it's one of the most complex roles in tech for me at least. Well, very interesting. So many authors actually wrote a wanna cover their own journey, right?

4:13So I think thanks for writing us. So your book has a forward from Patrick Kua, right? So he was probably one of the maybe foremost person who wrote about tech lead. He has a lot of resources, books, even podcasts about tech lead. So how does it feel to actually have the endorsement of Pat Kua for your book? Well, it feels great. I have to say my first training on tech, as a tech lead, was with Pat Kua in ThoughtWorks, some years back. So for me it's always, his work has always been an inspiration for the work that I'm doing.

4:52And I'm very glad like over the years we had the chance of working together on different things, and we meet at different conferences over the, like in different parts of the year. And so having him, endorsing this book and actually contributing and was, yeah, was great. Actually, I was expecting a little bit more of a complex process to get him on board, but it was actually really easy. And yeah, I'm very happy because I think we both believe in the same principles when it comes to tech leadership. It's great when people like kind of come together and put all of this in the same place.

5:32And the way I see it is kind of a continuance, right, of his work or on just emphasizing on how important and how complex this role is. Yeah. And I think since this also covered a little bit from your journey as well, so I believe there will be some unique angles Because I am sure for someone who become a tech lead, everyone's journey is different, and the role itself is not defined. So maybe let's start with that in the first place, right? How do you actually define the role tech lead, or technical lead?

6:05Well, this actually was one of the hardest things to, one of the hardest chapter in my book, to define this. Because depending on who you ask, you get different definitions. And I actually got to through, go through them all in all of the books that you mentioned. Like people have tried to define it. For me, the tech lead is a for leading a technical team and outcomes and results of that team. And I think this kind of captures all of these different nuances that I've seen in the definition.

6:40And yeah, it kind of gives justice to the complexity of the rule. Yeah. So just to capture some of the emphasis you made. So it's like the leading and be accountable of the technical aspects of a team. And maybe just a little bit of tangential here because people always would love to understand, the tech lead role and engineering manager role, right? So how do you see the Well, so again, this is where depending on who you're talking to, you get different definitions. So in my experience, there are times when these roles are exactly the same in different companies. The main difference, again, generally because again the difference from company to....

7:25The main difference, I think it comes from the fact that the tech lead works with one team and it's very hands-on in that team, right? Like they are working with the team side-by-side every single day. They are accountable for the decision and they are involved in all the process on the day-to-day of the team. The engineering manager, for me, they are maybe managing multiple teams or if it's just one team, they have like higher influence or they have access to like another level of stakeholders.

8:00And they might also be responsible for more strategic work than the tech lead. So this is my experience when you have both the tech lead, I've seen all of these different kind of scenarios where you have both the tech lead and the engineering manager in the team. They work very closely together. And sometimes their work kind of even clashes. That's why they have to be very clear on where my responsibilities start and where your begin. And in this case, like I said, the tech lead is very hands-on close to the team. The engineering manager would not code and would be responsible of the performance and growth of people. I also seen cases in which my, which was my case where we never had engineering managers, so the And actually a big part of the book, it's covering this, that even if you have these different support roles like engineering manager, architects, whatever. It still falls on you as a tech lead to make sure your team is performing to help your team grow. Even if it's defined in the job description or not. You're still gonna have to take care of that in order to make sure you're successful and your

9:02team is successful as a team. So that's another case where basically you have even more responsibilities because you don't have other roles. And of course, there are cases where you only have engineering managers. You don't have tech leads, and the engineering manager will be more closer to the team, will do even hands-on work like coding alongside the team. But not at the, of the level of involvement of every day. So these are kind of the difference aspect I've seen. I don't think there is a best one. I just think it's very important to have clarity on what are the expectation, who's doing what, and how are we gonna work together to make this work.

9:37Yeah, thanks for sharing some of differences between engineering manager, tech lead. And I believe that in the industry or in every different companies, right, you might see some nuances and, you know, contextual things that might differ from the definition, maybe from your book or some other materials that are available out there, right? But one thing for sure, becoming engineers who want to move to the next level. And this comes with the problem of, you know, I think there's no well defined manual or maybe guidelines for anyone to transition properly. So tell us why this can be one of the most challenging transition for any software engineers who want to level up as a tech lead.

10:20First of all, it requires a mindset switch. And there are... There are like a couple of transitions that you have to go through in this process. One of them being, going from the I mindset to the we mindset, right? So it's not about you anymore as an individual contributor or doing a lot of work that you see quick reward on that you fully control that you can kind of oversee the whole process. When you are doing the switch to leading a team, all of the sudden, it's very, there is very little that you can control that there are out of your hands and there are lot of people that you have to deal with. And so the results and the outcome, you will have to basically switch from what can I do to what can we do, or what can I do to empower others to actually get results, right? So is that switch actually Pat Kua mentions is from individual to multiplier.

11:18For me, it's like the I to We, so it's more about, it's not about me anymore, it's about my team. And this also comes to the contributor, your success comes mostly from your results, your tasks. When it is a leader, it all comes from your team. You cannot be a successful leader if your team is not successful. That's kind of the sec, the first one. The second, it's about the starting to, stopping to think about the code as the main or the task or the outcome as the main result and start thinking about value.

11:52So what does it mean by? It means that, you need to be... your users, your stakeholders and value. It's different for each and one of them. And you'll have to understand all of these nuances and bring it back to your team and being able to explain like what's the, Instead of just kind of taking that for granted, which you are as an individual contributor and just trying to fulfill those expectations. So you'll have to be the one kind of navigating all of that conversation around value and how do we make sure we deliver value as a team.

12:24And third, for me, it's the thinking to long-term thinking. So everything you do as a leader, it takes time for you to see the return of investment. Let's say that, right? So let's say you are putting effort into growing someone in your team, it doesn't happen in a day, right? Like you'll have to postpone rewards. So that instant gratification that you get when you're coding, when you're finishing a task, actually this was one of my hardest, my toughest challenges that I had to overcome.

12:54Kind of letting go of the fact that things take time. Having patience and being able to see in the future and know how all of this effort is gonna pay off and getting to that moment, right, and making peace and within the day-to-day, with the short, with the slow feedback and with the slow steps that we are, the progress that we're making. Because yeah things will take longer. And it's one of the most frustrating things, especially when you're coming up from that mindset of, I see things instantly, you know? So yeah, these, I think are the three things, this mindset shifts that you have to go through from one day to another, right?

13:34Take time to do and for, to make individuals. Like the challenges are gonna be different based on their experience and how the teams that they'll be working on. Yeah, so I really love this part of a mindset shift that you mentioned, right? So in fact, in the book you covered it much, much longer, right, so in depth. So I think just to summarize, the first key mindset shift is actually thinking from individual to team level, right? And then from just putting effort producing code, you know, as a result, but thinking about value, value here could be something, you know, maybe like for business stakeholders, for product, for team, or whatever that is, right? Definitely depending on your context. And start shifting from short-term thinking to long-term thinking.

14:21So I think you mentioned, interestingly that the one you struggle the most is the last one from short-term thinking to long-term thinking. I think, generally also I feel that the higher the level you are, the more outcome you become responsible of. I think generally it takes much longer to actually gets the result. So maybe from your experience here, if you can share, how can you help people who also have the same problem, I want more like fast result, you know? So is there any kind of habit, mindset shift as well that you use to actually help you?

14:53So some things that helped me, were specifically starting to track progress. So instead of just looking at, okay, we wanna get there and when we're gonna get there, we'll see, start putting an milestones along the way that I can mark as progress. And this is not easy to do. It sounds easier than it actually is. But kind of going into that process and getting my team into the process of thinking, okay, but where, what is one thing that is gonna, one step that is gonna get us closer to this?

15:26And actually defining it and working towards that instead of always thinking about the long term. This was one thing that really helped me. It also helps me because once you have these milestones at every step, you are able to stop and understand if you're still going in the right direction. It kind of gives you the space to reshift, you know? So again, when it comes to long-term plans, I think the milestones and the tracking, the slow little steps, progress are key to keep motivated in the process, to feel like, you know, allow you to do the switch needed in the progress.

16:01Because when you have a long There's so many questions that you don't know, you cannot plan so much ahead. So this gives you the chance to re-address and re-adjust if you learn something new. So that's one of the things that really helped me to do the switch and forcing myself to, okay, you think big, you make a big plan, but then you go back in the small steps and bringing your team. This is the second thing. I think bringing your team on you are, it really helps because mindset. Everybody's working on the same kind of style. So it also helps you stay grounded and focus on that. What else helped me?

16:40Well, a lot of reflection and the work with myself. Like I've done a lot of taking am I doing with this topic? Like in regards to frustration, in regards to, just kind of taking that, again, those milestones, which can be your personal milestones, you wanna get better with patience. I think self-reflection can do a say, okay, how did I handle this or the other. The problem is that when you're impatient, when you want things to happen fast, it comes up in team. They start putting pressure not just on you, but on them, right?

17:20So it's not comfortable. Not for you but not for them either, right? So I think the third part that I wanna bring, which really helped me, it's feedback. So constantly keeping in track with how my attitude, how my behavior, how my approach impacts the people around me. So constantly checking on that key part of a high performing team and being able to be successful. And so constantly getting my stakeholders, my team input on how am I doing, how we are doing, right? Because again, it's about the success of we as a team kept me in check that okay, I'm on the right track. Even if I don't see it, even if it's not clear, we are definitely doing something right. So yeah, these are the three things that, that constantly help me to let go of the, of the need of getting instant results. Wow, I feel those are pro tips, I think applicable, not just for tech lead role, but any kind of leadership role or managerial role, right?

18:15So I think thanks for sharing that, right? So I think for people who want short-term thinking, long-term thinking, definitely tracking progress, be it a milestone, roadmap, whatever that is. And not to forget, right? Summarizing all the accomplishments when you reach that progress and milestones and then share it with to the team or stakeholders is definitely gonna be useful as well. So I think one of the biggest challenges for anyone who has transitioned to this tech lead role is the, you know, the situation where they have to let go a lot of coding. So for a senior engineer, mostly seniority or their capability in producing code.

18:53This is probably one of the opinion. This was also one challenge that I had in my past, when I transitioned. From producing code and now you have to teach other, either like for example producing the code themselves or you just write the technical documentation or you just review people's code. Or you just influence in some other ways, not code. And the other thing is one of the, as a result of that, right, because you're not doing a lot of the code, you are being asked to do a lot more influential thinking, well. Or even sometimes leading other people. So I think maybe start from here, this issue of letting go of the code.

19:31So what do you think people should start shifting in their mind to address this? So first, just a disclaimer, I didn't really struggle with this problem myself because I always, career in tech. I realized I'm way more driven by the group results and team results instead of my results. So I always focused on, okay, How, you know, just... I was always more into that space. So coding or letting go of coding for me wasn't such a big problem. But coming back to what you're And I do work with people every day and I see this as a very big challenge. Like people that are very comfortable in the coding, they like it, they enjoy it, and now they are pushed to go to the to the next level - whatever the reason - and they really struggle to let go of that part. So I do agree with you, it's a very big challenge. And I see people that I work with, navigating every single day.

20:31So I can tell you some things that I see helps them. First, I think it's about doing the transition, right? So the reason that I'm saying this is because if you are putting yourself through this process, why? Is it because someone is pushing you? Is it because you want to get some of the benefits of being a leader? Is it because there's a part of your work that is not so interesting or like satisfying anymore? Like getting back to your why. Why are you doing the transition? Why is this a challenge?

21:04Can really give you some answers, you know, on what's the friction there? Second, it's important to understand exactly, like even if you're, when you're jumping in the lead position, like how like? Like how much coding? You have to make peace with the fact that you'll have to let go of that coding. It's just a fact, right? Like you can ignore it. It's just like, if you wanna be successful, you're gonna have to do that transition. So the question comes to what So kind of making your, with some people, I put some definition. Like for example, I expect to code 30% of the time or 50% of. They have these kind of expectations. And then you can create a process where that can happen. Like you can block time in your calendar. Some people do the pairing.

21:53Like there are different sure to get close to that percentage. But it's all about testing. That's a testing experiment is like, okay, how much can I sit to my expectation based on the where my team is? And this brings me to the third point. It's very important to understand what your expectations are, and if your current context can sustain them. That the reason that I'm saying this is because I see teams where, as a tech lead for example or as an engineering manager, coding alongside your team is a requirement.

22:26I think makes your life really hard, but it's a requirement, which means you might have other roles around you that take care of some of the other things that you are, like growing people or performance or whatever. That can be like you have staff engineers or whatever, like that's one thing. It can help you take the load and then you can focus more on the coding. So it's a different context in which you're in, which is very different than when you're the single person that has to lead the team, you have no support around.

22:52Then you'll have to realize that you're not gonna be able to do both effectively. So the reason that I'm saying this is because you can make a decision which is maybe I need to change context, the context in which I wanna lead, because I wanna stay closer to the code. So I wanna be in a, and they are all of this, like all of these scenarios, I see them every single day from one company to one company they differ. But there is a reality. If you wanna be successful, at least in the tech lead, at least for a period, you're gonna have to make peace with the fact there's gonna be less coding. And it's also that the thing of understanding that there are period.

23:29So for example, there's a period right? That's where you have to be more coding. Or there's the period when you really have to deliver something. The goal is clear, the scope, it's clear, you just have to get hands-on. And that's the part where you can go wild just coding alongside your team. So that's the third part, kind And understanding that there are decision to do more of this or more of that. And third, it's like you can also find different ways to feel, to stay close to tech, to the code, which is not necessarily the coding part, right?

24:08And this means unblocking people, finding problems, coaching them to a problem. I find people find that very rewarding. So they don't solve the problem, but just working alongside with someone, pairing, helping them go through the process. It's very satisfying and it still gives that feeling. And I do have to say that the main reason that I see people struggling to let go of that is because of fear. It's very... This is the part where they feel com...

24:34This is the... This is where they feel comfortable. Coding, it's safe. I've been doing this. I know how to do it. You get the instant gratification. You get, you know, you, it's fully in your control. The other side, it's, it gets crazy, right? That's where you have to deal with people and with stakeholders and with pressure and with people like an alignment and miscommunication. And it's hard to go there. So the reason most people hold back, it's because they don't like it. So then the question comes back to what I told you. Okay, then why are you doing it?

25:07Why are you trying to gain out of it? And if you really want to do it because of other reasons, then you'll have to pay the price. But this clarity, I've seen com- makes making complete changes for people's perspectives and their decision. Because at the end of the day, it's about people want to feel like they have a choice. And getting clarity on your why gives you the, gives you the space to make that choice intentionally. And not just feeling like someone is taking something from you and it's you deciding for that or for the other.

25:35So yeah, it's just an exchange. It's not giving up on something. So yeah, that, that, that really helps. Hopefully this answer your question. Yeah, definitely. I think it's much clear now the clarity that you just gave, right? Especially for people who role. Always get this clarity when you, when the first time you're doing it, right? So I think getting the why is definitely very important. So this is nothing technical at all, right? So this is about yourself, trying to understand why you are taking up this responsibility to be a tech lead role. And I think the fear is definitely in anyone's mind whenever they transition to something new, right? So because before, there was a lot of comfort, comfort zone, right, where you are, you know, you're good at what you're doing.

26:21And then having to transition to are a lot of question marks, right? Especially if something that deals a lot with, you know, non-technical problem. Which brings me to a new segue, right? So in, in your book you mentioned, tech is actually not a tech problem, but it's always a people problem. So I believe every, you know, tech practitioners who have gone through their tech careers for a Because sooner or later, you'll realize, oh, this is clearly just a lot of people's problem to solve, not the tech problem.

26:54So tell us the importance of this mindset as well, and what can we do to actually shift this mindset? Well, yes, exactly as you said. I think once you've been doing it enough time for enough long time, you realize very quickly that every time you jump into technical problem, it's usually someone not talking to someone or someone not being aligned with someone, even if they think they are. Most of the time people, they think they are aligned or there is some information missing or there is fear and decision. But it's not a problem with the actual technology. And so, yes, the more, the more I've been through this journey, the more I realized that the moment when you ask the right questions, you very often get to a non-technical problem.

27:40So coming back to you, to your point, in order to do that switch, it's about being more developing the skill of asking them the right questions. And those are what is the problem we're trying to solve? Why is this a problem? Who has the ownership, which I see teams and projects running everybody thinks is accountable, but when everybody's accountable, no one is. So kind of developing the skill of asking these questions and always going back to the basic, like what is the problem we're trying to solve?

28:12Why cannot we do it this other way? So challenging all the assumptions that are in the room, it really helps kind of taking a step back. The thing that can help you most in this space, I believe as a tech lead instead of more than... I think the skill that can really help you identify and make the difference between, okay, when it's a technical problem, it's a people problem, it's the facilitation skills. So getting really good at helping the group, helping your team, helping the people in the room.

28:43Sometimes there are more people than your team to define what to agree to align on, what is it they're trying to solve and how they plan to solve it and what are the problems, what are the risks. And having the, discussing the elephant in the room instead of just kind of going deep into the trying to do. So the facilitation skills I think are key. I think for me are a game changer because even sometimes even if I don't, you can use them even if you don't know the tech.

29:12I've been in multiple conversation with clients, because in ThoughtWorks, I used to switch clients and so every time there was a new technology, a new thing to. But even if you don't have the can still help the group a lot to make a decision by using their common like together knowledge, you know, on that. Just kind of driving the conversation and helping them define, okay, what, what are we trying to achieve, going back to the goal and navigating the discussion, stopping when people derail. So this can really help to improve this skill. And your team will greatly appreciate it. Like it's a really tough skill to develop. I know myself because I work really hard in developing it, but I believe it worked every, every minute you're putting into it.

30:02Yeah, so I think the sooner you realize, right? Most of the tech problems are They are all people problem or organizational problem or even cultural problem, right? So I think start by, you know, finding the right questions and to ask, right? Be it in the discussion, meetings setup or even like with the stakeholders, right? So sometimes there are some challenges that you have to deal with which are non-technical problems. So I think thanks for highlighting that. And I think I would agree facilitation is one of the crucial skills, especially when you have to kinda like be the middleman, right?

30:34You have stakeholders on one side, but a tech team on the other side. You always have to bridge the misunderstanding, the gap between those two things. And yeah, definitely if you are a good facilitator, you can kind of like iron out a lot of issues, be the communication problem or the direction or alignment problems, right? Which brings me to the next question that I wanna ask you which are more tactical. So I believe there are some skill sets which are very, very important when someone transition to this role. So I think you mentioned about facilitation skill, right? So the other one that I find really, really challenging is actually about delegating.

31:11We discussed just now, right, but actually you ask somebody else to produce the code for the team. So delegation is definitely one aspect and being accountable of the technical deliverable of the team. So tell us maybe the pro tips here, how should one delegate better as a tech lead? Yeah, this is very fresh in memory. I just had a session this morning on delegation with the tech lead group. So the key secrets for effective delegation, it's first setting the clear expectations.

31:44Like when you are delegating someone, once you have the topic in mind, once you have the person in mind that you want to delegate to, it's about setting clear expectation. And this is the part that most people struggle with. What is it that you want? What is the outcome? What do we expect? And people think they know. But once you start asking, it's like maybe this and maybe that. But what if you choose one thing? What are you trying to achieve? And they're like, I want the task to be done. What does that mean?

32:10Because your definition of can be very different things. So... and this is actually one of the main fears tech leads have on delegating. The outcome on when giving it to what the outcome would be if they do it, right? And that usually happens not clear from the beginning. So what is it? What does done means? What do we expect from them? What do we expect the outcome to be? By when? Like having some sort of time bound. I like to use the SMART framework to apply to the delegation.

32:42I find it very effective when Like kind of defining, okay, the, what is the goal, the specific, the measurable, like having some metrics around it, actionable, relevant. And the key part is the, what I add to it is the trackable. And this is the part that people need. So the trackable means, you have a way of tracking progress. So when you are defining, okay, we're gonna work on this for, let's say in a month, we have to have this ready, how are you gonna check in?

33:12How often? And setting that from the beginning removes a lot of the pressure from you to having to go, oh, being worried and thinking what they are doing. What's- imagine you have from the beginning. You say, okay, every week we have a check-in on this topic and see where we are. More than that, let's have a board where all the work, whatever that you are doing, we track it there. Every, the whole team has access to it, you know. There's no fear of missing out in there because you can easily see.

33:38Also, this gives you the chance to jump in quickly if there is a problem, as we talked before So let's say you find some third-party thing tool not working. Instead of finding out at the end or running out of time, one week after when you have the check-in you can realize, okay, we definitely have a problem. What do we do? We need to change scope, we need to re-address? So this gives you back 'cause you're still accountable when you are... This is the key part when you're delegating.

34:10So this gives you back that having to be on top of someone. Hey, how are you doing? How is the process? Why did you not do this? And this is the next step that I want to talk about, which is the strategy you are gonna take for delegation, it's gonna depend on the task and the person you are delegating to. The reason that I'm saying this is because for, if you are delegating to someone that is completely able to deliver the task independently, doesn't need any support, and they have the knowledge and the confidence and everything, that's where you're gonna take a completely hands-off approach.

34:47And probably your checkings I still definitely advise to have a process instead of just saying, yeah, let them, we'll talk whenever. Have a process. Worst case scenario, show up like look, everything is on track. Perfect! Let's move on to the next thing. But there's always things that people don't talk about. So this kind of gives you the chance without you having to jump over them. So this is where you take a more hands-off approach. When you have someone, for example, if you wanna help someone grow, a great way to do that is through delegation. So you have a task which doesn't, it is not urgent, doesn't present a risk, and you could do it in five minutes. But instead you choose to give it to someone that maybe it's gonna take them a day, but they're gonna learn something. And so this is where you might have to take away more hands-on approach.

35:33You have to be very clear about not just what you expect, but also also how do you expect them to do it. So you have to check this. You also have to make sure we're checking the authentication, you, whatever. Be explicit all the things You have to make them clear if And you'll have to be way more, you have to have more check-ins, you have to be more on board, okay, what's happening? More conversations, more support needed for them. As you can see, the approach really differs on their levels of experience and the task.

36:04And I'm saying that because doesn't mean they are a senior in everything they're gonna be doing. So maybe that the task, it's completely new and then there's gonna be needing more support. So it's the combination of the individual with the task. But yeah, coming back to your advice, it's about setting expectations. I, every time I see a problem something somewhere wasn't said. It was assumed we are on the same page and we weren't. So keep repeating whatever it is say, yeah, we all know this already.

36:41Perfect, then we are on the same page. So these are the tricks for delegation that I use. They sound simple, but as I can see every single day working with tech leads, when you apply them, things get a little bit complicated. Yeah, something simple doesn't always mean easy to apply, easy to implement, right? So I think thanks for sharing this pro tip. Again, I find this is applicable but any kind of leadership, manager position. You will find this challenge over and over again because especially we work with people, right?

37:11And there are a lot of happen. So setting clear expectations is definitely very crucial in any kind of leadership position. So one other challenge when you do this delegation and being accountable for the things, right? So for a lot of tech leads, especially those who also have the engineering managers, the counterpart within the team, these tech lead by definition do not have the so-called the leadership official role. They are some kind of like just person appointed to be accountable for the technical deliverable, but not necessarily managerial authority for the people within the team.

37:45So tell us maybe from your some of the tips to actually influence someone without authority? Because maybe people would not listen to you because you are not their manager per se, right? So is there anything that they can do differently here? Yes. So there's definitely things that you can do to lead without the official authority. And there come back to the things that I already mentioned, one of them being facilitation, having great skills and bringing people together and reaching a certain goal, even if without using kind of your power, right?

38:19This is a great thing because you can get all the, input, all the information, and you can create together, right? So that's one part. Second, it's the setting of the clear expectations also apply here. If you ask someone to do something or to help you with someone being clear from the beginning on what do you need, but also why do you need it? And this is the key part. And I think it's even more important when you don't have the authority. It just kind of can make that extra shift, which is the why I need this or what.

38:50What are the, sorry, what is the impact of this being done or not being done? So kind of showing people the full picture can really make that switch. So even vulnerability, it's a great skill here. Like sometimes I go to people and I say if this doesn't get done by today, I'm gonna be in big trouble. Just kind of be honest and be straightforward. Don't assume they know, you know. Because when usually people by the end of the day. Imagine if you just switch this and you go, hey, Henry, I just, please can you help me with this? Look, if we don't get this ready, these stakeholders gonna be or these users are gonna... When people hear the why and the impact, they have a higher tendency for jumping in because it's not just you wanting things, it's because there are actually some, there's a reasoning behind, right?

39:37So being clear with impact and being straightforward with people and asking for help, it's also a great way to get people to help you or to do the things without using the power. Something that we don't much use it. It is like, you know, it's very powerful, but it, because it requires on your side to accept that you need help, and people struggle with that. You literally have to go, look, I don't know how to do this. I'm lost. Can you please help me? It requires a certain level of vulnerability and courage to do that.

40:09But even as a leader, at any level, I believe vulnerability, it's a superpower. So learning to develop that, even if you don't have the, the official role, again, I think it's a superpower. It can really help to be able to be transparent saying, I don't know. Being the one in the room as a leader to say, I don't know. We can make like magic for your team to kind of develop that psychological safety in your team and people being able to contribute.

40:37But coming back to your point. So with all of these things in mind that they can definitely help to basically influence people without authority. I do have to say that in my experience, and I've been in that case and I'm speaking also from all of these people that I help navigate this every day, is that it's really hard to be in a position where you have the accountability without the authority. And the main reason is that when you've used all of these strategies that I already mentioned, there is a point where someone might still tell you, yeah, but why should I do it because you say so? And that's the point.

41:14Like there is an extreme where the only thing you can use, it's authority. Like, you know, we need to do these, there are expectations. We, the setting of expectations from your role, from your, that you cannot do if you don't have the authority. So I just wanna emphasize that people that are, I think it's unfair to put someone in that position. I've been there. It's really hard because it And it's just, even if you don't use that authority ever, it's just the idea, you are starting from a different position and it's easier to make those, to have those conversations.

41:49And as long of course as you keep yourself in check and don't use that as a tool. Because either way, even if you're in the position and you use it as a tool is gonna burst in your face. It doesn't go for very long to use that authority. But I do have to say if it's possible and you are in that position, make it visible. Like if you are already doing the work, right, why not making, make it public? You know, this is a, I never got this. And when I ask people and they go back to their manager and they say they're struggling, the It's way harder. And it's very different because the case that you describe is not you are in your team and you're trying, like a team member and you're trying to influence your team. And if you get there, fine, but if not, then the manager comes in and whatever.

42:35This is you describing that I am things. So it's like kind of having the tech lead role in the shadow which is very different. This is management not wanting to take the ownership of making the decision. This is as simple as it is because you already have one. You just don't wanna make it public because you think, ah, they can do the job. And it's just easier for everyone until they burn out and they leave. Which is usually happens with these people. It can only last for so long.

43:02So yeah, it's very different. The position where you're in, but the tools can still be used. I have to put that very important part. Yeah, it's very important in fact. Indeed, I would like to emphasize, right, even though maybe there are tools and techniques you can do, but definitely is difficult by itself, right? Especially if the counterparts, you know, the, the, the leaders, the managers who are supposed to do that role doesn't So I think that's always very, very difficult.

43:30And I think maybe getting alignment with those people is one area that you should do as well, so that, you can get more influence from them, you know, managing the people to follow the work that you are trying them to do. Which you mentioned about impact, right? So I think maybe a lot of tech lead are also questioning, you know, even though they seem to be busy all over the places, you know, trying to set the technical direction, right, and all that. How do they measure their impact within the team, right? Because in the past, maybe as a coder, it's very clear, you know, how many tasks you do?

44:02You know, how many features have you built? Any bugs that you have found So maybe as a tech lead, it's much more vague. How can you measure the impact then? Well, the first sign that you is the performance of your team. So if you wanna measure your per- your impact, your performance, you have to measure the performance and the impact of your team. That means their results, it how is the team feeling overall? So it's whatever you define as team performance and team, like health, what brings back to you.

44:40So it's a sign. A team performing well, it's a sign of a good leader behind, and it speaks highly of you. So that's where I would start. First, it's about the team performance. Second, it's feedback. I keep going back to feedback like as a leader, even if you think you're doing a great job, if you don't, if the people around you don't agree, I'm sorry but it's, you are having a, you're missing a piece of reality there, right? So it's constantly getting the feedback from the team, from your team, from your stakeholders, from the people around you. And this can be intentionally like specifically going and asking for it or just kind of keeping track of what people are telling you on the frustration or what are they complaining about.

45:22So that's the second tool that definitely can help you to measure performance. And the third that I would add here which is a tough one but I really believe it's a great metric, which is measuring how not there. I think, I really believe that a is a, they say like, the goal as a leader, it's to make yourself indispensable. You never really get there because there's always thing that only you can do. But the intention behind it is, how do I make my team so autonomous, not dependable on me, and be able to work together, collaborate, so I don't have to be there?

46:04So if you can go on vacation for two weeks and not check your phones and completely trust your team to take care of whatever it is, then it means you are doing a good job, you know. And you come back and there's no fires and everything that's been handled, then it's, again, it's a good sign. So I call this the stress test some time to get there, right? You need some invest in your time to, sorry, in your team, and you need to get to a point in order to do this stress test. But I really believe it's a good indication if you're doing a good job as a leader.

46:36I love the stress test. So definitely if the tech lead goes away for vacation, right? There should not be a lot of pings, issues that requires the tech lead to be involved, and even like solve the issue himself or herself, right? So I think that's definitely a good tips for people. So I wanna bring up our conversation to, you know, the AI impact. In fact, one of the challenges that you say you listen a lot to, a lot of tech leads challenges is definitely the impact of AI.

47:04And I think we all know how AI you know, maybe workflows, skill So let's go into the impact of AI to the tech lead, because I believe some of the hypothesis that is happening, you know, across the world it's like team size is getting smaller, maybe less developers. Maybe these so-called tech lead or the seniors are required to work a lot more to produce the code, even like use AI coding assistant to produce the code. So maybe let's analyze here. What are some of the observations that you have seen happening with the impact of AI? Well, so definitely there are, there is an impact, a big impact exactly as you're describing.

47:44Now that impact I would say it's depending on who you're asking, where they're working, the context, the environment, the company they're working in. And so, I've seen what you are less people in the team, there's more work. But I also seen the other extreme where there's actually more need for dealing with the generation of AI in coding. And so there's definitely But coming back to your question the first one is there is one more thing a tech lead needs to worry about. Regardless of where you are on your journey with AI, and again, I'm seeing companies with zero lines of code written by human, and at the same time, you have the extreme with no AI whatsoever, so I see this daily.

48:31But regardless of it, I think your responsibility as a leader is to at least be aware of what's happening and what are the tools out there and what do they do, how they can help you, how they can hurt you, like whatever, you know. Kind of having this awareness is the first step. I, you owe this to yourself, you owe this to the work that you are doing. So that's the first thing, it's kind of. Another thing that you have to be aware of that it doesn't necessarily directly impact your work because it's not like one day you come, okay, now we use AI.

49:06But it's definitely something So that's the first step, kind of understanding exactly what is it out there, where you are, what we can do, what can we not do about it. Second is the conversation you need to start having and being involved in the, at the company level. Because there's gonna be decision being made and sometimes the decision will move faster than you being able to catch up with them. So whatever your management team, whatever decides, you're gonna have to bring that back to the team and explain and get them on board, and you're getting on board with them at the same step exactly as you said and adapt to that.

49:37Do we have more code now? Do we have less? How are we gonna integrate it? I believe the secret is to be, again, be vulnerable to your team. Be honest about what you know and what you don't. Admit that this is a journey for everyone. I know some people look like they might know more than others what they say, but at the end of the day, we are in exploration phase still, right? So every team is trying to kind of, and every leader is trying to understand how to integrate it smoothly. It's about being straightforward to your team and say, this is where you are, this is what we need to do, or this is what we would like to do.

50:09How do we do it together? I've seen this over and over on how it really makes it easier for you and for your team to start integrated these processes in a safe way, right? So you can decide together You can have experimentation mind the overall context. This is very important where like, where are your companies and what's your area of business? Or you cannot start injecting agents if you have, I don't know, a very legal space, right? So, yes, it comes back to your adaptation to the market and to the company's needs.

50:46And constantly, this is even more important, as you said, as we maybe have tools that generate some part of the work, then, okay, there are other problems. You know, every time you solve So how is your team gonna adapt to that? And how are we gonna work to benefits or the pain of the process? So yes, that's how I think it aspects that you mentioned. Okay, are the tech is now just gonna have an army of agents, whatever? I, to be honest, I don't know. I haven't seen that yet, still yet, sorry. Like just, I think that's some of the things that we have to be curious and constantly aware of and seeing what's happening and see where it, where we get.

51:30But I do believe in the power So I think if it's one thing engineers, we've been adapting, tools have been changing forever. As long as we have that openness process, I think we're gonna be fine. Right. So definitely, yeah, adding more Especially if you are, you know, direction of the team, definitely you should be checking out, you know, the latest and greatest about AI, which tools that can be introduced to the team. And if you are using AI itself, what are the impact, right?

52:09It could be some technical impact, maybe the amount of quality that gets produced by the team. Or it could be the AI risk, right? You know, we have so many security issues that there are in the news, right? So definitely tech lead should be aware of those things and help the team to actually also level up their capability. So one aspect of AI is definitely, you know, for any tech lead, we can always get seduced to use this AI to come hands-on. And I I believe, right?

52:38This is, to me personally, it can be a great seduction that you simply forgot the other responsibility that you have. So maybe, is it a good thing hands-on by leveraging on AI tools? Or is this something that has to view? In my view, I think it needs to be cautiously done. And the reason that I'm saying this is because first, you are doing a big change in the process. This is the same as I see it when you all all of a sudden have engineering manager that are not integrated in your come and they just make a random PR and say accept it, and then the team is like, but yeah, how does this, no, no, just take it.

53:18You know? I feel like kind of the same process. You all of a sudden is like, okay, I'm gonna do this. So what I'm trying to say by caution is I think you have to make sure your team is on board with whatever it is that you're trying and you are doing. So if that's part of it, you wanna be, I dunno, trying out something, whatever, just make sure you fully integrated in the process of your team. Because if all of a sudden, you have AI generated code overnight and your team doesn't know what to do with it, and I see this.

53:44I've seen people doing this. I've seen head of engineering send this PR overnight and saying, I have solved your bug in two hours. And people are like, why I do this? Because there are no bugs. Who solves this, this pipeline So the reason that I'm saying is that if you don't have, you don't want chaos, especially when you're leading a team, you need to make sure you keep them on the journey with you, whatever it is that you're trying. Now you can also do small Some teams do this Friday tryout day, right?

54:12They have this thing, they have some tokens, they have some, and they try things out, and then it's up for everyone. And then again, but it's you But it's very different when you all of a sudden start to do different. Some people are like, I'm gonna show them how easy it is. That's not necessarily the way to bring someone. They're gonna even push more back because you're coming as a I know it all and whatever. They're gonna try to show you lead everywhere, anywhere, sorry.

54:38So it's just about, again, in whatever plan you have. As long as you want those results and your results will not be impacted by the outcomes of it. Because as we know, what might seems faster, might be slower in the long run. Yeah, so definitely don't break the process simply because now you have this superpower of AI, right? So I think, yeah, I always find leaders who jump into, you know, seemingly their own conclusion of a problem and solve it for the team and, you know, lets the team just accept it without actually reviewing or go through the proper process is something that actually weakens your kind of like leadership because now people don't trust the process.

55:18They will just follow you, you hierarchy to actually solve the problem. Or follow your process and do their own process. Yeah, that's even worse. So for your example, you know, sorry for interrupting. No problem. So let's say for the team now who has used a lot of AI, right, for generating code. Now is it like tech lead's responsibility to be, you know, accountable for, you know, I don't know, code reviews and AI-generated code are kind of like within the right quality, the right, you know, kind of like acceptable expectations.

55:52So tell us also a practical guide here, how should a tech lead do. Because I'm sure teams who get used AI these days will get a lot of more output churning out code really fast, right? I mean, the tech lead being accountable for whatever it's delivered as a team, it's still a thing. Regardless if it's coming from AI or from all of the sudden you have 100 people generating code, Nothing changes in the accountability. You cannot say, well, this AI, I did there because it's not working, right?

56:24So it's still on you. That doesn't change. Now how you deal with it because you all of a sudden have less, you, like you said, you have more outcome. First, I'm not a fan of the even before the AI, right? I don't think that tech lead needs to put their take and their mark on everything. I think that's a very red sign of, being a blocker and a blocker for your team and it doesn't help anyone. And you don't wanna be there, right? So if you're talking about the collaboration, this goes against it.

56:59So reviewing every PR, it for me was never a thing even before the AI. Now, yes, there is, basically there are more risks, right? This is what we're talking about. There are more risks now because this post the other day from someone that I follow on LinkedIn, and he was saying you. We had so much code. Like most of the code that we wrote every single day, right? Because most of the work we're doing, it's maintenance or like building on top of something that exists. I mean, come on, how much we are actually invest inventing from zero these days?

57:41So this kind of get me to think, generated by human, it's still a lot of unknown that we are working with daily. So what I'm trying to say, I think it's always been a problem. It's not, just more in our face and bigger. So coming back to what some the same guidelines apply. You need to have a clear definition for what quality means for you. Like what do you as a team, what are the guidelines that you stand for and whatever it is that you're using to generate that code, those needs to stand. When it comes to testing that, when it comes to, I don't now, how fast you deploy, whatever it is, I think, those at least needs to be a conversation around if those still stand or if they need to change.

58:25But there needs to be some guidelines and whatever the code is generated or not needs to stand by it. And then it comes back to how the level of risk you wanna take. Because, okay, do we wanna check? And I've seen teams and I do it every day. Every line of code. If you accept a PR, it means you stand behind it. It means you reviewed it and they reviewed it. And it's, again, it's how team do it. But then you also have team that just say, okay, I'm gonna take the risk.

58:53I'm gonna take this as it is, if something really goes bad. It really goes so bad. But then they have contingency things in place. They have more time spent into testing or they have really good incident management processes that they can address, right? And you can also define the level of impact based on the task. If it's something easy or whatever. If it's a complete change of strategy, then you might want to have more eyes on it. But again, I think instead of you trying to figure this out on your own and how your team should do it, bring them in. See what is the problem, what are the fears? And again, how are we gonna make sure, you need to make sure the quality, the standards quality are met. How do you do that?

59:35It's for your whole team. So bring them in. Again, you have higher chance. More heads, more knowledge, and you bring them in an accountability. Because once they are part of the decision making process, there's a higher chance that they commit to it than you telling them how and what to do. So that's a key secret of getting people in aligned. Yeah. So I think definitely one thing, accountable for the team's technical direction and deliverables, right? I think coming back to the definition you mentioned earlier, and I think bringing the team in to put kind of like the guardrails, the quality that the team should adhere to definitely is very important.

1:00:16Especially if you can automate that, that's the better, right, so that you don't have to spend your time to actually police the result, the output of the team. So definitely those are a great thing, right? So maybe one more question about AI impact because we have talked about tech problem is actually people problem. So now should we consider tech problem as people problem plus AI problem or it's still a people problem? What do you think? The way I see it, it comes back AI being another tech tool that now we have in our work.

1:00:48More people, less people, it's still a people problem and I believe it's always gonna be a people problem. Even this what we've been the AI, we got to the people. How do you align? How do you make sure you move forward? What do we agree on? What risk do we take, right? It still comes back to the people. So yes, it always comes back to the people. It's just we'll have to adapt based on the tools that we are using. Yeah, so definitely I still agree that, you know, AI is just another tool within your tool set, within your tech stack, right?

1:01:19So definitely people problem is one of the bigger problem whenever you face in a leadership role. So I think for people who are role, do make sure to check Leveling Up as a Tech Lead. Definitely one of the rarest tech lead resource that is available out there. And, unfortunately, we have to wrap up. As we come to this end of conversation, I would like to ask you one question, which is like a tradition in my podcast. I call this the three Maybe if you can share, you know, some kind of advice that you wanna give to listeners, maybe Anemari, if you can share your version today, that will be great.

1:01:55Okay. Yeah, for sure. I'm thinking to choose. So first one would be a lesson that I keep on learning every single day working with tech teams is always make sure you have a clear owner. Because when everybody's So that's my first one. Second, invest in vulnerability, It's a superpower as a leader. Say more I don't know, admit when you make a mistake, these are gonna make go greatly with your team. And third, it comes back to the people. So whatever decision you're making, whatever process, whatever you're not sure how to or how to move forward, think about the impact it has for them, for your stakeholders, for... I think this is gonna greatly help you make those better decisions if you consider them in the equation at every step of the, every point.

1:02:49Lovely. I think. Yeah, those are great, definitely great advice, for, you know, people out there. So if people would like to follow you, ask you more questions, maybe about tech lead or maybe other things in general, is there a place where people can find you online? LinkedIn. I'm there all day. Cool. Okay, so I'll put in the show notes definitely. So thank you so much Anemari for your time. Thanks for sharing, you know, some pro tips for becoming a great tech lead, especially in these AI days where, you know, seemingly we all don't know how to deal with it. So I think what you share today is definitely gonna be useful for people in their journey to transition, you know, as a good tech lead.

1:03:27So, thanks again for your time, Anemari. Thank you so much, Henry, for the for the invitation. Have a great day.