Mentor Across Difference — Mentoring Engineers, Part 9
Mentoring Engineers · Part 9
An engineering manager is asked, in a calibration meeting, why one of their two mid-level engineers is ready for the on-call rotation and the other isn't. They answer without hesitation: "She's still finding her feet. He's been confident from day one." Someone asks how long each has been on the team. The answer is eight months for her and five for him. The manager hadn't noticed. They'd been mentoring both engineers in good faith for months, and the difference in treatment was invisible from where they sat.
That's the problem with mentoring across difference. Bias in mentoring rarely looks like hostility. It looks like a reasonable judgment ("confident", "not quite ready", "a natural fit for this project") that happens to line up with who reminds you of yourself. You can't introspect your way out of that, because the judgments feel accurate.
The working claim of this part: you can't fix bias by caring more. You fix it by checking your mentoring decisions against data you can count. The rest is adjusting how you communicate so the person in front of you can actually use what you give them.
Before you start
List everyone you mentor or manage. For each, note the last stretch assignment they got, when they got it, and who suggested it.
Pull the last written feedback you gave each person: 1:1 notes, review comments, performance reviews.
Re-read Part 5, Sponsor, Not Just Mentor. Sponsorship is where differences in treatment have the biggest effect on careers.
Step 1: Audit the decisions you can count (20 min)
Start with the data, not your feelings about it. For each person you mentor, fill in this table:
Signal | What to record |
Time to first on-call, design ownership or production access | Weeks from joining |
Stretch assignments in the last 12 months | Count, and who proposed each one |
Times you advocated for them where they weren't present | Count: calibration, staffing, promotion discussions |
Feedback specificity | Share of your written feedback that names a specific piece of work and an outcome |
Now look for patterns that line up with anything other than performance: gender, background, communication style, time zone, whether they're remote, whether they're like you.
The research gives you a reason to look at two signals in particular. Ibarra, Carter and Silva (2010), drawing on a Catalyst survey of over 4,000 high-potential employees, found that women were more likely than men to have mentors, yet were advancing less. Their explanation was sponsorship: women were, in their phrase, "overmentored and undersponsored". Correll and Simard (2016) found that women's performance feedback was more often vague and less often tied to business outcomes than men's. Advocacy and feedback specificity are exactly where good intentions don't protect you.
Test you can run: if two people with similar performance differ by months in time to first stretch assignment, write down the reason for each. If the reason is a trait ("confident", "a natural leader") rather than evidence ("handled the March incident well"), you've found something to correct.
Step 2: Make feedback specific for everyone (15 min)
Vague feedback is the easiest bias to fix because you can check it on paper. Go through the feedback you pulled before starting and mark each comment:
Vague: "Great year." "Needs to be more strategic." "Communication could improve."
Specific: "The migration plan in May caught the lock risk before we merged."
"In the API review, the objection about pagination landed after the decision.
Raise it in the pre-read next time."
A specific comment names a piece of work, what happened, and what to do next. If one person's feedback is mostly vague and another's is mostly specific, the first person can't act on what you've told them, and their progress will look slower for reasons that have nothing to do with them.
Watch for style words in particular: "abrasive", "too quiet", "not a culture fit", "aggressive". They describe your reaction, not their work. When you catch one, ask yourself what specific behaviour caused it and what outcome it affected. If you can't answer, delete the comment.
Test you can run: for each person, what share of your last ten written comments are specific? The target is that the share is about the same for everyone, and high.
Step 3: Adapt communication to the person, not the stereotype (15 min)
People differ in how they disagree, how they take feedback and how they speak up, and those differences often follow culture, language and personality. Erin Meyer's The Culture Map (2014) describes how cultures vary on scales such as direct versus indirect negative feedback, and explicit versus implicit communication. It's a useful map, with an important limit: individuals vary a great deal within any culture, so use it to form questions, not conclusions.
The practical move is to ask, early and directly:
"How do you prefer to get critical feedback: in writing first, or in conversation?"
"If you disagreed with me, how would I find out?"
"Is there anything about how meetings run here that makes it harder to contribute?"
Then adjust what you control. For someone who doesn't speak up in large meetings, ask for their view in the pre-read or in a 1:1, and quote it in the meeting with credit. For someone who disagrees indirectly, treat "that could be tricky" as a real objection and follow up. For someone working in a second language, send agendas in advance and accept written contributions as equal to spoken ones.
Test you can run: in your last three team design reviews, whose ideas were adopted, and how did those ideas get raised? If adopted ideas only come from people who speak first in the room, your process is choosing for style, not quality.
Step 4: Sponsor deliberately, and track it (10 min)
Sponsorship means using your own standing to get someone an opportunity: naming them for a project, putting their work in front of leadership, arguing for them in calibration. It's where informal affinity has the most effect, because it happens in rooms the person isn't in, so nobody else can see it.
Make it deliberate. Each quarter, write down which opportunities came up (lead roles, conference talks, visible projects) and who you put forward for each. Over a year, the list will show you whose career you're actually investing in.
Test you can run: count the advocacy row from Step 1 for each person. If it varies a lot between people with similar performance, decide on purpose whose name you'll put forward next time.
Step 5: Ask for feedback on yourself, in a way that makes it possible to answer (10 min)
"Do you have any feedback for me?" almost always gets "No, it's all good", especially from someone junior, from a culture where criticising seniors is uncomfortable, or from someone who's already the only person like them on the team.
Ask narrower questions that are easier to answer honestly:
"What's one thing I do in our 1:1s that isn't useful to you?"
"Was there a time recently you didn't raise something with me? What stopped you?"
When you get an answer, act on it visibly and say that you did. That's what makes people willing to answer the next time.
Step 6: Support without making it a rescue (5 min)
Two opposite mistakes are common. One is treating mentees from underrepresented groups as projects to be saved, which is patronising and puts you at the centre of their story. The other is overcorrecting: making their identity the constant topic or handing them diversity work by default, often unpaid and unrecognised.
The steadier approach: hold the same bar, give the same quality of feedback and sponsorship, and remove specific obstacles when you see them. Connect them with mentors who share their background or experience, including people outside your team, since your network isn't the only one they need. Then get out of the way.
Worked example: the on-call gap (composite scenario)
Context. The calibration meeting from the opening. A manager mentoring two mid-level engineers of similar performance.
The audit. The manager filled in the Step 1 table that evening. One engineer had joined three months later than the other and reached on-call first, design ownership first, and had been proposed twice for a visible migration project. The other had more months on the team and had been proposed for nothing. The manager's written feedback to the first was mostly specific ("the rollback plan in June was the right call"). Feedback to the second was mostly general ("doing well, keep building confidence").
What the manager changed. They rewrote their feedback notes for the second engineer, tied to actual work, and found two pieces of strong design work they'd never mentioned in writing. They asked her the narrow questions from Step 5. She said design reviews moved too fast for her to raise concerns, and that she'd been keeping a list of issues she'd spotted but not said out loud. The manager moved design discussions to a written pre-read with a 48-hour comment window.
What happened. Within a quarter she joined the on-call rotation and led the next schema redesign. Her written comments in the pre-reads caught two issues that would otherwise have shipped. The manager kept the quarterly sponsorship list going and saw the advocacy counts for the two engineers converge.
Lesson. The manager wasn't hostile and didn't believe they were biased. The table found in an evening what months of good intentions hadn't.
Trade-offs to make deliberately
Choice | You gain | You risk |
Counting decisions (Step 1) | Patterns you can't see by introspection | Feeling clinical, so explain why you're doing it if people ask |
Adapting communication per person | People can actually use your input | Stereotyping, if you adapt to a group instead of asking the individual |
Written pre-reads for decisions | Equal voice for quieter and second-language contributors | Slower decisions, so use a fixed comment window |
Deliberate sponsorship lists | Fairer access to opportunities | Feeling mechanical, which is better than the informal version that's unfair |
Common failure modes
"I treat everyone the same." Usually untested. The audit is how you find out.
Vague feedback for some people and specific feedback for others. The ones getting vague feedback can't act on it, and their progress looks slower.
Style words in reviews. "Abrasive" or "too quiet" describe your reaction, not their work.
Using a cultural generalisation as a conclusion. Ask the person.
Rescuing. It's patronising and puts you at the centre.
Final takeaway
Bias in mentoring shows up in decisions that feel reasonable one at a time: who gets stretch work, whose feedback is specific, whose name you mention in the rooms they aren't in. You can't see the pattern by reflecting on it. You can see it by counting. Your next action: fill in the Step 1 table for everyone you mentor tonight. It takes about twenty minutes. Then pick the one gap that surprises you most and correct it this month.
Sources
Ibarra, H., Carter, N. M. and Silva, C. (2010). Why Men Still Get More Promotions Than Women. Harvard Business Review, September 2010.
Correll, S. J. and Simard, C. (2016). Research: Vague Feedback Is Holding Women Back. Harvard Business Review, April 2016.
Meyer, E. (2014). The Culture Map: Breaking Through the Invisible Boundaries of Global Business. PublicAffairs.
Continue the Mentoring Engineers path
Previous — Part 8: Grow a Mid to Senior
Next — Part 10: Let Them Go
Part of the Mentoring Engineers learning path. Related: Build Team Culture.
