Anemari Fiser—400 tech leads, same problems—none of them technical

This talk addresses the primary challenges that tech leads encounter during coaching and training sessions. The speaker, who has over 12 years of experience in various tech roles, emphasizes the importance of understanding the role of a tech lead, which is often plagued by confusion regarding expectations and responsibilities. Through real-life examples, the speaker illustrates the significance of gathering feedback to assess performance and aligning expectations with team members, particularly when transitioning responsibilities. Additionally, time management and the ability to delegate effectively are highlighted as essential skills for tech leads, as they balance multiple demands. Strategies for giving constructive feedback and the necessity of clarifying priorities are also discussed, underscoring that many tech problems are fundamentally people problems.

No, no. Okay, we have it. Um, so welcome everyone for the next, let's say, 40 minutes. Uh, I'm going to share with you the main challenges that tech leads consistently bring in coaching and training sessions. So, uh, very quickly a little bit about me. Uh, I've been in tech for more than 12 years now. I started as a software engineer then moved in different roles software consultants

uh tech lead engineering manager product director at some point uh but my main focus for the past five years has been training and coaching techies in buildings building their soft skills particularly tech leads and building high performing teams so I work with a number of companies in different um environments with different cultures um so the learnings that I'm going to share with you today are coming from

that experience I want to start by showing you the definition of the tech lead. So the tech lead is a software engineer responsible for leading a technical team and accountable for the technical deliverables of that team. Now why is it important for me to start with this definition? It's because there are so many uh definitions out there on what the tech lead is. Depending on who you're

talking to, you're going to get different answers. I'm always surprised on how even working with people in the same company, I hear different um responses when I ask them. Okay, so what are the expectations um from a tech lead? I'm just curious, do we have any tech leads in the room? You raise your hand only. Oh, I see a number. Perfect. Thank you so much. Um don't

worry, it's very relevant even for uh the ones that you're you're not a tech lead. Um you can you can learn a lot about the challenges that you might face at some point. Um so yes there are a lot of definitions out there on what this tech lead actually is. Um this might even change you know like this this is based on all of this experience that

I had and and talking with so many companies and this seems to be the one that everybody seems to agree with but I heard the other day that the tech lead is g is just going to be an agent orchestrator. So you know um this might change but for now and for the sake of this presentation and I'm referring to the tech this is what I'm referring

to. So this confusion around the role and what exactly it's doing and what are the responsibility that come with the with the role of course makes tech constantly think about what exactly do they expect from me which brings us to the first challenge that they consistently bring in coaching session especially um which is am I doing a good job am I a good tech lead so this

particular tech lead came to me um some some months ago and he said look I'm very worried I'm not sure actually if I'm if I'm doing a good job. I I feel like I'm everywhere but really not not sure if I'm I'm fulfilling all the responsibilities and all the expectations that that people have from me. So in order to tackle this, we started by uh understanding exactly

why how does he defines being a good tech lead like what does it mean for him? What are the expectations that he has from himself in that role in that company at that point? Then we looked at the expectations that the people around had on him. So I asked him to go uh and get feedback well to get uh information from the managers and from his team

and from the all the stakeholders that were willing to talk to him uh and share their their view on exactly what is it that you expect from me and then um also looking at the job description. So, I know this sounds very straightforward, but I'm always surprised on how people don't read the job description in their company for like years. Sometimes it doesn't even exist. Yes, that

that also happens very often. So, once he got clarity on what exactly like getting an an overview over all of these different expectations that are out there, he realized that a lot of those weren't aligned between themselves or between the ones that he had and the ones that they had. So the next step was to go back and make sure that um he aligns the expectations. So

for example um it's very common for um junior developers to expect the tech lead to do to take all the technical decisions, right? They see the tech lead as the person that has the most knowledge um which very often happens that that the the best programmer in the team is uh promoted to the tech lead role. And so in this case this tech lead this was not

the way he wanted to run things. He wanted a collaborative environment. He wanted everyone to contribute. So him making decisions for the team wasn't really the way to go. And so he had to go back to all of these people and kind of make sure he explains um and aligns everyone on okay so this is exactly what you can expect from me and how do I plan

to run things just to avoid disappointment in the future. The next step was um him assessing himself on all the areas like the expectations were clear. Um like just we did a quick 10 one to 10 um scale assessment on okay where do you think you are and why is that we can use different things but this was kind of just the easiest and then I asked

him to also get feedback from all these uh all his stakeholders and his team and all the people around product and um just kind of getting feedback okay how do you think I'm doing in all of these different areas that that they are expected from me now after reviewing all of these data the conclusion he came up with is that he was doing a pretty good job

surprisingly. Now this is not the outcome that I we always get. Um so depending on on the on the context depending on the person sometimes um very often people out of this process they get like gaps or they identify areas that they need to focus on um that they need to improve which is a great way to move forward. But the learning that I want you to

take out of this story is that if you're not sure if you're doing a good job as a leader, as an engineer, as a professional, just ask for feedback. At the end of the day, when we think about growth and the way I define growth, I think about impact like how does your behavior, how does the things that you are doing impact the people around you? How

many people impact and how does your behavior like uh gets to them? So, if you really want to know if you're doing a good job, just people around. The second challenge that tech leads constantly bring is dealing with their time. Of course, this inconsistency in what exactly a tech lead is makes a lot of tech lead, especially the one they are just starting out to try to

fit into everyone's expectations, right? So, they just try to do everything. They are all over the place. um they are like working a lot of overtime and um they are al al constantly feeling like they they're running out of time and not nothing gets done. So I have a particular case um in which this this techly came to me and she told me well I have no

time for strategic work. Um, and the the the reason why this was a problem is because her manager uh came to her and she and told her that you're doing a really great job on the day-to-day, but you should be putting more effort in planning ahead for your team identifying issues and just kind of um like overseeing what's what's going to happen at put some more thought

process into it. So, in order to tackle this, we started by looking at all the things that she was taking care of at the first things sounded very um straightforward like managing stakeholder, managing like different cross team initiatives, doing some coding alongside the team, managing the backlog together with product. Uh but then some red flags started to pop up for me and that is that she was

facilitating all team meetings. She was driving all the one ones. She was um running and um owning like all the growth plans for all the different individuals in in her team um and also running all the is on boarding. So basically yeah doing everything for her team and her team relied on her for everything. So in order to approach this uh I asked her to identify some

activities that she could share with her team and after a lot of debates and conversation we she managed to identify the the yellow ones that you can see her here that she felt comfortable with um starting to uh explore sharing with her So then I asked her to pick one, one place, one initiative, one um responsibility that we can start exploring and experimenting with. The one she

picked was the 101. So just for context, she was spending a lot of time getting ready for this one ones. She would review notes, she would look at their growth plans, she would just make sure that each individual um it's covered, that they have what to talk about, that it's interesting, that it's relevant. when the point of 101 ones um is that you show up for the

people in your team for your team members and you are there to support them and they are the ones that have to make the most out of this 101 ones for their growth. So in order to um switch this um 101 agenda ownership back to to her team members instead of of her owning everything, we started by her going back to her team and saying, "Well, I'm

not bringing topics anymore. You will have to bring topics. I don't know how you're going to do it, but I'm not doing it anymore. Second, that's this. Um, doesn't work anymore. What happened? Oh, okay. It's working. Um, the second step was uh using the time. So, I mean going and setting the expectations worked for some people. They came in the next 101 ones and they had things

to discuss, but for some didn't. So for the one that didn't, I encourage her to use that space um to discuss okay why there are no topics. Is it a trust problem? Is it a I don't know what to talk about problem like what exactly is it? So um she identified a common theme which is they had not they had no idea on what and how would

be useful for them to bring up in those in those conversations. So in order to come with ideas to share with them, I asked her okay what are the topics that the people that actually came prepared brought to you like what did they want to talk about? And the recurrent topic was things around individual growth. So how can I go to the next level? How can I

develop this particular skill? And then she brought this to all the other peoples that were consistently like that didn't know exactly what to talk about and she used the one ones to help people grow which led to uh taking another responsibility out of her plate. Um and that is basically supporting their growth instead of leading instead of driving their growth. Right? So instead of her making the

growth plans and being blamed for when things were not going in the right direction, um just going in the in the in the support role and allowing people to to own those processes and just her being there to identify opportunities and um find options for them to help them grow but not owning that process for them. So by this time our coaching relationship ended um but she

already had more uh more time in her She started booking some blocking some time and started thinking about okay what are we going to be working next thinking about some risks uh but she also felt less pressure by this time she was already eliminating things from her uh plate and she understood a very key lesson which is going to help her basically start handing over a lot

of more of these things and that learning is that you as a tech lead you are accountable for making sure that all of these things get done but the whole team is responsible. So you have to learn how to bring your team into the journey and rely on them uh and build together instead of just you running everything. The third struggle well um this is usually comes

together with the time management one because usually people that struggle to say no um struggle with time management. Let's see. I'm curious if you're willing to share and raise your hand if you struggle in the past or you're currently struggling with saying no. Okay, I see a couple of of uh hands. Thank you so much. Um so yeah, it's a common it's a common thing um especially

in in overachievers, people that really want to to help and and be there um for their teams in different roles. So this particular client um she came to me and she said look I I really struggle to to push back and to say no to people. The problem is that I just feel like um my day is being run by someone else's agenda. I feel like everyone's

else problems gets done minus my priorities. So in order to tackle this we started by looking on okay what is important for you now? What are your priorities? putting that down on paper is there what happens? Okay. And then um you I encourage her to use the uh to use the time like basically to start pushing back um for and just saying look every time someone comes

to you with a request no matter how big or how small just ask them and tell them look I'm going to come back to you. Let me think about it. let me um just give me some time and I'm I'm going to I'm going to come back to you. So, the idea was for her to not say yes on the spot anymore and get a little bit

into that uncomfortable space of um it's okay to say no. So by the time she started doing this, you already started seeing the results because uh by just by getting some um some some time just by not responding in immediately or making their request a priority, she saw first that nothing bad happens like people were not reacting very aggressively to the fact that she couldn't she was

just saying okay let me think about it. Um and second she realized that most of the time when she was going back to people they already solved their problem by the time she came back. So it's like there were other ways for for them to solve the issue without relying on her. So the next thing that we did is I encouraged her to use the time that

let me think about it time to um take the requests every time there is a request coming in from an external request coming in to evaluate that against her priorities like how is this going to affect the things that I need to focus on right now. What needs to be dep prioritized? What does this actually means and how is going to impact me? then thinking about, okay,

why would you say yes to this request? Is it because it's in your responsibility or is just because you're trying to be nice or just because you um you're just feeling like you should be available and and reply to everyone's requests. So, just kind of spending some time in that uh thought process um can really make a difference. And the third one is actually thinking uh what

happens if you say no. So um just kind of exploring that space in which uh what are other options that you can still support them with their problem without you being the one jumping in or without you being the one doing the work. So in this case you came up with some great ideas like pairing that person with another one that can help them or sending them

like some resources like just you get creative the moment when you ask the right questions. So the learning here is that you need to have your cl your priorities clear and you need to defend those priorities because at the end of the day everybody else is. So you might as well um have to learn to kind of stick um up for for yourself also. And this is

going to be in your benefit but also in your team benefits because usually um tech leads that are very helpful and always there and always answer all the questions they get their teams very um comfortable with do with them doing that. So they get very comfortable in not trying too hard anymore. Right? So just like instead of trying to get the answers or trying to look up

for for answers somewhere else, they just go always to to this to this tech lead and they just rely on them to give them the answer. So have your priorities clear um and make sure you constantly iterate over there because they change um and they're going to help you to push back and stay um and and and say no to to things. The next challenge is people

struggling to give constructive feedback. And when I mean constructive feedback because I know there is a debate around it. Um I mean improvement feedback like okay what do you need to change in your behavior. So um this challenge comes in different forms. Sometimes tech leads come to me and tell me I have no feedback to give. I'm not sure exactly um what what to tell them. like

I know I should be giving feedback but I really don't know. Usually that's a matter of just um re refocusing on on addressing this challenge. So here in this case we look at things like how to pay attention to things that are happening for a certain individual in meetings and just kind of noticing how they're behaving. Maybe they do a presentation just kind of seeing what what

they're doing and actually being intentional about trying to get information that can help you and you can provide to help this person grow. Keeping notes and tracking notes on your one-on- ones on different conversations can really help or sometimes even reviewing what happened in this past week and how this individual was involved in that can already give you some ideas on things that you can share. There

is always feedback. Honestly, there is always feedback. It's just a question if you're willing enough to put the intention in there and the time and the effort to find it. Sometimes this challenge comes in. I don't know how to give feedback. And then we look at things like proper preparation and doing some um like we do some role playinging in in um in our our conversations and

kind of just preparing them for it. We look at the right timing to deliver the feedback or we use tools like SBI. Let's see who who here knows what SBI is. No, no one. Okay, I see some hands. Perfect. Thank you. So, it's basically a framework to deliver feedback which based on situation, behavior, and impact. Um I find that um techis love this kind of frameworks make

things way easier to structure your um your communication and your message and it reduces a lot the chance of people being uh aggressive or defensive when they're receiving the feedback. So if you're interested just come and ask me and um I can share more about it. But the most common challenge um that comes when it uh when we're talking about giving constructive feedback is and this particular

client he came to me and said I want to I have to deliver this feedback to to this individual but I'm very afraid they're going to get um they're going to react let's say aggressively or defensive or I'm not going to know how how to handle their behavior. So in order to tackle this um I started by um exploring uh and and we started by exploring together

all the scenarios that they were afraid of particularly the one that they were most afraid of. Okay. So what's the worst thing that you imagine that can happen? By doing this process um he identified that a lot of the scenarios that he had in his head in his head were really unrealistic like they could not happen in a professional environment. Second um by going deep into the

actual cases that maybe there there's a possibility that they might happen. He realized he had a lot of um options and a lot of ideas on how he might tackle them. So he felt way more comfortable in going and having that that conversation. So the learning um that I want to share with you is that um in my experience I see that our brains tend to make

the problems bigger than they actually are. So if you're feeling stuck in um uh holding back in giving this constructive feedback or even sometimes making a decision, what can really make a difference is getting out of your brain and when you feel like you're you know you're spiraling and overthinking and you cannot just move out of it. It can really help for you to uh write things

down. So just putting on on paper all the processes that are going through your through your mind or talk it over with someone. It would be great if it would be someone that would have like some um proper listening skills that that can guide you through the conversation like a mentor or a coach um that can really challenge in whatever you're you're thinking. It really speeds up

the decision process. Uh but yeah, just get out of your head and this is greatly going to help you to um to move forward. The next challenge um it's around delegation. So when it comes back to that time management, we all know that one solution is to delegate things. It's also a great opportunity to help your team members grow. So yeah, delegation it's a big topic when

it comes to tech leadership. So this particular client, he uh she came to me and and she told me, "Look, I want to delegate more. I know I have to. I want to get time more time for myself and I want to help my team um develop some new skills that I constantly feel like I'm I'm the only one having in the team but I'm afraid because

the last time that I delegated a task let's just say it didn't turn out the way I was I was I was expecting so I delegated this technical task to this senior developer in my team and after three weeks he came with something that um was a little bit on online uh in line with what I was expecting, but he missed a very key edge case that

it was so obvious and I don't understand how how he missed that. So, I'm afraid that this is going to happen again. So, I I asked her, okay, if you are so sure, it sounds to me like you are very um it was very clear to you that this edge case needs to be um needs to be taken into consideration. So, why didn't you tell him at

the beginning of the delegation process that he needs to take this into account? And she told me, well, because he's a senior engineer, he has a lot of experience. He should know this. This is common sense. Well, people, the problem with common sense is that it's not that common. And depending on who you're asking, you're going to get different answers to what the definition of done is,

to how um to what good looks like, um to what quality looks like. So instead of just kind of assuming that everybody um runs and instead of just running on common sense, you better make sure that um that you're align on on that understanding. So once we left this assumption aside, assuming that okay, it's common sense and everybody's on the same page, we started working on how

we can address the main challenges that come when uh and the main fears that come when it comes um when we talk about delegation. So in this case the fears were that the outcome will be different than what I was expected that the quality will drop if I don't do it myself. Uh or that I will lose all control over how this task is going to be

run. So how people usually describe this fear to me is like I'm going to give this task away and there's going to be three weeks passing and I'm not going to hear about it and then uh this person is going to come back with the outcome and it's going to be completely different than what I imagined and I will have nothing to say about it because it's

going to be too late. So in order to address all of these challenges there's a very simple strategy and it's so straightforward. um you probably heard it everywhere but still people don't do it and that is setting clear expectations first on the outcome like what do I expect at the end of this delegation process what are the artifacts that need to be delivered what are the edge

cases that I imagine you're going to tackle what are the the deliverables very being very explicit about what you have in your head if you would do it yourself like what would you expect the outcome to be very uh clear on the timeline. So I see more and more companies uh working um like avoiding discussing deadlines. I don't know if you also see this like it's kind

of no no we don't we don't tell our developers about deadlines. No, this scares them. They get freaked out and we don't want to put pressure on anyone. Well, let me break it to you. There's always a deadline. The only thing is if you're talking about it or not. So making it explicit to people in the delegation process on okay by when this needs to be delivered

are there any milestones in between that they need to be aware of is going to reduce again a lot of um the chance of things going off track and you being disappointed. And last but not least agreeing on a way on on a way on how we're going to work together. And this is the part that most people miss. So when it comes back to that control

and people being afraid of not having um any space to kind of review and just kind of taking giving this thing away uh also a lot of these tech lead that I talked to they are very afraid of micromanaging also. So in this case when they're delegating something they don't want to go um like pitching at people and just kind of hey how are you doing? What

is the status? have you been making any progress because they're worried about not hearing anything any So in this case um this uh she went back uh in this delegation process and she agreed with the person that she was delegating to that they're going to meet every week and they're going to discuss about okay how uh is the task going are there any problems are there any

um like risks that they need to that they need to discuss but also this would give her the chance to basically bring up um like jumping if they need to change course or if there's a really big risk she could feel in control. So by applying all of this process um things changed radically. Um we started like at the beginning with very small task and just kind

of applying the process getting trust in the process but over time um the task that she was delegating were getting bigger and bigger. Um so it weren't were uh really great but the secret is basically here in setting this this these clear Now the learning here is that most problems in tech teams come from people thinking they are on the same page when they actually aren't. Let's

see how many people agree with me here. Okay, I see I see some are not sure. Um probably you haven't feel enough pain yet but yes I you can trust me on this that uh usually the most uh the most problem comes when you when you leave the room and um and you feel like okay yeah we know everybody's on the same page. we know what we

have to do and then you go back into the next retro and no one has done the actions because we never agreed on who's going to do what but you just thought your your team member is going to do it. Um I have this um fun fact I have this um habit that I I I do as a as a leader. At the beginning at the end

of each meeting um once everybody agreed I just um share my screen and I open a document. I said okay sounds great. Just give me two minutes to write this down. Whatever I understood that we're we're going to do and who's going to be doing what. So I write it down with everyone in the room. I assign the people who like on the task and there's always

always someone in the room that tells me that's not what I got which is exactly that what I was expecting because um that's that basically triggers people to to share like that's not what I'm signing up that's not what I understood and then we can have a conversation about exactly what did you got um and making sure we are on the same page. So constantly validate that

you are um that you are agreeing and writing things down the way you understanding makes uh it's a great strategy to do that. The last challenge that I'm going to share with you today um comes from this experience that I had with this um startup. So they worked on this initiative like companywide initiative. There were like three teams involved um and and three tech leads um and

it went completely wrong. It took them they they released but with like six months delay. Um and basically when they tried to integrate everything blowed up as it usually happens. Um so my role was to come in and help them troubleshoot exactly what happens there like what uh what when these things that the these things got completely out of hands and what they could have done better.

So the first question that I asked these three tech leads already showed the bigger biggest underlying problem in the process. So I asked them who owned this initiative. The first tech lead told me oops the first tech lead told me the product manager, the second tech lead told me the engineering manager and the third one said the CTO but they weren't really sure. Um so this underline

a couple of of problems because there was no clear owner, no one overseeing um all the process on the high level. There was no shared timeline whatsoever between these teams. There were no enforced expectations that each team was basically planning their own individually. So of course when they try to integrate everything blowed up uh because there was zero coordination on the big picture. So the learning here

is that when everybody is responsible no one is. I'm a true believer of clear ownership. So um if you are currently in an initiative in a project whatever and you cannot pinpoint on who's owning this and when I refer to the owner it doesn't mean it's the person that is doing all the work is the person that makes sure that the work gets done. Um so if

you cannot if you're thinking about okay who owns this or you're not sure or you're having double um doubled uh thoughts um thinking about it or you hear different people having different understanding of who owning this um then um there's a high risk that this project is going to go off track. So it might be something that you want to um to look into. Um so these

are the main challenges that tech leads consistently bring up in trainings in coaching for the past five years. Work with over like close to 500 now of of them and this keeps coming up even in the AI area today. So you would think problems change but surprisingly no. So what looks like new problems um we have things like this again doesn't work. Okay let's try again. It's

gonna perfect. So what looks like new problems like how do I find time to um to learn and keep up with AI goes back to this uh unclear expectations on what is my role with AI and how how am I supposed to support the team in this progress goes back to time management and properly re-evaluating your priorities and understanding what should what you should be focusing next

and of course comes back to delegation everything that is related to time management um also it's related to delegation or the CEO opening a PR in a repo in the middle of the night. Apparently, this seems to be a trend these days. Um, so yeah, a lot of tech leads come to me like, "What should I do? How how do I handle this conversation?" Well, this challenge

goes back to the ability to say no, to push back, to give this um this feedback in regards to how you're feeling and how you think um and having the conversation on how things should happen. And basically it's definitely a a sign of a clear lack of alignment on how how we should be dealing with this situation and how we should be integrating this in our processes

if it's something that we want to do. Um or there is a high pressure these days especially with AI for teams to deliver faster. I actually a tech lead came to me the other day and and he told me well my manager came to me and said I just got your team five uh cloud licenses. now you should be going way faster. I expect you to deliver

three times uh earlier this initiative than we had initially planned. And he was scared and he was like what am I going to do because this is not how things work. We also need an on boarding phase into the tools and everything. So the um the the the main thing here is that this also shows a very clear lack of an alignment and ownership on okay what

we should be doing this. What does it mean being faster? Uh what does it mean still having quality? How is this affecting our ways of working processes? And yeah, a lack of proper communication and and agreement on that. So the learnings the the good part is that um whatever if it looks like new problems or old problems, the same strategies of tackling them apply. The fourth one

being gather feedback constantly. If you want to know how you're doing, if you're doing any changes or any process in your team, outside of your team, the only way to really know if you're uh if whatever you're trying to do is working is if you ask people around you, especially as a leader, your perspective uh on how you're doing, your gut feeling, it's only one very small

variable in that process because at the end of the day, as a leader, um your definition of success relies heavily on how your behavior is being um how it impacts the people around you. So the only way to know if you're doing a good job is to ask constantly the people around you. The second strategy is to con consistently share the responsibility with your team. So learn

how to rely uh on your team, how to bring them in conversations. Um I can tell you that um actually the more you have uh the more the earlier you involve your engineering team and everyone in the process of the decision making so from the starting of a project the higher the motivation and the commitment people have because um the especially when it comes to decision making

people um that were there part of the decision- making process um they are way more committed because they felt like okay I made this decision, I agree to it. It's way harder to just push back and say, "No, this is not something that I want to be doing." So, it's actually um a secret. Um and I know some there's going to be some friction and people are

like, "Yeah, but it's going to be more conversation." But in the long run, um you're reducing the friction that is happening later in the process. The third one, have your priorities clear and constantly uh reiterate over them and make sure you're focusing on what's important for you, for your team. uh because especially as a leader, people are going to go all over that and things are going

to change from one day to another. So, it's important for you to be able to stick to what you think um it's important right now and what has the highest impact. Um learn to give feedback, not just constructive improvement feedback, but also positive feedback. Um I actually think this is one of the reasons that people struggle so much with um with constructive or improvement feedback. It's because

they only give improvement feedback. So then the idea of of feedback is directly associated with something bad, something that I have to improve, something that I have to work on. Now imagine if you would incorporate the positive feedback in your in your culture, in your daily culture, right? So if you would um also tell people hey how good of a um job you're doing and in every

feedback conversation you would have also the part of what I appreciate and what are you're doing um right now imagine how that would change because then would that would open the space for having conversation consistently um and would lead the intention towards just helping people do better not just telling you what you're doing wrong. Make expectations explicit. No matter how clear you think you are, just reiterate

over it. Um you know there I mean these are there are studies on it. It's not me coming up with it but at the base of high performing teams there is overcommunication. actually the best performing team that I was part of um we um we applied this overcommunication strategy and um it can be annoying like even in my team people complain why do you have to repeat

things so many times well because it works because when you have when you're not afraid of asking the question because you should uh you should know the answer already people feel way more comfortable to to continuously learn and continuously having the the right conversations and Last but not least, constantly validate that you are on the same page. Now, all of these learnings um and all of this

experience and everything that I heard today in these earlier talks and everything that I keep reading keeps get uh getting me to the same conclusion over and over again and that is that most tech problems are people problems. So, if you wanna even in the AI area I can promise you that. So if you want to challenge, if you want to tackle the tech problems, you have

to look at the people behind them. All of these learnings and all of these um like strategies that I shared with you, I cover them um in depth in my recently released book with O'Reilly, Leveling Up as a as a tech lead. Uh which I have two copies of here for the first two ones that are going to ask me a questions. It's also signed, so it's

a nice extra. Um so yeah, thank you very much. That's it. Any questions uh in your interactions with this tech leads? What is the question that you felt was never asked? What is the problem that they have not expressed but you were seeing it already? Very good question. Uh the problem that they never asked. Well, I think I think every every problem that is being brought to

me, it's never brought on the real um like they don't say it with their own words. So all the things that I shared with you today actually didn't came up directly. Like people don't come to me and tell me well I have ownership problem. they're like I have this problem sorry I have this uh project that is getting delayed or is getting completely um sidetrack so it

actually takes a number of conversation and digging into to to get to the underlying issues so what I what I shared with you today it's basically here it's um already filtered process and information uh but if I have to think about like one thing that I think people struggle with and they don't uh like text struggle with and they don't they don't bring up as as often.

Um I think it's um their fear of um of not being good enough. So I think I I see this a lot like when it comes to all of these things like saying no or pushing back or giving feedback. Um I think the underlying fear and again something that I I no one comes to actually say it is that they are afraid that who I who am

I to kind of challenge people on this um on these topics and uh do I actually have enough knowledge to be going around and so there's a lot of self-doubt happening in especially in the tech space and it's a lot related to that lack of feedback but also that lack of clear clarity on what it's expected from people. Yeah. Did I answer your question? Awesome. Who's next?

Go. >> I have a question regarding do you have any special tips for tech leads who are in a team which is remote and or working in different cultures? So in different countries, different cultures then might clash right. So you have any any thoughts and tips on that? >> Yes. Um actually a number of teams that I I was part of I was leading and a lot

of of tech lead that I work with they are in part in exactly that situation especially these days with the remote environment and people like moving all over it's very common that uh you have a very crossunctional team people from all over the world like from different um cultures um so some tips that makes it easier I guess the first one it comes back to that overcommunication

especially when you have so many like dynamics and so many different um uh like say um perspectives in the team. Um I think having that proper um like constant um overcommunici where people can ask questions and it really helps to build that psychological safety because in the end in order to have a high performing teams you need that psychological safety and that overcommunication constantly repeating on what

are we doing why are we doing what um and answering those you know stupid questions that you should know the answer to over and over again really contribute to creating that space. Second, it's um consistent uh and transparent communication. So, I'm a fan of documenting things as I told you the example with like just at the end of the meeting taking the document and writing things down.

I just feel there is something about having something written that kind of creates as a non-verbal um contract, you know, that just because you you read that and you you agree to it, it's kind of you're committed to it even if you don't sign anything. So um that's like transparent communication where everybody has access to um to the information and to the decisions and the um all

the conversations that were um happening in the process of making those decisions. And third the consistent communication. So even in the remote environment um the the teams that I was uh leading we always had consistent um communication. True, of course you have different ch channels, but I think um having those recurrent uh progress meetings like okay, where we are, what are we doing? Uh are we on

track and kind of being very I was always very transparent with my team if there was a problem if there was pressure coming from stakeholders. I think it really helps to connect the engineering team with um the business and everything that is happening. So kind of acting as a channel of information instead as a blocker between between it. So yeah this is what I would say overcommunication

consistent uh communication and Other questions Thank you uh for the presentation. All of the points are kind of assuming that the person was rightfully assigned or promoted to the role. But have you had cases when like the person should not be a tech lead? And if so, how do you identify? >> What do you mean they should not be a tech lead? It means um they would

be more successful as a individual contributor working on what they were assigned or what they identified and that's it. >> Yes. Um actually I was working for a company that um they promoted or they're they start they just created this tech lead in their company. they didn't have it before. And as usually happens, they just they just took the most high performant engineer in each team and

they promoted them to to the tech lead role. Now, um things and so they brought me in to help them grow because they were struggling as you would expect. uh because they all of a sudden had this all of these new responsibilities wasn't just the tech that they were used to but they also had to do people management and performance reviews and feedback and tracking and alignment

and stakeholder management. So yes I had these cases what very often happens is that in my um coaching sessions I would have conversations with them and trying to understand if they really want to be there. So the outcome was that with some of the um some of those tech leads they actually realized that this is not for them and they switch back to to engineering. Uh at

the same time I was discussing with stakeholders because I had like their their ear um and I was able to um to kind of facilitate that process for them of transition. So they actually kept u their their salary increase and uh they were able to switch back to the um to the to the position before and they promoted other people that were more interested in handling these

people side in those roles. So I guess coming back to your point yes it happens very often that tech leads are um being told that they are a tech lead and they don't want to be there. Um I've seen people grow into the role. So some people are like I really want to give it a try. I want to try to develop those skills. So, we start

building a strategy for doing that. Um, but yeah, some realize in the process that it's not for them. Uh, but I also think the only way to really know is if you try it. So, if you're not sure, try it. >> Thank you. >> Anyone else? >> Other questions? Sorry. Come on. We have time for one more because I speak a lot. I don't realize We have

one more question as a team lead sometimes what I have and I want to be very open to the whole team. What am I doing and what are they doing? So basically one of the problems that I always struggled with was the competing lists of to-dos. So for instance we make a we always have like okay this is the work right and then you have another list

which you create when someone from another team says let's discuss this. There's another team which is the whole support which is other teams. there's a new team, there's a new list that's created that every time you do a review of something or so all these things tend tend to go into different documents or in different programs. Now it's easier these days because you can basically use the

MCP tools, bring everything together, try to put them in a certain order. But for me in the past this was a problem because I forgot about things that I said to someone until they had to tell it to me. How do you solve this? >> Well, I have to tell you the answer it is it depends. So what I found is that each individual tech lead kind

of solve these problems in a way that work for them. So for me particularly I'm very structured. Um, so I would just have a place where I would keep all of these different list and I would consistently review them and kind of making my own list of of priorities. Um, but I've seen tech leads that they would just uh get things off their plate. So um, a

very good way of kind of freeing things up from your plate is delegation is delegating entire initiatives. So one of those list like collaborating with a certain team on a certain initiative um you can delegate that to someone in your team and they there are these roles like feature lead and then they can take all of that to-do list and deal with it. So that's another way.

Um, but also there's a very cool uh strategy that I've seen working with especially techies that struggle with with with this time management which is creating off uh I will not worry about it right now list. So one thing that I've noticed is that yes you have all of these list but what actually it's going to get done. So you know you look at this list and

there's all these things that you think yeah they will be nice but I know I'm not get get I'm not going to get to them. So basically cleaning up and putting this into I will not take care of it for now really helps freeing that mental space and kind of making a constant decision on what actually you're going to be you're going to be focusing on. So

yeah, there are different strategies for for different individuals. Um, and I think everyone kind of have to finds their their own u their own way. Um, but constantly re re-evaluating okay what's important and finding ways to bring the team like delegating or bringing them into the process can reduce a lot the overload and the in the management of this list. Yeah. Does this this helps? You're not

sure. We can talk a little bit more after because I'm out of time. That's why I have to wrap it up. Thank you so much everyone. Have a great rest of the day.