 So, it's a fifth Europe item for me and it's really an honor speaking at Europe item because the energy and the vibe is really good. I really love it and it's a good conference. I'm Radoslav Georgiev. So it's Radoslav Georgiev if I say it in my native language or if I try to make it sound a bit more English, Radoslav Georgiev. Sea of Hacksoft, which is an end-to-end software development company based in Bulgaria, that's Eastern Europe. Yep, that's pretty much about it. And as per usual, the goal of this talk is to be practical, pragmatic and provide value for all of you. Me just doing this talk, it's kind of whatever. The main idea is some of you to get something from this talk and try to apply it or read more about it or research more about it. So that's the general idea of this talk. And the context pretty much is at Hacksoft we are currently growing and since we are doing end-to-end software development, we form quite a lot of software teams and when you have quite a lot of software teams, you need to have leadership. It's really, really crucial. If you don't have good leadership, you cannot grow. You cannot do your job well. And the other interesting thing about leadership is that it's hard to hire from outside. Like I'm just going to hire five leaders. There you go. Start working. You usually have to put in the work and grow them naturally from within because leadership pretty much is bound to the context of your specific company culture and the way you do things. So that's the context I'm going to speak from experience. And the agenda that we're going to cover is what's the role of a team lead, managing expectations and responsibilities, unfolding potential communication and at the end how to know if we are doing a good job. So that's pretty much it. And let's start with this. For us, software development is a team game. With opening a bracket, you can achieve a lot doing it solo. You can be pretty happy developing and working alone. And this is okay, but in our context, it's a team game. You either win as a team or you lose as a team. It's really hard for someone really, really good just on his or her zone to have an impact. So we have to be pretty good at team games. And we form teams for quite a lot of reasons. It's usually to solve problems, to build something, to do research, but we form teams. And by forming teams, this means getting a group of people together and setting some kind of a goal. And when you gather people together, call them a team, hand them over work, leadership is going to be established. And there are pretty much two options. Inside are going to be implicit leadership, which means nobody knows who the leader is, but also everybody knows who the leader is implicit. It's this person over here, or it can be explicit leadership like it's communicated. This is the person that's going to team lead this specific team. And since we are at a Python conference, explicit is better than implicit, at least from our experience. And it's always a good idea to have an explicit team lead, or at least start with saying, this is going to be the team lead. And this is going to be the person who's going to carry out the responsibilities of a team lead. So when you form a team, there is going to be some kind of leadership establishment. It's good to make this explicit. And the main idea of this talk, the point of view, is going to be, you are a newly assigned explicit team lead. You've been a software engineer up until now. And from now on, suddenly, snap, you wake up, you are now a team lead. And what now, what do we do now, what's changing for us, and how should we approach this? So perhaps the first important step, if we are in this situation, is to figure out what's the actual role of the team lead? What should I do? I now have a new title. The first thing that I'm going to do is change it in LinkedIn. Okay, check. Get some positive feedback from close friends, and what's next? So at least for me, it pretty much boils down to two things. And the first thing is achieving the goal, because you have a team and this team has a specific goal to achieve, whatever it may be. And it's usually the responsibility of the leader that this goal is achieved. If the team fails, it's the leader that's responsible. So that's the first thing. And the second thing is, of course, you should not forget that you are responsible for a group of people, so you should take care of them. It's like, if you just put the spotlight on you, and I am the team lead, and I am going to make everything an aye, aye, aye, aye, aye, you're kind of forgetting about that you actually have a team, and this team needs to do some work in order to achieve this goal. So you need to take care of them. And this picture with puppies. And this involves... I was looking for a picture of pushing and picture of pulling, and all the pictures were terrible. And then I found this where it involves both pushing and pulling in a single picture. So it involves quite a lot of pushing, which means you need to go around and push people to do stuff. But it also involves quite a lot of pulling, which is setting the direction and making sure everyone is committed to that direction and they walk on their own, like you're pulling them towards this goal. The other thing, and this was a big surprise for me when I started doing more leadership and team management and software development, is involves quite a lot of orchestrating, which means things are happening with or without you, and you kind of need to figure out where you need to jump in, where you need to just let go and don't do nothing, and where you need to direct and focus energy. And for me, the analogy is you're waving your hand and trying to orchestrate everything so it sounds good, because if an orchestra, everybody plays whatever they want, it's going to sound, but if it's going to be good, not really sure. And again, the second point, it's about enabling. So this image should communicate the word enabling. You need to enable the people, and if you don't enable the people, it's going to be pretty much there is work to do. Everybody's going to crunch it. You can push them, you can use authority, and most probably you're going to get the job done, to be honest. And this is the case in some places, let's say, and you can do this for quite some time, but you will end up with a team that just waits for something better to show up, and they will leave you. And this is not, at least for me, not a good way to form teams and not a good way to make something that's long-lasting. So it's kindling the fire within the people, and that's enough with the pictures. I just had an inspiration with using pictures for slides. And your thing, you're a newly appointed team lead, and if you're experienced before this, this is in software engineering, and suddenly you realize you have the responsibility for moving a certain part of the project and getting a job done, you might say, okay, what I'm good at? Software development. So I'm just going to do all the work, no matter the team. I know what to do. I will put in hours because I have this new responsibility, and most probably you will be able to do this. But this, as you can imagine, is, again, not a good long-term and long-lasting strategy, but there's a but. I think if you are new in the team lead kind of sphere, it's a good idea to do this mistake a couple of times. Like really, really try doing all the work so you can convince yourself that it's not a good idea and not a reliable strategy. It's kind of a rite of passage. Sometimes you need to kind of do it in order to understand why people say you should not do it. And this is, yeah, at least in my opinion, it's a good thing. And then you realize that it's not about doing all the work, but rather filling the gaps. Sometimes you need to fill the gaps and you need to jump in and just be there because you might not have all the resources. It might not be the perfect scenario, but it's more about filling gaps. And when people, for example, ask me, what do I do? I'm a gap filler, basically, in the company. That's all I do. Figure out where the gaps are, fill the gaps, push things forward. And there's something else. When you are the team lead, another set of forces start applying. And those are the outside forces because from now on, for this particular team, someone else, if someone else wants to communicate something and does not know anybody else on the team, it's going to be like, who's responsible? Who should I call? And that's the team lead. So that's another set of forces that are going to start working on you. And you're going to have internal forces also pushing towards you. And it's a good idea to realize that you're both external and internal buffer. Sometimes you need to buffer. Sometimes you need to react. But those forces are going to start applying. And if you're not prepared, the question is, okay, something's pushing me. Should I do something about it? Like, there are some folks in the team that are not playing very well with each other. Should I do something about it? Or there is a manager that wants everything shipped for tomorrow, if possible. Should I do something about it? And sometimes, yes, sometimes no. But the important thing is realizing that you are actually a buffer. And sometimes you need to buffer. And sometimes you need to kind of redirect energy and reuse the energy that you've buffered to push back, for example, or to manage if this is needed. And I said the keyword for the next slide, which is managing expectations and responsibilities, which turns out to be very, very, very, very important. And it sounds really boring. It sounds like a corporate talk from now on, where we're going to talk about expectations and responsibilities. It is actually really important. So let's see why. Imagine the following scenario. Everything's going well, but you know that Bob is not doing his best, for example. It's, you have this internal feeling. He's not doing this particular thing that I really want Bob to do. And then, as you are thinking this, your second thinking, your internal monologue, says, but have you told Bob you are actually expecting him to do that? And you're like, well, no. But Bob is smart enough to figure this out by himself, for example. And this is a really common pitfall. And it's really easy to get frustrated when you are in a team leadership or team management position. It's really easy. It's like your day job is to get frustrated. You wake up and frustration floats all around. And the thing is, frustration is actually really good. With time, you will start loving it because this is a clear sign, at least for yourself. You're frustrated with your team, which means you need to do some communication, some more communication, some more expectation management. Tell Bob that this is actually expected from him explicitly. And those are the responsibilities. Tell everyone. And that's why it's important because otherwise you start getting frustrated. And if frustration is kept within for too long, then bad things are going to happen. And at least from my experience, this is how it goes. You write down how you see it as a team lead. And then you go and talk individually with everyone and then as a group, how they see it. Iterate, negotiate, communicate. But the final thing is you need to handshake with everyone. For now, for this week, for this month, those are going to be the expectations, those are going to be the responsibilities. Does everyone, or do everyone, I'm not sure, does everyone agree with this? Do we have agreement? And if you have agreement, then you can carry on. And this is really important because if you manage the expectations and responsibilities well, you will achieve something that's usually referred to as team alignment in the big books about this topic, which if you have team alignment, then you've done your, at least you're doing your job that's expected from you and you're doing your job well. Because I really love this analogy. If you are driving a car with misaligned tires, even if the road is really good, and there was an Eastern European joke here, but I'm not going to say it. And even if the road is really, really good, but the tires are misaligned, your head is going to be bumpy. It's like the driving wheel is going to be like this. You're like, okay, the car is good, the road is good, what's happening? The tires are misaligned, most probably. It's the same thing with a team. Like it's a cheap analogy, but for me it's the same thing. You have really good people inside, you are doing your best, and still it's not working out. So most probably you need to kind of better align, I think. And how team alignment usually goes is it's a good idea to write things down. As with expectations, like write things down, have some documentation. This is how we do things here. This is like the team alignment. This is how we do things in this team, and we are aligned for this, which will give better visibility of team dynamics, more explicitness, which as we will see is a recurring theme of this talk, and it's great for onboarding new people because you can have a great team, but if nothing is written, like the team dynamics are implicit, because you've worked for a year, you know each other very well, and you know the expectations, you know the responsibilities, suddenly new folks come in, and they're like, what's happening? So team alignment should be explicit, should be written down, it's great for onboarding, and again it's not setting stone. As with, oh I forgot to, yeah, as with managing expectations and responsibility, it's, this is not a process, this is actually good, and I forgot to talk about it. Once you start leading and managing, sometimes you get this, you tend to talk at your Python and you say, okay I'm going to manage expectations and responsibilities with my team, things go well, everybody's happy, six months down the road, same problems, same frustration. So usually those things, especially when working with people, they're not like, let's set up the CI infrastructure once, and I don't have six months down the road, go and set it up again. It's like, if it's working then it's working, I don't have to do anything, but when you're working with people, it's usually you have to do it now, and you have to do it a month later, and you have to do it a month after this, and it's basically you have to do it indefinitely, because people tend to forget, things change, and if you want to be explicit, you need to do it very, very often. And I think this is quite a big shift from doing software development work and doing leadership work. You do things once they work, great, I don't want to touch this again, with people you have to do things more often. Yeah, and the same thing here with team alignment, it's not set in stone. You can misalign at some point, and you need to align again, so it's again explicit, regular thing to do. I have time, I have slides, this is good. And now to my favorite part, when you are leading a team, you need to unfold potential, you need to spread the wings and feathers of people. It's really, really important, because there is a high chance for both you and your team that there is unrealized potential, which means you can get better, your team can get better. There's really, really high chance. If there is like a team where everyone reach their ceiling, that's great for sure, but most probably the ceiling is up there, you're still somewhere here, and you need to see where the ceiling for you and your team is. And more or less this is up to you, this is up to the team lead to, at least this is how we say in Bulgaria, I'm not sure this is proper English phrasing, but to realize your potential you have potential to realize it. And it's a fine balancing act, because you need to balance between comfort for people and something that I love this terminology called proximal development, quick parentheses. So proximal development is when you give someone a task that just on their own, they won't be able to do it, but with a little bit of help pushing, nudging, they will do it. And this is what development looks like with a little bit of help, people start getting better. So you can push this zone further and further with more difficult tasks, and this is how you develop people. So to unfold potential, it's basically a balancing act between comfort and between proximal development, because comfort is good. You know, it's just not going to be this kind of a talk where I'm going to say for 45 minutes, get out of your comfort zone and do things because everybody's saying this, so it must be true. Comfort is productivity. Sometimes you need your folks and you to be in comfort so you can be productive, so you can get some job done, some work done. But if you stay too long in comfort, you might get lazy. People might start thinking they know everything and they need to find another job because there are no challenges for them, but it turns out all along you are just keeping them in comfort and kind of creating a false idea about this. So comfort is good, but you need to balance it. And the same thing with proximal development and making people struggle, because when you are in proximal development, it is a struggle because you cannot do this on your own. That's the definition. And if you push people, if you go to the other extreme and just push people and go do hard things, go do hard things, people might learn that they cannot do things on their own, which is not good, because you will then give them a task which is perfectly fine for their skill level. And they'll say, but I need help. You don't need help, you can do it. But if you have been here for too long, then this might be the case. So it is a fine balancing act between those two. And at least from experience, what I found is if you can somehow explicitly communicate and manage expectations about this with your team members, it's better. It's like we need to ship something quicker now. So we stay in comfort, everybody plays to their strengths. Like you have a really, really, really, really strong front-end team member who wants to do something, for example, back-end work. For now, you stay in front-end. This is not going to be forever. But for example, for this month, we need to ship this thing. And you need to get everybody's, I think, buy-in was the word for it, or you need to align again everybody what you're trying to do and what you're trying to achieve. So again, it's a lot of explicit communication. And again, I said the keyword communication. Going to the next slide, just going to drink water. It's really important to establish a good form of communication. But what does this mean? This is a good question. At least what we try to do is to over-communicate, which means communicate more than needed, which means sometimes being connoined. Like, let me again restate everything and I'm looking at people and if everybody rolls their eyes up, it's good. We know it. We continue. So over communication sounds bad, but I think it has more positive effects than downsides. It's less likely that your people will leave because they're annoyed because you talk too much. They might start memeing you for this, which is good for company culture, than people living because they're not feeling well in this particular team with this particular leadership. And an anecdote from experience. More channels, less DMs. Sometimes we form a team and we join an existing company with existing software development team to help them for a couple of months. And we join, we now use shared Slack channels, but before this, you kind of join their Slack or whatever they use. And all the channels are dry. Like last message was two weeks ago. And our first question is, is everybody on a vacation? No, no, no. We're here. We're working. Then why all the channels are dry? Are you using Gmail? Hoping, no, to say no. No, no, we're not using Gmail. No, no. Your side of relief, okay. But why are there channels that we're not included in? No, no, no. Those are all the channels. So where are you communicating? It's everything is in DMs, like two by two, two by three, which is, at least in my opinion, really bad because it fragments the information, silos things. And especially if the communication is about work, not talking about personal stuff, this should be kept in DM. But if it's about work, it's much better to communicate in channels because sometimes people will just read and feel what's going on. And when all the communication is happening in channels, the team leads and the managers can spot something which might be an alarm for them and follow up on this. And this is really important. If all the communication is in DMs, at least for me, it's not a good sign. And of course, we are now in the era of remote work. It's again annoying having to, if you're doing like eight hour Zoom calls a day, I'm sorry for you. I am a guy who if a meeting can, if one hour meeting can be reduced to 15 minutes, great. If a 15 minutes meeting can be reduced to one minute meeting, let's not do it at all. But sometimes you need to have faces because if you're not working in the same office and you're not seeing with your teammates, it might get a little aliny. I cannot say this word, sorry. You will start distancing each other if you're not seeing faces. So turn on camera. It's good to see faces. Like you need to be okay in the face, then you can wear sweatpants and just be comfortable. And the other thing that we found out from experience, which is again, sounds like a corporate talk, one-on-one meetings are really essential. And if I just put this light and say this thing here and you Google one-on-one meetings, you will find that there are not a couple, but plenty school of thoughts about one-on-one meetings. Like people saying, you should not do project sync in one-on-one meetings. You should not talk personal stuff in one-on-one meetings. You should always coach and mentor in one-on-one meetings. But in the end, you should do whatever you want in those one-on-one meetings. Because this is the time between you, the leader, or the manager, and someone from your team to talk. Regular, every week, recurring event in the calendar. Highest priority, meaning if there is another meeting overlapping with your one-on-one, the other meeting moves, not your one-on-one moves. It's really important. Highest of the priorities. And then you figure out what to talk about. Sometimes it's going to be project sync. Sometimes it's going to be coaching and mentoring. Sometimes it's going to be just 15 minutes of small talk, which is also good, because you're building a relationship. This is about building a relationship and getting to trust each other. So the folks in your team will come to you and say when they have a problem. This is what you want to achieve. Otherwise you're, do you have a problem? I'm poking you. Do you have a problem? It's like interrogation. And that's why one-on-one meetings are really, really, really, really important. And you should do them however you like and you're seeing fit. And being explicit helps a ton, again. At least for me, this was a big problem, because I was always thinking they know what I'm thinking. Everything's going good. But it's not the case. You have to be explicit. You have to explicitly state things, even things that are not, how to say, positive or comfortable. At least in the beginning. But this will build trust. And if you have trust, the rest will come, let's say. And I still have time. I still have slides. So it's going to be no slides, still time, so we'll have time for questions. At the end, what does team growth look like? Meaning you are a team lead. You've been doing this for, let's say, a year. Things are going well. You have this internal feeling that things are going well. And now the question is, how do I measure it? Or what do I look for? And for measurements, I'm not going to talk because I don't have experience with this. How to measure if you are an effective leader, like with metrics. But it's rather things that you can spot. And at least internally, we have this definition called rhythm, which is an entire article, which I'm not going to explain right now. You can imagine that rhythm is a flow state for teams. Like personally, you can be in a flow state doing work and making progress, rhythm, flow state for teams. So if you see that your team is in a flow state, is in rhythm, that's a good sign that you are most probably doing your job well. Alongside your, as we said, it's good to have explicit leadership. But people are people. And alongside your explicit leadership, implicit one is going to form, nevertheless. Unless you're some kind of authoritarian leader and you don't allow any kind of leadership. This is not what we want to do. Implicit leadership is going to form. And this is a good thing, especially when you start spotting it. Because when you start spotting it, you can start using it. You can start relying on people to help you out. And this is a really good sign that at least maybe you're doing a good job. See? And the ultimate test, of course, is what will happen if you suddenly disappear? It's a bit, I don't want anybody of you to suddenly disappear. It's like a little bit morbid. But what will happen if you decide to change jobs? New career opportunity? You're changing? You're leaving your team? What will happen? Because if you do your job well, you're going to have implicit leaders. And most probably those implicit leaders, someone will rise and become an explicit leader. So this is an interesting thought experiment. Just sit down, get in the mood for thinking, and ask the question of what will happen if I suddenly disappear, work-wise. And this can give you insights of what to do better, what to improve, what you're not doing so as good as you'd like to. And personally, at least for me, this is one of my biggest motivations for doing this, seeing people grow and develop. It's a really good thing because first, they are happy about it. Second, you have more people that you can really trust and rely on and not do all the work that needs to be done. So it's really a win-win situation. And of course, leadership is a vast topic. It's an important topic. And I was really thinking about what to recommend. Like, there are plenty of books, but I don't want to put like six books on the side. I just want to put one book. Most probably you know about it, but this book has references to other books. So what you can do is get this book, read it, it's good. It's really good. And then just do a breadth-first search on the references mentioned in this book. And you will most probably find something that speaks to you. Because that's the other important part. You need to find something that's relatable to you because you might read books that you're not feeling it, but for sure there are other books that you can feel, you can relate to, and you can improve. But this book is really good. Really, really good. Highly recommend it even if you're not in a leadership role. And then a lot of references. If you follow the references, it's going to be more than enough. I'm going to tweet it. Why not? And yeah, I think that's it. That's still time. No more slides. Time for questions. Thank you. Yeah, thanks very much. So if you guys have any questions, please walk to the mic. Hi, I just want to say that's probably my most favorite talk so far. And as a new team leader, it resonates with me a lot. And I have a creepy feeling that you've been watching me for the last half a year or so, because it covers all the areas that I struggle with. So it's a very short, a very good intro. Like you are new, how not to lose your head. And for me, the question is now, I don't want to always deal like all day, just with Google Meet, Google Calendar, Slack, email, Google Sheets. I am still an engineer inside, right? So how do you balance it yourself if you actually still do it? And how can you actually save your sanity and still be able to be passionate about engineering part of it? Got it. That's a good question. Not really sure I can properly answer it, but at least for me, for example, I'm still doing some engineering work, although I should not be doing it. And I know this, but yeah, this will come. And if there is no other way of doing engineering work and you love and like doing engineering work, I think open source is a good way of venting this energy. So at least this is my opinion, but I'm pretty sure there are folks here with better answers about this. But I got you. Take care. Thank you for your really great talk. I have a question about assigning tasks, because you mentioned that it should be balanced between a comfort zone and development and so on. How it corresponds to using methodologies like Scrum, Kanban, and so on? It's a personal, yeah, very personal question, because I have a lot of problems with this, especially with Scrum and assigning tasks based on... It's both of us. Yes. I just rolled my eyes when I heard methodologies. For example, we don't follow any particular specific methodology and we have the freedom to do it, because we kind of assign ourselves to the work, but I really cannot answer this. If someone can answer this, I would really like to listen to this talk. Someone with more experience, how to balance those things and fit within a corporate structure that requires you to also fit within some structure. But I cannot answer because we're not a corporate structure. We don't have experience with this. Thank you. So thank you for all this wonderful packed information about unfolding potential... Yeah. You said that, okay, sometimes we need to push people outside of the comfort zone, and... But one other thing I'm thinking is that some people, everyone has some superpower, and sometimes you don't know it, and people, if you don't ask them, they don't tell you. They'll think, I'm just going to do my job here, and if they ask me something, I answer, otherwise. So how do you learn that your team has... The members of your team have these feathers so that you can help them unfold them and gain from that? That is a really good question. One of the ways are by talking regularly to them, which is the one-on-one meetings, and the other... So it really depends on what's your style of leadership and management, but sometimes you can just shake things up. We're changing roles for a week. For example, this is only that we've been experimenting for some time, like assigning a team lead for this particular week, or just changing roles, or just rotating, so you can see how people act in different circumstances, but I'm still learning, because I really cannot answer... Give you a comprehensive answer about this, but for me, shaking things up when you have trust established might do the trick. Hi. Hi. Thanks for the talk. You talked about communication and seeing the phases from time to time. What do you think about remote work and coming back to the office? Is it... I feel that it's much better to be in the office in terms of communication, and do you maybe impose or in your company like a couple of days a week or a month or something so that the teams gather? So we are a relatively small company, 25 people, so the policy is do whatever you want. Work is hybrid. You can work from office. You can work from home, but the teams themselves, they kind of try to see each other at least a couple of times per two weeks or per month, or if it's been a long time where we haven't seen each other, then, for example, I try to step in and push some kind of team building activity that we can do just together. So, again, sadly, working with people and leadership is so about knowing your people and having an explicit baseline of rules, but then trying to see that this team is not communicating very well. Let's see what we can do about it. But remote is great. Hi, thank you for your talk. It was awesome. So I have a question. Can you tell us about a situation in your experience while leading teams? Like something that was totally unexpected for you? I believe some of the changes are common, but something that you totally did not expect. Okay, so I will mention two things. The first is I was really not expecting people. When people start realizing their potential, it's a game changer because then you can relax and rely on people, which is a great feeling. And the other thing is I have not mentioned conflicts, but the other thing is that you need to be prepared and aware that conflicts are going to happen. And even if you're doing the best and having the best leadership, people are people and conflicts are going to happen. And again, you need to resolve them with more explicitness. So those are the two things. Yeah, thanks for the insights. And I wanted to ask a question related to keeping your sanity. Now specifically regarding the buffer part. So you can be pushed a lot maybe by an external client. You may have also additional responsibility than just leading the team, like keeping track of deadlines, budgets. And so you may be pushing yourself also. And how do you stay sane and keep your team sane while at the same time managing to, you know, keeping track of the budgets and deadlines and whatnot? That's a good question. Most probably in most cases, you're going to have someone else being like a manager or a lead for you and you should leverage and use this. And if you're like feeling a lot of pressure, ask for help. It's not all on you. In our situation, it's a bit easier because we work with end clients and sometimes when we get too much pressure or we cannot work with those clients, we're just like, it's not a good fit. Here's another company. We're going in a different direction, but it's all about how much freedom you have to maneuver. And if you don't have much freedom, then you have to use the tools that are given to you. If you have a manager or a leader yourself, use this a lot. Like communicate, talk about different situations and how they would handle them and just use the tools available. And sometimes you just have to say, no, push back. This is not a career advice because again, we're not in a corporate environment. And most probably if you put me in a corporate environment, they're going to fire me after the first month. So I may not be the best person to answer, but this is what I do. Thank you. Hi, thanks for the talk. So you mentioned channels versus DMs. How do you suggest to push people towards the channels? Because you set up the channels first week, it's fine, and then they kind of are empty. My suggestion would be to be very annoying until people start communicating in channels without going to straight up conflict, this or that, like setting ultimate items. But you can nudge people and be very annoying, and most of the times it works. But it's about explicitly communicating and a team alignment. Team alignment. We're going to communicate in channels and we're going to discuss it. We're going to agree on it. And now if people are not doing it, they break alignment and then you can be more... So harsh is a bad word, but this is the word that I know in English, let's say. You can be more harsh with them and say, all right, we have alignment, but you're not following the alignment, so let's resolve the conflict. But be annoying. It works. If I may add a comment on this, I've seen that keeping irrelevant people out of the channel helps much. Because sometimes I've noticed the director or the division director is in the channel just because they like to take a look at everything and then people don't want to speak on the channel. Yeah, that is a good comment. And sometimes, for example, developers might not feel the freedom to express themselves if they're way too much upper level and senior executives in the channel. So then just create a channel where the developers can communicate more freely. This works, yeah. All right, thank you very much.