 Thank you everyone. I'm Radislav. I'm coming from Sofia, Bulgaria, all the way to Switzerland and this is my third Euro Python and also this is my third time speaking at Euro Python. And I'm really happy and I'm really grateful for having this opportunity, so thanks for having me and I hope this will be a good talk for you. Go of this talk. As always, I want to be really practical, really pragmatic and I want to provide value for you. So you have 40 minutes spent really well here in this room and actually the thing that I'm looking for is this aha moment. Let's use this from this guy's talk from this very particular slide. So this is my and go if at least a couple of people have this aha moment, then I'm going to be happy because I have provided value for for someone. So context, I'm the CEO of Hacksoft. This is a software development company and we develop software for our clients and we usually our clients rely with their businesses on the software that we develop. We develop the software in teams, of course, and in order to have a stable software and happy clients, we need to have a pretty good teams. We need to have productive teams that can ship quality software and not break production every day. You know, this is very important because otherwise clients are losing money and this is how to say it's very important thing. I will provide some cherry-picked examples from the last six years from being a team lead on several different teams and I hope this will be valuable for you. The agenda will jump straight into the topic. I will talk a little bit more about the team leader's perspective. For me as a team leader, what I care for and what I optimize for. After this, I'm going to talk a little bit about software development and what kind of problems we can have there and how can we solve those problems. After this, we're going to talk about features because after all we create new features for our clients and in the end we're going to finish in a phytonic way with a section called explicit is better than implicit because after all we are at Euro Python. So team leader's perspective. Aside from being the CEO of the company, my day-to-day job involves developing with Python, with Django and with JavaScript and I'm a team lead of several teams at the company working for different clients. So I've developed this perspective because at some point I said to myself, okay, I have a team, things are going well, but I have no formal education for this and I have no idea how I'm actually running the team. I have to formalize it. I have to write this down because if I want to transfer if I want to transfer my knowledge to someone else then I really can't do it because it's all in my head. So those are kind of the seven things that I care for and that I optimize for when I'm running a team. And this is what we're going to cover. Like we are going to have problems that impact on those seven things and we're going to try to solve those problems. So first of all, productivity. This is very important. We have to ship software to the clients. We have to have something working used by end users being on production. I think we can all agree this is very important. We need to ship software. So first of all, productivity. Second of all, I want my team to ship features with confidence because if we have a pretty unstable production and I believe you've seen this, people will be hesitant to merge pull requests and to deploy to production because they know that they have to fix other things, regressions, you know, constant regressions. And we want to eliminate this. We want to have higher confidence because this will make the team better and they will enjoy the work they do. Also, we want to have independence in the team. As a team lead, I don't want to be the bottleneck of everyone. Everyone asking me questions, oh, Rado, should I do this or should I do that? Well, I don't know. Figure it out. Run several tests and you can pick the better solution. So this is quite important. We want our team to be as independent as possible. Also, well-being. If you're working on a stressful project and you're stressing your team like more than needed, they will burn out. And when your team burns out, then you, as a team leader, you're also going to burn out. And when you, as a team leader, burn out, then the software is going to burn down. Software doesn't burn out. It burns down. Everything's going to crash. So this is quite important to have a healthy team because if you push your team too far, everything will eventually crash because software is created by humans and humans need to be in an okay state to do this. Also, something very important for me, less context switching. Being a developer, it's very important to be in this flow state. We all know the flow state. We're working on something. We are in it. We're wired in a couple of days in a feature and we're feeling pretty good. And suddenly, people start asking us different questions on topics that are not related with what we do. And if this is happening constantly, then we'll be constantly breaking people's flow, which means they will be less productive, less happy, and this will increase the stress level. So my philosophy for context switching is that the team leaders should handle most of the context switches. This is part of the job and that's why it's a hard job. And you should reduce the context switches between the team. There will be some, of course, but you should try to reduce them because then people will be productive and they will carry on the tasks they have to do. Also, someone being blocked. This is my favorite. You have a team of five. Two people are working like crazy. The other three are just, what should we do? You have a task, but we are waiting for the client. Have you asked questions? No. And stuff like this. You have to observe people being blocked and not working. You have to make sure everyone has a good knowledge on what they're working on and there's nothing blocking them or if something blocking them resolve it immediately, otherwise there will be people working like crazy and people just idling around making coffee. And of course, the last thing, which is really hard to quantify, but it's the team morale. This is the general feeling of the team. Are you going to work every day and you feel the team is like, there are better things that we can do, especially that right now it's summer in Bulgaria, or the team is like, we're shipping something quite interesting. Users are going to use it. We want to do this. We kind of enjoy, we find meaning in what we do. We kind of enjoy our job. So this is something that is, again, really hard to quantify. But as a team lead, you can get a feeling of the team morale and it's really important to keep that up. So I will go one by one, cherry picked examples, going for the aha moment, this makes sense. And I guess we'll have time for Q&A at the end. And the first thing that usually happens when we're developing software in a team environment, and it's a low hanging fruit, are the constant regressions. You know, constant regressions, what do I mean by that? This is production going down every hour, every day, something breaking, you create a new feature that breaks several other features. And the reason for that most often is because you have a client and the client says, all right, let's do a quick proof of concept for two weeks. We just want to see if this is viable. You do the quick proof of concept, of course. And then the client is happy. And without telling you, the client is now onboarding on your deaf environment actual users, your deaf environment becomes production environment, and the clients start pushing you for new features or completely right of everything. Because for the clients, when they see something working, they want to be like new feature, change thing, new feature, change thing. They want to be like snap and have the code base changes. You know, this is how clients think about software. And we all know this is not the case. So usually fixing constant regressions involves, and as I said, this is a low hanging fruit, those things stop all feature development. This is really working. You know, you say to the client, all right, we're stopping for, I don't know, a day, two days a week. And we want to stabilize things because we cannot develop like this. We need to make this proof of concept a proper production setup, add some tests, refactor some of the code because we've been cutting corners in order to make it for the two weeks because you have a presentation at some conference, but now let's make it stable. And this, if you explain this well enough to the client, it usually works. Also, it sounds strange, but add a continuous integration and please have tests because you may say, well, every software development project project has tests. And I will say to you, no, we are constantly having requests for, can you take a look at this seven years old Django code base? That's huge project that's running mission critical stuff for the business and has zero tests. Oh, and the developers, by the way, they just left us. So we need someone to figure this out. So this is very important. Have a continuous integration, have tests. We'll talk about tests later and at a staging environment where you can safely test and break without a problem. And this is fine. Now we have higher confidence because we have staging, we have tests, we have CI. Then all things are going well. You start working on different features. And this is a case that I observe very often. For example, we have Ivan and Maria and some other folks Ivan is working on a specific feature. Maria is working on a different feature. Those features have nothing in common. And let's say we're running in a Django environment where we have an app and we have our services PY file where we put our business logic. And this is just one Python module. And since Ivan and Maria need to write something related to this app, which is a new feature, they're going to write it in the services PY file. And because we've started small, we also have a simple test services PY module where all the tests are for the different services. And meanwhile, to spice things up, other folks are fixing existing services. And guess what happens in the two yellow boxes? Like constant merge conflicts, constant merge conflicts, because we're trying to, after all, be productive and move fast, move quickly, ship features. And this can be very, very frustrating. And it's very easy to do something about it. And since we're working in a Python environment with Python language, if we have a services PY module, we just make it a module that's a folder with sub modules inside and split by domain, split by features. The thing that we try to do is to isolate different people working on different features in their own files. This gives effect. And it's a nice way to kind of separate people, not stop stepping on their toes. And diagram wise, it looks like this. We just split the services in different features. We do the same thing for the tests, because I usually see people splitting the features, but not splitting the tests and ending up with test files with two, three, four thousand lines of code that you need to split because first it's slow in the editor to load all of this. And then it's really hard to fix merge conflicts that spans two different test cases for two different things. Sometimes get this funky. So with this, when you see it, you can optimize it. We usually do it when it's needed. We don't start with let's create an architecture for this, because this project is going to take five years to make. We don't know this. But when we identify we are running in some merge conflicts in some part of the code base, we try to split things around, we try to figure out abstraction. So this is not happening. All right. And then we continue. Local setup. This is a specific type of hell. And I love it. If your local setup is not okay, your developers can't even start working on their features. This is like maximum level of frustration. You have to do something. This something is required by the end of the week. It's easy. You know what to do, but you can't get your local environment running. And it's really, really, really, really frustrating. So my job as a team lead is just to sit down and make sure everyone, for example, has accounts for altered parties that we're using. Zero, go cardless, AWS, Mandrill, whatever, keys, accounts. I want to know that everyone on my team has the proper access to whatever is needed. So when they need it, and I do this before it's needed, because when they need it, it's already there and they won't be pinging me. I have to go out of context and create this for them. And the thing that really helps is organizing, keeping a spreadsheet, you know, if something is really hard to do in your head, if I'm running a team of two people, I don't need a spreadsheet because two people, everyone has access, you know, but if your team grows bigger, it's really hard to manage it in your head. And then you have to start managing it somewhere else. And this is like a really important key takeaway for software development, for team leadership, or whatever work you have to do. If things get too big, and you cannot fit them in your head, and you're going to forget about things, because this is what we do as humans, we forget, just add a spreadsheet, add a Trello board, something writes, write this thing down. So you have it as a reference after this. And then you have accounts for everyone, but I don't know how to start a project. It looks like Django, but I need an Inflex DB running locally on my machine. This is the first time I hear about this. I need salary brokers, stuff like that. I don't know how to run it. And in order to unblock your people to be able to work and to develop locally without problems, you have to document relentlessly. And I mean relentlessly, everything should be written down. And not only written down, because what usually happens is team lead says, person X, please create a documentation, because you know how to set up everything. Person X creates it, but because everything's running okay on his computer or hers computer, they can miss a step. So you have to then take the documentation, test it yourself and give it to someone else so they can test it. And if you achieve a running local environment, then the documentation is okay. And actually, this is, I love this because when you onboard new people to the team, this is a great test how well structured your team is. Can you provide a set of links and documents to the new onboard, to the new hire, so they can get up and running within a few hours and start actually working? If you can do this, then perhaps you've done a good job with the structure of the team. And that's why just relentlessly document, I know this is what's the word in English for this, cumbersome or not very pleasant. People don't like to document or document logos, but you have to do it in order for your team to feel better. Not to have, I cannot run this. I cannot develop because I cannot run this. And on top of this, because we are programmers, if we have a good documentation, we can then create scripts to automate most of the setup. Usually in all of our projects, we have something called bootstrap, which just creates a local environment that's ready to go. And for example, if we have an additional zero dependency that's not required for the majority of the system, we have a script that set up zero or sets up goal cardless. Or we have a script called everything that sets up, as you can guess, everything, which may take a few minutes. But after you run the script, it's going to say you're missing x, y, z as dependencies or environment variables or keys. And once you do this, you're ready to go and you can start working on your local dev with all dependencies set up. It's worthwhile investing time in this because we end up doing quite a lot of bootstraps, quite a lot of, okay, we did something, let's bootstrap, let's start clean. And this is actually helping us a lot. And next, speed of tests. Very important and often overlooked. Imagine you're working in a team where you have to do small PRs, merge often and deploy often. And your test suite takes 10 minutes to run on CI. You're not 10 minutes, it's liberal, it can be 15, 20 and more. You won't be feeling very productive. And you know what, humans adapt. If you want your team to make short commits and commit often, and also your tests take 10 minutes, they won't do short commits because instead of doing five commits and taking an hour, I will just bunch things and do one commit because I know tests take a while. And this is something that is very often overlooked but really, really, really important. You need this quick feedback loop from the test. It's not a trivial problem to solve. There were plenty of good talks at EuroPython about this. You have to just figure it out because people adapt and they work style will adapt to the speed of the tests, which is strange, but it happens. For me, the solution of the problem was to install PyTest Exdist, just say minus M4 and from 10 minutes, it went to five minutes. I felt really good because let's try this and let's see if it's working and it's working. And after further test optimization, we managed to get it down even further. And this paid off because people now started working in smaller commits because tests were running faster. But you have to figure it out for your own context. And minus X means fail on the first error because sometimes you don't want your entire test suite running on CI if there is an error. It helps out. Optimize your test. It pays out. It really pays out. It was a strange observation that people adjust to the speed of the CI, but it is. All right. Working with clients. They request stuff. We call this stuff features. Sounds better. Instead of I'm working on stuff, I'm working on features. And features can be a source of a lot of problems and make sure everyone's on the same page with this. First thing that can be really problematic are feature descriptions, no matter if you're using Jira or Trello or whatever you like or whatever your team is using. There is usually a client or a product owner that says, let's do this. And they will either provide you a card with some description or let's do this. And you have to create the card with some description. And if this description is not correct or if you have not understood as team lead, for example, what needs to be done, people will be working on the wrong thing. And after a week, you will find out when the client is testing or the PO is testing. And they say, hmm, so we were expecting something else. This is not what we were expecting. And this this can be quite detrimental to the team morale and to the productivity because you just do work that's going to be undone and redone again. And sadly, sometimes it happens sometimes you do something that's not going to make it. But if you do this for every feature, it's bad. And the thing that I usually try to do is to ask a lot of questions. That's why clients don't like me very much because I ask a lot of questions. And they have to think and they have to answer those questions. But once this is ready, and we know what we are actually doing first, we may save some over engineering that's not needed currently. Because when the client says, I want something, we as programmers start to expand and inflate and cover all the cases and make it backwards compatible and make it production ready for millions of you know, business as usual for us. But after some question, after some talking, you can scope down the feature, you can write it, you can create diagrams, and you can leave it in a good state because then you don't have to repeat the entire conversation. It's like, can you please read the card and say something that's not okay according to you to the client. And then you can safely give this card to the team, to the developers. And another very important thing, make sure they read the entire card because you've just spent an hour or two writing down a good description, creating diagrams, then a developer takes the card, reads it diagonally and still creates something else. And still there's work to be done and stuff like this. So it's very important to have some kind of planning, don't overdo it, but some kind of planning so everyone's on the same page. At least from my experience, this is very important. Saves a lot of headaches and you will not have all the negative impacts of work being condone. So Ivan and Maria, they're briefed, they know what needs to be done for two specific features and they start working on those features. But feature A and feature B, although different, they rely on common piece of software that can be either there or yet to be implemented. And again, since we're working in team, we have to synchronize this because what can happen? Ivan and Maria, if for example, this common piece of abstraction is not implemented, they will implement it themselves. And after this, we'll have to undo some of the work or all of the work because they haven't synchronized between them that they need this common piece of software or there can be abstraction and Ivan adjusts the abstraction for his needs. Maria does the same thing for her needs. And in the end, we have incompatible abstraction in the middle. And this happens quite often. And the way to solve it is to first identify it and then have them pair on the common part. So they're on the same page. They know their requirements. They know that this abstraction is going to make it to be okay for both features or create the abstraction. So it's okay for both features. And then they're going to do their job and you won't be undoing work again. Undoing work can be very detrimental to the team morale. We kind of attach ourselves to the code emotionally. And when this code is deleted, people take it negatively like they've done something bad. And sometimes it's not like this. So this is very important. Make calls conflicts. All right. Okay, I'm okay with the time. Can slow down a bit. And those were some terrific examples from day to day software development and how to solve problems that are happening quite regularly and to keep your team happy. Keep your team productive. And now the part that I call explicit is better than implicit because we're at the Python conference. This is a favorite scenario. There's the bug. You know, sentry error in a Slack channel. We have a team of four. They're happily developing features, communicating, everything's fine. But suddenly there's a sentry error. And what usually happens is that the sentry error loves attention. And it gets the attention from all the developers because there's a notification in a channel that's dedicated to sentry errors. And what usually happens? Everyone starts looking at the error. Everyone starts running some shell to check things around. Everyone starts looking at the code. If they synchronize, someone will make a fix. If they don't synchronize, several people can make a fix. Then they have to synchronize which fix should go to production. Two hours have passed. And it's lunchtime. And, you know, this is, at least for me, a really bad way to break the flow of your entire team. You have four people. And suddenly you have one person who's four people acting like one to fix a sentry error. And if this happens once a week, it's okay. It's bearable. It may be a really bad production error that requires the attention of everyone. But if this is like a really small error that's quite easy to fix, it's bad to break the flow of your entire team. And this is team of four. It can happen the same for team of seven. You know, because if there's an error and people care about the project, because if you have a team that does not care about the project, then nobody will break attention, but nobody will fix the error, which is also bad. This is, for me, this is quite bad. And it was happening quite often at different teams. So we decided to do something that's, you know, like a standard approach. Have a dedicated explicit firefighter for the week. This is the developer who is going to be the first responder to one or many, like a team, depends on your scale. This is going to be the first responder to an error. Nobody else looks at the error because they know there's someone explicitly dedicated this week to fix errors. And only if the error requires the attention of someone else, then pink, then take the attention of the other people. And this helps a lot. This increased the productivity and increased and reduce this panicking times where, oh, there's there, there's there. And everyone's running around contributing, you know, making it seems, seems worse than it is. And this explicit firefighter, you rotate it every week. So everyone goes on that duty. And it's, it works really well. And while we are at explicitness, there's one more team rotation after this, while we're at explicitness, something that's, again, a low hanging fruit, but I've seen problems with this, your team should know very well the way that you're working with Git and GitHub. Because I've seen teams where several people are using Git flow, several people are using GitHub flow on the same project. And they're happy, but it's not compatible inside the same project. So make sure you have written explicit rules for how you use GitHub. This is the flow that we use. This is how we do pull requests. You can have pull request templates, issue templates, all the good stuff that's provided, for example, from GitHub, and perhaps Bitbucket and GitLab. So everyone's on the same page for how you're using Git and how you're using GitHub. Otherwise, there's going to be chaos. My fixes are in develop. What's develop? We merge in master, you know? So no matter what you use, it's really important to have this. Those slides should have been before the period of time, but no worries. And another thing that I've observed, and it pays off really well is to separate refactoring from feature development, especially on big projects. Because sometimes you want to do a small bit of refactoring and also introduce a feature with this. And what happens when you do this is you have a very unreadable pull request, because you may hide new feature or new functionality in the refactoring diff, because the diff is going to be this was removed, this was added, but it's not the same remove in the same added with different name. We have two more lines in the middle, and people can overlook this at pull request reviews, and those two lines can actually break. So it's really hard to read. And the other thing is if this pull request breaks something, now you don't know, was it the refactoring? Was it the new feature? Was it a combination of both things? So refactoring should be just refactoring, and then after this make a new feature pull request, because it's going to be much easier to read, mostly new lines. You don't have pull requests where you have 200 new lines, 200 removed lines, and it's beautiful, you know, red and green, but it's really hard to read. And while we're at the explicit thing, writing down how you do pull request and writing down how you how you do, you know, refactoring PRs versus feature PRs, it's a good idea to have something that we call team rules, to write everything that's implicitly known in the team down, everything that's, this is how we do things here, because when you go to a new team and you ask why is this like that, and someone answers, this is how we've always done it, it's a good idea to sit and write down all those implicit rules and make them explicit and have them at one place, because first, you can spot strange things that are no longer valid and you can fix them. Second, everyone on the team can be on the same page, you kind of establish a framework for everyone, and you say if you want to be on the team, this is the framework that we follow, you know, this is how we do things in this team. It may not be optimal for every case, but this is how we do things here. This is very important for people, for coherent teams, to have coherent teams. And also again, onboarding new people, this is great, because when you onboard a new person and everything's implicit in the team, this new person has to navigate those implicit rules, ask questions, understand from observations. Well, it's much better to provide him a document or her document and say, you know, this is the team, this is the framework of the team, read it, ask questions if something's not clear enough, and let's go with it. So very important and actually yields good benefits, those team rules. Again, make it explicit instead of implicit. And while we are at the explicit and implicit, that's something else that we've observed that it's very important, at least for me, have an explicit leader. You know, there are teams with flat structure and there's an implicit leader. There's this person that everyone listens to and everyone kind of knows that's the person that makes the final decisions. And it's again, a good idea as everything else to make this person explicit to say, this is the team lead, he yields, he's responsible, if something goes wrong, he's responsible, you know, the leader is responsible for this. And he also or she also makes the final decision. If there are people arguing, then the team lead makes the final decision. And it's really good to have this. Otherwise, there's going to be implicit one and politics will be involved, sadly. And again, know who the leader is and something that I was leading a team at Hacksoft. And then I gave this team to someone else who's now coming, who's now the new team lead, and he did something very, very smart. He said, let's rotate every week the team lead. Because when you are a team lead, you have a different perspective. And not always developers will know what's in your head or will know what's what's it like to be a team lead. And when you start rotating them, first, they start understanding way more things. And they start understanding why such things are like they are. And then they have more responsibility, they're more involved, they find more meaning in the job they do, because this is what when you are on a leadership position, it's quite different. So this yielded really good results, breaking 10 minutes. And I can highly recommend it to give it a try, just rotate team leads, again, have everything explicitly written down, make it easy for someone to step in. And also, this will, how to say, this will improve the team with everyone's perspective. Because sometimes when you have a strong leader in a team, he will push his perspective and vision at the end, it will be mostly that. But when you rotate people on the team leading position, then you're going to enrich this team perspective and enrich this vision with everyone's vision and everyone will feel way more involved inside the team. And again, I can highly recommend this. And we'll finish with conflicts, but not merge conflicts, but rather human conflicts. This is something unavoidable, at least in my opinion. If there is a team without a conflict, then there's just a conflict waiting for a proper time to surface. And it's really important how you're going to handle the conflict. Overcommunications seems like a really, really good general recommendation, because oftentimes conflicts come from people not communicating enough between each other, having expectations for someone else, having expectations, for example, person A has a specific expectations for person B, and when person B does not meet those expectations, there's already a conflict. So it's really important to lay down expectations, to overcommunicate. There will be people that will work. It's going to be hard for them to work together, and you have to identify this. And depending on your structure, sometimes it's good to make them work together more so they can start playing well with each other. Or sometimes it's a good idea to not make them work together for a while until they figure out different things that they need to solve for them. And I cannot give good recommendations here, because it's a hard topic, but read books on management, read books on leadership. It helps a lot. Practice it. For example, rotation on the team leading position is a very good practice for everyone to have this leadership capacity in themselves. There are always toxic people that no matter what, they will be toxic, and they kind of enjoy chaos and hierarchy and bringing things down. You have to identify this. Sometimes it's fixable. Sometimes it's not fixable. Then you have to let them go. There are people on the other side of the spectrum. There's something called malicious obedience, where they do exactly what they've been told and they don't think. They're kind of dependent on you, and it's like you're telling them step-by-step like a computer program what to do. And they do exactly this and nothing else, which is also not the desired trait inside of a team. So you have to learn to identify those things and somehow work around them, fix them. And firing is really hard. Easier said than done. It's really, really, really, really, really hard. Because when you have to fire someone, the first, at least probably the first thought is, well, it's my responsibility that this person is not fitting well. I have not done enough things. And it's usually the case. But you have to kind of see where the line is and you say, I've given enough opportunities. It's not working. Let's see what we can do about it. And of course, finally, adapt. If you have processes and you follow them blindly, people will learn to play the game and will be, again, unproductive and ineffective. You know, these humans are really good at adapting and they will adapt. They will learn to play the game. So you have to make sure those, at least for me, those seven traits for a team are always met or we are doing something about them. Because if you say, all right, I've invested a week, here are the processes. This is the framework done. I have no longer, I don't have the need to touch it. Just follow the process blindly. This is not working. You know, things are changing, people are changing, circumstances are different. So you need to adapt. You need to not constantly but often, perhaps once a month, revisit everything. Check if everyone's happy. Check what's happening. You know, be friends with your team and adapt everything. And perhaps the takeaway, ask your developers for pain points and they will tell you because if you think there are no pain points in your team, you're just ignoring the problem. Just ask them, what are the pain problems? Write them down, discuss them. Some of them are not fixable. Some of them may be, this is part of your job and you have to learn to do it. And some of them are fixable, easily fixable. Some of them require more work. But it's kind of the process of thinking about your team and thinking about the well-being of your team and trying to do things to improve the well-being of your team if you have good intentions. And this will yield good results, I think. At least this is how we see things at our company. So thank you. This was it for me. Questions? Time for a few questions. Please use the microphones. I think you have to go to the microphone. Sorry, I had to come all the way from the back. Two questions about the rotation of the leader of a team lead position. So we were wondering if it's a continuous rotation or you just try full rotation once and then settle on the actual team lead? That's a good question. Continuous rotation. Very interesting. The second question is, is the team lead also responsible for personnel stuff like appraisals, sick leave, all that kind of stuff or just purely the technical? So this depends on your company structure. In our company, the team leads, if you have to take a vacation, you ask your team lead, for example. And this is a really good question. We separate the, can I take a leave and so on from this to the original team lead. The other is leading the day-to-day job, but at some point, I guess, we'll just make everything go in this team lead tradition. But this is a good question. We don't want to kind of overburden right now the rotating team lead with paid leave, sick leave, vacations and so on. But this is coming. We just have to get there. Yeah. Okay. So that's good to know. Like in our case, those tools are tightly coupled into one position. So then the rotation will be really hard, especially with like ongoing conflicts or growth patterns for developers, stuff like that. Cool. Interesting. Thank you. My question is along the same line as well. I think it works mostly if all the engineers have the same level of expertise. So how does that work on a team where, for example, I lead a group of nine developers. And so the developers have different sets of expertise. Some are like seasoned system engineers. Some are like front-end engineers. Some are like both. I think that works mostly in an environment where everybody is a full-stack engineer and everybody thinks they're full-stack engineers these days. But I'm not sure how to... How would I even do that when I am like the leading them? And we have like a principle software engineer. So I'm not sure how to do that. Yeah. That's a good observation. We are a team of full-stacks and it's working really well. If you have different expertise then, I guess you have to just see your hierarchy inside the team and figure out how many leaders you have because you might have leaders on the different teams and the leader that leads all of them. And figure out a rotation that works for you. It's just give the people opportunity to be in a leadership position to see what it is. But you should have to figure it out. Okay, thank you. I don't think we have time for more questions, but you can grab that. I'll be here afterwards. Thank you. Let's give him a big hand.