Here’s a signature problem for any growing team: the need to deliver value is ever-increasing, while the shape and function of engineering teams can fluctuate wildly.
To navigate that tangle, many companies align employees as mentors and mentees.
But if your organization operates outside of the traditional top-down supervisor/subordinate model, the manager-as-mentor thing isn’t going to work.
We talked to Matt Leibel, the Senior Director of Engineering for Vistaprint Digital—the arm responsible for Vistaprint’s digital marketing for small businesses. Leibel works with a team of about 60 engineers that have been refining a new approach to mentorship.
This mentorship strategy didn’t come out of nowhere, though. What Leibel dealt with at Vistaprint will sound familiar to any scaling team. Here’s what they came up with…
How the Vistaprint model works
“By proxy, it’s changing the way we have to think about the dynamics of teams,” Leibel says. “The old model of top-down management doesn’t work well in an agile environment. So we challenged ourselves to ask how we could do mentorship differently.”
The old top-down structure relied on managers reviewing task progression and pushing for goal-oriented results from their engineers every week. Vistaprint Digital had the idea to spread leadership to all levels of the organization.
“We switched to a model where people are focused on mentoring and coaching individuals,” Leibel says. “That way, they can achieve what they want to achieve in their careers, while also guiding themselves to what’s important within the organization.”
This mentorship program is essentially built on one-to-one pairings. Leibel suggests that these pairings grow out of conversations between team members, based on how each person wants to grow and develop – not based on which team they’re on at the moment, or who their immediate manager is.
At first, the setup can be a little clunky, as people learn to feel comfortable with the organic process. But once they align mentors and mentees, and they work out what they can do for each other, they start to see the value.
An important thing to remember here is that the mentor/mentee relationship is not necessarily based on organizational hierarchy. Leibel says that the mentors tend to be a bit more senior than their mentees, but not across the board. The relationship here has much more to do with the engineers’ own personal growth goals.
How this model works for the organization’s deliverables
Here’s where you’re lucky. The software engineering industry already has frameworks in place, particularly in companies that are agile, that tell us how to get things done.
That doesn’t go away with the mentorship program. In fact, mentors can help improve the process of meeting deadlines and providing deliverables. Part of being an engineer is collaborating with your squad. If you’re not collaborating well, then meet with your mentor about that problem.
“Mentors are going to help you be better at that,” Leibel says. “That’s how we pair the mentorship program with the need for productivity. They balance each other out.”
In fact, this system offers advantages over traditional management. A lot of management folks tend not to be technical enough to offer beneficial coaching and mentoring to a software engineer. It’s a flawed assumption that non-technical people can provide substantial professional development guidance to a technical person.
“Basically, what I want are badass software engineers,” Leibel says. “How do you get them? You pair them with other badass software engineers.”
At Vistaprint, that philosophy is reaping rewards.
How this model shows results
The mentorship program at Vistaprint has struck a balance between skills-based development and career/personal growth mentorship.
“When we started, I was personally more interested in the skill path to make sure we were giving people that support,” Leibel says. “What I found is that giving the mentors a chance to become more involved leaders has strengthened their ability to develop as individuals. That goes beyond the skills it takes to be a badass software engineer, a badass collaborator, a badass teammate.”
Vistaprint’s program started off with eight mentors for 60 people. Over the last year and a half, that number has grown to 16 mentors and more employees continue to opt in: percentage-wise, Leibel estimates that 95% of his team is participating.
And that level of buy-in has reduced their dependency on HR, as well.
“It’s really hard for people to break the idea of how this system is related to how HR systems work,” Leibel says. “The old-school way is that HR says somebody’s my manager, so I have to follow this hierarchy. Breaking that mindset to emphasize personal growth and development is probably the most significant upfront challenge.”
But the results are undeniable. Leibel says his team doesn’t turn to HR as much because they are more comfortable figuring out issues for themselves. The mentorship program has empowered them to own what they want to do for themselves and be able to freely ask questions and get advice.
Tips for implementing our own mentorship program
1. Keep it voluntary.
“Both sides of the mentorship are optional,” Leibel says. “And the duration of the relationship is optional.”
He’s had several cases already where engineers change their mentors two or three times. Sometimes it’s because the relationship isn’t working out. More often, though, it’s because they realize the benefit of learning from multiple coaches. And sometimes the mentors are the ones instigating the change. “We’ve seen mentors go to the mentee and say, ‘I have nothing more to offer you,’” Leibel says.
And as for those people who opt not to participate in the program, Leibel’s attitude is to let them be – so long as they’re meeting their contribution levels, and the feedback from their teammates is in line with expectations.
It’s so easy to roll things out as mandatory initiatives, and that comes with its own sets of issues. By making the mentor/mentee relationship voluntary, you get stronger buy-in from your participants, which can only improve the efficacy of the program.
2. Negotiate with the other areas of the organization.
The mentorship program, on paper, will not reap immediate and quantifiable benefits. You’re likely to have product folks and business folks who don’t understand why you’re spending time on mentoring instead of engineering.
“We had to let the rest of the organization know that there might be a little bump in the workflow,” Leibel says, “but we expected it to normalize into the same amount of time that our engineers would be spending with managers anyway. Ultimately, we’re not using any more time, especially for the mentees.”
3. Keep the overhead low for your mentors.
The flip side is that your mentors will be going above and beyond for their own personal growth. Leibel definitely got questions from outside the engineering organization about why these engineers were spending so much time in one-on-one mentorship sessions.
That’s when he realized that his team needed to grow from its initial eight mentors. Now that they’ve spread out the mentorship duties and gotten more mentors up and running, the time-management issue has become far less of a concern.
4. Be okay with unquantifiable benefits.
“I wish I had a way to track the benefits of the program,” Leibel says. “But heuristically, I think this program is a net gain.”
Whether or not other divisions adopt your new approach to mentorship or simply accept it as engineering’s experiment, you will ultimately end up with connected and engaged engineers. And they in turn learn how to mentor the next wave of connected and engaged engineers.