Most mentorship fails in a slow decay of calendar invites, until both people are relieved it stopped.
I wrote a version of this in 2018, drawing on years of mentoring designers from underrepresented backgrounds and later through Andreessen Horowitz, and before that founders at Rockstart. I've had several more years of it since, on both sides. What I wrote then still holds. What I left out was the half that decides whether any of it applies.
Ask what they are up against
Before any of the advice below, there is a question that decides whether the advice is worth giving. What is this person actually up against? A great deal of mentoring energy gets spent in places where it cannot possibly work, and the spending feels productive the whole time.
A mentee with a manager who does not give feedback, on a team with no clear levels, in a company where promotion runs on visibility, does not have a mentoring problem. They have an employer problem, and an hour a fortnight with a sympathetic outsider will not touch it. What that hour can do is help them see it clearly, which is worth something and is not the same as solving it.
I have watched organizations use mentorship as a substitute here, and it is an efficient substitute because it looks generous. Pair the underserved people with senior volunteers, run it for a year, report participation. Nobody has to change how promotion works or how feedback is given. The burden of navigating a structure that disadvantages someone gets handed back to that person, now with a coach.
If the answer is a skill or a blind spot, mentoring is the right instrument, and the rest of this is about how to use it. If the answer is the shape of the place they work, what I can usefully offer is narrow. A straight account of what I think is going on, an introduction or two, and the point that leaving is a reasonable move rather than a failure of nerve. I have given that advice more often as I have gotten older, and I have not once regretted it.
Meet them where they are in their career
Most often it fails like this. A mentor answers the question they find interesting rather than the one that was asked. I have done it myself. Somebody wants to know how to handle a specific piece of feedback from their manager on Thursday, and you give them a framework for career narrative arcs.
Speak at their level, about their situation, in language that matches where they actually are. And be concrete about where that is: a striking number of designers have no idea what level they're operating at, because nobody has ever told them plainly. Helping someone locate themselves is often the single most useful hour you'll spend with them.
Then tell them what the next level requires, and be clear which parts of getting there are outside their control. Pretend that getting ahead is purely about merit and you make people feel personally responsible for problems built into the place.
Teach them to ask better questions
At every level, what separates one from the next is question quality. Not answer quality.
A junior designer asks whether the button should be blue. A senior one asks what happens to the rest of the flow if this action becomes the default. A lead asks whether we should be building this surface at all given what we learned last quarter.
And the factors a good question has to hold have expanded. It used to be aesthetics, ergonomics, usability, data, technical constraints. Now it's also business model, ethics, inclusion, what the thing does at scale to people who never chose to use it. That's a harder discipline than it was when I started, and I don't think we've adjusted how we teach it.
You can hand someone an answer and solve their week. Teach them the question and you've changed what they can do without you. That is the actual goal, and the reason mentorship should end.
Relationships are not a soft skill
Talent on its own is not enough, and pretending it is does them no favours. Relationships are how work gets funded, and how it survives the first person who objects to it. Someone who does not know this will do excellent work and watch it get shelved, and conclude the problem was the work.
Be specific here. Which people in this organization need to know what you're doing? Name the ones who'll be in the room when your project is discussed and you aren't. And work out who has been burned by something adjacent and will object for reasons that have nothing to do with you.
This is not cynicism. It's the operating system. And it is far more invisible to people who didn't grow up around it, which is why it belongs in mentorship rather than being absorbed by osmosis from people who already had the map.
Teach them to advocate for themselves
Most designers I've mentored underclaim. They describe a team outcome when they drove it, or list what they made without saying what it changed.
A fix here is mechanical, not attitudinal. Keep a record as things happen: what you did, what changed because of it, who else was involved. Not a brag document, an accurate one. Almost nobody can piece this together at review time, so they fall back on vague description, and vague description reads as a weak year however strong it was.
If you're mentoring someone from a background where self-advocacy carries a social cost (and for a lot of people it demonstrably does), say that out loud. "Just talk about your work more" lands very differently depending on how it's received when you do.
Show them a path, not a destination
Worst of all, a mentor presents their own career as the route. Mine involved three companies of my own, four as an executive, a move to California and a move back, and almost none of that is repeatable advice. It is a run of particular situations I happened to respond to.
What transfers is the reasoning. Why I took a role, what I was optimizing for at the time, what I'd weigh differently now. Decisions are portable. A path isn't.
Why it decays
Three ways it comes apart, none of them dramatic.
Nobody agrees when it ends. No one has said what "done" looks like, so it runs until it gets awkward. Set an end point, six sessions or one specific goal, and renew it deliberately if it's working. Ending well is not failure. It's the design.
A mentor is getting something they haven't admitted to. Being needed is pleasant. If you're honest, some of what makes mentorship rewarding is being the person with the answers, and that incentivizes dependence without anyone intending it. Watch for it in yourself. I have caught it in myself.
No preparation. Thirty prepared minutes beat ninety unprepared ones. If your mentee arrives without a specific question, the session becomes pleasant catch-up, and pleasant catch-up is what a relationship decays into right before it stops.
None of which is complicated. It is just easier to write the advice than to admit that most of the difficulty is in the upkeep, and most of the rest is in whether the problem was reachable at all.
Adapted and much expanded from notes I wrote in 2018. I've built design and product teams at Honor, Lyft, Grammarly and Pitch, mentored founders at Rockstart, and mentored designers from underrepresented backgrounds, including through Andreessen Horowitz.
© 2026 Renato Valdés-Olmos