 Okay, welcome everyone, my name is Maciej and I'll be talking to you about what it's like to lead a special interest group under Kubernetes organization and a team in the OpenShift. In the OpenShift organization on the red hat, while I'm here, you probably already figured out that I'm actually leading an actual special interest group in Kubernetes and I'm also leading a team with an OpenShift. What is funny when I was talking with my managers yesterday, they asked me, can you still change your, the title of your talk and add the, and not end up crazy or on drugs. I'm like, I can't change the title, but I can change the slides in whatever way possible. And the images at the bottom express only a limited set of my emotion that I'm going through on a daily basis, honestly. So yeah, it's usually starts with, I'm a cool geek, I'm going to work something out through this pair to, yeah, vomiting. Anyway, what is a special interest group in Kubernetes? How many of you are familiar with what Kubernetes is or the organizational structures of the Kubernetes project? Okay, quite a few. So basically, and I'm going to read it out so you don't have to. SIG is compromise of members from multiple companies and that's a very important element. Multiple companies and organizations with a common purpose of advancing the project with respect to specific area. In my particular case, that area is CLI, which stands for kubicutl, kubectl, kubectl, whatever you want to call it, that's perfectly fine. There are several other subprojects that the SIG CLI is looking after, but that's a topic for a different, for a different call. What we as a SIG CLI are responsible for is one topic, but if you look broadly what we have to do and what are the processes that we are required to fulfill on a daily basis, they are written, it is highly defined, each and every single SIG has two things that it needs to follow. First of all, there is a big document called SIG Governments, which describes how each and all the SIGs are working. It puts a set of requirements on every special interest group. And those requirements are basically you need to meet regularly. Obviously if you're from different companies, very frequently scatter across the globe, you need to have a way to communicate. The communication channels varies from Slack to mailing lists, GitHub, issues, pull requests, as well as Zoom meetings. For example, in our case, SIG CLI is meeting every other week on Wednesday. And we will be having a meeting next Wednesday at 6 p.m. Central European time. If you need to convert that one to your time zone, I'll leave it as an exercise for you. Then we're meeting every other Wednesday where we are discussing current issues, plans, and basically everything around the projects and the topics that we look after. Once per quarter, every SIG is required to show up for a community meeting, which is held currently once a month. During the community meeting where the entire Kubernetes community is invited, you report the things that you were working. Your SIG was working on in the past quarter. You lay out the basic plans for the SIG for the next quarter and what you achieved in the past quarter, which with the speed of Kubernetes project, that's basically what you did in the past release, what's your plans for the next release. Like I said, the release is another topic, and there's usually once a release, there's a meeting that is devoted entirely to planning. We try to also meet once per release to discuss how well we did with regards to the previous release, but it doesn't always happen. We try hard to make it happen. And just recently, we started doing an additional meeting. They voted entirely to going through the bugs and all the bugs, issues, and pull requests that the Kubernetes has opened for our area. And of course, everything is written down in the special docs describing. Okay, so that covers the part of the Kubernetes part. Let's focus currently on what a team is in a general group as well as within the OpenShift org. So that's a definition from Wikipedia. Basically a team is a group of people who are interdependent with respect to information, resources, knowledge, and skills who combine their efforts to achieve a common goal. In my particular case, that common goal is not one, but three. Those three goals are OC, which is an OpenShift client similar to Kube-Cuddle. The second goal is the scheduler. And the third one is all of the workload controllers that my team owns. That includes deployments, stateful sets, deployment configs, and everything else. So pretty big, and we're only five people if I remember correctly. What are our responsibilities? Of course, there is a doc. It's written down. Unfortunately, it can't be made public. It's an internal doc, which is pretty obvious, I guess. What a team does, especially one like ours, which is pretty scattered around the globe as well, because I'm in Poland, I have Jan and Tomasz based in Czech, and I have Sally and Mike based in Boston. So it's not that bad, but it's still a couple of people scattered around different time zones and different places around the globe. Thankfully, we only have about six hours time difference between each other, so it's manageable. So if you look carefully, you'll see that the responsibilities our team has are almost identical with the responsibilities of a sick. The only difference is we meet much more frequently. We report much more frequently, and we communicate much more frequently with the team. That's probably the only difference, and as long as a lot of the communications and discussions that are happening within a team are somewhat internal, all of the communication with regards to the communities project is always public. So if you think about it, running a sick shouldn't be that bad. It's pretty, if the group of people is self-organized, they're usually working on from different companies, so each company will have different incentives why they're working on things, and I'm privileged enough to have a wonderful team of people that are very self-motivated, self-organized. You can think of me as pretty much not much doing anything. I could literally sit on a beach and just check the boxes once in a while and ensure that the team is working, but it's not that simple. There are a couple of challenges that each and every single person and a team lead, lead, manager, and literally everyone in both open source community and the regular work everywhere is facing. Does anyone have any ideas or challenges that they can come up with? And let's see how much they fall within the ones that I mentioned. Anyone wants to speak up? Don't be afraid. I'm not biting or anything like that. Okay, shy being shy is one of the challenges that I need to also work with, so that's not a problem. No worry. Okay, so the biggest issue, literally the biggest issue every single time that I need to is time management, and I'm pretty sure that every single person out here working on anything, you don't have to be in an IT. You can be a people manager. You can be working in a completely different environment, completely different things. You still have to manage your time. There are several good resources that I stumbled upon. I got a chance to read through. One of such resources is Peak Performance by Brett Stolberg and Steve Magnus. It's a wonderful book that encourages people to push the borders of their capabilities a little bit further. If you imagine if you're practicing for a marathon, you're a person that never jogged in your life, and you want to do, marathon is like 20-something kilometers, that's a half marathon. A marathon is 41 kilometers. So let's say half marathon to be easiest. If you've never jogged before and you want to do 20 kilometers, doesn't matter the results, but you want to jog 20 kilometers, it requires you to get from not running to being able to jog for 21 kilometers. That's a lot of work. So you start by doing a little bit, and then you're pushing yourself a little bit more, a little bit more, a little bit more. The same approach can be taken to basically working on anything that can be, I don't know, playing piano, that can be learning to program go or literally any kind of activity. Doesn't have to be specifically physical activity. If your goal is to be better at it, you always need to push yourself a little bit harder. That's one of the topics of the Peak Performance book. It's pretty amazing. I totally recommend if you get a chance to read through it. The other cool thing, the other cool resource that I went through is Getting Things Done by David Allen. And David Allen is basically, in short, organizing things in several categories, simple. You stumble upon a thing, and you quickly make a judgment. Is it simple enough that I can make a judgment decision right now or I should put it for some other time? If it's simple, make it happen and forget about it. If it's something that you need to devote a little bit more time, plan accordingly or put it in a place so that you don't forget about it. So basically trying to be reactive to all the things that are happening. For that, a manager from my past recommended me something that is called a bullet journal. There's a webpage bulletjournal.com and basically every single day I'm starting with figuring out what my tasks are, what my tasks are for the past days and stuff like that. I literally have a notebook specifically devoted to this and I can show you. It's helpful by now. And it's literally every single day it's filled with notes, what I did, and all that I will be working on. So you need to plan your days and to ensure that you're not getting busted by a million of things going on at the same time. And trust me, I have so many interruptions on a daily basis. And I think the most important thing that you need to do when it comes to time management, you need to ensure to take your time off. And the time off, it includes going for holidays, doesn't matter where. It includes going offline for the night, going offline for a weekend. And stay actually disconnected. Spend the time with your significant other, spend your time with the kids, with your family. Do something that you actually enjoy doing a lot that can be fishing, that can be jogging. Well jogging is a separate thing because you, aside from stepping away from the keyboard, it's also important for you to keep a healthy life. That includes food, make sure that you eat healthy and whatever, but also do exercise. A lot, especially in the area of hours where we sit for 8, 10, 12 hours. And trust me, I am sitting sometimes in meetings for 10, 12 hours. Like past Wednesday when I started at noon, all the way until 7 p.m. Oh, and this is the most important part. How many of you is multitasking? You're doing it wrong. There's no such thing. It is impossible for you to multitask. Think about it reasonably. The only achievable multitasking that you can do is drinking a coffee and reading a book. But that's not multitasking. An example from my past, not that far away from this Tuesday. Okay, I can probably go and listen to two meetings at the same time. Both of them, one and one. That's what I would call multitasking. You're actually listening to two meetings. Think how much I know from both of those. Every tenth of a word of this one and every tenth of a word of that one. That's not multitasking. It's impossible for a multitask. Switching from one task to the other task requires a significant effort. If you're listening to a meeting and you're working, you're not multitasking. You're either working or you're either listening to the meeting. The same applies for presentation. And I caught myself doing the same thing exact past two days. When I was working on my laptop, I wasn't listening to the presentation. And the same other way applies. So there's no such thing as multitasking honestly. If somebody tells you that they do multitask, that's a lie. They don't. People, that's the second topic. Every single time you go to a grocery store, you work with your team, you meet with people, you work with people, you talk with people. Working with people is the hardest thing on earth. It is, it always was, it still is, and it always will be. People have moods, people have emotions, people have problems. And you have to deal with that in actual real time. There's no going back and forth. And it's very easy to offend someone by saying something. Especially, especially in a multicultural environment. Something that I would not ever, ever thought about being offending to a person that I'm working with, might be perceived by the person on the other end completely differently. Because my culture and his or her's culture completely differs. And are perceiving stuff that I'm seeing as a joke for him that might be an offend. That's a, a, a significant problem. My manager, we've had lots of, lots of conversation about different topics. We have very good relationship with one another. And we basically, our one-on-ones sometimes end up talking about everything from career growth to whatever we did yesterday. And he told me once how he's approaching his managerial approach. He told me that he had a manager back in the days, a one of the worst manager possible. And whenever he has an issue with something that he wants to do, the first thing that he's going to think, what would that manager do? And he will ensure to do the exactly opposite. Because he knows that would hurt him. So I'm thinking about it as a team lead. I have different leads in the past, one betters, other worse. Thankfully, I had so many good examples in the past. I'm trying my best. I don't know, you should probably ask my team members how I'm doing, but I'm hoping it's okay-ish. Other assignments that I have as a team lead or a SIG lead is shielding people from interruptions. And I have something that is called imposter syndrome. A lot of people might have heard about it. But basically, my approach and my fight with imposter syndrome, because that's a constant fight, is I'm trying to ensure that I'm not bothering those people. If they're working on some specific topic, I'm taking a lot of work on my head to ensure that they are not interrupted. That ends up not always well, because that ends up sometimes me being overloaded, whereas sometimes I could just pass over, but I'm working, that's a constant problem. Yeah, I think. And the last one, communication. Communication, communication, communication. Since we're working with people, it's the communication that is the most important thing. It's the only medium, especially, I've mentioned that before, our team is scattered around the globe a little bit, but we need to communicate within the SIG. We don't have the chance. Once in two weeks, we only see each other on a video. Once a year, sometimes twice a year during cube cons, we get a chance to meet each other in person. That's not a lot, but we need to have a mediums for exchanging the ideas, exchanging problems. The discussions that we're having, ranging from, I don't know, I bought something cool recently, I'm not gonna mention what. Our friend recently told us, it's very US specific, so I'm not gonna use it here. Up to, oh, I have this great idea that we should probably think about or what will be planned for the next release and stuff like that. Everything is being discussed in those. But this is how you build relationships with the people because the relationships are what helps you drive the further progress. And I think I have about three, four minutes left. So, before I can talk a little bit more probably about it, but I'd like to open the floor for questions if you have any. So, I've mentioned jogging and everything. I jog in the morning. My, the rest of my family goes to work, goes to school. And with them leaving, I'm also leaving for my jog and my days are shifted a little bit. I would say I'm working nine, 10 until five, six, until seven p.m. So, this ensures that I have a significant overlap. And then again, every other week, when the majority of the meetings that I have within Kubernetes community, all the meetings we held are held in a time that is appropriate for the West Coast, which is nine hour difference, East Coast, and Europe, which basically means for me, the meetings are six, seven, eight. Eight is the latest one that I'm attending. So, it will happen that I will be working every other Wednesday until nine p.m. But I'm trying to shift my stuff and eventually if I have something to deal with, I'm gonna deal with that in the mornings because that's also easier. All of the offices and everything are usually open in the mornings and it's easier to deal with those in the mornings. I don't know, do run some errands. Like I mentioned, jogging and general activities. I do those in the mornings and then I can spend the other half of the day working. So, that's the approach that I'm taking currently. Yeah. The moods and tempers, how do I handle those? I think it's always case by case. There's no golden rule. First of all, it takes a little bit of time to get to know the people and then over time you just, I don't know if there's any golden rule, honestly. It's observing people, learning from people and trying to turn the bad things around and pulling out the good things about people. That's usually the best approach. I'm not saying about minimizing because you need to help them grow their problems into solutions so that's one thing and then strengthening the good side of people and trying to bring those to a light. Something that I'm not sure if that helps or answers. Oh, I'm very lucky enough. I don't have any troublemakers. I actually have the most amazing team. So, okay, we're out of time. Thank you very much. If you have any questions, I'll be down at the Kubernetes booth for the next two hours. So, if you wanna talk about the teams six, I'm more than happy to answer any of your questions. Thank you.