Tech Leadership Is More About People Than Tech

Thank you. And now, let's go to the talk. Hello, and welcome to my talk on how tech leadership is more about people than tech. So this is a topic that I'm very passionate about, and I use any channel that I can find to talk about it. On LinkedIn, in my newsletter, in events like this, thank you so much for the invite, and I'm also building a course with O'Reilly on this topic, so it looks like there's a lot of interest in it.

So in order for you to understand why I'm so passionate about this topic, I think it would be useful for me to share my story with you. So I started off as a software engineer, I've been in tech for more than ten years, but very early in my career, I realized that I was way more interested in why are we building the things we're building, and how can we do it better as a team than playing with the latest technology or the latest tool? And so I find a way to be part of those processes was by growing into a tech lead role. And so eight years ago, I came to Spain, I moved to Spain to join Totworks, which is an international consultancy company that helped me grow in a couple of years into a tech lead. And so this role was everything that I was looking for. I was part of making decisions, I was part of growing people and helping them move forward in their careers, and I loved it so much that I put so much effort into it that I burned out in the role. And so I had to quit the role that I loved, and I started digging into what exactly is it that I've done wrong that I burned out in the role. And part of that journey, I became a certified coach, and I started working with other tech leaders, struggling with the same things.

And I realized, OK, maybe my struggles are normal. Everybody is dealing with this. And so I used those learnings, and along the way, in the next roles that I picked up as a leader, one of them being product director as a startup in Barcelona. But my main focus for the past three years has been working with people in tech, helping them level up in their careers, and training tech leads to build high-performing teams. So for a big part of my career, I believed that in order to be a tech lead, you needed to be the most technical person in the room. And so I focused on that. I focused on developing my technical skills. But the moment I got into the tech lead role, I realized I had the wrong assumption. And so every time in my day-to-day, and these are just some examples, but there are many more, every time I was dealing with people, I was dealing with problems in my team, I kept on learning the fact that I had the wrong assumption about the tech lead being the most technical person in the team. So every time two developers were fighting for hours on what JSON parsing library to use, it wasn't about the JSON parsing library. To tell you a secret, they are pretty much the same. But it was about the fact that they had an internal conflict between them, a continuous conflict, so they couldn't pretty much agree on anything. It wasn't about the JSON parsing library. Or when there was too much tech debt in a project, in a team, and no one was taking care of it, it wasn't because the team didn't have the tools, the knowledge, or the resources to deal with it, but it was often because no one in the team was taking ownership in moving it forward. Or, and the team couldn't agree on a technical approach, on a technical strategy moving forward, it wasn't because the technical strategy wasn't the clear way to go. I've seen tech leaders putting a lot of effort into making it the clear way to go, like drawing diagrams or documentation, but it was about the fact that people were struggling to commit because they felt like they weren't part of the decision-making process early in the process. So they were struggling to commit because of that. And so all of these experiences, and many more, that I've had in my career, but also that I've seen tech leaders deal with in their day-to-day work, led me to this conclusion.

And that is that most tech problems are people problems. And I keep learning this lesson every single day. So in order to tackle these problems, which are not necessarily technical problems, I realise I don't have to go into deep diving into all the different JSON parsing libraries out there and convince my team which one is the best one, but I actually had to develop my soft skills or my people skills.

This is a list of soft skills that I believe that are required for a tech leader to have. It's not the whole list. The list is way longer than this. But these are the ones that I found the most common, and the ones tech leaders keep bringing it up when we have conversation. They struggle with dealing with conflict, they struggle with delegating work, they struggle with getting and receiving useful feedback, and so a very common question that I get when I share this with people is, okay, so I want to do better. I want to become a better tech leader. I want to improve these skills. Where do I start? And so my answer is start anywhere.

You have a problem with your team not using feedback properly, start there. You have a problem with your team not aligning on a technical solution, start there. Wherever you start, the trick is to make a change in your approach. Find a strategy that you haven't used in the past. Talk with people around you, read a book, listen to a podcast, whatever. Just find a strategy that you haven't used before and apply it on the process. And then reflect. Why did it work? Why did it not work? What can you take from there and adapt your process to that? Get feedback from people because the key part of the feedback is that when you are a leader, it doesn't so much matter on what you think and how good the job you're doing. It's like your input, it's not so relevant if you don't get feedback. If your team is not telling you or agreeing with you that you're doing a great job or your stakeholders are in line with that, it doesn't pretty much matter what you think.

Oh, I think I'm awesome. Well, if you don't get the same feedback from your team, then you might be wrong. And so a big part of the reflection process is incorporating feedback. So once you have all of these learnings, it's about adapting your process to incorporate them and do better next time. Even finding a strategy that didn't work, it's a step forward. You can use that and eliminate it from your resources and explore new options. So the process that I'm sharing with you here, it's not a new process. It's not a process that I created. It's actually the process of continuous improvement.

And the thing with this process is that it never ends. You can always do better, mostly when it comes to soft skills. And that idea usually overwhelms people and scares them. It's like, okay, there's always more to go. Like how do I know I'm making progress? How do I know I'm moving forward?

Well, the answer is simple. The secret to stay motivated and keep going in this process of continuous growth is by incorporating celebration as part of your reflection process. So Anna mentioned before that brag bank. Well, you can call it brag bank, you can call it brag list, you can call it accomplishment list, whatever you want. The idea is every time you find something that you're proud of, something that you learned, something that you achieved, track it. Track it for yourself. But this after you celebrate it. So celebrate together with your team or you can have your own little ritual.

I don't know, having a coffee at your favorite coffee shop. It's just about marking the moment of progress. So then it's about writing it down. I really advise that you write it down on paper. There is a process that gets triggered there. I'm not going to go into that, but trust me. So write it down. What is it, that thing, that you're proud of? What is the progress? This is going to act as an artifact for you moving forward. And there are going to be moments when you're going to be overwhelmed and you're going to feel like, oh, nothing, it's working. So you can go back to this artifact and use it to move forward in the process and see that you've done things, that you've made progress, that you've helped people. It's just a matter of keep going at it and remembering that you are a human and you're going to make mistakes. And that's okay, as long as you want to do better.

So another question that I get very often when I show people this list is, okay, but if I would be to choose one soft skill from this list and start improving on tomorrow in order to become a better tech leader, what would that be? And my answer is simple. Listening. I think these days there's a lot of noise around us. So we're doing a lot of hearing. There's like a podcast, there's like audio books, there's like talks, there's like there's a lot of information coming at us. But I think we're actually doing less listening because the type of listening that I'm talking about and the one that you need in order to lead effectively, it's active listening.

It's being there for the other person, giving your full attention, your undivided full attention and really caring about what they're trying to tell you. The thing is, the moment you start improving your listening skills and you work on them, your empathy is also going to improve because you're going to be able to put yourself in the other person's shoes easier. The moment your listening skills and your empathy skills develop, your feedback skills are going to become better because hopefully you're going to use all of this information that now you're listening to, that people are trying to tell you, in order to adapt your feedback to them to help them get better. So I think you know where I'm going with this, right? Wherever you start, you're going to have an impact on all of the other skills. There's the beauty and the pain of the continuous improvement process, mostly when it comes to soft skills. I do invite you to go through this process because by developing your soft skills, you're not just going to become a better engineer or a better tech leader, you're going to become a better human.

The only question is, if you are willing to get out of your comfort zone and bet on people. Because I'm not going to lie to you, it's tricky, it's complex. Most of the time it's uncomfortable, but it's definitely worth it. I can promise you that. Because no matter how much tech will develop, you will always have to work with people. So you might as well get better at it.

That's it. Thank you so much.

Any questions? Thank you so much, Anna-Marie. Really, really enjoyed that talk. Also, it was personally very timely for me because, what's the date? Two weeks ago, I became a team lead. So I was listening genuinely, looking for ways that I can apply this. So thank you so much. Remember ask your questions in the Slido. The Slido number, just in case you are wondering, is 1415. And then you can also catch Anna-Marie afterwards, in the speaker's Q&A. And so one thing I did want to ask, specifically, especially because you spoke about listening and empathy and getting to understand and really focus on the problems and what they're saying, because they're sometimes not the actual tech problems, but they're people problems. How do you sometimes get past the noise, especially when conflict resolution and people are maybe adding a lot of emotional weight when they're having disputes? How do you cut through the noise and actually find what the problem is, what the people problem is? Well, first thing that I would do is get away from the problem. It's way easier to solve, mostly when it comes to a conflict problem. It's way easier to solve if you don't have that initial frustration or worry to deal with it. So my first piece of advice would be just go away from the problem and from the people for a while. Take some time to think about it. Take some time to reflect. Take some time to talk with some people and get a little bit of that frustration out, and then go back and dig into the problem. A great way to do that is through your one-on-ones, which, by the way, is the first thing that I recommend. Also for you, in every tech lead, team lead role that you're going to be, this is one of the first things that I would do, which is set up one-on-ones with your team. It's a great opportunity for you to start digging into those conflicts and understanding, okay, where the problem is and how we can get to the bottom of it. And trust me, when you really want to listen, people will start talking.

Awesome, thank you. All right, we've got some audience questions that have now come in. This one's from Ade Reza. How could we find a good strategy to apply and then follow the impacts? So how do we figure out, because you said just find a strategy that you have. So how do we find one of those? I mean, for me, the best strategy to find the good strategy is to talk to people. I find that very, I mean, it's my personal style. I really like the fact that with a person I can dig into what their context is, so it makes it easier for me to pick and choose what can I use, because I think context is very important. Because most of the advice that you find in books or chat GPT is general.

It doesn't consider your particular problem. So when you're talking with a human, you can say, but look, look, actually my team member has this particular context. So you can bring that up and pick their brain into exactly how that strategy find for you. So I would suggest talking to people, but of course, there's a lot of spaces like this where you can watch a talk, read a book, listen to a podcast. The idea is to get a new strategy. Then you experiment and you will find out what works best for you.

No, you're absolutely right. Exposing yourself to those strategies means you're more likely to find one that fits you. You had that list, and what was it meant by vulnerability on the list? That's a tough one. I think vulnerability, it's a tool that tech leaders are not using enough of. There's nothing more powerful than going in front of your team and saying, I don't know. I have no idea how to solve this. I need your help. Or saying I don't know how to approach this or I haven't heard about this. That brings your team to a level of safety where they can also start sharing about what they're struggling with and what they don't know. And it kind of creates that space where everybody can work together and focus on the problem instead of just trying to hide behind the, oh, everybody should know this. So that's a great way to start. And you can use it in many other ways. By sharing your story, by sharing your struggles with your team and just kind of being human and open about the fact that you also have things to learn moving forward.

And I think part of being a lead is there's great power, but with that great power comes great responsibility. And part of that responsibility is sometimes giving negative or constructive feedback. For example, this person asked about advice giving negative feedback. Example, a bad job was done. Maybe the developer doesn't really want to hear about it. How can you find a way to communicate that for the betterment of the team? Well, I think first there are some things that you can do to avoid or reduce the risk of getting in the situation of people where people are not so open to getting the feedback. And one way of doing that is by building a feedback culture in your team from the beginning. So creating that safe space and making feedback just part of your normal day to day as a team. And there are different ways to do this. If you want to find out, just reach out to me and I can share with you.

If you want to find out, just reach out to me and I can share with you. But by building the culture, no one is going to be surprised that you go and tell them constructive feedback. Right? It's just something we do. I used to run we call it a feedback session with my team once a month. So that's kind of an opportunity, a retrospective where that just happens. So people get more comfortable into it and it doesn't become this big thing where, you know... So that can help a lot with just making people more open to this is something we're doing And it's not so out of the ordinary. And it's like what you said about vulnerability. By being vulnerable and even being able to take and point out criticisms for yourself, your team is like, oh, they don't hate me. They're just pointing out the thing that I can use to get better. So you're absolutely correct.

Another person has asked about any courses or education, maybe something more formalized for transitioning from a software engineer to technology leadership or management roles. I mean, there are a lot of those. I have a couple in my mind. I can share with you. I have a list. I can share with you the list. I mean, there's a lot of books, like for example, Crucial Conversations on Developing Your Communication Skills, which is a big part of stepping into leadership. But when it comes to very specific that transition from an IC individual contributor to the tech lead role, I think we kind of have a gap in the market, which is one of the reasons why I'm building this course now with Riley to tackle exactly this problem, which is, okay, so do you have the very experienced people and you have the people that are trying to get in? And then there is this struggle with people just starting out and don't know what the hell they're doing. No, for sure. Thank you so much.

The next question, I mean, it's 2024. I mean, four years ago, the world changed and the way we interact with people changed. And one thing which I find interesting is I took for granted how easy it was to build trust and build relationships with team members, build open openness. And so this question kind of relates to that. What techniques do you use to build trust, openness and skills in an offshore or distributed team specifically? Very good question and you're right, the world changed a lot. I think a lot of the principles that applies face to face still work, like for example, the vulnerability one, you can say, I don't know, also remote, right, in a meeting. The other way, I think it's very important for you to understand how the remote environment affects your team, right? So I think it's very important to create channels for communication and having those conversations, for feedback and for conversations, for challenging times. It's just about finding the right tools to do that. And keep experimenting with what works for your team.

I have to keep emphasizing on this because everybody's like, this is the best tool to do this. So I really think you have to adopt it, move fast, adopt it, see how it works, take the feedback from your team and reiterate on that. Thank you, thank you.

I love this next question. This is from someone who's maybe not a tech lead or not a lead yet, but how can you be the driver of change when there is communication issues or maybe some other issues, but you're not the lead? How can you almost manage upwards? Very good question. I think you have a lot more control than you think, being a team member, even if you're not the leader. And there is this thing about distributed leadership. So that's where it comes, where you have different people in the team that can take leadership responsibilities and ownership even if you don't have the title. And I think that's a great way to grow. But coming back to the question. So it's just about taking initiative, right? So like the tech lead is able to say, I don't know. You start by saying, I don't know. You start by asking those questions. When you're in a meeting, you know, and you have this question that you're not sure what they're talking about. Be the one that asks that. I can promise you, if there's something that you don't get in a meeting, there's going to be someone else in the team that also doesn't get it. And it's going to be very grateful when you're asking that question. So it's about identifying these little opportunities where you would like something from your leader and you just step in and do that. And second, I'm going to wrap it up on that. Give feedback to your tech lead or tech leader and tell them what you want from them and ask them how they can help you and ask for their help.

Now, this is kind of maybe a bigger career kind of conversation. And you're a coach as well. I often think like, especially as you start to grow in your career, get more experience, especially in lots of companies that have like L1 to L6 or some equivalent of that, you kind of get to this fork in the road where there's management, the management chain, and then just specializing even more as an engineer. What are some of the advantages and disadvantages of each chain? Maybe there's someone here who's trying to decide which one works for them. How would you go about picking which one? Yeah, so I think this is a common problem that I deal with. A lot of people that I work with come to me with this question. We usually start digging into what their needs are. Because until now, everybody kind of have a preference. They just might not be ready to accept it.

They just might not be ready to accept it. People kind of know what they want. It's just they might not be up there. They're afraid, oh, I'm in writing the right career move. What's going to happen if this or that? Right? So they're kind of afraid of accepting that. But I think it comes back to understanding what your strengths are. So that's a key part. Strengths are natural things that come natural to you and you assume it comes natural to other people, but they don't. So understanding what your strengths are, understanding the things that you enjoy doing and how do they fit into the roles, and keeping in mind that it's a reality. When you move into management, I mean, again, depends on the context, and I know companies that have leaders in tech that still code on a daily basis, but it's very important to know that you're going to be doing less coding. So if that's what you want, and more people. Way more people. Regardless if you want it or not, and regardless if they put it on the job expectations or not. Right? So I think it's just important for you to be aware of that and know how is that going to impact you. So more people, spreadsheets and slideshows, less writing code. Are you sure you want to make the switch?

Okay. So another question was do you have any advice on how to apply these techniques when the effort is not really being reciprocated by others on the team? I can understand how it can feel very frustrating to someone who's trying to make that difference. Yeah. I've definitely been there. I think that where I would start is to try to find an ally in your team. Right? So that doesn't necessarily have to happen in a team forum. You can have some one-on-ones with your team. Try to identify people that agree with you on the problem and start supporting you. Go to your leader, to your tech lead in the team, and tell them, hey, I think we have this problem. Do you feel the same? And then allow them to give you a voice. It can come easier. You want the improvement. It doesn't matter if it comes from you or not. But you can ask your tech lead to support you in whatever it is that you're pushing for.

But you can ask your tech lead to support you in whatever it is that you're pushing for. And last but not least, consider that you might be the only one having that problem in the team. If people don't really put the effort in supporting you, it just might be something that you'll deal with. It doesn't make the problem less important, because it's important for you, but you might need a different strategy to work on it. I love that. I love that. And also sometimes take a reflection on yourself. If you're the only one complaining, are you the common denominator as well?

Okay, next one as well. I know we've gone through a lot of questions, but we've got a little bit more of time. But how do you keep up the energy? Because, I mean, just improving yourself takes a lot of energy. Like you said, reading all these books, doing all these research, faithing takes a lot of energy. How do you keep... I don't want to say motivation, because maybe it's a bit of motivation, discipline, but how do you keep that momentum going? Yeah, I mean, one of the secrets I already shared in the presentation is keeping track of progress. I mean, that sounds so straightforward and everybody talks about it. Accomplishment, leagues, Brad Bang, whatever. It works, people. It just works, right? It requires that extra effort to write it down, to think about it. A simple way to make yourself go through that process is by building your CV. In your CV, you'll have to think about what worked well. So that's an exercise that I actually do with people in boosting their confidence and motivation. The second thing that works for me, it's important to know and keep in mind that it's not like you can always improve at the same speed. It's okay to take breaks from improvement. I sometimes say, look, I had enough. I don't want to learn more. I'm okay. I want to stick a little bit where I am now and that's okay. So I think it's important for you to constantly be aware of where you are, where do you want to get and how that impacts you and keep staying in the process, right? That's the key. And it's okay. There is no rush. There is no, you can always be better, but it can also redefine.

Taking time off for improvement can do great for your improvement. Awesome, awesome.

We will wrap up with this question. I know you said you had a list with all the books and different resources on leadership. Where can people find this list and where can people find out more about the work you do?

Yeah, LinkedIn. I'm all day there. I'm sharing resources, I'm sharing tools, I'm sharing tips, and I'm also writing about them in detail in my newsletter. So please feel free to check it out and please reach out to me. I reply to every single LinkedIn message that I get and I'm more than happy to help you with anything that you're struggling with. Thank you. Awesome. Thank you. Can we give Anna Marie one more massive round of applause? Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.