Mentorship at Scale: Why It’s Now a Leadership Expectation

Photo by Vitaly Gariev on Unsplash

Why Mentorship at Scale Is Now a Leadership Expectation, Not a Perk

Six months ago, my director asked me to mentor three junior PMs. Last month, that number became eight. My calendar didn’t get any emptier. According to SHRM’s 2025 Workplace Learning & Development Report, 68% of organizations now list “coaching capability” as a required leadership competency for managers at the director level and above—up from 41% in 2022. The message is clear: mentorship is no longer optional goodwill you do when time allows. It’s a core function of mid-level leadership, and most of us have no system for doing it without burning out.

The collision is real. Harvard Business Review’s May 2025 analysis found that managers report feeling 34% more time-compressed than they did 18 months ago, largely due to increased AI productivity expectations and compressed sprint cycles. At the same time, organizations are pushing coaching cultures downward, expecting individual contributors and mid-level leaders to absorb mentorship responsibilities that used to sit with L&D teams or senior executives. The result: leaders who want to mentor well but have no operational framework for doing so at scale, and junior employees who need more guidance than ever as career paths fracture and skill half-lives shrink.

The Batched Mentorship Operating Model

Most leaders treat mentorship as a series of one-off 1:1 conversations. That works when you’re mentoring two people. It collapses when you’re mentoring eight. The alternative is a batched, reusable system that treats mentorship like a product: designed once, deployed repeatedly, improved iteratively. This is a four-part operating model, and the second step is the one most leaders skip.

Step 1: Define your mentorship scope and say no to everything else. You cannot mentor everyone on everything. Pick two domains where your experience is genuinely differentiated—for me, that’s data product scoping and stakeholder negotiation in technical environments. Everything else gets referred out. When someone asks for career advice on a topic outside that scope, I connect them to someone better positioned to help. This is not abdication. It’s honest resource allocation. A vague mentorship relationship where you’re guessing at answers is worse than no relationship at all.

Step 2: Build reusable frameworks, not custom advice. This is the step most leaders skip, and it’s the only one that scales. Every time I answer a question in a 1:1, I ask myself: is this a one-time answer, or a repeatable pattern? If it’s repeatable, I document it as a decision framework, a checklist, or a set of diagnostic questions. For example, I was getting the same question from four different PMs: “How do I know if this feature request is worth building?” I created a two-page prioritization rubric with weighted criteria and sample scoring. Now when that question comes up, I send the rubric, we discuss their specific case for 15 minutes instead of 45, and they have a tool they can reuse without me. The next mentee gets the same rubric, refined based on what the previous four learned. This is how you mentor eight people without working 60-hour weeks.

Step 3: Batch recurring topics into group sessions. If three or more people are asking about the same topic within a quarter—how to run a sprint retrospective, how to write a technical spec for non-technical stakeholders, how to negotiate timeline extensions—run a 60-minute group session. I do this once a month. It’s not a training seminar. It’s a working session where I walk through the framework, they bring live examples, and we workshop them together. The value isn’t just in my input—it’s in hearing how other junior PMs are tackling the same problem. And it gives me back four hours of calendar time I would have spent repeating the same advice in separate meetings.

Step 4: Measure impact with two metrics, not surveys. Most mentorship programs measure the wrong things: satisfaction scores, number of sessions held, qualitative feedback. Those matter, but they don’t tell you if mentorship is actually working. I track two numbers: decision velocity (are mentees making decisions faster and with more confidence than they were 90 days ago?) and repeat question rate (are they coming back with the same question type, or are they applying the frameworks independently?). If decision velocity isn’t improving, the mentorship isn’t translating to capability. If repeat question rate isn’t dropping, I’m not building durable skills—I’m creating dependency. David Ohnstad’s data product management writing uses a similar principle: feedback loops that measure behavior change, not sentiment.

When Mentorship Turned Into a Bottleneck Instead of a Multiplier

Two years ago, I was mentoring a PM who kept scheduling 30-minute check-ins to ask variations of the same question: “Is this roadmap prioritization reasonable?” The first three times, I walked through my reasoning. The fourth time, I realized I was the problem. I had never given him a prioritization model he could use independently. I was solving the problem for him every time instead of teaching him how to solve it himself. He wasn’t learning. He was outsourcing judgment.

I built a simple scoring framework—three weighted dimensions: business impact, technical feasibility, strategic alignment—and a decision tree for edge cases. Sent it to him with examples from our past conversations. The next time he had a prioritization question, he came to the meeting with his own scoring, his reasoning, and one specific edge case he wanted to pressure-test. The meeting took 12 minutes instead of 30, and his confidence was visible. More importantly, he stopped scheduling those check-ins. He didn’t need them anymore. That’s when I realized: effective mentorship makes itself obsolete.

I applied the same approach to the other seven people I was mentoring. Created frameworks for the most common question types. Batched the recurring topics into monthly group sessions. Started tracking decision velocity and repeat question rate. My mentorship calendar time dropped by 40%, and the feedback I got was better than when I was doing ad hoc 1:1s every week. The junior PMs felt more capable, not less supported. That distinction matters. Mentorship that creates dependency isn’t mentorship—it’s a maintenance contract.

Stop Treating Mentorship Like Therapy and Start Treating It Like Skills Transfer

Most leadership advice on mentorship emphasizes listening, empathy, and psychological safety. Those are necessary conditions, but they’re not sufficient. The conventional wisdom is that great mentorship is about being available, being present, and being supportive. That’s wrong. Great mentorship is about transferring decision-making capability as quickly as possible so the mentee doesn’t need you anymore. According to McKinsey’s 2024 report on organizational learning, the most effective development programs are those that result in measurable behavior change within 90 days—not sustained engagement over 12 months. Mentorship that feels good but doesn’t change how someone makes decisions is just expensive emotional labor.

The harder truth: if your mentees still need the same level of guidance after six months, you’re not mentoring—you’re doing their thinking for them. This doesn’t mean you cut people off or refuse to help. It means you focus relentlessly on building reusable tools, frameworks, and mental models that they can apply independently. The goal is not to be the person they come to every time they have a hard decision. The goal is to be the person who taught them how to make hard decisions on their own. That requires a different approach than most mentorship training teaches.

Mentorship Needs the Same Rigor as Product Development

One thing that changed David Ohnstad’s approach: I started treating mentorship relationships the way I treat product feature development. That means defining success criteria upfront, tracking leading indicators of progress, and iterating based on what’s working. When I start mentoring someone, I ask them to write down two specific capabilities they want to build in the next 90 days. Not vague goals like “get better at stakeholder management”—specific, observable skills like “run a feature kickoff meeting without needing my review beforehand” or “write a technical spec that engineering accepts without major revisions.”

Then I ask: what would prove to you that you’ve developed that capability? What decision would you be able to make independently that you can’t make today? This forces clarity. It also makes it obvious when mentorship is working and when it’s not. If someone says they want to get better at prioritization but they’re still asking me to validate every roadmap decision 60 days in, something isn’t translating. Either my frameworks aren’t clear enough, or I’m not giving them enough room to practice and fail without me. Both are fixable, but only if you’re measuring.

The other product principle I apply: user research. I ask mentees every 30 days what’s actually useful and what’s noise. Are the frameworks helping or just adding process overhead? Are the group sessions valuable or would they rather have 1:1 time? Are they applying what we discuss or is it staying theoretical? This isn’t a satisfaction survey—it’s a usability test. The goal is to find out if the mentorship operating model is working as designed, and if not, where it’s breaking down. David Ohnstad on AI and enterprise SaaS explores similar feedback mechanisms for validating whether a system is actually being used the way you intended, or just tolerated.

What the Research Shows: Mentorship Is Becoming a Frontline Leadership Competency

Salesforce’s February 2025 report on essential sales manager skills listed “developing talent through coaching” as the #2 most critical capability for 2026, up from #7 in 2023. The shift is structural, not anecdotal. Organizations are flattening hierarchies, which means fewer promotion opportunities and longer tenures in mid-level roles. The tradeoff: companies expect those mid-level roles to absorb more leadership responsibility, including mentorship and skills development. This isn’t HR rhetoric. It’s a redefinition of what a manager does.

Gallup’s 2024 State of the American Manager study found that employees who say they have a mentor are 67% more likely to stay with their organization for more than three years, compared to 34% of those without mentorship. Retention is the business case. But here’s the part most organizations miss: that same study found that the quality of mentorship mattered far more than the frequency. Employees who had infrequent but high-impact mentorship (defined as sessions that resulted in a clear action or decision) reported higher engagement and capability growth than those who had regular but low-substance check-ins. This aligns with what I’ve seen: batched, structured mentorship beats ad hoc availability every time.

What to Watch: The Rise of Micro-Credentialing and Just-in-Time Mentorship

The next shift won’t show up in the data for another 12 months, but it’s already happening in pockets. Organizations are starting to treat mentorship as a discrete, stackable skill set rather than a general leadership expectation. You’re seeing internal certifications for “technical mentorship” or “career navigation coaching”—narrow, defined competencies with clear outcomes. This mirrors the shift toward micro-credentialing in learning and development, where employees earn recognition for specific capabilities rather than broad role titles.

The second trend: on-demand mentorship platforms that match employees with internal experts based on specific, time-bound needs. Instead of assigning a mentor for a year, you get matched with someone who solved the exact problem you’re facing right now, you have two 45-minute sessions, and then the relationship ends. This is mentorship as a service, not a relationship. It’s controversial—plenty of leadership thinkers argue it erodes the trust and continuity that make mentorship effective. But for organizations with distributed workforces and high mobility, it’s pragmatic. The platforms that succeed will be the ones that figure out how to preserve the high-impact, decision-focused structure while removing the calendar overhead.

How do you scale mentorship without overwhelming your calendar?

Build reusable frameworks for recurring question types, batch common topics into monthly group sessions, and define clear success metrics that measure whether mentees are making decisions independently. The goal is not more meetings—it’s faster capability transfer so mentees need you less over time, not more.

What’s the difference between effective mentorship and just being available?

Effective mentorship transfers decision-making capability through structured frameworks and tools that mentees can apply independently. Availability without structure creates dependency, where mentees keep coming back with the same questions because they haven’t learned how to solve the problem themselves. Measure success by decision velocity, not calendar time spent.

Why do most mentorship programs fail to produce measurable business outcomes?

Most programs measure engagement or satisfaction instead of behavior change. They prioritize frequency of interactions over quality of skill transfer, and they don’t define success criteria upfront. Without clear metrics tied to capability growth or decision confidence, mentorship becomes a compliance activity rather than a development strategy.

What This Means for Practitioners and Leaders

For practitioners building mentorship practices: treat this like a product launch. Define the scope of what you can credibly mentor on, build reusable tools that scale your expertise, and track whether mentees are making better decisions faster. If your calendar is filling up with mentorship meetings and your mentees aren’t becoming more independent, your system is broken—not your intent.

For leaders evaluating mentorship as a leadership competency: stop measuring mentorship by hours logged or number of relationships. Measure it by decision velocity and capability transfer. The best mentors are the ones whose mentees stop needing them within six months because they’ve internalized the frameworks and can apply them independently. That’s the outcome worth rewarding.

Here’s the question to ask yourself: if you looked at your mentees’ decision-making today versus 90 days ago, could you point to three specific decisions they’re now making independently that they used to escalate to you? If not, what are you actually teaching them?

For more on this topic, visit David Ohnstad on AI and enterprise SaaS.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.