It’s not business, it’s personal
This is the second post in a series about my involvement in the developer onboarding program where I work. The first one can be found here.
This post will focus on three aspects:
- Picking mentors for our program
- Coaching mentors and setting expectations
- Data collection
How we choose mentors
Following Kate Heddleston’s advice, we select mentors who have been at the company for roughly a year, based on the assumption that they remember what it’s like to be new. This increases the likelihood that they can easily recall any bootstrapping issues or ‘Aha!’ moments they experienced during their onboarding process. Having those memories fresh, we hope would result in them being humble, nice and helpful.
If that profile cannot be found we then search for an empathetic and kind senior developer or team lead who is equipped with good social and communication skills. Someone we love interacting with on a regular basis and has the bandwidth to dedicate him/herself to the program.
Bonus: Mentorship is an excellent platform for employees to test the waters of leadership roles. It also pushes forward employees who have not had the chance to shine within their current teams.
Coaching mentors and setting expectations
All of our mentors go through a week-long mentorship workshop that helps them define their roles, prepare for code reviews and pair programming, develop developers, and most importantly, soft skills.
Examples of things we discuss during this workshop include:
- Providing feedback: How, when and prerequisites
- Collecting data about the students and the program, as it progresses
- Defining their time commitment
- Showing rather than telling (through code reviews and pair programming)
- Creating a safe learning environment.
- Nurturing critical thinking.
Assigning mentors to mentees
At the start of the course pairings are made based on members’ CVs and mentors experience. Mentees coming in with more experience will get mentors that have more experience. One on ones start on the first week of the course.
Following basic content (Scala, TDD, ..), the group is split into pairs for a three week long project (nothing-to-production). By that time we will have collected enough data about our mentors and Kickstarters. At this milestone we may decide to make changes in the pairings.
We ask one question:
“How can we make this person better and more powerful than they already are?”
We address the Kickstarters’ strengths and weaknesses, and pair them with mentors that can help bring out the best in them and push them forward.
Experienced group members are paired with more experienced mentors. Members who receive praise often will be assigned to mentors who do not dispense praise as easily (but provide feedback and further learning opportunities). Members who we think would make larger leaps as a result of positive feedback will be assigned to mentors who give more of it.
Data collection (through mentoring sessions)
For us, mentors don’t just help their mentees, they also help us identify and fix issues with our program and environment.
Mentoring sessions are formatted in a way that help us collect data for both short-term and long-term actions:
- Session prep with one of us. This is a quick 2–3 minute summary of what the group worked on since the mentor last visited, with special attention paid to difficult issues that arose during the program, such as good questions or topics that were discussed, but not necessarily understood by everyone. (Lately we’ve been doing this using a Slack channel)
- Private 1:1 with the mentees. This is to get their mentees talking and asking questions they wouldn’t ask in a group setting. We expect our mentors to have a 1:1 with their mentees for one hour every week.
- Code review, held in the shared workspace, preferably with the mentee’s teammate listening. An important note is that most of the work is done in pair programming. We encourage open discussions between mentors, course leads, and anyone who comes into our workspace so mentees hear several opinions and options to solving a problem.
- Lastly, a 5–10 minute checkout process with a course lead to collect feedback concerning issues that require our immediate action. (Lately we’ve been doing this using a Slack channel)
Karen Cohen heads the Wix Kickstart program for server developers.
Originally published at karenmeep.github.io on February 9, 2016.
Originally published at karenmeep.github.io on February 9, 2016.