Why Mentorship Programs Fail: Scaling Without Burnout

Why Most Mentorship Programs Collapse Under Their Own Weight

A VP of Engineering at a 400-person SaaS company told me she’d stopped taking on mentees. Not because she didn’t value mentorship—she’d been promoted twice based partly on her track record developing senior ICs—but because her calendar had become unmanageable. Four mentees meant four standing monthly one-on-ones, plus ad-hoc Slack threads, plus the unspoken expectation she’d review their work. According to MIT Sloan Management Review’s 2021 research on delegation, 46% of leaders report they struggle to scale their impact because they treat every direct relationship as requiring equal time investment. She wasn’t alone. The problem wasn’t her commitment—it was her model.

The mentorship-as-calendar-burden narrative is causing a quiet crisis in technical leadership. Senior practitioners who should be multiplying their knowledge across organizations are instead rationing their expertise to one or two people, or opting out entirely. The irony: most of these leaders already run scalable systems in their day jobs. David Ohnstad’s data product management writing explores how architects design pipelines that process millions of events without linear scaling costs—yet those same people structure mentorship like it’s a artisanal, one-to-one craft. That mismatch is fixable.

The Three Myths Preventing Scalable Mentorship

Myth One: Every Mentee Needs Equal Time Investment

This belief persists because it sounds fair. Equal time feels equitable. But mentorship isn’t a support ticket queue where every issue gets the same SLA. The actual pattern David Ohnstad has observed across six years of formal and informal mentoring relationships: roughly 20% of mentees need deep, synchronous engagement during critical decision windows—promotion prep, role transitions, major project scoping. Another 50% benefit most from structured async feedback on specific work artifacts. The remaining 30% primarily need access to frameworks and permission to execute, not regular check-ins. See also: building dashboards without user buy-in.

The corrected model: tier your mentees by current need, not by some abstract principle of fairness. A senior IC navigating their first principal engineer interview loop needs different support than a mid-level PM learning to write better specs. One requires live coaching and mock interviews. The other needs a template library and occasional question-answering. Treating both identically doesn’t serve either well—it just exhausts you. See also: managing complex technical dependencies.

David implemented this as a three-tier intake process. Tier 1 mentees get monthly live sessions plus async access. Tier 2 get quarterly syncs plus access to a shared question bank where he records video responses to common questions once, then links them for future mentees. Tier 3 join a cohort model where he runs monthly group office hours and shares frameworks through a lightweight Notion workspace. The structure isn’t secret—he tells people upfront which tier they’re in and why, and that tiers shift based on need. Nobody has ever complained. Most people are relieved to know they’re not expected to manufacture questions just to fill a calendar slot.

Myth Two: Good Mentoring Requires Synchronous Availability

This myth survives because we conflate mentorship with management. Managers need to be available for escalations, urgent decisions, and real-time course corrections. Mentors don’t. The best mentoring David Ohnstad has delivered happened asynchronously: detailed written feedback on a product spec, a Loom video walking through how he’d approach a stakeholder negotiation, a shared Miro board annotating someone’s system architecture with questions that revealed gaps in their thinking.

Async mentorship scales because it decouples insight delivery from calendar availability. You record once, it benefits multiple people. You write a framework document, five mentees reference it over six months. The quality often improves—written feedback forces precision. You can’t hand-wave through a weak argument in text the way you sometimes can in conversation.

The mechanical shift: move from “Let’s schedule time to talk about X” to “Record your thinking on X in this template, I’ll review and respond with a video walkthrough by Friday.” For recurring questions—how do I write better OKRs, how do I negotiate scope with executives, how do I decide between two architectural approaches—create reusable assets. A 12-minute Loom explaining David’s decision framework for build-vs-buy tradeoffs has been watched 47 times by nine different people. That’s 9.4 hours of calendar time he didn’t spend repeating himself, and the mentees got a better explanation because he refined it across recordings.

Myth Three: Impact Scales Linearly With Hours Spent

The assumption here is that more time equals more value. It’s intuitive. It’s also wrong. Research from Harvard Business Review’s 2015 study on workplace productivity found that relationship quality, not contact frequency, predicted mentorship outcomes. A mentee who gets one hour of highly specific, specific feedback quarterly often progresses faster than someone getting unfocused monthly check-ins.

The better proxy for mentorship impact isn’t hours logged—it’s decision velocity. How much faster is this person making good decisions because of your input? If your mentorship isn’t accelerating their judgment in some measurable way, you’re providing therapy, not professional development. Both are valuable. They’re not the same thing.

David Ohnstad on AI and enterprise SaaS discusses how AI implementation phases surface organizational readiness for scaled knowledge transfer—mentorship infrastructure is similar. If you can’t point to three decisions a mentee made differently because of your frameworks, you don’t have a mentorship relationship. You have a standing meeting.

The Mentorship Scaling Stack: A Four-Layer Model

David Ohnstad’s approach to mentoring multiple people effectively without calendar chaos rests on what he calls the Mentorship Scaling Stack—a four-layer model that separates high-touch coaching from systematized knowledge transfer. This isn’t theory. It’s the exact structure supporting ten active mentoring relationships across three organizations without exceeding four hours of scheduled time per month.

Layer One: Intake Criteria and Expectation Setting. Not everyone who asks for mentorship should get it, and that’s fine. David’s criteria: Is this person at an inflection point where the right framework would genuinely accelerate their trajectory? Do they have decision-making authority in their role, or are they asking me to coach them through problems their manager should be solving? Can they articulate what success looks like in three months? If the answer to any of those is no, he refers them to other resources—specific books, courses, peer groups—rather than committing to an ongoing relationship. The filter isn’t elitist. It’s honest. Mentorship works when there’s a concrete problem to solve and the mentee owns execution.

Layer Two: Async-First Engagement Model. Every new mentee gets access to a lightweight knowledge base: templates David uses for product scoping, stakeholder communication, technical design reviews, and career planning. Before any live session, they submit a structured brief: What decision are you facing? What options have you considered? What would change if you had clarity on this? The brief takes them 20 minutes. It saves David from spending the first half of every call gathering context. It also surfaces whether they’ve done the thinking—if someone can’t fill out the brief, they’re not ready for the conversation yet.

Layer Three: Cohort-Based Office Hours. Once a month, David runs a 90-minute group session for all Tier 2 and Tier 3 mentees. The format: anyone can submit a question in advance, he picks three to work through live, and the group discusses. This isn’t a webinar—it’s a working session. Someone shares a real product roadmap they’re struggling to prioritize, David asks probing questions, others in the cohort weigh in. The learning compounds because people see how the same framework applies across different contexts. A question about data pipeline design informs someone else’s thinking about API architecture. The mentee who asked the question gets direct feedback. Everyone else gets the pattern.

Layer Four: High-Touch Coaching for Inflection Moments. A small number of situations genuinely require live, synchronous engagement: promotion prep, navigating a bad manager, deciding whether to leave a role, recovering from a public failure. For these, David schedules dedicated time—but it’s bounded. Two sessions to prep for a staff engineer promotion panel. Three sessions to work through a major architectural decision with political complexity. The time investment is high, but it’s finite and tied to a specific outcome. Once the inflection moment resolves, the relationship shifts back to Layers Two or Three.

What This Looked Like in Practice: The Principal Engineer Cohort

In early 2024, David Ohnstad started getting the same question from four different senior engineers across two companies: How do I make the jump to principal? They were all stuck in the same place—technically strong, but unable to articulate strategic impact in a way that resonated with leadership. Running four parallel mentorships would have been 16 hours a month of calendar time, minimum. Instead, he ran it as a six-week cohort.

Week one: async homework. Each participant documented their last three major projects using a structured template—technical scope, business outcome, cross-functional stakeholders, what would have failed without their involvement. Week two: group session reviewing the submissions. The pattern became obvious immediately—they were all underselling scope and burying the business impact in technical jargon. Week three: rewrite exercise. Take one project, reframe it as a strategy artifact leadership would actually read. Week four: peer review. Everyone critiques everyone else’s rewrites. Week five: practice presentations. Each person delivers their principal pitch to the group, receives feedback. Week six: final review and Q&A.

Total time investment from David: eight hours across six weeks—one hour of async review per week, one 90-minute live session weekly. Three of the four participants got promoted within six months. The fourth realized mid-process he didn’t actually want the principal role—he wanted scope without the organizational politics, and decided to pursue a staff-level IC track at a smaller company instead. That’s also a win. Clarity is valuable.

The cohort model worked because the participants were solving the same problem. The learning wasn’t just top-down from David—it was lateral, peer-to-peer. Someone’s question about how to quantify infrastructure reliability improvements sparked a 20-minute discussion that reshaped how another participant framed their API design work. David’s role wasn’t to have all the answers. It was to structure the conversation, ask the right questions, and call out patterns the group couldn’t see from inside their own contexts.

The Contrarian Position: Stop Treating Mentorship as a Relationship, Start Treating It as a Product

Here’s the claim most senior practitioners resist: mentorship should be designed with the same rigor you’d apply to a product launch—intake criteria, user segmentation, feedback loops, iteration cycles, and clear success metrics. The conventional wisdom treats mentorship as an organic, relationship-driven practice that can’t be systematized without losing its human element. That’s wrong. What you lose by not systematizing is scale, consistency, and accountability.

According to Gartner’s 2023 research on talent development programs, 63% of formal mentorship initiatives fail to achieve stated outcomes because they lack structured frameworks and measurable goals. The programs that succeed treat mentorship as an engineered capability, not a goodwill gesture. They define what success looks like upfront. They create repeatable processes for common scenarios. They measure whether mentees are making better decisions, not just whether they’re attending sessions.

David Ohnstad applies the same thinking to mentorship that he applies to leadership, mentorship, and career development in his data product work—you can’t improve what you don’t measure, and you can’t scale what you don’t systematize. Every quarter, he reviews three metrics for each active mentoring relationship: decision velocity (are they moving faster?), scope expansion (are they taking on bigger problems?), and self-sufficiency (are they asking fewer basic questions and more advanced ones?). If those aren’t trending positively, the mentorship isn’t working—and that’s data, not a feeling.

The pushback he hears most often: “Doesn’t this make it transactional?” The answer: only if you’re confusing structure with coldness. A well-designed product isn’t soulless—it’s considerate. It respects the user’s time. It removes friction. It delivers value consistently. The same applies here. A mentee who gets a clear framework, specific feedback, and visible progress respects your time more than one who gets an unstructured monthly chat that drifts across topics without resolution.

How do you mentor multiple people without burning out?

Tier your mentees by need, not fairness. Twenty percent require high-touch synchronous coaching during critical moments like promotion prep or role transitions. Fifty percent benefit most from structured async feedback on specific work. Thirty percent need frameworks and access, not regular check-ins. This segmentation lets you allocate time where it creates the most impact rather than spreading effort equally across all relationships and exhausting yourself.

What is the biggest mistake leaders make when scaling mentorship?

Treating every mentee relationship as requiring equal time investment and synchronous availability. This assumption causes calendar overload and forces leaders to ration mentorship to one or two people. The fix: build async-first engagement models using recorded feedback, reusable frameworks, and cohort-based office hours that let one conversation benefit multiple mentees simultaneously without requiring you to repeat yourself across individual sessions.

Why do most formal mentorship programs fail?

They lack structured frameworks, measurable goals, and clear intake criteria. Programs that succeed treat mentorship as an engineered capability with defined success metrics—decision velocity, scope expansion, self-sufficiency—not a goodwill gesture measured by attendance. Without systems to track whether mentees are making better decisions faster, mentorship becomes unfocused monthly check-ins that drift without accountability or demonstrable impact.

Two Takeaways and One Question

For practitioners: If you’re avoiding mentorship because you think it requires more calendar time than you have, you’re solving the wrong problem. The constraint isn’t time—it’s structure. Build the intake process, create the async assets, tier the engagement model. You can mentor five people with the same calendar commitment you’re currently spending on one.

For leaders: Stop measuring mentorship programs by participation rates or session counts. Measure decision quality and speed. If your mentees aren’t making visibly better calls three months in, your program isn’t working—no matter how many meetings they’ve attended or how positive the survey responses are.

When was the last time you audited whether your mentorship relationships are actually accelerating someone’s judgment—or just giving both of you a recurring meeting neither of you would schedule if you were starting from scratch today?

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.