GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

As an engineering manager, you’re concerned with your team delivering the best products they can, as efficiently as they can. That goal, of course, is easier to accomplish when your team is comprised of seasoned veterans.

But more likely, you’re fortunate to have team members who are early in their careers, or new to your organization, and the reality is that they require a different sort of leadership.

Greg Sabo, an engineering manager at Asana, knows what that sort of management looks like. His primary responsibility is mentoring new engineers to achieve success in their roles.

“Currently, I primarily manage engineers who are earlier in their careers — with maybe one or two years of professional experience,” he says.

Asana takes a unique approach to management — it embodies a structure similar to a matrix organization, and sometimes goes by the name “cross-functional management.” The engineers that Sabo manages are members of different teams, so he’s not responsible for assigning work or managing their projects. He is responsible for looking at their progress as a whole, and ensures that they are stable, engaged, and that they have clarity around what’s expected and how they can progress in their career.

In a word, he’s mentoring them.

“I have this unique perspective where I look at people’s progress as they’re growing individually, rather than specific projects that they’re working on,” he explains.

Sabo would love to have a rubric for how to mentor every new engineer. The reality is, though, that how to mentor someone depends on the project they’re working on, the team they’re working with, and the technologies that they need to work with for their growth to reach its potential. But what he can provide, in each individual circumstance across the board, is perspective both on the company and on constructing a rewarding career.

In this interview, Sabo shared his perspective on how to use mentorship to effectively incorporate new engineers into your organization (while providing clarity around what “mentorship” really is) — and offered action items to help individuals progress and ensure that you’re building a productive workplace.

The mentor-mentee relationship

Mentorship is one of those words that gets bandied about quite a bit, because it can mean quite different things to different people (for both the mentor and mentee) and in different contexts.

But for Sabo, it all boils down to building a relationship. “Great mentorship requires both parties to be fully present,” he says.

At Asana, each individual contributor has an established mentor. That mentor is on the same team as the engineer, usually not as the team lead (though occasionally so). And that person’s role is to be always available for the new engineer.

“Mentors can help mentees validate whether their assumptions are correct, and can help mentees leapfrog part of the learning process by explaining how they’ve tackled similar problems in the past.”

“Especially when you’re newer in your career or when you join a new company, you’re going to have a set of assumptions around how things should work, or how to act in various situations,” Sabo explains. “Mentors can help mentees validate whether their assumptions are correct, and can help mentees leapfrog part of the learning process by explaining how they’ve tackled similar problems in the past. In the workplace, mentor-mentee relationships can help a new hire ramp-up much more quickly.”

In this way, you can think of a mentor as a liaison between the new hire and the organization. Rather than translating the company culture by feel, new hires have someone whose role it is to show them the ropes and help them become a part of the team more quickly and smoothly.

The mentor/manager distinction at Asana

That role, Sabo stresses, is different than what a manager can offer. A manager’s purpose is to reconcile the needs of the individual with the needs of the company, communicate clearly what the company expects from the contributor, and provide feedback to make sure things are going in a good direction.

“There’s a different relationship with a mentor,” Sabo says. “It needs to be rooted in a foundation of psychological safety and trust, which can be difficult for managers to build as they’re also the person holding the hiring and firing power over that person.”

That’s why Asana establishes a mentor for each individual contributor, who has a distinct set of responsibilities from that of a manager. The roles are filled by two different people, which, in practice, is particularly useful for new hires who are getting a feel for their environment.

But Sabo recognizes that this structure doesn’t work for every organization. At the minimum, he recommends establishing a mentor for each new hire for a specific timeframe (perhaps the first 30 or 60 days). Even better, is if the established mentor is someone who is interested in moving into a people-leadership role.

“In an ideal world, each individual contributor has someone they consider as a mentor. Someone who they feel comfortable to bring any type of problem to,” Sabo explains. “As much as the manager can encourage that type of relationship, it’s much easier if the mentor is a different person. In most companies, people should find mentors outside their organization. At Asana, mentorship is deliberately baked into our culture.”

“It’s so powerful to have a mentor on your team, working with you, because then you can take that relationship and continue to have an impact going forward.”

Also, management is a much more formal day-to-day (and year-to-year) role than mentorship. Sabo doesn’t plan a formal end to a mentorship relationship, because after a period of time (often a few months), the mentorship needs of the new engineer start tapering off. Yet there’s still a strong relationship that the engineer can leverage on an ongoing basis.

“That’s another reason why it’s so powerful to have a mentor on your team, working with you, because then you can take that relationship and continue to have an impact going forward,” he says.

And as well as preserving their assigned mentor relationship, engineers are also free to branch out to other mentors to grow their network of people who they trust enough to ask for advice and perspective. That continued growth has its foundations in that first established mentorship relationship.

Why “asking for help” is required

Many first-time engineers are joining organizations straight out of a formal education. That shift, from school to a professional atmosphere, Sabo tells us, is tectonic.

“The undergrad educational environment is very individualistic,” he says. “You’re evaluated on an individual basis. You study on your own, or maybe with the help of a friend or two. But it’s all about how you can focus and work on your own independently — it’s not about collaboration, and working with a group to find and build the right solution together. In most CS programs, you can be very successful without really having to talk to your classmates.”

That culture, of course, is completely different than working in an organization. New engineers must rethink what “success” looks like — what a “good job” looks like. They haven’t been taught how to survive, let alone thrive, in this new environment.

“I have the expectation that your job is to ask for help—or at least to communicate clearly with everyone around you, every day, multiple times a day.”

So the value that Sabo emphasizes most with his reports when they join Asana is this: He expects them to ask for help.

“Every now and then people will hear that, and they think, ‘Oh, this is a tip; if I mess up and I don’t know what to do, I can bail myself out by asking for help,’” Sabo says. But that’s not what he means: “I have the expectation that your job is to ask for help,” he explains—“or at least to communicate clearly with everyone around you, every day, multiple times a day. And if you’re not asking for help, then something’s wrong, even if you’re pushing code. Your top priority is to ask for help.”

A curriculum for better communication

That last point bears repeating: Sabo’s top expectation of new engineers isn’t even to commit code. It’s to ask for help—for insights, opinions, perspectives—at every opportunity.

He sees in engineering that the “rugged individualist” mindset is the default. Plenty of commonly used phrases are subtly toxic, he says, such as calling outstanding contributors “10x engineers,” “rockstars,” and “superstars” — or even including those in job descriptions.

“Those are very individualistic terms,” he says, “and that’s not how work gets done. I would not want somebody who’s writing ten times the amount of code but not talking to anyone else on my team. They’re probably wreaking havoc on things.”

Sabo understands that it takes practice and skill to have a productive conversation, where knowledge truly gets shared and transferred. Engineers don’t learn those skills in college, so unless they picked them up somewhere else, they don’t have them. More troublesome is, they don’t realize they don’t have the skills.

“A lot of these communication skills develop naturally from practice and from stumbling your way through conversations.”

That’s why Sabo doesn’t expect them to have the skills right away. He prioritizes quantity of communication over quality, especially for people who are brand new to the team and the industry.

“It’s much easier to coach someone when they are choosing to communicate, rather than to pull someone out of their shell,” Sabo says. “Although I can speak to people about effective ways of communication, I won’t even bring it up if I don’t think they’re communicating and overcommunicating frequently. It creates a tension of trying to ‘ask the right way.’ A lot of these communication skills develop naturally from practice and from stumbling your way through conversations.”

In other words, by setting the expectation that engineers communicate with each other and share knowledge frequently and consistently, Sabo sets an informal curriculum. Just by doing, without worrying about how they’re doing, his mentees learn communication skills that will not only help the engineering team work more cohesively down the road, but will also help the engineers be more adaptable and flexible in their careers.

Build a foundation of psychological safety

Every angle of Sabo’s perspective on mentoring fresh engineers is rooted in an idea he mentioned earlier: psychological safety. A mentor can offer a sense of “unconditional” psychological safety in a way that others in the org structure cannot, purely due to the nature of the roles.

“Psychological safety is something that everyone should be working towards — managers and individual contributors alike,” Sabo explains. “Yet, in my experience, the mentor — or ‘onboarding buddy’ in some cases — is the first beachhead into true psychological safety on the team. Somebody who doesn’t have a clear, perceived power over that person is probably going to have the easiest time of achieving psychological safety. Others, have to work harder for it.”

That said, psychological safety doesn’t happen like magic just because of the dynamics of a working relationship. Establishing it is something Sabo advises mentors, particularly more junior mentors, to encourage.

Psychological safety is a complex topic, but it helps to think of it in broad strokes. Organizational behavioral scientist Amy Edmondson defines it in her TEDx Talk as “a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.” Engineers benefit from psychological safety when they feel like their job security, their inclusion in the team, and their role as an engineer are not threatened. These engineers feel free to take risks, and they feel free to fail — which is particularly essential to creative work. They feel capable of voicing their opinions, and debating or collaborating with others to find the right solution. And while there are obvious distinctions between work and personal life, they feel secure in being themselves at work.

One tactic Sabo has found that helps build psychological safety in the workplace and with new engineers is to model vulnerability.

“Vulnerability is not something that you can dive right into — it’s more effective and natural for everyone to slowly start showing vulnerability as a habit, like a systematic shift.”

“Say you’re meeting with a person you’re mentoring, and you can reveal something about yourself that someone might be a little hesitant to reveal in a professional context, something that makes you seem more human,” Sabo explains. “A really good starting point is to talk about your family, if you’re comfortable talking about that, and offer small talk, like what you did over the weekend. That’s kind of like the bare minimum. If you’re not offering that much, then you have a very formal, professionalized relationship that’s not going to feel very psychologically safe.”

Going beyond that bare minimum, Sabo finds it helpful to discuss places where you, as the more experienced engineer, have failed professionally. Or, discuss ideas that you are unsure or nervous about. Those opportunities afford stepping stones into vulnerability and demonstrate that you trust the other person.

“Vulnerability is not something that you can dive right into,” he says. “It’s something that takes time and a conscious effort for it to start being modeled by others. It’s more effective and natural for everyone to slowly start showing vulnerability as a habit, like a systematic shift.”

One way you can do this is by dedicating time to get coffee and socialize. Make that purpose explicit; tell the mentee, “Let’s just talk and get to know each other more.” Some people try to press these conversations into the beginning of a formal 1:1, but that can feel like forced conviviality. Taking the initiative to show that you care about getting to know your mentee is a valuable step in establishing psychological safety between you two, and by extension between the new engineer and the organization.

Those seemingly small steps—helping new engineers feel welcome and secure—is what it takes to help individuals transition into wholly invested members of the team.