00:00:11
Hello everyone and welcome to "All Onboard: Cruising on the Mentorship."
00:00:17
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.
00:00:23
Yeah, I wouldn’t be offended if you walked out right now.
00:00:28
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.
00:00:36
We’re going to discuss an internship that we started at our company with high school students and some of the processes we used to help them onboard and feel at home at Vitals.
00:00:43
So, a little bit about me before we get started. Alright, technical problem solved.
00:00:51
Hi everyone, I’m Gretchen, and I’ll be your cruise director for this talk. I currently work primarily as a back-end engineer at Vitals, which is a health software company.
00:01:04
I’ve been there for about three years now. However, the path that led me to software development has been anything but straightforward.
00:01:12
In fact, I didn't even know that web development was a viable career option until about four years ago.
00:01:19
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.
00:01:25
Here’s some evidence of that; I promise I did actually accomplish things in the classroom.
00:01:32
Unfortunately, like many other teachers, I ended up burning out and turning to a completely different career.
00:01:37
It’s a career I love, but a different career nonetheless. However, I maintained my passion for education.
00:01:44
In the fall of 2016, I looked to volunteer my teaching skills and ended up working with a company called New York on Tech (NYOT),
00:01:51
which is a New York City-based outreach organization that provides technology education and mentorship to high school students.
00:02:00
They have several programs, including the one I worked with called the Tech Flex Leaders Program.
00:02:08
Over the course of the school year, about 45 students enrolled in the program dedicated their Saturdays to learning HTML, CSS, and vanilla JavaScript.
00:02:13
They toured tech companies across the city and met with mentors to write their resumes and build their public speaking skills.
00:02:18
I only taught about once a month—not a huge commitment, but definitely a fun and rewarding experience.
00:02:25
At the end of the year, they demoed their final projects, which were interactive websites tailored to the needs of a mock client.
00:02:32
It became clear just how impactful my small contribution had been over the course of the year, which was truly nice.
00:02:37
After the school year ended, the second phase of the Tech Flex Leaders Program initiative kicked in.
00:02:43
The students had the opportunity to interview at several partnering tech companies, and NYOT aimed to place as many students as possible in a six-week paid internship.
00:02:51
In February of 2017, the folks at NYOT approached me asking if Vitals would mind hosting two interns for the summer.
00:02:58
I said I didn’t know but let’s find out. Now, I’m not going to get into the months of prep work that our legal and HR teams did to make this possible.
00:03:06
Suffice it to say, it was a painful process for them, and I probably owe them several adult beverages.
00:03:13
But everything worked out in the end, and on July 10th, two fresh-faced interns joined Vitals for a whirlwind six weeks.
00:03:20
So here’s our cruise itinerary for the next 28 minutes.
00:03:26
First, we’re going to have a quick chat about why we should formalize mentorship onboarding.
00:03:34
Then, we’ll go through some basic tenets in approaching the building of a program.
00:03:40
After that, we’ll dive into the interns’ experience at Vitals in particular.
00:03:47
I want to discuss the idea of project-based mentorship featuring a framework called Understanding by Design (UBD).
00:03:56
Finally, we’ll talk about how we onboarded our interns to culture and domain knowledge while also helping them level up their coding skills.
00:04:03
Last but not least, we'll have a champagne toast—just kidding.
00:04:09
Let’s take a quick poll. Please contribute by raising your hand if you think mentorship is a good thing.
00:04:16
Wow, 100 percent of the room. I was hoping that would be the case.
00:04:22
I mean, why would you be here otherwise?
00:04:27
Now raise your hand if you think it's important for workplaces to have established mentorship programs.
00:04:34
Okay, these results shouldn’t be terribly surprising.
00:04:39
And the good news is that most social scientists and HR teams will agree with you.
00:04:47
There is a wealth of resources that will outline how important mentorship is for the mentee, the mentor, and obviously for the company as a whole.
00:04:55
So, some highlights for the mentee: mentorship can bring about personal growth and make career paths clearer.
00:05:02
When a person develops solid relationships within an organization, they’re more likely to be an active part of that organization’s culture and want to grow with it.
00:05:09
For the mentor, those who mentor others within an organization tend to be more satisfied with their jobs and more committed to that organization.
00:05:16
Not to mention that placing someone in a mentorship role allows them to stretch their leadership skills.
00:05:22
This is important, especially in small organizations where leadership roles may not be readily available.
00:05:29
Lastly, companies that offer mentorship programs tend to have higher employee retention rates.
00:05:36
Providing a solid mentorship program implies investment in your employees, so it’s a win-win for everyone.
00:05:43
Finally, just out of curiosity, raise your hand if your current workplace offers mentorship opportunities.
00:05:52
Okay, fewer hands in the room, but not as few as I thought, which is a good sign.
00:05:57
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.
00:06:02
What’s the point of secretly mentoring someone? It seems a little manipulative.
00:06:08
Otherwise, he’s a great captain.
00:06:13
Now, some basic tenets before we dive into our internship story.
00:06:19
Number one: there is no one-size-fits-all way to onboard an employee, mentor someone, or run an internship program.
00:06:29
I’m just going to provide some basic strategies we implemented, and if you like them, feel free to use them.
00:06:36
But by all means, this is not the be-all and end-all of mentorship.
00:06:41
Number two: there is no hacky way to do this.
00:06:48
Good onboarding and mentorship take thought and time.
00:06:53
The worst way you can onboard someone is trying to develop a plan on their first day—don’t do that.
00:06:59
And last but not least, and this is probably the most important, be flexible.
00:07:05
Adjust the plan as you go, and don’t be afraid to scrap things that aren’t working.
00:07:12
If you have ideas on how you can enrich someone’s experience, incorporate those ideas into your day-to-day.
00:07:18
Now, let’s meet the interns. First up is Paul.
00:07:24
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.
00:07:30
This was one of the reasons we hired him over the other potential interns. Not to mention, he has a great attitude and positive energy.
00:07:36
He’s just an all-around great kid.
00:07:43
Our second intern is Serena. She’s currently a senior at a public school in Queens.
00:07:50
Unlike Paul, she didn’t have any tech experience prior to joining NYOT, but what we really liked about Serena was her background in journalism.
00:07:56
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.
00:08:02
We thought these two would work really well together, and that's why we ultimately went with Paul and Serena.
00:08:10
So now we have our interns. Let the internship begin.
00:08:16
Fun fact: this is one of only three pictures taken during the entire duration of the internship.
00:08:22
You’ll see the other two later on. If you do this kind of thing, I recommend documenting your process.
00:08:27
So, project-based mentorship is the biggest takeaway I hope you get from this talk.
00:08:34
Project-based mentorship is precisely what it sounds like; you assign a mentee a project with a clear end goal and a defined deadline.
00:08:42
Then, mentor them through that project. After the project is complete, you should have some formalized assessment process for the interns.
00:08:48
We already had our deadline set; they were going to be with us for six weeks.
00:08:55
We wanted them to be able to demo their progress to the team at the sprint review on the Friday before their last week.
00:09:01
That left only five weeks to complete it, which is not a lot of time, especially because they were only working four days a week.
00:09:09
We knew we were going to supplement their experience with workshops and coding exercises.
00:09:15
In other words, this wasn’t the only thing they would be working on during their time with us.
00:09:21
So, given that limitation, we chose what we thought would be a relatively straightforward project.
00:09:29
Like many tech companies, we use HipChat, not Slack, and we’ve integrated a bot that we lovingly named Dradis.
00:09:37
We’re admittedly a bunch of nerds who were at one point really into Battlestar Galactica.
00:09:44
We use this bot for various things like deploying code, checking and updating client environment conditions, and playing a hacky version of Dungeon Master.
00:09:52
We also use it to turn feature flags on and off for our various client environments.
00:09:59
So, the project we assigned to the interns was to write a script for Dradis that would show where a certain feature was enabled across client environments.
00:10:06
We already had a few API endpoints to call for this information and some scripts in the bot code that they could leverage.
00:10:12
Our dynamic duo simply needed to pull it all together and create a neat little script.
00:10:19
This was obviously easier said than done, considering Paul and Serena had no Vitals domain knowledge.
00:10:27
The concepts of feature flags, our client naming process, and our environment organization were completely foreign to them.
00:10:34
Their coding skills were also pretty limited at this point—they had only one year of basic HTML, CSS, and JavaScript under their belts.
00:10:41
The bot code, fun times, is written in CoffeeScript, which is similar but not identical to what they had learned.
00:10:48
Additionally, they didn’t know what APIs were or how to make requests, and they had accounts on GitHub, but had never cloned a repo, pushed code, or made a pull request.
00:10:55
They also had never used HipChat, so there were many barriers to progress right from the get-go.
00:11:01
This is where UBD and backwards planning come in.
00:11:10
One of the frameworks that was all the rage when I was a teacher back in 2008 was UBD—Understanding by Design.
00:11:17
There are seven key tenets of UBD, but I'm not going to get into them today.
00:11:24
Most of them align with my personal opinions about education and curriculum design.
00:11:30
It's about thinking purposefully when planning a curriculum.
00:11:38
Most teachers wouldn’t walk into a classroom without a well-crafted plan, and we should approach mentorship the same way.
00:11:44
Have a clear plan of attack well before someone shows up on your doorstep.
00:11:51
UBD also focuses on students gaining understanding through authentic performance.
00:11:58
If you think of traditional learning experiences, you might picture a lecture hall where someone talks for 45 minutes.
00:12:05
But research shows this is rarely the most effective model for learning. The more engaged a student is, the more understanding they will gain.
00:12:14
So that brings me to the next tenet of UBD: teachers should act as facilitators or coaches, not just transmitters of knowledge.
00:12:21
Mentorship should work the same way. Instead of giving a mentee all the answers up front, the focus should be on coaching mentees through problems.
00:12:29
In this way, learners develop understanding and should be able to demonstrate that understanding.
00:12:36
Assessing their own path to that understanding is also important.
00:12:43
These are all useful ideas to keep in mind, but when it came to my teaching practices and developing a plan for our interns, I was really only interested in the tenet concerning backwards planning.
00:12:52
Backwards planning sounds exactly like what it is; you plan a curriculum backwards using a step-by-step design process.
00:12:59
You can use backwards planning for almost anything, like planning a vacation or a talk at RailsConf, for example.
00:13:07
So, how do you go about planning something backwards?
00:13:14
Step one: identify the end goal. If you're planning backwards, the first and most important thing is to know where you want to end up.
00:13:20
This end goal should be concrete, measurable, and have a clear output.
00:13:27
In other words, it should be easy to tell if the goal has been successfully completed.
00:13:34
I recommend putting together a list of criteria that satisfies the goal.
00:13:41
For our interns, the end goal was the completion of their HipChat bot script.
00:13:47
We laid out that criteria for them at the get-go: I should be able to type "dradis, where is such-and-such feature active" and have Dradis return an alphabetized list of client environments where that feature is active.
00:13:54
It's easy to measure completion. If I type that phrase and nothing happens or I get gibberish back, the project is not complete.
00:14:01
On the other hand, if I type that phrase and get my desired list of client environments and can verify its correctness, then it is complete.
00:14:10
At this point in the process, you should also identify the timeline you have to work with.
00:14:18
As I mentioned, we had about five weeks for our interns to complete the project.
00:14:24
However, that wasn’t exactly accurate; they were only in the office Monday through Thursday.
00:14:30
So, I tried to budget two to three hours a day for them to work on the project while being mindful of other commitments.
00:14:36
Once you’ve identified the end goal, break down that goal and identify specific tasks the person will have to complete to produce the output.
00:14:43
Better yet, if the person you’re working with has a good amount of context and a clear idea of what that project should be, have them help you with this or do it entirely by themselves.
00:14:50
Unfortunately, we couldn’t really do this with our interns due to the time crunch and their lack of context.
00:14:58
To break down the HipChat bot task, I thought about how I would approach the problem and wrote down the steps that the interns needed to take to solve it.
00:15:06
Some tasks involved in completing their project included identifying where in the code the script would go.
00:15:13
They also needed to save the file accordingly, use regex to help the bot understand the command, and alphabetize the list of client environments.
00:15:21
Additionally, they needed to handle errors when API endpoints returned incomplete data.
00:15:29
I can assure you there were many more tasks involved, and it’s important to remember: in approaching the breakdown of a goal, no chunk is too small.
00:15:36
In fact, the smaller the task, the better; it makes it easier to digest.
00:15:43
Once you’ve defined all your chunks, you can organize them based on the order in which they should be completed.
00:15:50
Boom, project chunked and ready to go.
00:15:57
Sometimes, though, just chunking the main project isn’t enough.
00:16:04
It’s also helpful to break down the skills necessary to complete the tasks.
00:16:11
For each task, identify what the person should be able to do by the end of that task.
00:16:17
Skills and tasks are different; a task is the output you want produced, while a skill is a broader ability needed to complete the task.
00:16:25
To outline skills, I generally start with the phrase, "interns will be able to...." So, some of the skills we defined for our interns included:
00:16:35
"Interns will be able to push code to GitHub and make pull requests;" "Interns will be able to run applications locally using Vagrant;" and "interns will be able to write scripts using CoffeeScript."
00:16:42
There were quite a few more, but you get the idea. These skills are much broader in scope.
00:16:49
Next is scaffolding. This is a term you hear frequently in education.
00:16:56
If you happen to find yourself around a group of teachers, feel free to mention it; it means to build understanding toward a goal in a meaningful order.
00:17:03
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.
00:17:10
You start with basic concepts and gradually add complexity.
00:17:17
For learning programming concepts, I recommend creating small, related projects that introduce concepts and help build the skills you defined earlier.
00:17:23
For example, to ease the interns into their project, I gave Paul and Serena a presentation about HipChat bots.
00:17:30
This presentation answered questions like: What are chatbots? How do they work? What sorts of commands can you run on our bots?
00:17:36
I also told them why we named our bot Dradis—we’re a bunch of nerds.
00:17:43
Once they had some initial context, I offered them a quick challenge: write a script that returns words of affirmation when someone types "greatest compliment me."
00:17:49
This was an easy challenge because it didn’t require user arguments or an API call, and Paul and Serena knocked it out in about an afternoon.
00:17:58
It was an easy win for them and helped provide building blocks for their final project.
00:18:05
I then gave them a slightly more complicated challenge: when someone types "greatest give me [blank]," the bot makes a request to the Giphy API.
00:18:12
It would take the term the user input and return a single GIF.
00:18:18
This task built on what they learned in the previous challenge by adding user input and API calls.
00:18:24
Naturally, this second project took a few days instead of the initial few hours, but once they finished, their skills and context grew.
00:18:31
It’s important to note that although I specified the desired output upfront, we didn’t work toward that output initially.
00:18:37
We built it out in pieces that reflected the tasks I had originally defined.
00:18:43
We ended up building it from the inside out, stubbing client names or features as necessary.
00:18:50
This should feel familiar because this is how people typically approach coding—chunking it into manageable parts.
00:18:56
Step five is formal assessment. I’ve mentioned several times that Paul and Serena are in high school.
00:19:02
The mention of assessment kind of struck fear into their hearts.
00:19:09
It's been a long time since many of you have been in school, but think back to the anxious anticipation before getting an important exam back.
00:19:16
I’m sure you can empathize with what Paul and Serena felt.
00:19:22
But I believe honest, authentic feedback is important for learning.
00:19:29
So, we did a formalized but informal assessment process.
00:19:37
Every Friday, Paul and Serena, as individuals, answered some questions on a shared Google document.
00:19:44
They provided feedback about how they thought they were doing that week.
00:19:50
Those questions included: What’s one specific thing I learned last week that I’ll take into this week?
00:19:56
How do I rate last week overall, on a scale from one to ten, and why?
00:20:03
Lastly, what am I going to do this week to make it better than last week?
00:20:10
After they answered those questions, they had the weekend to process their reflections.
00:20:16
On Monday, they met with me individually for 10 to 15 minutes to discuss their answers.
00:20:23
I generally let them do the talking, but I would occasionally offer my own feedback.
00:20:30
Every week, they added to the same Google Doc, allowing them to visualize their progress.
00:20:37
This is the whole point of assessment, right? It’s not to assign a grade.
00:20:43
It's to help someone identify their weaknesses and work to improve them.
00:20:50
We wanted Paul and Serena to have a full experience during their internship.
00:20:55
We aimed to ramp up their programming skills, familiarize them with parts of the Vitals domain, and help them meet important team members.
00:21:02
In other words, like any new hire, they needed access to both our technical and team culture.
00:21:08
One of the best ways we introduced Paul and Serena to people in the company, the Vitals codebase, and other tech career paths was through walkthroughs.
00:21:16
The walkthroughs we conducted had two different flavors.
00:21:23
The first flavor is a code walkthrough, which is great for onboarding new team members, regardless of their skill level.
00:21:30
When planning code walkthroughs, identify the key parts of your application needed for a new team member.
00:21:36
Then, identify existing team members willing to present on those key parts and schedule times for them to meet with the new hires.
00:21:43
Ideally, these presentations end with some DIY section, allowing listeners to cement what they learned.
00:21:50
For instance, one of our UI developers, Christian, led Paul and Serena through a JavaScript testing workshop.
00:21:57
At the end, they wrote some tests and felt pretty good about it.
00:22:03
The second flavor of walkthroughs is a career walkthrough.
00:22:09
For these, we highlighted different departments within the company, such as DevOps, UX, and product.
00:22:15
Our interns shadowed team members for a few hours to get a taste of what a career in this field might look like.
00:22:22
You might remember I mentioned we only have two pictures from the internship; well, they were taken during our intern shadowing.
00:22:28
Alana, our UX expert, hosted them; this is where they asked questions about a mobile mock platform they were building.
00:22:35
These types of walkthroughs build camaraderie and create low-pressure mentorship opportunities for team members.
00:22:41
As teenagers, Paul and Serena didn’t always feel comfortable in a company full of adults, which can be true for new employees as well.
00:22:49
One effective way to bridge that gap is through regular check-ins or chats with different team members.
00:22:56
Each morning, we scheduled Paul and Serena to meet with a different teammate for 10 to 15 minutes.
00:23:03
We had our teammates on rotation, so they only checked in with interns once or twice a week.
00:23:10
This was an easy way to provide low-key mentorship opportunities.
00:23:17
The interns found it useful to determine how they wanted to use that 15 minutes.
00:23:23
Sometimes they asked for help with coding problems, effectively turning those check-ins into mini pairing sessions.
00:23:30
Other times, they simply used the time to chat and get to know each other.
00:23:36
You’d be surprised at how trust can build from just a few 15-minute conversations.
00:23:42
While Paul and Serena may not have felt entirely comfortable by the end of the six weeks, I think they definitely relaxed a bit.
00:23:50
Setting aside time for new hires to pair or mob with teammates is crucial for developing team culture.
00:23:56
We didn’t schedule specific times for our interns to do this, but they paired together mostly.
00:24:03
We do, however, schedule this for new hires.
00:24:10
Alina, who joined Vitals in January, is a fantastic programmer.
00:24:18
Within her first few weeks, she was driving mob sessions with three or four others working on our Angular front-end.
00:24:26
This helped her onboard quickly, both in terms of learning the app and getting to know her teammates.
00:24:34
The final component of the internship was finding ways to level up our interns' coding skills.
00:24:40
Initially, I thought it would be great to use Exercism, which is a platform for testing coding knowledge.
00:24:48
Unfortunately, we quickly found it was a bit too advanced for our interns, considering their limited JavaScript knowledge.
00:24:55
This is a great example of flexibility. Once we realized Exercism was above their skill level, we scrapped it entirely.
00:25:03
I created some smaller coding challenges I had used in previous classes to help them build confidence with the basics.
00:25:10
These included tasks like iterating through arrays, manipulating objects, and making API calls.
00:25:17
I tailored these challenges to little skills they would need later in their bigger project.
00:25:24
I put these challenges in a public repo and had Paul and Serena create their own branches and make pull requests against those branches.
00:25:31
That way, they also got practice using GitHub and could track their progress.
00:25:37
Now, the daily breakdown: this is super important for people who are new to the workforce, including interns and apprentices.
00:25:44
Make a schedule, and give them that schedule at the beginning of the week.
00:25:51
How many times have you started a new job and felt unsure about your schedule?
00:25:58
As new employees, they need to know where they are going and who they are reporting to.
00:26:04
Having a physical schedule helped significantly.
00:26:11
So, how did the project go? I thought about demoing this on Dradis today.
00:26:17
But I realized I can’t keep HipChat open while I’m talking, since people would ping me about things like lunch.
00:26:24
So, I took some screenshots this morning. Here’s their project: as you can see, "Dradis, where is COST active?".
00:26:31
This functionality allowed the original GZ to search for where the feature COST is active.
00:26:39
Initially, it outputs a bunch of errors—that's exciting!
00:26:45
They did implement some error handling, which was added in at the end.
00:26:53
Basically, for every client environment that isn't active, an error will be thrown.
00:27:01
You’ll need to wade through a lot of that first, but eventually, we see that COST is active in these environments.
00:27:07
We could determine which environments had this feature enabled.
00:27:14
The interns made it happen and yes, it was down to the wire.
00:27:20
On the last day, they pushed the final code to the repo just minutes before their deadline.
00:27:26
So what did Paul and Serena think about their experience?
00:27:32
Paul mentioned that what he enjoyed the most were the workshops and interactions with coworkers.
00:27:38
Not to mention, there was a kitchen where he could grab snacks—so he didn’t have to bring lunch every day.
00:27:44
That’s fair enough! I heard from Paul recently; he’ll attend the University of Buffalo next year.
00:27:51
He’ll be majoring in computer science.
00:27:58
Serena stated that the internship showed her that working as a team and seeking guidance from team members gets the job done.
00:28:04
She also asked about working with us again this summer, which is great.
00:28:11
She plans to study computer science too, but hasn’t yet decided if she wants to stay in the city or go out of state.
00:28:17
She has been accepted into several universities and again plans on studying computer science.
00:28:24
The ultimate vote of confidence is that Vitals is allowing us to host interns again this year.
00:28:31
Overall, I’d say our first round was a success.
00:28:37
Before we go, I want to mention that if you are in the New York City area, please reach out.
00:28:43
I have a bunch of swag, including stickers and flyers. If you are interested in hosting an intern or becoming a teacher for NYOT, we’d love volunteers.
00:28:50
If you want to be a sponsoring company, that would also be fantastic.
00:28:57
Please come up and grab some swag.
00:29:04
Lastly, I must thank Vitals because without them, this crazy experiment wouldn’t have happened at all.
00:29:10
So thank you, and I promise—champagne toast!
