 to keep an eye on your mentee and make sure that they're kind of going in the direction you want because they're not working in a vacuum. You may have set them off on working on some API part of your project or some obscure part that really needs freshened up or whatever they want to be working on, but that's still got to fit into the larger ecosystem of your project. So you got to make sure that they're going in the right direction. The student gets stuck. If they get stuck and they want to help them, if you don't have that clear communication line, then they're either going to sit on their hands and not do anything, or they're going to ask other people and you're going to get into the long solution problem again. Again, this is why. Another problem that we see with mentoring is that the student disappears. Now, I taught at the college level occasionally and one of the things I tell my students is, look, I understand you're going to get sick. I understand you're going to have family problems. I even understand that you're going to go out too late drinking this weekend and on Monday morning, you're not going to be quite human. Okay? And then you're not going to get your sign done when it turned in, right? And I always encourage them, and it's always amazing me how many university students feel like they can't do this. It drives me nuts. I'd say, just look, tell me. I can cut you some slack. Not every time. I mean, if you do this all the time, then we're going to have a conversation. But I mean, you talk to people. Okay? And your mentor, your mentee disappearing is something that really, that line of communication, hopefully that will never happen. And if it does happen, if they have a life crisis, if they have a situation where, look, I can't do this right now, then they should be free to tell you and you should be free to accept that. So how do we avoid situations like what I've been talking about? Well, obviously, I've kind of wove this in in the conversation in that, you know, you really need to have those lines of communications. And proactive mentoring is real what we call it. And I'm going to kind of walk through now what I think is proactive mentoring. The first thing you need to do is figure out your management style. There's a few different ways of doing it. There's the authoritative style where, you know, on the boss, you're not the boss. You know, I say you do it, you jump how high go. Okay. Unfortunately, I mean, that's not me, even with my daughters. So, but some people do that. And some people can actually make that work. They command a certain amount of respect. They're good at what they do. They can be authoritative. More preferable, I think, is like a democratic, collaborative forms of management where you have meetings and say, look, we've got this problem. How do we solve it? And then finally, coaching, which is sort of like somewhere in between where you list, you know, you kind of work in collaboration, but you're also the coach. You're leading the game plan and kind of going from there. I'm not here to recommend any of the styles, but pick the one you want. And for goodness sake, be consistent. Don't flip around. I mean, unless you have a major life change in your life and, you know, you've seen the light or something like that, if you start authoritative, stay authoritative. Okay. That doesn't mean be a jerk about it, but stay that way. If that's how you work best and people will understand it and work with you. Okay. A big thing that we do when we work with mentees in our organization and our projects is that we try to set expectations. We try to make sure that goals are aligned. So when we have developers go to our mentees and they say, you know, okay, what are you going to be working on is what the end result is going to be. You have to be very, very clear because unclear circumstances happen all the time. One of my favorite examples is, you know, every once in a while, I'll get an email from a former colleague who I've worked with and other jobs and they'll ask, Hey, how do you like working at Red Hat? And I'm like, well, how do I answer that question? What is the expectation of that question? Because is it, well, I love working at Red Hat. I work with really cool people and I get to do lots of cool things and I get to talk to people like you all the time. It's awesome. Is that what they want to know? Or are they kind of like, Hey, is there any job available? You know, no, and I'm not, I'm not complaining and if they're valued interested former colleague, I'm going to try, you know, find some, maybe find something for them. But I have to align my, my expectations with theirs and figure out how do I answer the question? And that's just one small example of how this happens with all of us all the time. So you line your goals, definitely define a process. And by process, I mean anything from here's the infrastructure of the project. Here's the repository where you go. This is how we do it. We use pull requests instead of, you know, straight mergers, things like that. Any of that little detail work, you've got to make sure you find that process. And again, that helps avoid confusion in the long run. Take an interest in the mentee. Okay. You need to involve yourself in active listening, relationship building and learning how they do it. Because this is actually leading to the big finish. Okay. But you really need to kind of know where mentee is about. Where are they coming from? Where do they want to go? And how they approach things. Okay. Now, question, don't be stalker. Okay. Because you don't want to be the guy or the gal who is, you know, for, hey, what do you do this weekend? You know, what, you know, how, how was your weekend? You know, you know, who are you with? Where'd you go? What, you know, no, that's bad. Don't do that. But do you find out what their interest in it? Like an example, I used to be a reporter. So I was the mainstream media that Trump is yelling about. I'm sorry. But I was a mentor for a young reporter who really didn't seem to like doing what we call in the business feature stories and feature stories where you go up to somebody and they've done something really cool. Like they built a house made out of popsicle sits or something like that, which I swear to you is almost true. They do something like that. And you send a reporter that and they're like, and they're like, they turn back that, you know, it's like, well, no, why, why did they want to build a house out of popsicle sits? What motivated them to do that? You know, I'm sure we, they're crazy, but maybe get deeper in there and find out. And this reporter really can really use stories like that. And then I found out that she was a stamp collector. And I was like, and I'm not a stamp collector. But I know about stamp collectors is this and coin collectors and any other kind of collectors the big detail oriented. So I started putting her on stories that had lots of data in them. Like I would send her to the local school boards is very small town. I'd send her to local school boards. We have to go through all these different rules and regulations about the schools and the city councils and things like that. And she loved that. And her writing got better because she was passionate about detailed work. She didn't care about the touchy feely emotional popsicle house building guy over here. She wanted the right facts. And so that worked out. So understand the motivation of your mentees. And that will go a long way to helping them flourish in whatever job you have them doing. This is a problem that some people have way before giving advice. This gets into again active listening relationship building and learning their style. But the one thing that you need to do as part and parcel of this is when somebody comes to you with a problem. It is very easy to try to want to fix it. We are all developers or sysadmins or technology oriented people. We like to build and we like to fix. That's not always a good thing. Because that doesn't necessarily help them. It might solve the problem but it might not help them. There's two different ways of doing that. So there's an article I read on the internet when I was researching this. He basically said he calls this hitting the pause button. So when a mentee comes to you with a problem do not immediately respond to them and say here's how to fix it. Also and this was actually interesting. This is what I used to do. Don't just give an example of how this had happened to you before. Because in these enlightened times that's been presented as an option of how to do this. Instead of solving their problem you just back and say well yes when I was kid something like that happened to me. This is kind of how I did it. And that's good but it's not even that might not be the best thing. This gentleman recommended and I like this was that you ask the mentee more questions about what their problem is. You try to get to the heart of the matter and you kind of guide them to the solution. This is more time consuming. This may not get the problem fixed. It may not be always recommended because if the problem is hey the server is on fire you might not want to hit the pause button. I get that. But it is something that is not really time sensitive and you can kind of sit back and wait a little bit and work through it. That's a better way of doing it. Guide, use guided questions and try to work them through. They are having a problem with the manager on the team. Why did this problem start? Why did it happen? What do you think is going on? You can still answer some questions for them. You are the mentor. You have got some knowledge here. Oh yes, well that manager really doesn't like that kind of code because there was a terrible childhood accident that he had with C. You think I'm kidding? A nightmare is about Pascal but that's a whole other thing. But things like that. You have knowledge so I'm not just saying sit back and let them try to figure it all out. Give and take and help them kind of work the solution out themselves because after they are done with you they may have other mentors but they are also going to have their life ahead of them. Because typically mentees tend to be younger, not always. I don't want to discriminate on age but they typically tend to get the start of their careers. So they have got to kind of figure things out on their own. Don't assume anything. This is my biggest thing. You can watch the news and see how stereotypes and assuming things about given people are making things bad everywhere. You don't want to have stereotypes. You don't want to just say and this is a trap. We all fall into this. My big thing is probably as I am getting a little bit older I'll be 33. How do I work with people who are obviously much younger and smarter than I am? But they don't have that wall knowledge. So for me that's a challenge. It's like okay I don't want to stereotype and say oh you're like really young so you don't know anything. And that's a real problem for me. And how do you work to avoid that? You've got to push through that. You've got to perk each person equally and figure out what they're about. And this goes back to the other slide where you've kind of talked about what they're about and figured it out. Don't just assume that because somebody is in a certain social group, gender group, age group, any group, programming group. You know I know the pearl people have a problem with our people and the python people but no it's okay. But don't seriously don't assume anything about how you're doing this because you need to actually understand what they're about and emphasize the communication. Because here's the one basic thing I want you to remember from this entire talk. If you're going to be mentoring anybody or you're going to be a mentee, okay? The one thing you need to remember is they are you, okay? And this is a problem sometimes. I had no no no no. So when I was starting out as a young porter on a small town newspaper and I was covering things like the popsicle houses and things like that. You know my boss was this really crusty old, I swear to you, cigar chopping journalist who had been around since the dawn of time. Okay, very gruff, very conservative, very authoritative. You know and here's me. Not really. I'm Mr. Him maybe hey how's it going kind of thing you know. So our working relationship was difficult especially at the very beginning but I will give him credit. He never tried to make me into him. Okay, and that's actually a pretty sign of a good mentor or a good boss for that matter. You had to let your people be themselves. If you want everybody to be like you then go stand in front of a mirror. Okay, and have fun with that. Maybe not. But they aren't you. Okay, motivation comes in different forms. Okay, and this is my one non-free picture and I put like through the copyright in there and I apologize but it's a perfect example of what I've seen. If you've ever seen Kung Fu Panda this is a funny little kids movie and you know I have child so what are you going to do? But the one thing I liked about this movie was they try to teach this panda how to do Kung Fu using the old traditional ways and it didn't work and the only way they actually succeeded was they figured out what this panda was about, food and how motivate him to do what they needed to do and so they took a completely different five ways approach to doing it. Now obviously that's a fictional funny haha kind of example but it is telling because this is the kind of success stories that we see with mentors and mentees all the time. Okay, understand your mentee. It's not about just getting a project done. It's about making sure they have the tools to guide themselves through your project and other projects beyond that when they leave and go and do other things. And with that I believe I'm done. I am done. So any questions? Yes? Thank you. How do you help your mentor as a mentee to become a mentor for you? How do you help? We have like a mentor who have assumptions about his mentee and stuff like this. Okay, so the question is if you have a mentor who's making assumptions and maybe not doing things as well as they should how do you kind of guide them through it? The first thing is well lead by example is always good but the other thing is too in your project it helps to have I mean again I'm gonna go back to Google Summer of Code they have a lot of rules and a lot of documents and they're awesome, right? But that's them and they're paying money and they gotta make things really formal rigid. You don't have to do that but you should have a framework in your project. If you're gonna start really mentoring people on a regular basis then I would say that you would go to the project leaders or start this yourself and say we're gonna mentor and we're gonna follow these guidelines. You know, because you need to have some things to fall back on. So if somebody here is not being a good mentor you need to kind of have at least some guidelines that say well that's not how we do things. As a mentee? Yeah, you can. Because a lot of what I said was mentor to mentee. Okay, I misunderstood your question. So you're asking how as a mentee we approach this. If you're a mentee and you've got a mentor that's not doing this right you can establish a communication, you can be proactive and say look this is what I want to do. How do you help me do this? And if they can't help you and they're really resistant to change then you may want to reevaluate the relationship. But yes, you can be proactive for your side. It's a two-way streak because there's a thing where it says mentor is here, mentee is here. Do this. It's not really that. It's more like this. This person just has more experience about that project. I guarantee you every single one of you in this room is smarter than me about many things. I know a lot about comic books but you may not. But you may know something really about something else that's cool to do. It's a difference in experience. It shouldn't be a hierarchy kind of thing. But if you're a mentee, if you find yourself in that position, don't be afraid to push back. You've got to get something out of this. Yes. Any suggestions or results to start in North? The question is how do we sign up mentors and mentees at a project? The first thing is, well, see if you need, see if you have a history with this already. Because sometimes some projects are easier to enter than others. Sometimes it's so easy to come in and collaborate. It's awesome. You don't really need to mentor anybody. But if you want to do this, what we did in Overt was it was pretty straightforward. We set up a separate mailing list. We made announcements to all the developers worldwide and said, look, we've had great success with Google Summer Code. We've had great success without Ricci. We'd like to keep doing this because we really need to get more developers into our community. So for us, it was not a very formal process. We basically just sent out the word, found out who was interested. I was there as a community manager, so I was there to identify people who might be stakeholders in this. And so it was kind of nice because I had some people step up and say, I would like to do this. So that's one way of doing it. And I do suggest you sort of cast a net, see if anybody's interested. If they're not interested, find out why. Maybe you don't need mentors. Or maybe nobody in your project had a good mentor when they were younger. So at that point, you have to flip it and be proactive and say, well, I think this is something we need. Yes, that's kind of what we don't know. A lot of potential mentees ask for mentors, but there's no, we don't know how to attract mentors. What do they say when you ask them? Or is it just like crickets when you ask? Do you know who they are? Well, yes, this is in my company, but we need a potential mentor. Now, see, if you're working in a corporate kind of way, one thing you could do is try to get that, try to make that a part of their job description. You know, we never had to do that at Red Hat because there's people at Red Hat that love to do this kind of stuff. But I've seen that done. Now, again, I'm not your company, so I don't know. But that is a way to do it, to encourage participation and say, hey, this is something we feel like, that if you want to move up the ladder, you know, you giving, sharing your experience with somebody else is an important part of that. Yeah, I'm not really selling on that. Just one more. I think you had your hand up. He had his hand up first. Someone said to us that a good mentor, don't give correct answers, but make good questions. In order to build this kind of relationship, do you have any suggestions about good questions? So the question was, what are some good questions that you as a mentor can have for your mentees to be a good mentor? I really, ever since, and that was a true story, although not about the Popsicle house, but because I blanked on what it really was. But I really did have a young person who was not really into detail, didn't want to do the feature stories, really wanted to do the detail work. So ever since then, every time I've been a manager or mentor or whatever, I've always asked the question about what are your interests, which seems a little personal sometime, but for me that's a great question. So what are your interests outside of work? Why do you start, like, as a developer, why do you start coding? You have to learn what you can about that person. To me, those are the questions. So there's not really like one or two or three questions in there. But the overall goal should be, you know, just find out as much as you can about your mentor. And by the way, share a little bit about yourself to them too. You know, if they understand about you, then they might not be defensive because it is hard to get away from the whole up and down mentor-mentee thing. You know, so I'm very self-defacing, like, personally. So I do tell people, look, I'm a nerd, you know. So deal with me like that, you know. And I think those kinds of questions help most. So, yes? Yeah, because she's smarter than me. So if the mentor, the outreach program is for mentors or if it's for communities or the May to August graph. So if you are interested in being a mentor, come talk to me. And by the way, sir in the back, actually, as soon as she said that a meeting might be going on, tell your people maybe they should practice first on a formal program like outreach. Because I think that our participation in outreach and Google summer code kind of helped spark more interest in mentoring within our project. So, yeah, use them as kind of a starting point and see how people like it. So, thank you, sir.