#252 - Why Senior Engineers Struggle as Tech Leads: The 3 Mindset Shifts That Fix It - Anemari Fiser

[00:02:01] Introduction

Henry Suryawirawan: 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. And 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.

Anemari Fiser: Thank you so much for the invite, Henry. Really a pleasure to be here today.

[00:02:41] What Motivated Anemari to Write Her Book, Leveling Up as a Tech Lead?

Henry Suryawirawan: 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 taking over, you know, all the news about tech recently. So maybe in the first place, what motivates you to actually come up with this book?

Anemari Fiser: Well, first, my motivation comes from my experience as a tech 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 past four years, I’ve worked with different companies and 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. And 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’re even more like strong. 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.

Henry Suryawirawan: Well, very interesting. So many authors actually wrote a book simply because of they wanna cover their own journey, right? So I think thanks for writing and sharing your journey with 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?

Anemari Fiser: 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. And 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. And 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.

[00:05:41] How Is the Tech Lead Role Defined?

Henry Suryawirawan: 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 that may resonate with people as well. 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?

Anemari Fiser: Well, 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 software engineer responsible for leading a technical team and accountable for the technical 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. And yeah, it kind of gives justice to the complexity of the rule.

[00:06:45] How Does the Engineering Manager Role Differ From a Tech Lead?

Henry Suryawirawan: 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 engineering manager role?

Anemari Fiser: Well, so again, this is where things get complicated, because 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…. The 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, it’s at the next stage where 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. And 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 tech lead was doing everything. 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 team 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.

[00:09:37] Why Is the Transition to Tech Lead One of the Most Challenging Career Moves?

Henry Suryawirawan: Yeah, thanks for sharing some of these nuances about the 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 a tech lead is one of the main challenge for any software 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.

Anemari Fiser: First 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 and there’s a lot of variables 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. For 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 success, like as an individual 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. So what does it mean by? It means that, you need to be… And start thinking about your, 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, why are we, what are we trying to achieve? 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.

And third, for me, it’s the transition from the short-term 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. Kind 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? Take time to do and for, to make and for each and one of individuals. Like the challenges are gonna be different based on their experience and how the teams that they’ll be working on.

Henry Suryawirawan: 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.

[00:14:21] How Can Tech Leads Shift From Short-Term to Long-Term Thinking?

Henry Suryawirawan: So 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?

Anemari Fiser: So 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 actual effort to identify 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? And 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, you’re moving forward and to allow you to do the switch needed in the progress. Because when you have a long initiatives, you never know. 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 the journey, on whatever journey you are, it really helps because everybody’s in the same 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? Well, a lot of reflection and the work with myself. Like I’ve done a lot of taking time to think about, okay, how 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 long, can go a long mile to just kind of looking back and 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 the wrong way also for your team. They start putting pressure not just on you, but on them, right? So 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 and the feedback culture is a 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.

Henry Suryawirawan: 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? So I think thanks for sharing that, right? So I think for people who want to start shifting from 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.

[00:18:34] How Can Tech Leads Learn to Let Go of Writing Code?

Henry Suryawirawan: 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 they are chosen to be a tech lead because of their either seniority or their capability in producing code. This is probably one of the hardest transition in my 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, influencing other people as well. Or even sometimes leading other people. So I think maybe start from here, this issue of letting go of the code. So what do you think people should start shifting in their mind to address this?

Anemari Fiser: So first, just a disclaimer, I didn’t really struggle with this problem myself because I always, this was one of the thing defining for me early in my 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 we, can we do it better? 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 saying definitely stands. 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 next level or they want to go 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. So I can tell you some things that I see helps them.

First, I think it’s about getting very clear why are you 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? Can 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 would you like your day to look 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 are you willing to let go of? 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. Like there are different strategies that you can make 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. I 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. Then 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. So for example, there’s a period when you are planning work, right? That’s where you have to be more focused on the strategic work and you’re gonna be doing less 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 of seeing the long journey. And understanding that there are periods where you make a 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? And 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… This 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? Why 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. So 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.

Henry Suryawirawan: Yeah, definitely. I think it’s much clear now the clarity that you just gave, right? Especially for people who transition into this tech lead 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. And then having to transition to a new role, definitely there are a lot of question marks, right? Especially if something that deals a lot with, you know, non-technical problem.

[00:26:30] Why Is Every Tech Problem Actually a People Problem?

Henry Suryawirawan: 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 long time would understand this. Because sooner or later, you’ll realize, oh, this is clearly just a lot of people’s problem to solve, not the tech problem. So tell us the importance of this mindset as well, and what can we do to actually shift this mindset?

Anemari Fiser: 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 a what it seems to be like a 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 someone doesn’t wanna make a 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.

So 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 is a very common struggle. I see teams and projects running behind it, which is like 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? Why 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. Sometimes 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 tech, which is just an avoidance of what exactly we’re 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. I’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 knowledge on the technology, you 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.

Henry Suryawirawan: Yeah, so I think the sooner you realize, right? Most of the tech problems are not really tech problems, right? 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? You 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?

[00:30:52] How Can Tech Leads Delegate Effectively?

Henry Suryawirawan: 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. We discussed just now, right, about not producing code anymore 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?

Anemari Fiser: 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. Like 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? Because your definition of done and my definition of done 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 someone else is not gonna be what the outcome would be if they do it, right? And that usually happens because the expectations were 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. I find it very effective when I do this exercise with people. 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? How 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. Also, this gives you the chance to jump in quickly if there is a problem, as we talked before with addressing things quickly. So let’s say you find some sort of whatever technology, 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. So this gives you back that control of jumping in without 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. And probably your checkings are gonna be less. 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. You 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 that you have in your head. You have to make them clear if you want those things to happen. 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. And I’m saying that because just because someone is a senior 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 point, if it’s one piece of advice, it’s about setting expectations. I, every time I see a problem with delegation, it’s because something somewhere wasn’t said. It was assumed we are on the same page and we weren’t. So keep repeating whatever it is that you think you’re aligned. Worst case scenario, they’ll say, yeah, we all know this already. Perfect, 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.

Henry Suryawirawan: 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 not just for tech lead role, but any kind of leadership, manager position. You will find this challenge over and over again because especially we work with people, right? And there are a lot of misunderstandings that could happen. So setting clear expectations is definitely very crucial in any kind of leadership position.

[00:37:18] How Can Tech Leads Influence Without Authority?

Henry Suryawirawan: 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 the authority as like the managerial authority for the people within the team. So tell us maybe from your experience as well, what are 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?

Anemari Fiser: 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? This 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. What 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 with power like I just need this 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? So 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. But 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.

[00:40:37] Why Is Accountability Without Authority Unfair to Tech Leads?

Anemari Fiser: But 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. Like 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 makes your life 10 times harder. 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. And 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 reason that I’m saying it’s hard. 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. This is you describing that I am accountable for all of these 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. So 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.

Henry Suryawirawan: 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 leading without authority 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 align with what you want to do, right? So I think that’s always very, very difficult. And 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.

[00:43:42] How Can Tech Leads Measure Their Impact?

Henry Suryawirawan: 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? You know, how many features have you built? Any bugs that you have found from the work that you did? So maybe as a tech lead, it’s much more vague. How can you measure the impact then?

Anemari Fiser: Well, the first sign that you are doing a good job as a leader 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 means, like their collaboration, how is the team feeling overall? So it’s whatever you define as team performance and team, like health, what brings back to you. So 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. So 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 your team is doing when you are not there. I think, I really believe that a great leader gets to a point where their team, like the goal 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? So 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 for a leader because it takes 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.

Henry Suryawirawan: I 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.

[00:46:52] How Does AI Change the Role of a Tech Lead?

Henry Suryawirawan: 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. And I think we all know how AI can actually impact a lot of, you know, maybe workflows, skill sets required within the team. 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?

Anemari Fiser: Well, so definitely there are, there is an impact, a big impact exactly as you’re describing. Now that impact I would say it’s very different, again, 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 describing where okay, there’s 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 different extremes.

But coming back to your question on what’s the impact, I think 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. But 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 team, and 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. But it’s definitely something you need to be aware. 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. Do 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. How 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 where you want to go. You can have experimentation as long as you always keep in 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 responsibility and your adaptation to the market and to the company’s needs. And 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 a problem, you create others. So how is your team gonna adapt to that? And how are we gonna work to together without ignoring the benefits or the pain of the process? So yes, that’s how I think it changes in regards to the other 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. But I do believe in the power of adaptability of people. So I think if it’s one thing that, and especially software engineers, we’ve been adapting, tools have been changing forever. As long as we have that openness in order to constantly adapt and to integrate people in the process, I think we’re gonna be fine.

Henry Suryawirawan: Right. So definitely, yeah, adding more awareness about AI within the team, right? Especially if you are, you know, responsible for technical 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? It 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.

[00:52:26] Should Tech Leads Use AI to Get Back to Hands-On Development?

Henry Suryawirawan: So one aspect of AI is definitely, you know, for any tech lead, we can always get seduced to use this AI to come back to, you know, being more hands-on. And I I believe, right? This 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 for a tech lead now to get more hands-on by leveraging on AI tools? Or is this something that has to be cautiously done in your view?

Anemari Fiser: 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 process day-to-day, and they 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. You 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. I’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 that is not working, you know? 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 things like experiments. Some teams do this Friday tryout day, right? They 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 and the team in the process. 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 you are wrong, and it doesn’t lead everywhere, anywhere, sorry. So it’s just about, again, bringing the team in the journey 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.

Henry Suryawirawan: 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. They will just follow you, you know, using your power and hierarchy to actually solve the problem.

Anemari Fiser: Or follow your process and do their own process.

Henry Suryawirawan: Yeah, that’s even worse.

Anemari Fiser: So for your example, you know, sorry for interrupting.

[00:55:33] How Can Tech Leads Stay Accountable for AI-Generated Code?

Henry Suryawirawan: 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 making sure all these AI-generated code are kind of like within the right quality, the right, you know, kind of like acceptable expectations. So 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?

Anemari Fiser: 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, like the problem stays the same. Nothing changes in the accountability. You cannot say, well, this AI, I don’t know what the hell they did there because it’s not working, right? So 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 tech lead reviewing every PR, 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 delegation and that process and collaboration, this goes against it. So 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 there’s more, no controllable. Even though I just, I’ve seen this post the other day from someone that I follow on LinkedIn, and he was saying like, ah, but even before like you. We had so much code. Like most of the code that we work with is code that we didn’t 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? So this kind of get me to think, ‘cause even if it’s like 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 guidelines that I think, I think 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. But 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 team wants to handle it and 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. I’m gonna take this as it is, and I’m willing to take the risk 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? It’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.

Henry Suryawirawan: Yeah. So I think definitely one thing, a tech lead should still be 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. Especially 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?

[01:00:26] With AI in the Mix, Is a Tech Problem Still Just a People Problem?

Henry Suryawirawan: 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?

Anemari Fiser: The way I see it, it comes back AI being another tech tool that now we have in our work. More 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 discussing, all the topics on 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.

[01:01:10] 3 Tech Lead Wisdom

Henry Suryawirawan: Yeah, so definitely I still agree that, you know, AI is just another tool within your tool set, within your tech stack, right? So definitely people problem is one of the bigger problem whenever you face in a leadership role. So I think for people who are transitioning for the tech lead role, do make sure to check out Anemari’s book, right? 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 technical leadership wisdom. 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.

Anemari Fiser: Okay. 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 responsible, no one is. So that’s my first one.

Second, invest in vulnerability, in developing your 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, involve your team and always 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.

Henry Suryawirawan: Lovely. 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?

Anemari Fiser: LinkedIn. I’m there all day.

Henry Suryawirawan: 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. So, thanks again for your time, Anemari.

Anemari Fiser: Thank you so much, Henry, for the for the invitation. Have a great day.

– End –