Boost Engineering Team Success with Mentoring and a Growth Mindset

Looking back, I can say with certainty that my advancement as a technologist, professional, and human has hinged on fostering a growth mindset in myself and others.

Considering the growth of engineers—how we learn, advance, and struggle—has been a core feature of my career, but it took time to become a priority. I began self-taught, later earned a computer science degree, and spent a few years at a small dev shop where I was largely left to my own devices. I certainly improved as an engineer, but no one asked me to grow.

That changed when I joined a startup called Wealthfront. I was suddenly surrounded by brilliant minds moving very quickly. I found myself scrambling to keep up with my two mentors—both senior engineers who had come from high-impact teams at Google. It was a different world, where my daily challenges were difficult, uncomfortable, and exhilarating.

After a year, it was clear that whatever progress I had made as an engineer so far in my life was dwarfed by the growth I’d experienced in a mere 12 months under committed technical mentors. Someone had finally created space for me to grow, and I did.

As my career progressed at Wealthfront, I started mentoring others in turn, but I found myself wishing I could study mentorship full time. I eventually accepted a position as an instructor at Dev Bootcamp, where I spent four years helping beginners enter the programming field. Teaching in that environment was the most difficult, exhausting, and rewarding job I’ve ever had.

Mentorship culture

Now I’m at New Relic, partly because I see such a strong commitment to teaching and growth. Here I have been blessed with the mentorship of incredible engineers across two continents while also having the privilege to guide others as a mentor myself.

The culture of mentorship at New Relic is already strong, but I’ve been exploring how we can improve. I’ll share two critical lessons I’ve learned that I think may be useful to anyone doing onboarding or mentorship. I'll also share the tools inspired by these lessons that my team has implemented to foster growth.

Lesson one: Reassurance is not mentoring

I’ve worked with a lot of students and engineers over the years who felt like they weren’t doing enough: growing, becoming independent, learning deeply. Imposter syndrome is real, and so are the high standards we hold ourselves to.

Time and again, the tool I used to help them was reassurance. The individual was usually their own loudest critic, and I thought the solution was to remind them that they were doing great.

It took me a long time to realize that hidden in the statement “you’re doing great” is the viewpoint from which that statement is made. What I was really saying was, “You’re doing great, in the eyes of myself and your teammates.”

I provided this kind of reassurance with the best of intentions, but when someone expresses that they’re unhappy with their performance, your perception of them is of secondary importance. Responding immediately with “you’re doing great” doesn’t help the individual resolve feelings of wanting to do better; worse, it serves to silence them. In the end, kind words don’t help individuals gain agency and mastery over their growth process, nor do they relieve the anxiety of wanting to do better.

I’ve come to understand that the focus of a mentoring relationship must be on the feelings and perception of the mentee, not the mentor. Instead of telling someone they’re doing great, consider asking them why they feel they aren’t. Work with them to explore questions rooted in their experience, such as:

• What makes you feel unsatisfied with how you’re growing?
• What makes you feel like you’re doing well?
• Why do you want to grow, and what motivates that desire?
• What can we do to help you feel like you’re growing effectively?

As it turns out, these questions can be just as effective when mentoring someone who, in your eyes, isn’t doing well. If you see an opportunity for growth in your mentee, find a way for that opportunity to align with their own experience and motivations.

When it comes to guiding others, make sure your focus is grounded in their experience, not yours. You play a vital support role, but your mentee is the one walking the path.

As a mentee, don’t be afraid to ask for what you need. Your mentor is there to provide guidance and advice, but you must own the process. As the learner, it is ultimately up to you to pick which road you’ll walk together.

Lesson two: Growth means feeling uncomfortable, growth means feeling safe

At Dev Bootcamp, we spent a lot of time talking about the interplay between comfort and psychological safety in the learning process and how they combine to form the “growth edge.”

Fear of failure, a sense of isolation, or a lack of support can make it difficult for an individual to feel psychologically safe. On the other hand, the support of others, a sense of connection and camaraderie, and the freedom to make mistakes build a sense of safety.

On a different axis, we have comfort, which is not the same as safety. If we are to grow, we need to be outside our comfort zone. If we’re too comfortable in our tasks, it’s hard to learn new skills or deepen our understanding of a subject.

The "growth edge" is the mental space we occupy when we feel safe and uncomfortable during our work. That’s a hard thing to sustain long term, and we can’t expect to grow continuously, but when someone’s ready to take on a new challenge and improve, the “growth edge” is the goal. All of this is easy enough to say, but how we create that space is another question altogether.

In my observation, technical onboarding and mentoring use these approaches:

• Approach A: Pair, pair, pair! What better way to ensure someone feels safe and supported as they "drink from the firehose"? The intention is to be at a new learner’s side to answer questions and guide them every step of the way.
• Approach B: Tell the mentee to jump into the deep end! The new learner will feel uncomfortable as they navigate a brand new task, but that’s what it takes to grow. You can encourage them to ask the team questions, but trust that they’ll figure it out if you leave them to their own devices.

These approaches aren’t bad, but they can’t be the only two options. In Approach A we’ve likely created a strong sense of safety by being exceptionally connected, supportive, and engaged. On the other hand, it’s a very comfortable environment. It’s hard to struggle when a senior engineer is next to you, ready to offer an answer. Approach A provides a safe space to learn, but it can be too comfortable to grow.

In Approach B we’re trying to help someone get outside their comfort zone. We know discomfort is essential in the growth process, but even on the warmest and most encouraging teams, this approach can create a sense of abandonment. In discussions with Relics, past teammates, and former students, I’ve seen how often Approach B leads to feelings of isolation. Some of us thrive in the deep end, but others feel lost.

I’ve tried both approaches as a mentee, mentor, and teacher, and it took me a long time to understand that these two approaches by themselves are not ideal for most learners. Every individual is unique, and in practice we all need some blend of both.

If we accept that mentoring requires us to root ourselves in the learner’s experience, we must provide them with tools to take charge of their process. If we want that process to be effective, we need to acknowledge every engineer’s individuality and offer an approach that is flexible and adaptable, not a “one size fits all” solution.

On my team, we're fortunate to have more than one former teacher and engineers who have sought out educational opportunities throughout their careers. Our pedagogical experience put us in a strong position to explore structured and flexible ways of learning.

We treat approaches A and B as a spectrum, and we have tools that help control where a growth opportunity lands. We encourage people to communicate how they want to grow, and we consider ways to foster that growth instead of being prescriptive. I’d like to share more about our process and positive results.

Mentoring with scaffolds

In a sense, "pairing all day" and “diving in the deep end” are just two extreme approaches to controlling how independent a learner can feel in their process. Instead of picking one or the other, we try to find the right mix that produces a healthy tension between independence and support. We aim to provide a scaffold for a mentee’s onboarding or technical growth experience, creating the following characteristics:

• A sense of psychological safety
• Room for independent struggle and discomfort
• Structured opportunities for interaction between the mentee and mentor, such as pairing, discussion, or another form of interaction

The scaffold we build is usually around a JIRA ticket or some other work unit that represents a new challenge to the learner, and it looks like this:

• The mentor and mentee meet to discuss the problem. The goal is to make sure both individuals understand the problem. You should discuss different approaches and weigh the pros and cons.
• Together, you design a solution without implementing it. Diagrams, pseudocode, type contracts, or tests can be useful ways to sketch out a solution in a structured way that’s easy to refer back to later. The level of detail is up to the people working on the task and depends on the learner and the problem. Consider it one of the “dials” you can use to tune the experience together.
• Establish a check-in schedule for discussing progress, since the intention is for the mentee to work independently on the task. It could be four hours or 30 minutes, depending on the problem and the individuals involved.
• Now the mentee can take on the task alone with the freedom to struggle, ponder, curse, succeed, and shout with joy without feeling like you’re under the microscope. You can stretch to see how far you can get independently, but reach out with questions if you hit a wall.
• Check-in time. The mentor and mentee sit down to review code, discuss new challenges, and clarify concepts. As the mentor, you have a chance to course-correct if the mentee is going down a problematic path. As a mentee you have an opportunity to ask questions, share what you've learned, or show off a better solution you stumbled upon. Together, you can design the next phase of development and chart a course.
• After enough cycles, the task is complete. As a learner, you were able to experience taking ownership and engaging independently with a problem outside your comfort zone while still having enough structure in place to feel supported. As a mentor, you had time to address other tasks between check-ins, and played a critical role in the mentee’s growth as a coach and guide.

I’ve seen this approach work well. It's structured enough to guide but simple to adapt. Standardizing on this practice makes it easy to rotate mentors to avoid burnout. I encourage you to give it a try.

In quarantine and crisis it’s easy to feel isolated and distant, but there’s no better time to reach out and renew our commitment to learning alongside each other. We may be scattered, but we can still help each other grow. Read more about New Relic’s culture and why staying “Connected” is one of our core values.