# Tech Lead Transition and AI Integration Strategies

**Podcast:** Tech Lead Journal
**Published:** 2026-03-30

## Transcript

The main reason that I see people struggling to let go is because of fear.
Coding is safe.
I've been doing this, I know how to do it to get the instant gratification.
It's full in your control.
The other side, it gets crazier.
Today's guest is Anamari Feaser, author of Leveling Up as a Tech Lead.
She has trained over 400 tech leads worldwide and distilled the most common struggles into a framework that works.
I've suffered a bit as when I started out because there is a lack of resources specifically focusing on this role and on this transition from senior to lead.
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 is stopping to think about the code as the main uh 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 is actually not a tech problem, but it's always a 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 or someone not being aligned with someone even if they think they are.
What are some of the observations that you have seen happening?
Regardless of where you are on your journey with AI, your responsibility as uh 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 Legional 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.
It'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 Legional podcast.
Today I have with me Anne Marie Fisser.
So today we are going to talk about her new book, uh, which is about tech lead leveling up as a tech lead.
In my memory, I haven't covered this topic since Petqua came um so long time ago.
Uh I think it's quite refreshing to have another topic about tech lead uh in this episode, and also another book that you all can refer to whenever you want to find out about how a good tech lead should be.
So, Anne Marie, 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 Anne Marie, let's start with this uh 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.
Um so maybe in the first place, what motivates you to actually come up with this book?
Well, um, first my motivation comes from uh my experience as a tech lead.
Uh, I have to say I've suffered a bit as when I started out because there is a lack of resources specifically focusing on on this role and on this transition from from senior to to lead.
Um, and so yeah, that was the first motivation.
And second, um, since then I in the past four years I've worked with uh different companies and different um like people from different uh cultures, from different environments um that are in the tech lead role.
Um I think I reach over 400 people now that that I've worked with, uh training them on leadership skills.
And I've seen the the daily struggles that I felt some some years ago when I started um are still active and they are still repeated.
Um and now with with AI, I think they are even more um like strong.
Um they have even a bigger impact on people.
And so I yeah, I find it very um needed to start creating these these resources and and this support for people.
Um, because I think it's one of the the most complex roles in in in tech for me at least.
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.
Um so um your book has a forward from Patrick, Pat Kwa, right?
So he was probably one of the maybe foremost uh person who wrote about tech lead.
He has a lot of uh resources, books, uh, even podcasts about tech lead.
Um, so how does it feel to actually have the endorsement of Pat Kwa for your book?
Well, it feels great.
Uh, I have to say my first training on tech um as a tech lead was with Pat Kuwa in in Thoughtworks, uh, some some years back.
Um, 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 of working together on on different things and we met uh at different uh conferences over the like in different parts of the the year.
And so having him uh endorsing this book and actually contributing and was yeah was was great.
Um actually I I was expecting a little bit of a of a more uh complex process to get him on board, but it was actually really easy.
And yeah, I'm very happy because I think uh 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 in the same place.
And the way I see it is kind of a continuance, right?
Of his work of um 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 uh I believe there will be some unique angles uh that may resonate with people as well, because I I am sure for someone who became a tech lead, everyone's journey is different, uh, and the role itself is not defined.
So maybe let's start with that in the first place, right?
Uh, how do you actually define the role tech lead or technical lead?
Uh well, this actually was one of the hardest things to one of the hardest chapters in in my book to to define this because uh depending on who you ask, you get different different uh definitions, and I actually got to go through through them all uh in all of the books that you mentioned, like people have tried to define it.
For me, the tech lead is a software engineer um responsible for leading a technical team and accountable for the technical outcomes and results of that team.
Um and I think this kind of captures all of these different nuances that I've seen in the in the definition.
And yeah, it it kind of gives justice to the to the complexity of the role.
Yeah, so just to uh capture some of the emphasis you made, so it's like the leading and be accountable of the technical aspects of a team.
And um maybe just a little bit of tangential here because people always uh would love to understand uh the tech lead role and engineering manager role, right?
So, how do you see the engineering manager role?
Well, so again, this is where things get complicated because uh depending on who you're talking to, you you get different um different definitions.
So, in my experience, um there are times when um these roles are exactly the same in different uh 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 um side by side every single day.
They are accountable for a DC 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 um at the next stage where they are maybe um managing multiple teams, or if it's just one team, they have like um uh 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 I've seen all of these different kinds 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 responsibility starts and where you're uh 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 for 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 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 expectations, who's doing what, and how are we gonna work together to make this work.
Yeah, thanks for sharing some of these nuances about the differences between engineering manager, tech lead.
Um, and I 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 um other materials that are available out there, right?
But one thing for sure, um, becoming a tech lead is one of the main challenges 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 transitions for any software engineers who want to level up as a tech lead.
First of all, it requires a mindset switch.
Um, and there are like a couple of transitions that you have to go through in in this process.
One of them being um going from the I mindset to the we mindset, right?
So it's not about you anymore.
As an individual contributor, you're 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're doing the switch to to leading a team, um, all of a sudden it's very there is very little that you can control.
And um, there's a lot of variables that they are out of your hands and a 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, Patkua mentions is from individual to multiplier.
For me, it's like the I to we.
So it's more about uh 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 second the first one.
The second, it's about the um starting to stopping to think about the code as um as the main uh or the task or the outcome as the main uh result and start thinking about value.
So, what does it mean?
But it means that um you need to be and start thinking about your your users, your stakeholders and value is 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 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 will 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, um, for me, it's the transition from the uh short-term thinking to long-term thinking.
So everything you do as a leader, it takes time for you to see the uh the return of investment.
Let's let's say that, right?
So let's say you're uh putting effort into growing someone in your team.
It doesn't happen in a day, right?
Like you'll have to postpone re 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 um 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 um how all of this effort is gonna pay off and getting to that moment, right?
And making peace and with with in the day-to-day with the short, with the slow feedback and with the slow um steps that we are the progress that we're making, because yeah, things will take longer.
Um, 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, this I think are are the the three things, these mindset shifts that you have to go through from one day to another, right?
Take time to to 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've been working on.
Yeah, so I really love this part of uh mindset shift that you mentioned, right?
So it in fact in the book you covered it much, much longer, right?
Um, so in depth.
So I think just to summarize the first uh key mindset shift is actually for thinking from individual to team level, right?
And then uh from just putting effort producing code, you know, as a result, but thinking about value.
Value here could be something um, you know, maybe like for business stakeholders for product, for team or whatever that is, right?
Uh definitely depending on your context, and start shifting from short-term thinking uh to long-term thinking.
So I think you mentioned uh interestingly that the one you struggle the most is the last one from short-term thinking to long-term thinking.
I think um generally also I feel that the the higher the level you are, uh, the more outcome you become responsible of.
I think generally it takes much longer to actually get the result.
So maybe from your experience here, if you can share how you can um you help people who also have the same problem.
Uh I want more like fast result, you know.
So is there any kind of um habit, mindset shift as well that you use to actually help you?
So um some things that helped me uh were specifically starting to track progress.
So instead of just looking at, okay, we want to get there, and when we're gonna get there, we'll see.
Um, 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 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, um, 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.
Um, it kind of gives you the space to reshift, you know.
So again, when when it comes to long-term plans, I think the the milestones and the tracking the slow little steps, progress are are key to keep motivated in the process, to feel like you know you're moving forward, and to allow you to do the switches needed in the in the progress.
Because when you have a long initiative, 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 readdress and readjust if you learn something new.
Um, so that's one of the of the things that that really helped me to to do this 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.
Um, so it also helps you stay grounded and and and focus on that.
What else helped me?
Well, a lot of reflection and the work with myself.
Like I've I've done a lot of taking time to um 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 you can be your personal milestones.
You want to get better with patience.
Um, I think self-reflection can do a uh a long uh 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 it's not uh it's not uh comfortable, not for you, but not for them either, right?
So I think the third part that I want to bring, which really helped me it's feedback.
So constantly keeping in track with how my attitude, how my behavior, how my approach uh 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 helped me to let go of the of the need of getting instant results.
Well, I feel those are pro tips, I think applicable, not just for tech lead role, but any kind of leadership role or manager 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 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 role is the um, 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 list 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 uh had in my past um when I transitioned from producing code, and now you have to teach others, 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 uh influence in some other ways, not code.
And the other thing is one of the uh as a result of that, right?
Because you are 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 with this uh issue of letting go of the code.
So, what do you think people should start shifting in their mind uh to address this?
So, first, just a disclaimer, I didn't really struggle with this problem myself because I always, this was one of the things defining for me early in my career in in tech, I realized I'm way more driven by the um 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 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 um 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 through 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 I uh I see people that I there I work with um navigating every single day.
So I can tell you some things that I see helps them.
First, um, I think it's about getting very clear uh why are you doing the transition, right?
So the reason that I'm saying this is because um it you're 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 it's not um 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 what's the friction there?
Um, second, it's important to understand um exactly like even if you're when you're jumping in the lead uh 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 want to 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 uh you can create a process where that can happen.
Like you can block time in your calendar, some people do the pairing.
Um, like there are different uh strategies that you can make sure to get close to that percentage, but it's all about testing.
That's a testing experiment.
It's 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.
Then the reason that I'm saying this is because I've I see uh teams where um, 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.
Um, 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 want to lead um because I want to 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.
Um, 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 periods.
So, for example, there's a period when you're 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 um, there's the period when you really have to deliver something.
The goal is clear, the scope is 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.
Um, and third, it's like you can also find different ways to fee to f stay close to tech to the code, which is not necessarily the coding part, right?
And this means I'm blocking pre people, finding problems, coaching them to a problem.
I find people find that very rewarding.
So they don't that 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 um 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 comfortable this is the um 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 unalignment 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 c 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 while give 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 uh giving up on something.
So yeah, that that that really helps.
Hopefully, this answered your question.
Yeah, definitely.
I think um it's uh it's much clearer now, the clarity that you just gave, right?
Um, 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 um I think getting the why is definitely very important.
So this is nothing technical at all, right?
So this is about yourself uh trying to understand why you are uh taking up this responsibility to be a tech lead role.
And I I think the fear is definitely in uh anyone's uh mind uh whenever they transition to something new, right?
So because before there was a lot a lot of comfort, uh comfort zone, right?
Uh 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 um, you know, non-technical problem.
Which brings me to a new segue, right?
So in in your book, you mentioned um tech is actually not a tech problem, but it's always a people problem.
So I believe every every you know, tech practitioners who have gone through their tech careers uh for a long time would understand this because sooner or later you'll realize oh, this is clearly just a lot of uh people's problem uh to solve, not the tech problem.
So tell us uh the importance of this uh mindset as well, and uh 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 um 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 want to make a decision, but it's not a problem with 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 uh 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 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 them, which is like we everybody thinks is accountable, but when everybody's accountable, no one is.
So, kind of developing the skill of asking these these questions and always going back to the basic.
Like, what is the problem we're trying to solve?
What, what, why cannot we do it this other way?
So challenging all the assumptions that are in the room, um, it really helps kind of taking a step back.
The thing that can help you most in in this um space, I believe, as a 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, when 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 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 we're trying to do.
Um 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 conversations with clients.
Um, because in total used to switch switch clients and 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, um, on that, uh just kind of driving the conversation and and 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 uh this skill, and your team will greatly appreciate it.
Like it's it's a really tough skill to to develop.
Um, I know myself because I work really hard in in developing it, but I believe it's worth every every moment you're putting into it.
Yeah, so I think the sooner you realize, right?
Um, 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?
Um, be it in the discussion meeting setup or even like with the stakeholders, right?
So sometimes uh there are some challenges that you have to deal with, uh, 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 kind of like be the middleman, right?
You have stakeholders on one side, but uh tech team on the other side, you always have to bridge the misunderstanding, the gap um between those two things.
Um and yeah, definitely if you are a good facilitator, you can kind of like iron out a lot of issues, uh be the communication problem or the direction or alignment problems, right?
Which brings me to the next question that I want to ask you, which are more tactical.
So I believe there are some skill sets which are very, very important um when someone transitioned to this role.
So I think you mentioned about facilitation skill, right?
So the other one that I I find really really challenging is actually about uh 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 uh of the team.
So tell us uh maybe the pro tips here.
How should uh one delegate better as a tech lead?
Uh yeah, this is very fresh in memory.
I just had a session this morning on on delegation with uh with the tech leads group.
So um the the the key secrets for effective delegation, it's first setting the clear expectations.
Like when you are um 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 expectations.
And this is the part that most people struggle with.
What is it that you want?
What is the outcome?
What do you 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 when delegating, the outcome on when giving it to someone else is not gonna be what the 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 mean?
What do you expect from them?
What do you expect the outcome to be by when?
Like having some sort of of the time bound.
I like to use the smart framework to apply it to the to the delegation.
I find it very effective when 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, um, actionable, relevant, and the key part is the what I add to it is the trackable, and this is the part that people miss.
So the trackable means um 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're doing, we track it there, every the whole team has access to it, you know.
There is 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 to 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 readdress.
So this gives you back, because you're still accountable when you're 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?
What did you not do this?
And this is the next step that I want to talk about, which is the strategy you're gonna take for delegation.
It's gonna depend on the task and the person you're delegating to.
The reason that I'm saying this is because for uh if you're delegating to someone that is completely able to deliver the task independently, doesn't need any support, um, 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 check-ins 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 it's 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 want to help someone grow, a way great way to do that is through delegation.
So you have a task which doesn't is not urgent, um, it 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 a way 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 as explicit, all the things that you have in your in your head, you have to make them clear if you um 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 is completely new, and then there's gonna be needed more support.
So it's the combination of the individual with the task.
Um, 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 online.
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 it.
They sound simple, but as I can see every single day working with tick tech leads, when you apply them, things get a little bit complicated.
Yeah, something simple doesn't always mean easy to apply, uh 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 uh 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 uh in any kind of leadership position.
So one other challenge um when you do this delegation and being accountable for the things, right?
So for a lot of tech leads, uh especially those who also have the engineering managers, the counterpart within the team.
Uh, these tech leads 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 a like the managerial authority for the people uh within the team.
So tell us maybe from your experience as well, what are some of the tips to actually influence someone with the authority?
Because maybe people would not listen to you because you are not their manager per se, right?
Um, 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 um 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 um 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's it just kind of can make that extra shift, which is the why I need this, or what what are the uh 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 uh even vulnerability, it's a 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 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, um, Henry, I just please can you help me with this?
Look, if we don't get this ready, these stakeholders are gonna be, or or these users are gonna when people hear the why and the impact, they have a higher tangency or or jumping in.
Because it's not just you wanting things, it's because they're actually uh 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 um to help you or to do the things without using using the power.
Something that we don't mar much use it is like you know, it's 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?
Uh, it requires a certain level of of vulnerability and courage to do that.
But even as a leader, at any level, I believe vulnerability is a superpower.
So learning to develop that even if you don't have the the official role.
Again, I think it's 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 for your team to kind of develop that psychological safety in your team and people being able to contribute.
But coming back to your point, um, so with all of these things in mind that uh they can definitely help to to basically influence people without authority.
I do have to say that uh in my experience, and I've been in that case, and I'm speaking also from from all of this these people that I've 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 is authority, like you know, we need to do this, there are expectations.
We the setting of expectations from your role, from your that's you cannot do if you don't have the authority.
So I just want to 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're starting from a different position and it's easier to make those to have those conversations.
Um, and um, 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 in your face, uh, 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 feasible.
Like if you're already doing the work, you are why not make it public, you know.
You know, I 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 it's it's hard, it's way harder.
And it's very different because the case that you describe, it's not you are in your team and you're trying like a team member and you're trying to influence your team.
And if we 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 wanted to take the ownership of making the decision.
This this is as simple as it is because you already have one, you just don't want to 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 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.
Yeah, I find that too.
That's very important part.
Yeah, it's very important.
In fact, indeed, I would like to emphasize, right?
Uh, even though maybe there are tools and techniques you can do, uh, but leading without authority definitely is difficult by itself, right?
Especially if the counterparts, you know, the the leaders, the managers who are supposed to do that uh 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 uh you can get more influence from them, um, you know, managing the people to uh follow the work that you are trying them to do.
Which you you mentioned about impact, right?
So I think maybe a lot of tech leaders are also questioning, you know, even though they seem to be busy all over the places, you know, trying to uh set the technical direction right and all that, how do they measure their impact with it 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 uh features have you built, uh, any bugs that you have found from the work that you did.
Um, so maybe as a tech lead, it's much more vague.
How can you measure the impact then?
Well, the first sign that you're doing a good job as a as a leader is the performance of your team.
So if you wanna measure your perfor your impact, your performance, you have to measure the performance and the impact of your team.
That means their results, it means like uh their collaboration, how is the team feeling overall?
Um, so it's whatever you define this team performance and team um like health, uh, 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 what 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're you're having uh uh you're missing uh you're a piece of reality there, right?
So it's constantly uh 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 the what they're complaining about.
Um so that's the second um the second tool that definitely can help you to to measure uh performance.
Um and the third that I would add here, which is uh a tough one, but I really believe it's it's a great uh metric, which is measuring how your team is doing when you're not there.
I think I really believe that a great leader um gets to a point where their team like the goal is uh they say like the goal as a as a leader it's to make yourself indispensable.
You never really get there because there's always things 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, um, 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're doing uh uh 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 for a leader because it takes some time to get there, right?
You you need some investing your time to sorry in your team and you need to get to a point in order to do the stress test.
But I really believe it's a good indication if you're doing a good job as uh as a leader.
I love the stress test.
So definitely, uh, if the tech lead uh goes away for vacation, right?
There should not be a lot of pings, issues that uh that requires a tech lead to be involved and even like solve the issue uh himself or herself, right?
So I think that's definitely uh a good uh tips for people.
Um so I want to bring up our conversation um to you know the AI AI impact.
In fact, uh one of the challenges that you say you listen a lot to a lot of tech leads uh challenges uh is definitely the impact of AI.
And I think uh we all know how AI can actually uh impact a lot of um, 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 uh some of the hypotheses that is happening um you know across the world is like team size is getting uh smaller, uh maybe less developers.
Um 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 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.
Now, um 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 uh in.
And so um I've seen what you're describing, where okay, there's less people in the team, there's more.
Where but I also seen the other extreme where there's actually more need for for dealing with the generation of AI and coding.
And so there's 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 the AI.
And again, I've seen companies with zero uh lines of code written by human, and at the same time you have the extreme with no no AI whatsoever.
So I see this daily.
Um, but regardless of it, I think your um responsibility as uh as a leader is to at least be aware of what's happening, um, and what are the tools out there and what 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 are 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 uh it's uh definitely something you need to be aware of.
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 moves 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 getting on board with them at the same um 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, or they say, but at the end of the day, we're in an 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 uh straightforward 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?
Uh I've I've seen this over and over on how it really makes it easier for you and for your team to start integrating these processes in a safe 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 your company is and what's your your area of business, or you cannot start in 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 uh 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 um are we gonna work to together uh without ignoring the benefits of the pain of the process?
So, yes, that's how I think it it it changes.
In regards to the other aspects that you mentioned, okay, are the tech lists now just gonna have an army of agents, whatever?
I to be honest, I don't know.
I haven't seen that yet, still, yeah yet.
Sorry, like just I I think that's some some of the things that we have to be curious and constantly aware of and seeing what's happening and see where where it where we get.
Um, 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 we're gonna be fine.
Right.
So definitely uh um adding more awareness about AI uh within the team, right?
Um, 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're using AI itself, what are the impact, right?
It could be some technical impact, um, maybe the amount of quality that gets produced by the team.
It could be the AI risk, right?
You know, we we have so many security issues that they're in the news, right?
So definitely tech lead uh 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, uh 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?
Um, this is uh to me personally, it it can be a great seduction that you simply forgot the other responsibility that you have.
So maybe uh 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?
In my view, I think it needs to be cautiously done.
And the reason that I'm saying this is because you're doing a big change in the process.
This is the same as I see it when you all of a sudden have engineering managers 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 have 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 you that's part of it, you want to be, I don't know, trying out something, whatever.
Just make sure you fully integrate it 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 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 selled your bug in two hours, and people like, but why do I do this?
Because there are no bugs.
Who solves this pipeline that is not working?
You know, so the reason that I'm saying is that uh 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.
Um, 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 things.
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're wrong, and it doesn't lead everywhere anywhere.
Sorry.
So it's just about again bringing the team in the journey in whatever I uh plan you have, as long as you want those results and and your results to not be impacted by the outcomes of it.
Because as we know, what might seem faster might be slower in the in the long run.
Yeah.
So definitely uh 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, let 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.
Sorry, or follow your process and do their own process.
Yeah, that's even for your example, you know.
Sorry if I interrupt.
No problem.
So let's say for the team now who has used a lot of AI, right, for generating code.
Um, 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 uh 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 uh used AI these days will get a lot of more output, um, 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.
Like the problem stays the same.
Nothing changes in the accountability.
You cannot say, Well, this day, 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 um like you like you said, you have more outcome.
Uh first, I'm not a fan of the tech lead uh reviewing every PR, even in before the the AI, right?
I don't think the tech lead needs to put their uh take and their mark on everything.
I think that's a very red sign of uh being a uh blocker and um uh a blocker for your team and it doesn't help anyone and you don't want to be there, right?
So if you're talking about the delegation and that process and collaboration, this goes against it.
So um every reviewing every PR, it for me was never uh uh a thing even before the AI.
Now, yes, the there is basically there are more risks, right?
This is what we're talking about.
There are more risks now because there's more uh ongo uh no controllable, even though I just I I've seen this uh this post the other day from from someone that I that I follow on LinkedIn, and he was saying, like, uh, but even before, like you we had so much code, like most of the code that we work uh with is code that we didn't write every single day, right?
Um, 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 investing inventing from zero these days.
So this kind of game get me to think, because even if it's like generated by 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 now just more in our face and and and bigger.
Um so uh 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 know, how fast you you deploy, whatever it is, I think uh those at least needs to be a conversation around if those still stands or if they need to change, but there needs to be some guidelines and whatever the code is generated uh or not needs to stand um stand by it.
Um, and then it comes back to how the team wants to handle it.
It's and the level of risk you want to take.
Because, okay, do we wanna check?
And I've seen teams, and I do do it every day.
Every line of the 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 it's how team does it, but then you also have teams 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.
Um, really goes uh 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 that they can address, right?
And you can also define the level of impact based on the task.
If it's something really 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 it that's a that's that's a key secret of getting people in um aligned.
Yeah, so I think definitely one thing, um, 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 uh 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?
So maybe one more question about AI impact, because we we have talked about uh tech problem is actually people problem.
So now should we consider tech problem is people problem plus AI problem, or it's still a people problem.
What do you think?
The way I see it, um, it comes back to AI being another tech tool that now we have to be great in in 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.
Yeah, so definitely I've uh still agree that uh, you know, uh AI is just another tool uh within your tool set within your tech stack, right?
Um so definitely people problem is uh what one of the bigger problem uh whenever you face uh in a leadership role.
So I think for people who are tr who transitioning for the tech lead role, do make sure to check out Anne Marie's book, right?
Leveling up as a tech lead.
Definitely uh one of the rarest uh tech lead uh resources that is available out there.
And um unfortunately we have to wrap up as we come to this uh 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 is them.
Maybe if you can share, you know, some kind of advice that you want to give to the listeners.
Um, maybe Anne Marie, if you can share your version today, that would be great.
Okay.
Um, yeah, for sure.
I'm thinking to choose.
So, first one would be uh and 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 is 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 when you make a mistake, these are gonna make go greatly with 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 how on how to move forward, um, involve your team and always think about the impact it has for them, for your stakeholders.
For I think this is gonna greatly um help you make those better decisions if you consider them in the equation at every step of the um every point.
Those are lovely.
I think yeah, those are uh great, definitely great advice uh 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.
Uh okay, so I'll put in the show notes definitely.
So thank you so much, Anne Marie, for your time.
Thanks for sharing, you know, some pro tips for becoming a great tech lead, especially in these AIA days where you know, seemingly we all don't know how to deal with it.