How to Get a Mentor Without Telling Them

Hi everyone. I'm Erin Fox and I am so excited to be here in London, so excited to be here to talk to you all. This has been a passionate kind of project that I've come across lately and as I was refining key concepts and ideas for this talk, I realized that it should have been called How to Get a Mentor Without Telling Them or Secretly Get a Mentee. So a little change in the title there, so it'll be fun. Of course, I like setting myself up with some goals. So how to be a good mentor and a good mentee I think is very important. We don't really talk about how to be a good mentee. Usually it's mentor and so we'll go a little bit into that. There's always room for improvement in your career. If you hate your job but you love your company or you love your company but you hate your job, I think mentorship can really help level that out and have a really successful career. And even if you guys are here today, you've came to watch my talk, you've came to react Advance, I think it's a great audience because one, you're really excited to, well, hopefully you're excited, but you're here and you want to further your career, you're here to learn and so I really think that's a good crowd to be talking to. And so how are we going to achieve these goals? So as I mentioned, we're going to go into mentorship, particularly like engineering mentorship and how I think that's a little different than the traditional mentorship. We'll talk about some tips of being a good mentor and a good mentee and I have a fun example of a bad mentor experience that I've had that we'll talk through. I have some really fun stories of my experience on how I get mentors without telling them. I think it's very traditional to go up to someone and be like, hey, I want you to be my mentor. And it's like, you know, I got a lot of PRs open, I don't have time. That's a big commitment. And I really see it as how you approach someone. And so I don't remember where I learned this, but if you approach someone straight on, that's like very intimidating. Like, hey, do you want to be my mentor? Like in your face. But if you do like the side step of like, hey, you want to teach me a little react for like an hour a week? That's kind of my move is approach from the side from someone that you want to learn something from. So we'll go into my tips there. And mentorship, like I mentioned the slide in, has really come so natural for me. Up until a little bit ago, I was working on a promotion with my manager and she sat me down and said, you're really good at finding people to help you with things and you're not realizing how much you're helping them. And I was like, oh, I thought I was just being really selfish. I was just trying to get my job done, trying to, you know, do the day to day. But as I slowly started forming this talk, I was like, dang, I am helping a lot of people. And we'll get more into the examples later. But naturally asking for help, putting yourself out there, being in vulnerable situations in order to become a better engineer not only ends up progressing your knowledge in certain areas but it has the ability to help others further their career, find out if there are certain roles they want to become and maybe even establish a new thread of learning throughout accompanying your team. And so I'm not afraid to be vulnerable. I'm not afraid to say I don't know a lot of things. But I'm willing to admit I'm very good at getting mentors. And I think the first thing I mentioned about mentorship, it does feel very concrete. And so I want you to walk away thinking that maybe you already have a mentee or you're a mentor to someone and you don't even know it. And yeah, so it's a slowly approaching from the side I think is kind of like a thread throughout this talk. And we'll have some more specifics later. So let's break it down. So my definition, a quick one, is teach people what you know and then teach them how to teach themselves. It could be explained a lot of other ways but for me that's the main concept of engineering specific mentorship. And so with any mentorship relationship, we have a mentor and we have a mentee. And usually the mentor is the more senior person and the mentee is the more junior person. And so I think when you have a mentorship, let's say like now in this day and age, I don't know if that's the right saying, but it's like you're the mentor the entire time and you have a mentee. And I kind of want to break that. I want to be able to flip flop the titles. So like sometimes you're a mentor and sometimes you're a mentee. So say I'm really good at react. I'm here at react Advance. I hope I know a lot of react because I'm here. And I'm working with someone that's really good at Rails. And I don't know much about Rails. There's like magic that happens and like files get added and it's, I don't know, active record things. And so I want to be able to like swap knowledge. So I'll be able to be the mentor when I'm teaching about react. They will be the mentee even though they probably have like 20 years of experience because Rails is so old. But then we'll be able to flip that. When I'm trying to learn about Rails, I'm going to be the mentee and they're going to be the mentor. So it's a very flip flop and back title. And I think that's really the big benefit of a mentorship is being able to learn from each other. And so let's talk about a good mentorship. Someone who is willing to learn and share their knowledge and help others. They're willing to listen and explain hard concepts in a handful of different ways. I think the smartest people, the smartest engineers that I have ever got to work with or to learn from are really great at explaining concepts like three ways. My favorite thing to do to know if someone... I do this to my husband a lot. I'm like, do you really know that? Do you know... Explain that in like three different ways. Like, just find out if they really know what they're talking about. And so being able to understand a complex topic and explain it a handful of different ways for other people to understand it helps the person learn and understand it and it helps you to be able to explain things and actually understand the concept. So they also provide guidance by guiding the mentee in a certain direction, not by doing it for them. Don't take over the keyboard. Don't take over the screen. How many times have we been remote pairing and it's like, oh, can you give me control? Okay, here's a function. You know, like that happens a lot. And being able to teach them to teach themselves, helping them find the right file can really make it so you don't have to have this call again. Like, you've helped them discover how to find a file once. Hopefully they'll be able to find it again. Google with them. I can't tell how many times if somebody asked me a question and I asked, like, not mean, but did you Google it? Did you really, like, do you know how to Google correctly in a way? And it's a skill. Googling really is a skill to learn. Google with them. Teach them, you're like, I don't really go to this one. I really go to, like, this file to find all my code. Let's just copy the stack overflow and see if it works. And then they learn about stack overflow, they learn your shortcuts, they make the time more efficient. So really teach them to teach themselves. And these little moments are really, like, mentorship moments that you might not even realize that you're doing. And now we have a good mentor, but, like, has anyone had a bad mentor or a bad experience? Because I know that I have a great example of nobody does. Okay. So as I was working as a junior engineer, I was, like, fresh, didn't really know how to Google, didn't know a lot of things. And so we were pairing probably, like, weekly on frontend react. At the time it was react Native things. And I was leaving way more confused than when I started. And it really helped me understand and, like, create this effect that I like to call is the Siegel effect. And the Siegel effect is when you're pair programming, someone comes in, messes everything up and then leaves you. And you're, like, my linting errors are going off. Like the console. All my tests are failing. And so it's kind of like Siegel, like the bird at the beach. You know, the annoying bird. So they come over and crap all over the place and fly away. That's the Siegel effect. So they attempt to help you. They make a bunch of changes. Then leave you hanging because you got overwhelmed with not knowing how to solve it. You got too busy. Or they don't know how to be a good mentor. They don't actually know what they're doing. They leave you in a worse situation and you have no solution, no confidence. You're probably thinking I suck at my job, I should quit. So the Siegel effect is real and doesn't apply just to engineers. It could be in your life. And we don't want any Siegels in our life. But I was actually doing some great reading on Twitter earlier today and some British journalism came up and I found this one. For us, we were learning that exotic bird they found was actually a Siegel covered in curry. And I thought this was great. I was, like, oh, my gosh, another Siegel effect. I haven't had time to figure out what this metaphor would be. I feel like this one is a lot worse than the crapping all over your code and flying away. This one is like deleting your code base or something wild. When someone is trying to help, the crap's all over your code and flies away. I've been a Siegel at times, not knowing that I was. It's good to recognize when you have them. If it's happening, I think when you are in a mentorship or you're pairing with someone and it's just not working out, take a pulse check. Maybe, like, I'm not hitting my goals, not hitting my work goals. Time to just take a step back and maybe find a better partner, take a pause. I think side tip, that's, like, a great thing to do. Instead of saying this isn't working out, say, oh, let's take a pause. Let's take a break for a month or so and pick back up in a little bit and see how it is. Because then it's not, like, I mean, obviously you want to give them direct feedback and say, yeah, the pairing is not really working for me right now, but I want to take a pause and evaluate my goals and what's happening and take a pause. So now that we know, don't be a Siegel. Maybe you are a Siegel. There's a cure for it. What makes a good mentee? So no one really talked about this. When I was starting off, I saw all these great mentorship, like how to be a good mentor. I couldn't find a lot on how to be a good mentee. And so I kind of have my own stuff going here. So open and willing to learn. They show up prepared. They've Googled the topic, they've watched videos, you've read blog posts, you search the company Slack. Sometimes people post a whole bunch. Slack has so much information. Just get good at searching in there. Maybe they find the right, like, in the code base, they find the right file and say, oh, this is called, like, new email JS. This is the page where all the new emails are. But you don't know, like, the syntax or the code to find it. So they've done everything possible before they've shown up. I think another thing that's important for a mentee, too, is learn who you're working with, their communication style, and how you work with them. So I pair with someone who wants to know exactly what we're working on ahead of time. So I'll send them the PR, I'll send them a line of code, I'll send them a little blurb of what we're working on. And other times I work with people that just like to jump right in and it's a fun challenge. So learning about who you're working with is a great skill as a mentee. And I think learning about each other, too, when you are doing as a mentee, learning their styles, it really, like, helps company culture and enhances the experience and it really speeds up the learning when you are learning. I've written an article about this, how to pair programming when remote. It can be remote or not remote. It's kind of the same thing. Yeah, if you have any tips, I'd love to hear them. You can throw them in here or hit me up on Twitter. But really, really into that. Okay. So I really do believe mentorship is a great way to spend your time. You can spend it during work with someone that you work with or not during work. It's a really good way to just, like, feel good. You read about all those, like, older people, like, about to pass on later in life and they say, oh, what advice do you give to the younger crowd? And they're like, oh, work less and all this stuff or help people more. Help people more. You never know. You could really feel good about helping people succeed in their career. They wouldn't be maybe in their career without your mentorship that you're giving them. And it's important to know that both you and the other person, whether it's the mentor or the mentee, show up wanting to achieve something. If you don't have that two-way street, it's probably not going to work. It could be really, like, granular, like, how to learn Rails, as I mentioned earlier, or best architectural practices for a react app. Or even if you're just trying to negotiate your salary and you see someone that had a great has a great career with poise and confidence, message them and be a ten-minute conversation. I think that's a great, fulfilling conversation that you could have for mentorship. And so I walked through a lot of these theories, and now I want to illustrate some specific topics that I've had throughout my career. And throughout my career, I've always had a mentor. Wherever I've worked, I've always found people's strengths. I love meeting people, I love getting in there and learning about what they're really passionate about and what they're really good at. And then I seek them out to help me. Which sounds really selfish, and it is. I want to be a smart, more well-rounded engineer, and so I want to find alleys and avenues to help me get there. And the first step is to really figure out what are your weaknesses and who has those strengths. So a weakness of mine could be react. Strength is coming here and trying to find someone, do the sidestep and say, hey, you want to teach me some react? And then vice versa. What is someone's strength that I could share with others? So I'm giving a talk. I would love more people to give talks, more people in representative groups to give talks. And so I'm more than willing to help people, mentor them, and to be giving more talks. So how do I get mentors without asking them? So I have a mentorship story, I have a pair programming story, and a leveling up story. So I am a full stack, full time software engineer at ConvertKit. ConvertKit is a creator marketing platform where we help creators earn a living online through email marketing. I should be better at this. Earn a living online through email marketing products and more recently email sponsorships. We are about 20 engineers across five teams. When I joined a few years ago, I knew nothing of Rails. I mostly had react Native and react experience. I was becoming a full stack engineer. So I wanted to get paired up with someone who has been at the company long enough because I have no idea how to search files in Rails so hard. So I wanted someone that was there for a while and knew their way around. And luckily we had a formal mentorship program. So you tell what your goals are, you get paired up with someone, and it was fantastic. I didn't ask him, I just signed up for a program and I got a mentor. And initially the program was quarterly, so you could switch mentors if you want, but we have stuck together for over two and a half years now. We meet once a week or every other week. And the reason ours, other than what I have already mentioned about a good mentee and a good mentor, a reason I think it has been so successful is because of side projects. Sometimes if you have a mentor and you don't know what to work on, side projects are really fun. I know there are some projects at work that you are dying to change or dying to do. This is a great example of what you can. The code that kind of lies between the squads never really gets completed. So we ended up working on an email signup validation project. And so what that means is we learned that historically people who sign up at ConvertKit with a Gmail account, traditionally later on in the funnel, end up being higher paying customers. So we wanted to be able to catch their misspelled email through login. So a lot of people forget the dot in dot com or they do gmail instead of gmail. So we were able to work on a mentorship project where we could do a full stack project and catch these and eventually get to see a lot of the data come through of us getting higher paying customers. And so from the mentorship perspective, he was able to really work on a passion project of his that he would never have gotten to do. And so if you hear someone mention, oh, it would be so great if we had better authentication or if we have life cycle components and we want to use hooks, those are good opportunities and side projects that you know you never really get the chance to do. But if you want to do it, you can find a mentor, you can find a mentee, do it once a week for an hour or so and get that through. So the whole time that we're doing these projects, we do it through pair programming. And when I started, there was no pair programming at my company. And I love pair programming. So I wanted to see if we could make it more common and more real practice across our remote engineering team. And again, I'm selfish, so that's why I wanted to bring pair programming to the company because that's how I learned the best. And actually, more engineers pair every day at ConvertKit now and it really helps build a culture of engineers working together, as I mentioned earlier in his talk, go further together. That's kind of the goal. Through participation and encouragement of pair programming and by bringing and starting to work together more, the entire team is better for it. And so I think a simple Slack, like a public channel in your company of, hey, I don't really understand use effects, I went to a couple of talks at react advanced, but I'm still confused, does anyone have time to help me with it? And that's a great mini mentorship opportunity. Hop on a call, be able to talk about their lives, great company culture, and then be able to share your knowledge and everyone's learning. So pair programming is a great way to have these little micro-mentorships, kind of sessions without really asking for a mentor. And lastly, can you level up in your career? Another teammate and I started working, I wanted to learn more about Tailwind. In the beginning I never really knew how that worked. So again, selfish, I really wanted some help learning more frontend stuff. And not only was I getting a lot of great frontend UI debugging experience, but they were learning how to be a mentor and I would ask them for career advice, I would ask how their kids are doing, what architecture would you recommend I do for this api component. And they were discovering that they really liked it. They really liked mentoring. And eventually an engineering managing role opened up and since they had concrete examples, they had experiences to pull from working with me, they got the manager role. And so mentoring can open up doors for career opportunities, maybe you don't know if you want to be a manager yet, so maybe mentoring can help you see if you can get there or you want to be a tech lead. It doesn't have to be a heavy label. It can be mini pairing sessions. It's not a large time commitment if you don't want it to be and it's a great way to learn like different career paths that you're into. And so putting yourself out there and being open to learning as a mentee or a mentor can really inspire other people to want to do the same and that's why I'm here. Setting up a mentorship program with your company, focusing on side projects, pair programming, really enhances your career and others' career and that's what I hope you get from this talk. Just to learn about these ways to get a mentor without telling them or maybe secretly get a mentee. And, again, this is a real rising passion of mine. I think about it probably more than I think about code lately. So thank you for listening. Thank you so much, Erin, step into my office, it's been a while since I've been able to actually sit down and do a Q&A live, so it's good to chat. First of all, how are you feeling? That was a great talk, by the way. Thank you. I'm good. Good, good, good. So we've got a few questions coming in from the audience, coming in, and one of them is more just about sort of pair programming. You talked a little bit about pair programming and asking for tips to build confidence and prevent anxiety. I mean, I've done live demos, I've done pair programming, and just there is this magical thing about when someone's looking at you type, just everything goes crazy. So any tips for anxiety and confidence when you're pair programming? Yeah. I think for me, I like to be super organized before I pair program. So like I mentioned, I do all the Googling, I like to have the files up, I like to have the slacks up, I have a list of to-dos, and I have a list of questions. So I think being prepared really helps before you even hop on a call or sit next to someone. And that helps with my confidence level. But I think nobody could type in front of anyone. Everyone gets so scared of live demos, so it's like we're all the same. So it's hard to not be scared, but we all can't spell. Yeah, absolutely. I feel like I've been there where your hands start shaking and you can't actually type. I've been there. One thing you talked about, which I loved, and I'm not going to try to flashback to any breakups I've had, but when you talked about like, oh, we need to take a break, maybe for a month, we're going to pick it back up. How do you let a mentor know, right, I would like a break, but you also do want to give that mentor that feedback as to what maybe they could be doing better to be a better mentor to you, to be a better mentor to someone else. How can you communicate that in a positive way? Yeah, I think regularly throughout a mentorship, you should always have some pulse checks of like, hey, how's this going? Is this the right time of the week? Like, do you need it like on Tuesdays instead of Fridays? Or how's it going? Are you getting anything out of this? And if you're not, like, that's totally fine. Like, just be open and honest with them if it's working. I think it's really important to tell them if it is working, because sometimes they don't know and it's good to know. I've had times where it was the whole Siegel thing. That was the first time I had to have been like, I think you're really busy right now. And you know, like, Sally's not. So I'm going to go. I'm going to get some help from Sally today. And maybe we could pick back up in a couple weeks when you're not as busy. Or I'm trying to like learn a different, the different styles. And I'm not quite connecting with the way that you're learning. I'd love to give you some tips. But I really got to get this project done. So thanks for your time. That's a lot. I totally get that. And I think that's a great approach. And one thing you spoke about, you kind of dropped being busy. Because one thing that happens is sometimes there's deadlines coming up and we need to focus. And sometimes things that are good practices become the first to go. And pair programming might be one of them. So how do you manage that? When, for example, as a sort of organization, as a team of developers, you start getting busy and pair programming doesn't necessarily seem as high on the list of priorities. But how do you make sure you can still fit it in? Yeah, I think that's a great question. I think it depends on the project. So I mentioned with the passion projects, the side projects that we get to work on. If we're at that, I do cycles. So if we're at the end of the cycle and nobody really has time and everyone's frantically trying to get their work done, we won't have the pair session. So I think if it's a pair session for a project or depending on like your timeline and your goals for what you need, I think taking a pause on pair programming. I do a lot of pauses, I guess. Taking a pause on the pair programming for a bit to get like essential work done is totally normal. Yeah. And I love when you talked about giving a pause, taking a pause, also sometimes setting a time frame. So it could be, can't do a pause because I'm busy right now, but in a month or after this deadline, let's pick it back up. And someone asked a question which I find very interesting, which is, how do I get my teammate to do pair programming with me when they prefer texting? Oh, yeah. That's tough. Because some people just don't really enjoy texting. You mean just like on Slack? So a part of me thinks it's like a Slack, either they'd rather just answer questions rather than sit with you. If you're ahead, you can feel free to like clarify. Yeah, no, I work with people that are totally into more text-based too. I think that could be just their style of communication and they don't want to be on video and that's totally fine. I think you could go screen share and not be on video. I do that all the time too with some people. So you don't actually have to be on video to do it. A part of me is like, I just say, I don't really understand this, can you explain it in a different way? And so if they end up just typing a lot and you ask them three times and you still don't understand, like, it's not really clicking for me, I'd love to do a demo. Do you want to schedule time or do you know anyone else that has time that can help me? No, I totally get that. And one thing you kind of spoke about is you spoke about different ways. Maybe it could be a video. How do you, because I, for example, I know at work we're trying to do a lot more async. So how would you do like async mentorship? Is there such a thing as async mentorship? Yeah, I think posting in Slack and if anyone has time in the next week or so, pair program with me or text it out, I guess, if that's what you want to do. I think just not setting deadlines on mentorship or pairing makes it more approachable in a way. So, yeah, I think just posting about it on Slack, like, can I set up time with anyone either today or tomorrow? Give options. I think that's the best way to gain the goal. And kind of a question that's come in, because I know some people in this room might be mentors themselves, and I think this is a good one, which is what are the things you've done to the co-op to avoid dishing out the seagull effect as a mentor rather than just as an employee? Yeah, I think knowing what I don't know. So if I went in and tried to do some, like, kubernetes stuff, I would be a seagull. Or some Docker stuff. Like, just knowing what you know and what you don't know to be able to help someone is good to know. I would be like, oh, let's go talk to Chris. They know so much more about it and I want to learn, too. So I'm going to stay on the call. So I think knowing that the seagull effect is a thing is good. And then knowing other people that can help you not be a seagull. Nice. And as you sort of people grow and become from starting off as junior developers, become senior developers, staff developers, principals, leads, their time becomes much more higher in demand. How does someone who maybe does have a busy schedule, how do they balance mentoring others and getting their own work done? Yeah, I think time management is really huge. I think my mentor that I mentor with, now we're going once a week and it was a lot. So now we go every other week. I think just being open and honest of what you can work on. And if you don't have time for side projects, maybe someone just needs a lot of help understanding hooks. And so you'll just have 30 minutes of hooks practice or something like that. I think understanding how much time commitment they can have and how much you have, the communication there just from the beginning. Now that makes total sense. I know people folks, you can still feel free to add more questions. But one question that I've kind of had is like sometimes I have a mentor and maybe there's a mentor in a specific scope or a specific thing, kind of like what you spoke about in different languages. When you think about your mentors, is there any way you categorize them or is just every mentor kind of generalist or do you have mentors you go to for specific things? Oh yeah, I have like 10. For different reasons. Like one is like career advice, another one is Rails, another one is react. I think having just the mini ones makes it a lot easier than just having one that is limited on their knowledge. And then it's less of a time commitment. So I don't, I just know like, oh, they're really, this is who I go to for career advice, this is who I go to for react advice. And I think that's, it's beneficial to have it that way because you're like networking and you keep connections with people at older jobs. And you just, yeah. Yeah. No, I totally get that. I think like having multiple, it's like diversification, right? You shouldn't just do it with your stocks, do it with your mentors as well. No, thank you so much. Really, really appreciate having you here, Erin. And let's give Erin a wonderful round of applause.