It’s not business, it’s personal

This is the second post in a series of posts about my involvement in the developer onboarding program where I work. The first post can be found here.

In this post I’ll focus on a different aspect of our onboarding program: Mentors.

This post will focus on three aspects:

• Picking mentors for our program
• Coaching mentors and setting expectations
• Data collection

How we chose mentors

Following Kate Heddleston’s advice (@heddle317), we opted for choosing mentors who joined the company up to a year ago based on the assumption that they’d remember what it’s like to be new, it would increase the likelihood that they would recall bootstrapping issues they had with our framework and any ‘Aha!’ moments they experienced in their onboarding process. Having those memories fresh, we hoped would result in them being humble, nice and helpful.

Sadly, we didn’t could not attain enough people who matched that exact profile for our program, so our second profile of choice was an empathetic, nice senior developer (or team lead) equipped with good social skills. Someone we loved interacting with on a daily basis and we thought could have the bandwidth to deal and care.

Assigning mentors to mentees

We started out without assignments, as we wanted collect some data before making a decision.

Our mentors met the entire group at a kickoff meeting where we had one of those awkward “Hi, I’m Karen and … Kangaroo” type rotations. We had everyone talk about their expectations of the program, what they hope to learn and achieve.

During the first month of the course when basic content was studied (such as Scala, TDD, and Maven) we had the mentors come in once a week and answer questions, not yet assigned to specific members of the group. When there were no questions we encouraged them to socialize and get to know their new colleagues. Following every mentor session, we collected feedback focusing on the mentor’s impressions of the group as a whole and its members, and common areas of struggle (Does everyone (or a couple of members) have trouble understanding a certain concept? If so, we can have someone come in to hash it out).

Following basic content, the group was split up into pairs for a three week long project. That’s was when we paired mentees and mentors. We asked one question:

“How can we make this person better and more powerful than they already are?”

We tried to address their strengths and weaknesses, and pair them with a mentor that could help bring out the best in them and help push it forward (as opposed to challenge them). Members of the group who were soft spoken and didn’t communicate much were assigned to the most communicative mentor we had (to get them talking). A member who was continuously praised by the group was assigned to a mentor who did not dispense praise easily, but instead provided feedback and further learning opportunities. Members who we thought would make larger leaps as a result of positive feedback were assigned to mentors who gave more of it.

Coaching mentors and setting expectations

Giving the mentorship a construct and providing guidance as to what is expected is crucial, if only to make sure that everyone is on the same page and that things get done. Things we discussed with our mentors:

• How to give valuable feedback (tell me what to do, not what not to do)
• In some cases, ‘Google it’ is a better answer than serving the solution on a silver plater
• The data we’re looking to collect, what we want to hear back from them
• How much time of theirs we plan to take up (and that even if they care, they shouldn’t spend all their time with the group as they are needed for their team’s tasks).
• The atmosphere and learning environment we’re looking to create in the program. We opted for an ‘ask all your silly questions here and now’ environment. When people asked us questions privately (so as not to be embarrassed) we commended them for asking, then wrote out an email to the entire group with the answer, explaining why that question was definitely not a silly one, and that they should ask more ‘silly questions’. Other times we got the entire group’s attention to do that in person.
• Keeping in line with the learning environment we wanted to create (more on that later), the group was told several times (and in several mediums) that quality trumps quantity. The project is a throw-away project, features of the project are there so they could learn from them. There is no deadline, the project and its features are meaningless.
• Mentor sessions format

Mentor sessions

As mentors have other work to tend to, we wanted to take up no more than 1–2 hours of their time per week. We stressed not to go over that amount so as not to have this come up as an issue for the following cycles of the program. Mentor sessions had the following format:

1. 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 to difficult issues that arose (such as good questions or topics that were discussed, but not necessarily understood by everyone).
2. A 1-on-1 with the mentee, in a private setting. This is to get their mentees talking and asking questions they wouldn’t ask in a group setting.
3. Code review, held in the shared workspace, preferably with the mentee’s teammate listening. An important note is that most of the work was done in pair programming (otherwise we probably would not have encouraged this). We also encouraged open discussions (between different mentors, between us, between anyone who came into the workspace) so mentees would hear several opinions and options to solving a problem (In the course retrospective, this was called out a couple of times to have been a success). Another important thing to note is that format worked because of the atmosphere we created. As our mantra was “quality (and learning) over quantity”, members did not compete against each other, but rather helped and taught one another (This was also pointed as a successful aspect of the program in our retrospective).
4. Lastly, a 10 minute summary, with one us running the course, to collect data. Now that mentors have been assigned their mentees, we started building profiles on group members: What they’re good at, what they need to improve upon, red flags which may have been spotted, characteristics, narrow vs broad focus. Don’t feel bad about doing this, it’s necessary for assigning group members to existing teams once the program is over.

Summary

This week was the members first week out of the program, having joined their new teams, spread throughout the company. Seems as though we prepared them well for their respective roles, though time will tell how much value this program really provided. We got positive feedback about the format of the mentor sessions, proving this formula works (that being said, we haven't tried other formulas, which may also work!).

It seems as though we (mostly) made good decisions and created a great learning environment.