 All right. Yeah, thanks, everyone, for coming. Thanks a lot for coming to this session. I'm happy to see people are excited to talk about mentoring. So yeah, the whole point of this session is to talk a little bit about what makes a mentorship successful. And I'm going to give you some tips specific to the cloud-native world. But the idea is that some of the things we're going to talk about are kind of general to mentorship as a whole, and also maybe even helpful for improving communication in other parts of life as well. So we're going to start a little bit more existential maybe than maybe we would like to with these two questions. So what is a good mentor and why do I want to mentor? So what is a good mentor? Like, what is a good mentor or what is a good mentor? And this slide is actually a little bit misleading because I'm not going to answer these questions for you. I'm actually going to talk about the third question, which is, how can I become a better mentor? So we have the what, the why, and the how. And the whole thesis of this presentation is that if you can answer these two questions on the slide, if you can define for yourself what the mentorship experience should be and also figure out why you want to do it, then you're already most of your way towards becoming a better mentor. And you'll be able to use all the suggestions that I'm going to present today to improve the whole process. So kind of with that in mind, this talk should really be renamed to be becoming a better mentor. And in fact, I think it's kind of a nice distinction to make because I can't tell you what it is that you want to accomplish, but I can definitely give you some suggestions to help you get there. Yeah. So without further ado, my name is Luca Serbenmarin, and I'm an engineer and I'm also a maintainer of one of the CNCF projects called Thanos. And I didn't study teaching or anything. I studied engineering. But I have been teaching in different environments for the last 12 years, like tutoring and mentoring and everything from chemistry to guitar to GRPC. So everything that we're going to be talking about today is taken from experiences. And in fact, a lot of the suggestions that I'm going to be talking about in particular came from actual retrospectives that we did for mentorship programs inside of the Thanos project. And actually, one of my co-maintenors, Guidreus, is here as well. And we worked on a lot of the ideas that are in the slides together. So thank you very much, Guidreus. So yeah, inside of Thanos, we've been doing mentorships for the last few years. And sometimes mentorships go really well. And sometimes they go really not so well. But in every single scenario, we have a lot to learn. And yeah, so one of the things that we care a lot about in Thanos is about learning in particular. So we're always trying to think about how we can make things better. And in particular, how we can make the mentorship experience better for students the next time around. And I think this raises a really big question, which is, why does it matter? Why should we invest so much effort in making a mentorship experience better for students? We're open source maintainers. We're probably more or less smart people. Then we can just impart our knowledge and everyone around us. So I think that's kind of a fair question. Why should we care so much about getting it right? Because at the end of the day, a lot of these mentorship programs are just free money. And I know some people are peaking around free money. And the thing is that, yes, there is real companies out there, like legitimate companies like Google and the Linux Foundation, that they have managers and department heads whose mission it is, roughly speaking, to get one group of people on the internet connected with another group of people on the internet and to give them money to mentor. And that's a huge opportunity. So this is why the stakes are so high. For some students, a mentorship can be a lifeline. And for other students, it can, at the very least, be their first experience programming in a formal setting, or their first experience in open source at all. So if a mentorship program goes poorly, it can mean that this student will never participate in open source again. So the stakes are definitely really high. So the definite absolute number one tip that I have for everybody is to set your goals and to define the what and the why of your program in the first place. So this might sound a little bit silly. The goal of a mentorship program is to finish a project. That's kind of obvious. But I would argue that it's actually not so obvious because a project may have many different reasons for wanting to take on students. And anything that we can do to make an implicit goal explicit and to communicate our goals with everyone else is going to be really valuable and pay dividends in the long run. Because if we don't set any goals, then we have nothing to aim towards and nothing to look back and reflect on. So we'll never know if we're heading in the right direction. You technically can't fail without a goal, but you technically can't really succeed either. So ask yourself. And I mean, really, really ask yourself, what do I want to accomplish as a mentor? Why am I doing this? Do I want to just have help on a project? Am I doing this because I want to build a community? Or am I doing this because I really like just the pleasure of teaching other people? And I think that this is true for mentors, but it's also a really good question for mentees as well. How can we be a good mentor if we don't even know what a student wants to learn? Inside of the Thanos project, we start every single one of our mentorships asking our students this exact question. What do you want to learn? Because maybe they want to learn go-ling. Or maybe they want to learn about open source software. Or maybe they just want to build their CV. These are all legitimate reasons to do a mentorship program. But if we don't know, then we can't aim in the right direction at all. So encourage your students to really think about this question. And also, once they've thought about it, encourage them to actually ask for what they want. If we all are able to ask for what we want a little bit more, then we're all going to communicate better, and we're going to be better off in the long run for sure. So if you're a student in the audience, like think for yourself, hey, I'm going to be surrounded by some hopefully smart people that are well connected for the next three months. What can I learn from here that I can't learn in another scenario? And the last thought on the subject is if you ask for what you want as a mentee, then your mentors are going to be able to actually curate the goals of the project to suit your learning needs. And on the other side, on the flip side, as a mentor, you'll also be able to curate the tasks of a project to suit the goals of the open source project itself. So here's an example from the Thanos world. From our point of view, a mentorship program is not really supposed to be a school project at all. Our mission is to tell people, to teach our students about real-world engineering. And in the real world, there's laws of unknowns. In fact, sometimes the unknowns are so great that you won't even be able to finish the project at all in the first place. So the goal of the project shouldn't be, hey, finish some task. Instead, the goals that we have for our mentorship projects are we want to teach people about contributing to open source. We want to teach people to learn how to work together. And we want to empower the next generation of open source contributors. And one thing that we always like to say inside of the Thanos team is that our like actually, I say this all the time, which is our evil plan inside of Thanos is that we want people to fall so much in love with open source and with the Thanos community that they'll want to keep working on Thanos even after the project is over. So take time to really think about the goals of the project and communicate them to everybody around. So like I mentioned, the real world and engineering is full of unknowns. And sometimes it's going to be full of really unpredictable things that's going to break everything from the very beginning. So the unpredictable is going to happen. And we should try to be flexible and accommodate this. That means that we should have backup plans. For example, one thing that happened to us in a previous Thanos mentorship session is that in the very first week of a program, an external community member finished the entirety of a student's project within the first week. And that meant that we had to adapt really, really quickly and come up with like an alternative plan. And on the flip side, another thing that happened was that one time the project ended up being so challenging that there was no way we were going to finish it all. Super did not anticipate how challenging it was going to be. And in this case, we had to push the goalpost back. So in both situations, we found that it was really useful to get together, think about the goals, think about what we're trying to learn, and come up with a new project. And again, the point of the program for us is not to do a single project. So once you have a project in mind and once you've actually done some work, you can hopefully create a feedback loop and you can start to make some improvements in the whole process. So how can we guarantee that we actually learned from our mentorship programs? Like, how can we guarantee that we get valuable feedback from every mentorship program? How can we make sure that our mentorship program is self-correcting? How can we make sure that every mentorship is better than the one before? And in other words, how can we make sure that at the end of every mentorship, we come up with more suggestions like the ones that I'm going to be presenting today. And the way that we've been doing this inside of Thanos is that we hold retrospectives. And I know that people can barely contain the excitement to start the human wave right now. But we even have a little document inside of Thanos that is an outline describing what the mentorship process or sorry, the retrospective process looks like so that mentors and mentees know what to expect. And for us, holding consistent and well-structured retrospectives is a really helpful way to get high-quality feedback from everybody involved. And that way we can make everything better the next time around. So holding retrospectives is really cool. But people here are probably really interested in mentorship and interested in learning and interested in pushing the boundaries. So it's natural for us to ask ourselves, how can we learn even more than this? Like, consider the following problem. If we hold a retrospective just at the end of three months, then I have to wait till the end of the program to get any feedback about if I'm doing things correctly or not. And on top of that, I have a limited bandwidth as a maintainer, so if I can only mentor two students every year, that means that I only have two learning opportunities to improve things in an entire year, and that's not very much. So what can I do to learn more so that I can improve my meeting with my mentee, which may be tomorrow? And one strategy that we've done inside of Thanos is that we've been holding retrospectives among all of the mentors so we can share and aggregate feedback from every single retrospective. And in practice, this is a really cool tool because it means that I may only have two students every year, but there may be a bunch of other maintainers that have in total 10 students, so I can go from learning from just two things to learning from 10 things and multiply my learning by 5x, and that's a really, really huge difference, right? So suddenly we can learn way more than we were ever anticipating. But actually, one more thought on this is that when sharing details more broadly within the entire maintainer team, it's important to keep in mind that some details shared inside of a retrospective are gonna be shared in confidence and are not appropriate to share more broadly, so keep in mind that we should only share things that are appropriate with everyone else so you can keep the trust of the whole community and keep people safe. But yeah, getting 5x the amount of feedback is really great, but how can we get even more feedback? How can we learn even more than we have been doing just inside of one open source community? And one approach that we've come up with inside of Thanos is that we want to share our feedback and our learnings with an even broader community, so that might mean all of Thanos, not just the maintainers, but the entire Thanos community or all of Kupkan. And in fact, one of the feedback items that we had from our last internal Thanos meetup was, hey, we should share all the things that we're learning with a much broader or like the entire open source community. And so here we are today, actually. And the idea is that if we can go to more talks from more maintainers or more mentors, we can go from learning 1x or 5x to 20x and really accelerate and learn a lot of stuff and really make things better for mentees. So there's still one problem here, which is we've shared feedback with the whole Thanos community and with the entire Kubernetes community as well, so we've been learning a lot, lot more. But what we've really done is just increase the learning bandwidth, but it still takes me months to learn, right? This problem, which is that we still have a really long or slow learning latency. So this is a really big question, which is how can we learn faster? And one approach that we've been doing is that we try to hold mini check-ins with our students like every single meeting. That means that if we have a weekly meeting with a student, we'll try to always ask a question like, hey, how are things going? How are you feeling? Is there anything that we should be doing differently? Asking any variation of this question, it may sound really menial, but it's like if you're asking really empathetically and honestly, you're trying to improve the process and that's really key for us to get more feedback because at the end of the day, if you only hold a retrospective after the entire process is over, it's too late to fix things right now. So on the subject of meetings, another really important piece of feedback that we have is to have meetings frequently. We try to have meetings always at least once a week inside of Thanos. Even if you have nothing to really update about, actually scratch that, if you have nothing to update, then you should especially have a meeting because it sounds like you could improve the process. Even if your only update is, hey, I wasn't able to finish my work, that's totally worth communicating. Maybe you can use this hour to say, hey, you know what? We should have unblocked you better or we should be changing the way that we're setting our weekly goals because you weren't able to meet it. So no matter what we do, having a check-in is really useful. And of course, the goal here shouldn't be to just fill an hour, right? If the check-in is really, really short, that's fine, but having more frequent feedback is always helpful. So yeah, meet often, but also keep in mind that everyone is really busy and has limited time to meet face to face. So you have the undivided attention of your students and vice versa of the mentors for one hour every week, so let's use this as efficiently as possible. That means that it's probably not the most efficient use of time to do work that you could otherwise do alone because you're gonna end up just doing some coding work alone with the added pressure of somebody watching you the whole time. And that's fine if your goal is to do pair programming then for sure, by all means, program together for an hour, but at least do it consciously. Instead, if the point of this check-in is to improve the process, then it's probably a better use of time to work asynchronously because when you're working asynchronously, you're gonna naturally run into problems, you're gonna naturally run into doubts and run into issues, and a weekly check-in is the perfect environment to ask and answer these kinds of questions. We'll skip this and come back if we have time. So yeah, speaking about issues, this slide here might sound like really obvious, but I think it's actually one of the hardest things that we're gonna talk about today, and that's about being transparent. So being transparent and communicating is really a two-way street between mentors and mentees. And the reason is that this is so important is because without transparency, it's gonna be way harder to succeed. And I know that this slide says problems here, but oops, I know this slide says problem, but it's actually about everything. We need to be transparent about our concerns, our worries, but also about the successes that we're having and the praise that we want to share with one another. And the thing is that communication is important for any relationship, and a mentorship is a relationship plain and simple. Without transparency, the relationship can't work, and on top of that, trust is extremely important to have any kind of transparency. So if I ask any random person here, hey, do you trust me? Maybe somebody would say politely, yes, I trust you, but that's kind of a shame because maybe you don't feel the trust or the security to be vulnerable and say, hey, Lucas, all these points are making sound really great, but I'm really busy as a maintainer, and I'm worried that I don't have enough time to implement these things, and instead I want maybe some practical, simpler advice that you could give me, and I think that's really, really helpful and transparent feedback, but saying something like this requires a lot of trust. And ironically, building trust, one of the best ways to build trust is also to communicate empathically and honestly. So it kind of works both ways, right? We need trust to be transparent, but we also need transparency to build trust. So we could talk about just this subject for plenty of sessions, and if you want to talk more about this kind of communication stuff, like let's chat afterwards, but it's definitely a really important subject. So yeah, once we're making progress on a project, we want to make sure that we're keeping our momentum and moving towards our goals, and one of my goals as a mentor is to help students meet their goals. So how can we prevent people from getting stuck? And one of the most useful things that we found is that it's really valuable to time box your explorations and your troubleshooting, and really hold yourself accountable to this time boxing. So one thing that happened to us in the Thanos world was that we got super in the weeds trying to fix some protobuf issue with a student, and it took us days, and if we're being honest, it actually took us weeks, until we finally realized, hey, we have to take a second to think about this problem from another angle, and we realized that we should have been attacking it from the top down, from the API level, instead of the bottom up, but we would have never thought about this or we didn't take a break to think about everything from another way. So it can be extremely useful tool to time box and set limits to the amount of time that you'll invest on something, and to really hold yourself accountable, and if you haven't figured something out at the end of this limit, then maybe it's time for a check-in and to think about something from another angle. Yeah, and kind of in the same vein, keep in mind that it can take weeks, it can take a really, really long time to get feedback, not to mention consensus from the broader community on a big proposal. So don't let this block you, and in fact, make sure to plan other work so that the feedback, waiting for the feedback doesn't become a bottleneck in your work, and also try to have a backup plan because it may be totally the case that your big proposal will be rejected by the community, and then what happens? So yeah, make sure that feedback doesn't become a bottleneck. Yeah, and then this one is maybe a little bit more self-explanatory, but try to merge often and frequently. Every time that we make a PR, this is a valuable opportunity for feedback. You know, it's gonna be really difficult to get a huge chunk of work merged after three months, and instead, if we can make iterative progress and get feedback way more frequently from the community, we'll be able to get features actually merged, but also give recognition for all the hard work that students are doing, and that's super, super valuable. Yeah, this can be a really big challenge in some kinds of projects where maybe you have to merge a whole coherent chunk of work altogether, and try to think outside of the box. Maybe a strategy that you can take is to have a fork of your project, and you can merge frequently to this fork, and then you can actually get reviews on all these PRs on another fork, and then you can merge this to the main branch or anything else, but try to think outside of the box so that you can get more feedback as often as possible. Yeah. So, in the end, make sure that you keep the collaboration relationship between your students and your mentors friendly and empathic and caring and understanding of one another, because mentoring throughout the pandemic has been a huge challenge for everybody, right? I mean, we've had families lose lost. My God. We've had families that have lost loved ones. We've had people who've gotten sick. We've had people who've had to change jobs. We've had people who have had to change priorities or have just changed interests, and these are all normal things that happen in life. These are all really normal challenges, and they're not gonna go anywhere. So, try to always stay understanding of one another, and the best thing that we can do as mentors is to always support for and care for one another and to really be there. So, yeah, I mean, in the end, we learn a lot every single time that we do mentorship. I know that I learn a really a lot every single time. I know that, yeah, I really appreciate the whole mentorship experience. I really appreciate working together, solving problems, making friends, and I hope that everyone else does too. So, thank you very much. Do you have time for questions? Yes, we have plenty of time. So, one question I have, do you typically get assigned a mentee or do you select a mentee? And if you select, how do you do it to make sure it clicks, so to say? Yeah, that's a really good question. Most of the time, we select mentee, so in most of the different programs, for example, in Linux Foundation or in Google Summer of Code, there's a platform where students can apply to a project, and normally the way that we've done this inside of the Thanos team is that we will meet together with a group of, all the maintainers who want to mentor a student, and they'll review a bunch of applications together, and then whenever possible, we ask students also if it's possible to meet with them, to get more feedback from them, maybe have like a video call or something, and then we'll make a selection. It's happened that sometimes there's only one student that applies, so they'll probably be the student that gets the program, but other times there's a lot of students and we have to make some tough choices. Yeah, thanks. You got it. I just, I keyed off of the merge often comment, and one of the things that I've noticed, a lot of people coming into open source don't really know how to do intrinsically, is how to structure and break up PR so that they're easily reviewable. Is that something you talk about much with your mentees? Yeah, that's a really good question. This is something that definitely comes into the mentorship process, and I think that there's a couple of different strategies that you can take. One of the strategies that we do take is that we try to structure the work that we assign every week so that it's incremental, and we say, hey, maybe by the next week the goal should be to get these functions implemented, and then we can make the PR and we can review that. So we definitely try to structure the work, and then there's also maybe more pedagogical part, which is we'll try to impress upon them the importance of merging often so that you can get more feedback, but the other strategy is just to give these kinds of tasks and it will just happen naturally it's on its own. So that definitely works as well. And one of the patterns that I see people do often is they discover as they're working on something they need to refactor a class, and then that refactor gets pulled into add a feature, and all of a sudden the review gets more than twice as hard in comparison if you did the two separately, and I didn't know if you had had that experience as well. Definitely, this has happened to us, for example, with this one problem where we had to refactor this protobuf thing that took us weeks, like it ended up being a huge difference, a huge diff at the end of the day. And yeah, so it took way, way longer to review, and I think that this maybe a little bit signals the importance of having mentors as much as possible, do some investigative work before they're assigning their tasks to different students, and so they kind of have a rough idea. Obviously, things like we said earlier, there's a lot of unknowns, and they're gonna go awry sometimes, but as much as we can, if we can plan ahead, that's gonna be really helpful. Sometimes you also have to teach people intermediate get. That too. Which is a little terrifying. Yeah, thank you. All right, everybody, if there's any more questions, you can definitely meet me afterwards, and we can have a chat in person, so thanks a lot for coming.