How to Get a Mentor Without Telling Them

I'm Erin Fox and I'm so excited to be here in London and talk to you all. This has been a passionate kind of project that I've come across lately. 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. Little change in the title there. It'll be fun.

Of course, I like setting myself up with some goals. 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.

Even if you guys are here today, you've come to watch my talk, you've come 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. I really think that's a good crowd to be talking to. How are we going to achieve these goals? As I mentioned, we're going to go into mentorship, particularly 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, and 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, 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. I don't remember where I learned this, but if you approach someone straight on, that's very intimidating. Like, hey, do you want to be my mentor in your face? If you do the side step of, hey, want to teach me a little React for an hour a week, that's kind of my move, is approaching from the side from someone you want to learn something from. So we'll go into my tips there.

And mentorship, like I mentioned the slide in, has really become 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. Like, I was just trying to get my job done and 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, like, vulnerable situations in order to become a better engineer not only ends up, like, progressing your knowledge in certain areas, but it has the ability to help others further their career, find out if there are certain roles that they want to become and maybe even establish a new thread of learning throughout a company or 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. I think the first thing that 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 thing, 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 Advanced. I hope I know a lot 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. Not that I have any magic that happens and files get added and I don't know, ActiveRecord things. And so, I want to be able to swap knowledge. So, I'll be able to be the mentor when I'm teaching about React. They'll be the mentee even though they probably have 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-flopping 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's 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. Do you really know that? Do you know... I've done it 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 them 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. 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. 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, not mean, but like, did you Google it? Did you really, like, do you know? Had 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, oh, 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, 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're 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 the Seagull effect. And the Seagull is when you're pair programming, and someone comes in, messes everything up, and then leaves you. And you're, like, my linting errors are going off, the console, all my tests are failing. And so it's kind of like Seagull, the bird at the beach.

You know? The annoying bird? They come over and then crap all over the place and fly away. That's the Seagull 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. Or they don't actually know what they're doing. They leave you in a worse situation.

And you have no solution, no confidence. And you're probably thinking, I suck at my job. I should quit. So the Seagull effect is real and also doesn't apply just to engineers. And we don't want any Seagulls in our life. But I was actually doing some great reading on Twitter today. And some British journalism came up. And I found this one. For us, that exotic bird they found was actually a Seagull covered in curry. And I thought this was great. Oh, my gosh, another Seagull effect. But 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 delaying your code base or something wild.

Yeah, when someone is trying to help, the crap all over your code flies away. I've been a Seagull 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 and be 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 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. Then it's not, I mean, obviously, you want to give them direct feedback and say, yeah, the pairings aren't really working for you right now, but I want to take a pause and kind of evaluate my goals and what's happening and take a pause.

So, now that we know don't be a Seagull, maybe you are a Seagull, 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. 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 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. 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. Other times I work with people who 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, you 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 thread 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 could 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 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 like 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 ten-minute conversation. I think that's a great, fulfilling conversation that you could have for mentorship.

I walk through a lot of these theories and now I want to illustrate some specific topics that I've had throughout my career. Throughout my career, I've always had a mentor. Wherever I've worked, I always found people's strengths. I love meeting people. I love kind of like getting in there and learning about what they're really passionate about and what they're really good at. 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. I want to find alleys and avenues to help me get there. The first step is to really figure out what are your weaknesses, and who has those strengths. A weakness of mine could be React. Strength is coming here and trying to find someone, do the sidestep, and say, hey, want to teach me some React? And then vice versa, what is someone's strength that I could share with others? I love more people to give talk, more people in representative groups to give talks. 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? I have a mentorship story, a pair programming story, and a leveling up story.

I am a full stack, full time software engineer at ConvertKit. It 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're 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 full stack engineer, so I wanted to get paired up with someone who's been at the company long enough because I have no idea how to search files in Rails so hard. So I wanted someone who 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've 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've already mentioned about a good mentee and A reason that I think it's been so successful is because of side projects. Sometimes if you have a mentor and you don't really know what to work on, side projects is really fun. So I know there's some projects maybe at work that you're like dying to change or dying to do. And this is a great example of what you can. So the code that kind of lies between the squads never really gets completed. And 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. And so we wanted to be able to catch their misspelled email through login. And so there are a lot of people spell, they forget the dot in dot com, or they do Gnail instead of Gmail. And so we were able to work on a vendorship 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, from the mentors 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, like those are good opportunities and 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. Again, I'm selfish, so that's why I wanted to bring pair programming to the company, because that's how I learn the best. 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. I think a simple flack, 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? 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. Pair programming is a great way to have these little micro mentorships, sessions without 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. I wanted some help learning more frontend stuff. 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, I would ask them what architecture would you recommend I do for this. 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 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 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 different career paths that you're into. And so putting yourself out there, and being open to learning as a mentee or 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. 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 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, 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, like, 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 spell.

Yeah, absolutely. I feel like I've been there where your hand starts shaking, and you can't actually type. I've been there. One thing you talked about which I loved, and, like, I'm not going to try to flash back 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? Do you need it on Tuesdays instead of Fridays, or how's it going? Are you getting anything out of this? And if you're not, that's totally fine. 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 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. I'm trying to learn 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.

No, 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 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 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 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 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. Yes. If you're okay, feel free to clarify. Yeah, 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. Part of me is like, I just say I can't, I don't really understand this, can you explain 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, be like, ah, it's not really clicking for me, I'd love to do a demo. Like, do you want to schedule time or do you know anyone else that has time that can help me? No, I totally get that. 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.

So, yeah, I think just posting about it on Slack. Be 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 other 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.

Yeah, I think knowing what I don't know. So, like, 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. Like, 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, self-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 were 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 a side project, 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.

That makes total sense. I know people 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 a different reason. Like one is like career advice, another one is rails, another one's 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. I just know like, oh, this is who I go to for career advice, this is who I go to for React advice. And I think it's beneficial to have it that way because you're like networking and you keep connections with people that have older jobs. And you just ... Yeah. Yeah. No, I totally get that. I think having multiple ... It's like diversification, right? You shouldn't just do it with your stocks, do it with your mentors as well. No, thanks so much. Really, really appreciate having you here, Erin.