Mentorship as Infrastructure

The best mentor in the organization resigned on a Tuesday. Staff engineer, four years in, and the title wasn’t why it hurt. She had quietly built most of the mid-level bench: code reviews that taught rather than gatekept, career conversations no one assigned her, and a standing invitation to watch her debug. None of it was on a roadmap. All of it was load-bearing.

Within two quarters, the engineers she’d been developing had stalled and one had left. Leadership’s response was to add “mentors others” to the values page and hope the trait reappears in the next hire.

Wrong response. The organization didn’t lose a generous person. It discovered it had built its development pipeline on one. Mentorship isn’t a disposition some seniors have and others lack. It’s infrastructure: named pairings, explicit handoffs, and development wired into the work itself. Most companies never build it and then wonder why growth depends on who sits nearby. This mattered before agents started writing routine code. It matters more now.

The Volunteer Theory of Mentorship

Ask most leaders how their engineers grow and every answer is a character reference. We hire people who love to teach. We have a culture of learning. When growth stalls, the explanations stay personal: seniors are too heads-down, juniors aren’t hungry enough. The fix is always a value restated at an all-hands meeting.

Call this the volunteer theory of mentorship. It has three predictable failure modes. Volunteer mentorship concentrates: mentors gravitate toward mentees who remind them of themselves, so the people most likely to succeed get developed twice while everyone else gets luck. It evaporates: the entire arrangement leaves with either party. And it taxes exactly the wrong line item. Your strongest engineers do it unfunded on top of a full roadmap until the quarter that finally stops them.

The volunteer theory has a corporate cousin that looks like a fix and isn’t: the Program. Once a year, a spreadsheet matches names, calendar invites go out for monthly coffee, and by the second quarter the meetings are rescheduled into oblivion. A program is the volunteer theory with a project plan. It places mentorship alongside the work rather than inside it. That is why it dies when the work gets loud.

Development Is a Duty, Not a Disposition

The military runs the counter-example and it’s boring on purpose. Years in Airborne and Special Forces units showed me an organization that develops people relentlessly while assuming nothing about anyone’s teaching instincts. Every soldier has a named developer: a specific sergeant, not “leadership.” Counseling is scheduled, written, and signed so it happens in months when nobody feels reflective. It works that way because the military can’t select for nurturing temperament and constantly rotates everyone. Development lives in the structure because the people never stay put.

Engineering orgs aren’t rifle platoons. They share the one constraint that matters here: expertise is always in motion. Any development model that assumes the same teacher will be there next year has an expiration date. A team of six with one natural teacher doesn’t need infrastructure. Add growth, churn, and a reorg a year. The volunteer model becomes what it always was: hope with a good quarter behind it.

Four Components, No Heroics

None of them requires anyone to become more generous.

One name per person. The principle: every engineer can answer without hesitating who owns their development. The implementation that holds: a named developer on the record, usually a senior or staff engineer a level or two up and outside the reporting line, deliberately not the manager. Managers own evaluation, and the questions that drive genuine growth (“I don’t understand our own architecture,” “I think I’m underperforming”) don’t get asked of the person who writes the review. Some orgs fold development into the manager’s job. If yours does, be honest about which questions will never reach them.

Development lives inside the work. The highest-bandwidth teaching surfaces already exist: code review, incident response, design review, the first draft of a spec. Wire the pairing into those. The mentee writes the post-incident review, presents the design while the mentor asks questions from the back of the room, and reviews the mentor’s pull requests, not just the reverse. Coffee chats are where development goes to be adjacent.

Handoffs are events, not drift. When a mentor rotates, resigns, or gets reorged, the pairing transfers explicitly: a name out, a name in, both parties told. Most abandoned mentees were never dropped on purpose. They were orphaned by a calendar entry that quietly stopped recurring.

Fund it or forfeit it. Mentoring capacity appears in planning like any other commitment, and developing others is required evidence at senior levels. Not a tiebreaker. A requirement. What the calendar and the ladder don’t protect, the roadmap eats every time.

None of this replaces generosity, and it shouldn’t try. Structured pairings can go through the motions, and your natural teachers will keep doing more than the system asks. The infrastructure makes a narrower promise: generosity is no longer the organization’s only mechanism.

The End of Osmosis

This used to be a retention argument. It’s becoming an existential one. As agents absorb the routine tickets juniors learned on, the learning path doesn’t disappear. It moves to review, specification, and judgment, which are skills that transfer person to person or not at all. The structure above stops being a retention play and becomes the production line for your senior bench. The osmosis era of engineer development is ending. What replaces it is either built or absent.

Rerun the opening scene with the components in place. The staff engineer still resigns. People leave, and no structure changes that. But her mentees have named successors within the week, because transfer is an event. Their development continues inside the work, because it never depended on her calendar. The organization loses a person and keeps a pipeline.

The next resignation is already on someone’s calendar. Decide what leaves with it.