 on the mentorship. For those of you that came here looking for more boat puns, I apologize. There are two in the title, and that's enough. You're not getting any more. I fully wouldn't be offended if you walked out right now. All right, so for the next 40 minutes or so, we're going to talk about mentorship processes and how you can use them in your own company. And we're going to talk about an internship that we started at our own company with high schoolers on some of the processes that we use to help them on board and kind of feel like they were at home at Vitals. So a little bit about me before we get started. All right, technical problem solved. Hi, everyone, I'm Gretchen. I'll be your cruise director for this talk. A little bit about me before we get started. So currently, I work primarily as a back-end engineer at Vitals, which is a health software company, contingents over here, Wave, hello, hi, thanks. And I've been there for about three years now. However, the path that led me to software development has been really anything but straightforward. In fact, I didn't even know that web development was a viable career option until about four years ago. For the better part of the decade prior to that discovery, I taught English theater and, strangely enough, epistemology at a New York City public high school. Here's some evidence of that. I promise I did actually accomplish things in the classroom. Unfortunately, like many other teachers, I ended up burning out and turning to a completely different career, a career which I love, but a different career nonetheless. But I did continue to be passionate about education. So in the fall of 2016, I was looking to volunteer my teaching skills, and I ended up working with a company called New York On-Tech, NYOT, which is a New York City-based outreach organization that provides technology education and mentorship to high school students in the city. And they have several different programs, including the one I worked with, called the Tech Flex Leaders Program, try and say that one five times fast. So over the course of the school year, the 45 or so students that are enrolled in the program dedicated their Saturdays to learning HTML, CSS, vanilla JavaScript, touring tech companies across the city, and meeting with mentors to write their resumes and build their public speaking skills. So I only taught about once a month, not a huge commitment, but definitely a fun and rewarding one. And at the end of the year, they demoed their final projects, which were interactive websites tailored to the needs of a mock client. And it became clear just how impactful my small contribution had been over the course of the year, which was really nice. So after the school year's over, the second phase of the Tech Flex Leaders Program initiative kicks in. So the students have the opportunity to interview at several partnering tech companies, and NYOT aims to place as many of the students as they can in a six-week paid internship with those companies. So in February of 2017, the folks at NYOT approached me asking if Vitals would in mind hosting two interns for the summer. And I said, I don't know, but let's find out. Now I'm not gonna get into the months of prep work that our legal NHR teams did in order to make it legally possible for two minors to work for a company that deals with protected health data. Suffice to say that it was a painful process for them, and I probably owe them several adult beverages. But everything worked out in the end. And on July 10th, two fresh-faced interns joined Vitals for a whirlwind six weeks. And that's how we get to where we are now. So here's our cruise itinerary for the next 28 minutes. First, we're gonna have just a quick chat. Why should we formalize mentorship onboarding at all? Then we'll go through some basic tenets in approaching building a program. And then we'll dive into the Vitals interns experience. In particular, I wanna talk about this idea of project-based mentorship, featuring a framework called Understanding by Design, or UBD. And then we're gonna talk about how we onboarded culture and domain knowledge for our interns and helped level up their coding skills. And then last but not least, we'll have a champagne toast. Just kidding. All right, so let's take a quick poll. Please contribute. Raise your hand if you think mentorship is a good thing. Wow, 100% of the room. I was hoping that would be the case. I mean, why would you be here otherwise? All right, now raise your hand if you think that it's important for workplaces to have established mentorship programs. Okay? These results shouldn't be terribly surprising to anyone and good news, most social scientists and HR teams will agree with you. There is no dearth of resources that will tell you how important mentorship is to a mentee, to a mentor, and obviously to a company as a whole. So some highlights. For the mentee, mentorship can bring about personal growth and make a career path clearer. And when a person develops solid relationships within an organization, they're more likely to be an active part of that organization's culture and wanna grow with that organization. For the mentor, well, generally people who mentor others within an organization tend to be more satisfied with their jobs and more committed to that organization. Not to mention placing someone in a mentorship role allows them to stretch their skills as a leader, which is important, especially in small organizations where leadership roles may not be readily available. And finally, companies that offer mentorship programs tend to have higher employee retention rates. Providing a solid mentorship program implies investment in your employees. So it's a win-win for everyone. Finally, just out of curiosity, raise your hand if your current workplace offers mentorship opportunities. Okay, so fewer hands in the room, but not as few as I thought, which is a good sign. And just for the record, as much as I love Captain Holt, I have some real issues with his idea of what good mentorship is. What's the point of secretly mentoring someone? It seems a little bit manipulative. Otherwise, he's a great captain. All right, some basic tenets before we dive into our internship story. Number one, there is no one-size-fits-all way to onboard an employee, mentor someone, or run an internship program. We're just gonna give some basic things that we did, and if you like them, use them. But by all means, it's not the be-all and end-all of mentorship. Number two, there is no hacky way to do this. Good onboarding and mentorship take thought and time. Worst way you can onboard someone, try to develop a plan on their first day. Don't do that. And last but not least, and this is probably the most important, is that be flexible, adjust the plan as you go. Don't be afraid to scrap things that aren't working. And if you have some ideas about how you can add to someone's experience, by all means, incorporate those ideas into your day-to-day. All right, so let's meet the interns. First up is Paul. Paul is currently a senior at a boys' school in the Bronx. He loves video games and has participated in several video game-related hackathons. That was one of the reasons that we hired him over other potential interns, not to mention he has a great attitude, a really positive energy, just an all-around great kid. And our second intern is Serena. She's currently a senior at a public school in Queens. Unlike Paul, she didn't have any tech experience prior to joining New York on tech, but what we really liked about Serena is that as a journalism student, her communication skills are top-notch. And she is a workhorse. We knew that if we gave her a task, she would get it done. And we thought these two would really work well together. So that's why we ultimately went with Paul and Serena. So we've got our interns, let the internship begin. Fun fact, this is one of only three pictures that were taken throughout the entire duration of the internship. You'll see the other two later on. If you do this kind of thing, I recommend documenting your process. All right, so project-based mentorship. And this is kind of like the biggest thing that I hope you take away from this talk. Project-based mentorship is what it sounds like. You're gonna assign a mentee a project with a clear-end goal and a defined deadline and then mentor them through that project. And then after the project is all said and done, you should have some formalized assessment process. For the interns, we already had our deadline set. They were gonna be with us for six weeks and we wanted them to be able to demo their progress to the team at the sprint review on the Friday before their last week. So only five weeks to do this. And that's really not a lot of time, especially since they were only working four days a week. And we knew we were gonna supplement their experience with workshops and coding exercises. So in other words, this wasn't the only thing that they were gonna be working on the entire time that they were there. All right, so given that limitation, we chose what we thought would be a relatively straightforward project. So like many tech companies, we use HipChat, not Slack. And we've integrated a bot that we've lovingly named Dratus. We're admittedly a bunch of nerds who at one point were really into Battlestar Galactica. But we use this bot to do various things, like deploy code. I ripped these by the way from our room this morning. Check and update client environment conditions. Play a hacky version of thy dungeon master and et cetera, et cetera. We also use it to turn feature flags on and off for our various client environments. So although we had a task to list all of the features for a given client environment, what we didn't have was a way to see where one feature was enabled over all the client environments. So that was the project that we gave the interns. Write a script for Dratus. Where is such and such feature active? That will return all of the client environments where that feature is active. So we already had a few API endpoints that we could call to get this information. And we already had a few scripts in the bot code that could be leveraged for this project. So our dynamic duo simply had to pull it all together into a neat little script. Which was obviously easier said than done because, don't forget, Paul and Serena had no vitals domain knowledge. So the idea of feature flags, our client naming process, our environment organization, just totally foreign to them. Their coding skills were pretty limited at this point as well. They had only had a year of basic HTML, CSS, and JavaScript. The bot code, fun times, is written in coffee script. Similar, but not. And they also didn't know what APIs were or how to make requests. They didn't really know what GitHub was. They had accounts, but they'd never cloned a repo, pushed code, or made a pull request. And they'd never used HipChat. So that's a lot of barriers to progress right from the get go. How do you even deal with that? So this is where UBD and backwards planning come in. One of the frameworks that was all the rage when I was a teacher back in 2008 was UBD. Understanding by design. There are seven key tenants of UBD. I'm not gonna get into them, but they are for the most part in line with my personal opinions about education and curriculum design. It's all about thinking purposefully about curriculum planning. That one seems like it should be pretty common sense. Most teachers wouldn't walk into a classroom without a well-crafted plan. And I'm of the opinion that we should approach mentorship the same way. Have a clear plan of attack well before somebody shows up on your doorstep. UBD also focuses on students getting understanding through authentic performance. So if you think of traditional learning experiences, you might picture something like this. Say a lecture hall, somebody talks for 45 minutes, the students take notes, yada, yada, yada. But research shows that this is rarely the most effective model for learning. The more engaged a student is, the more he or she will gain understanding. So that brings me to the next tenant of UBD. Teachers should act as facilitators or coaches as opposed to transmitters of knowledge. And mentorship should work the same way. Instead of giving a mentee all the answers up front, the focus should be on coaching mentees through something, asking questions, posing problems, et cetera. So in this way, learners truly begin to develop understanding. And they should be able to demonstrate that understanding by explaining, interpreting, and applying that knowledge and assessing their own path to understanding. So these are all useful ideas to keep in mind. But when it came to my own teaching practices and developing a plan for our interns, I was really only interested in the tenant concerning backwards planning. And that's also what it sounds like. You plan a curriculum backwards using a step-by-step design process. Fun fact, you can use backwards planning for almost anything, planning a vacation, I don't know, a talk at RailsConf, for example. Yeah, so how do you go and plan something backwards? All right, step one, identify the end goal. If you're planning something backwards, the first and most important thing you need to know is where you wanna end up. So this end goal should be concrete and measurable and have a clear output. In other words, it should be easy to tell if the goal has been successfully completed. I recommend putting together a list of criteria that satisfy the goal. Hey, Chris Traeger, his goal is to run to the moon. And although this, I guess, is measurable and has a clear output, side note, this goal should also be realistic. For our interns, the end goal was the completion of their hip-chat bot script. And we laid out that criteria for them in the get-go. I should be able to type, Dratus, where is such-and-such feature active and have Dratus return to me an alphabetized list of client environments where that feature is active. It's easy to measure completion. If I type in that phrase and nothing happens or I get some gibberish back, the project is not complete. The goal has not been satisfied. If I type in that phrase and get my desired list of client environments and I can verify that that's correct, well, then it is complete. At this point in the process, you should also identify the timeline you have to work with. Like I said, we knew we had approximately five weeks for our interns, but that wasn't exactly an accurate timeline. We only had them in the office Monday through Thursday from 10 to four. And like I said before, the internship is not solely focused on the completion of the project. So I tried to budget two to three hours a day. That's it for them to work on the project. And I began planning backwards to fit that allotted time. All right, so once you've identified the end goal, you wanna break down that goal and identify specific tasks the person will have to do in order to produce that output. Better yet, if the person you're working with has like kind of already a good amount of context and a clear idea of what that project should be, you can have them help you with this step or you can have them do it entirely by themselves. For us, we couldn't really do this with our interns because of the time crunch and they had so little context going into it, but for me to break down this hip-bot task kind of like that tech flex leaders program, blah, blah, blah. I thought about how I would personally approach the problem and then I wrote down the steps that the interns would have to take to solve it. Some of the tasks involved in the completion of their project were identify where in the code the script is gonna go and save the file accordingly, use regex to get the bot to understand the command where is such and such feature active, alphabetize the list of client environments before sending it back to the user, handle errors for API endpoints that return complete data, you get the picture. That's not all of the tasks that we had as a part of this particular goal. There were a lot more and I would say like in approaching the breakdown of a main goal, no chunk is too small. In fact, the smaller the better. It's easier for someone to digest that way. Once you've got all your chunks defined, you can organize them based on the order in which they should be completed. Boom, project chunked, ready to go. Sometimes though just chunking the main project isn't enough. It also can be helpful to break down the skills that are necessary to complete the tasks. So for each task, I think that it's helpful to identify what the person should be able to do by the end of the task. So skills and tasks are different. A task is the output you want produced, but a skill is the broad ability necessary to complete the task. So for me, in order to be clear about that, I generally outline skills by starting with the phrase so and so we'll be able to do fill in the blank. So as an example, some of the skills that we identified for our interns were, interns will be able to push code to GitHub and make pull requests. Interns will be able to run applications locally using Vagrant. Interns will be able to write scripts using CoffeeScript. There are quite a few more, but you get the idea. These skills are much broader in scope. Step four, scaffolding. Scaffolding is one of these terms that you hear a lot in education. So if you ever happen to be hanging around with a bunch of teachers and you wanna seem cool, feel free to just bust this one out. It basically means to build understanding toward a goal in a meaningful order. With scaffolding around a building, you start from the ground up and build pieces on top of each other and learning works the same way. You start with basic concepts and gradually add complexity. This can be accomplished in a variety of ways, but for learning programming concepts, I recommend creating small related projects that introduce concepts and help build the skills you defined earlier. So for example, in order to ease the interns into their project, I started by giving Paul and Serena a little presentation about hip chat bots that answered the following questions. What are chat box? How do they work? What sort of commands can you run on our bot? Why did we name our bot Dratus? I already told you the answer to that one. We're a bunch of nerds. So once I'd given them some initial context, I offered them a quick challenge. Write a script that when someone types Dratus compliment me, it will return some words of affirmation. So this was a nice challenge because it didn't require interpolating user arguments, nor did it require an API call. Paul and Serena knocked it out in about an afternoon, so it was an easy win for them and it gave them some building blocks for their final project. Here it is in action. You look nice in that shirt. But we didn't jump into the final project just yet. I gave them a second slightly more complicated challenge, a new script, when someone types Dratus giffy me blank, make a request to the giffy API for the term the user input and return a single gif. So this takes the concepts from the previous compliment me challenge and amplifies them a bit. This time they have to take the user input into account, they have to make an API call, they have to wade through the response to get the data they want. So naturally this second project took them a few days instead of a few hours, but again, once they'd finished it, they'd built up their skills and context a little bit more. Here's that guy. So it's important to note that although I let Paul and Serena know the desired output up front, we didn't work toward that output initially. I had them build it out in pieces that reflected the chunked up tasks I had initially defined. And we ended up building it kind of from the inside out, stopping some calls, hard-coding client names or features when that was necessary, just to work on one little piece at a time. So this shouldn't be unfamiliar to you at all because this is how people normally approach writing code. Sometimes you can't get it all done at once. You need to chunk it up, build it in a meaningful order. Scaffolding, see? You do it all the time without even really thinking about it. All right, step five, formal assessment once the project is over. Like I've mentioned several times Paul and Serena are in high school, so any mention of assessment kind of struck fear into their little hearts. And it's been a long time probably since some of you have been in school, but if you put yourself back in your teenage shoes for a moment and think about the nervous anticipation you felt before getting back an important exam or having to have a God forbid conference with your teacher about your performance for the marking period, I'm sure you can see where Paul and Serena were coming from. But I think honest, authentic feedback is important and I didn't wanna send our interns running. So we did formalized but informal assessment. So every Friday Paul and Serena as individuals answered some questions on a Google document that was shared with me about how they thought they were doing that week. So those questions included what's one specific thing I learned last week that I'll take into this week? How do I rate last week overall on a scale from one to 10 and why? What am I gonna do this week to make it better than last week? So once they'd answered those questions on Friday they get the weekend to process and on Monday they met with me for 10 to 15 minutes again as individuals to talk about their answers to these questions. I generally let them do the talking but I would occasionally offer up my own feedback and every week they added to the same Google doc so they could see the changes in their responses and measure their own progress during the course of the internship. And this is really the whole point of assessment, right? I mean it's not to assign a grade or a satisfactory unsatisfactory value it's so that someone can learn to identify their weaknesses and work to improve them or identify the challenges they have and make a plan to overcome them. All right so like I mentioned earlier we didn't want Paul and Serena to solely work on their project during their internship we wanted them to have a full experience we wanted them to ramp up their programming skills learn parts of the vitals domain meet important team members and learn about the organization as a whole in other words like any new hire they needed access to both our technical and team culture. So one of the best ways we found to introduce Paul and Serena to people within the company the vitals code base and other tech career paths was through walkthroughs. The walkthroughs we did with our interns had two different flavors the first flavor is a code walkthrough and these are great for onboarding new team members no matter the skill level of the person you've brought onto your team. When planning code walkthroughs you first wanna identify the key part or parts of your application that are necessary for a new team member to be familiar with. Then you can identify existing team members who are interested in presenting on those key parts and schedule times for them to meet with the new hire. Ideally these presentations will end with some sort of DIY section so that the person listening has the opportunity to cement what he or she has learned. So for an example, one of our U.I. devs Christian led Paul and Serena through a JavaScript testing workshop and at the end they wrote some tests and they were feeling pretty good about that. The second flavor of walkthrough is a career walkthrough. So for these we chose different departments within the company to highlight so DevOps, UX, product, et cetera. Tech related departments but our interns wouldn't necessarily do any work for them. And we picked a few people that Paul and Serena could just shadow for a few hours just to get a taste of what a career in this field might look like. So remember how I told you that we only had two other pictures of the internship? Well those came about during our interns shadowing our UX experienced person, Elana and here they are right now. Yeah, they walked around the office and asked some questions about some mobile mock platform they were building and then they like did some designy things. Great, thanks Elana. As an added bonus, both of these types of walkthroughs build camaraderie and give low pressure mentorship opportunities to people on your team and people across your company. So as teenagers Paul and Serena didn't always feel comfortable in a company full of adults and this can be true of new employees too. I mean not necessarily being frightened by adults but just that few awkward weeks when you don't really know everyone or know how you fit into a company just yet. So one of the ways we found that work to bridge that gap was to schedule regular check-ins slash chats with different team members. Every morning we scheduled Paul and Serena again as individuals to meet with a different teammate for 10 to 15 minutes and we put our teammates on rotation so they only checked in with our interns like once or twice a week. This was the easiest way to provide low key mentorship opportunities to everyone on the team and the interns found it useful too because they were able to determine how they wanted to use that 15 minutes. Sometimes they approached those check-ins with problems they were having with code, turning the check-ins into kind of like mini pairing mobbing sessions and other times they just used the time to chat and get to know each other. You'd be surprised at the kind of relationships and trusts that can build out of just two or three 15 minute chats. And I won't say that Paul and Serena felt like 100% comfortable by the end of the six weeks but I think they definitely loosened up a bit as the time went on. I'm sure you're gonna hear a lot about this in the coming days but setting aside times for new hires to pair a mob with their teammates on whatever the team is working on is crucial to developing team culture and disseminating knowledge about a platform. We actually didn't schedule times for our interns to do this. They were mostly pairing together but we definitely do do this, do do this with new hires. So Alina, hey Alina, who's in the audience right now, she joined Vitals in January and if she doesn't mind my saying so which she really doesn't have a choice because I've got the microphone, she's a beast, a really fantastic programmer and within her first couple of weeks she was driving in mob sessions with three or four other people on our angular front end and she is a Rails developer so this may have been a little bit stressful for her at the time and she can confirm or deny this, you could talk to her later but it definitely onboarded her quickly both in terms of learning the app and getting to know her teammates, right Alina? Great. All right, the final component of the internship was finding ways to level up our interns coding skills. I thought initially it would be a great idea to use Exorcism and if you haven't joined yet, you should, it's a great place to test your knowledge of coding languages and problem solving skills and it's got a great community for reviewing code and getting feedback on your practices so I'd highly recommend it if you're looking for established ways to challenge mentees. Unfortunately, and we found out this pretty quickly, it was a little too advanced of a platform for our interns since their understanding of JavaScript at the time was so limited and this actually is a great example of flexibility because once we realized that Exorcism was above their skill level we scrapped it entirely and I threw together some smaller coding challenges that I had used in previous classes to help them build their confidence with just the basics. Iteration through arrays, manipulating objects, making API calls, et cetera. I tried to tailor them to littleer skills that would happen later on in that bigger project that they were doing. Then I put those challenges in a public repo, had Paul and Serena create their own branches and make PRs against those branches so that way they also got much needed practice using GitHub and they were able to track their own progress. All right, the daily breakdown, last but not least, I think this is super important for if you've got people who are newer to the workforce or if you have an internship or apprentice program it really, really helps to make a schedule, put everything in a schedule, give them the schedule at the beginning of the week. Why? How many times have you started a new job and you're like, I don't really know what I'm supposed to be doing right now? And that might be a little bit better if you're a seasoned member of the workforce, but as kids, they needed to know from hour to hour where they were gonna be, who they were reporting to, who they were meeting with. It really did help to put an actual physical schedule together for them. All right, so was it successful? All right, how did the project go? I thought about demoing this, Andrea, yesterday but then I was like, I can't keep hip-chat open while I'm talking because people will ping me about stupid things, like what they had for lunch, not happening. So I took some screenshots this morning. So here's their project. Dratusware is cost-active, cost is one of our feature flags. Affirmative, the original GZ is searching for where cost is active. First it outputs a bunch of errors. That's exciting. They did do some error handling. We kind of threw this into the very end, but it's basically every client environment that's not active at the point is gonna throw an error. So you gotta wade through a lot of that first, but eventually we get this. Cost is active in these environments, the original GZ, and then a bunch of things. This is not the full list. It's pretty much active in all of our active environments. So yeah, I would say they made it work. Was it down to the wire? It absolutely was. They was there last day and they pushed some code, some final code to the repo at like 503. I was like, we did it. Blah, blah, blah, blah. All right, so what did Paul and Serena think about their experience that should define some measure of success? Paul said, what I enjoyed the most out of this internship were the workshops and being able to interact with my coworkers. Not to mention, there was a kitchen where I could get whatever snack I wanted, so I didn't have to bring lunch all the time. All right, that's fair enough. So I heard from Paul recently, he's gonna be attending the University of Buffalo next year and he's gonna be studying computer science. Serena said, working as a summer intern at Vital showed me firsthand that working as a team and turning to your team members for guidance and support gets the job done. She also inquired about working with us again this summer, which I thought was like, kind of, all right, she liked it enough that she wants to come back. She also plans to study computer science, but she hasn't made her decision yet because she doesn't know if she wants to stay in the city or go out of state. But she's been accepted to a bunch of universities and again, she plans on studying computer science. So I think the ultimate vote of confidence though is that Vital's is letting us do it again this year. So yeah, I would say overall it's a success. All right, before we go, I wanna say, if you are in the New York City area, please reach out, I've got a bunch of swag and stuff up here, stickers and flyers. If you're interested in hosting an intern, becoming a teacher for NYOT, we'd love volunteers. It'd be really great if you could do that. If you wanna be a sponsoring company that would also be fantastic, please come up and grab some of that swag. And last but not least, I have to thank Vital's because without them, this crazy experiment wouldn't have happened at all. So thank you guys. And I promised a champagne toast, so this is what you're gonna get. All right, thank you. Thank you.