Every engineering firm has the same conversation about mentorship. Yes, we need it. No, it’s not really happening. The senior people are too busy, the junior people are looking for it elsewhere, and the firm knows it’s losing ground but doesn’t quite know what to do about it.
It’s tempting to read this as a willingness problem. It isn’t. The senior engineers I’ve talked to almost universally want to pass down what they know. They’ve been at the firm twenty or thirty years. They want their work to outlast them. The problem isn’t that they don’t care. It’s that the version of mentorship most firms run asks them to add a thirty-hour-a-month commitment to a schedule that’s already overbooked, and they correctly conclude that’s not survivable.
This is a design problem, not a values problem. The American Society of Civil Engineers (ASCE), the American Institute of Architects (AIA), and other industry bodies have been publishing on this for years, and a clear pattern has emerged: the firms that have figured out how to make mentorship sustainable have a few things in common, and they’re worth being specific about.
Why this connects to a bigger problem
I wrote recently about what happens when senior engineers retire and most of what they know walks out with them. [Previous] The capture-it-on-the-way-out problem is real, and there are tools and processes that help. But the deeper truth is that knowledge retention isn’t really a retirement-eve problem. It’s a transmission-over-decades problem. By the time you’re trying to capture what someone knows in the last six months before they leave, you’ve already lost most of what could have been transferred.
Mentorship is the upstream answer. Done right, the institutional knowledge transfers over years, not in a panic at the end. The firm doesn’t have to capture a senior engineer’s judgment because younger engineers have already absorbed it through working alongside them.
Most firms don’t do this. They have informal mentorship that depends on whether senior engineers feel like teaching on any given week, and they have formal training that covers procedure but not judgment. Neither captures what actually needs to transfer. And neither survives the time pressure on senior people.
The version that burns everyone out
The default mentorship program looks like this. The firm pairs each junior engineer with a senior engineer. They schedule recurring one-hour meetings, weekly or biweekly, on the calendar. The expectation is that the senior will teach, the junior will learn, and the firm will retain talent and transmit knowledge as a result.
This is the version that fails. Senior engineers show up to the first few meetings and find that there’s nothing specific to do. They give vague career advice. They ask the junior what they’re working on. They run out of structured content within twenty minutes and spend the next forty making polite conversation. The meeting goes on the calendar, but the value is unclear, and within a few months the senior is canceling whenever a real project demand competes for the slot.
The junior engineer leaves these conversations confused about whether they learned anything. The abstract advice doesn’t translate into knowing how to do the work. The relationship feels obligatory on both sides.
After a year, the firm concludes that mentorship doesn’t work. The senior engineers are relieved when the program quietly winds down. Nobody got what they needed, and everyone is back to where they started, except the calendar is a little less full.
The mistake isn’t the people. It’s the structure. Formal hour-long meetings about career development are the wrong unit of mentorship for engineering work. The thing that actually transfers between senior and junior engineers doesn’t happen in scheduled meetings. It happens in the work.
What actually works
Across the structured programs that civil engineering and architecture firms have built over the last decade, and across the broader literature on mentorship in technical fields, the same patterns keep showing up. The firms that get mentorship right design it around the senior engineer’s time, not against it.
Mentorship inside the work, not next to it. When a senior engineer is going to solve a hard problem anyway, bring a junior engineer along to watch them think through it. The senior doesn’t have to prepare anything. They’re doing work they were going to do. The junior asks questions in context, hears the reasoning out loud, and absorbs the judgment as the work happens. Thirty minutes of this is worth more than any career-development meeting on the calendar.
Time measured in minutes, not hours. A fifteen-minute conversation explaining why a design choice went one way and not another. A five-minute walkthrough after a review explaining the reasoning, not just the fix. A senior pulling a junior into a client call because they should see how the conversation goes. None of these requires scheduling. Cumulatively across a quarter, they add up to real transmission. Per interaction, they cost the senior almost nothing.
Group formats, not just pairs. One senior engineer in a structured monthly conversation with three or four juniors is roughly three times more efficient on senior time than one-on-one mentorship. The juniors also learn from each other’s questions, which usually surface the things they were too unsure to ask alone. The senior covers more ground in less time and feels less like the lone source of knowledge.
Phase-based project shadowing. Attach a junior engineer to a senior on a real project for the duration of a specific phase: design development, schematic design, construction documents, whatever fits the firm’s work. The junior sits in on real meetings, participates in real decisions, hears real client conversations, and watches the senior make judgment calls in context. The senior doesn’t change what they’re doing. The junior gets weeks or months of structured exposure to how a project actually runs, without anyone scheduling an extra meeting.
Collaborative pairing on real problems. When senior and junior engineers work together on something where each has something the other doesn’t, the relationship stops feeling like teaching. The senior brings deep context and judgment. The junior brings current methods, fresh perspective, and often specific tool knowledge the senior hasn’t had time to absorb. Both contribute to the actual work. Both come away with something they didn’t have before. Neither is positioned as the expert or the student. The asymmetry that makes traditional mentoring uncomfortable goes away, because there isn’t one.
Light infrastructure, not heavy program design. Suggested agendas. A short list of conversation starters. A simple way to track who’s pairing with whom. The firms that build elaborate program documentation tend to spend more energy on the documentation than the mentorship. The firms that provide just enough structure to lower the friction of starting are the ones where it actually happens.
The part the program design can’t fix
None of the above works if the firm treats mentorship as extra work added on top of a senior engineer’s real job. The cultural condition matters more than the program structure.
The firms where mentorship actually happens have leadership that values knowledge transmission as part of senior engineering work, not as something seniors do in the margins. Mentorship hours are treated as chargeable. Performance reviews recognize developing others as a form of contribution. Promotion criteria for senior engineers include some version of “grows the people around them.” Leadership models the behavior themselves rather than just asking for it.
The firms where mentorship doesn’t happen are the ones where senior engineers see expertise as personal capital to protect, and the firm hasn’t created any structural reason for them to share it. No program design overcomes that. A senior engineer who believes that what they know is their professional security will not transmit it through any structure you put in front of them, regardless of how well-designed the program is. The cultural shift has to happen first, or the program is just paperwork.
This is the part most firms get wrong. They add a mentorship program without changing the underlying incentives. The senior engineer’s billable utilization is still the primary metric. Mentorship is still extra. The program quietly dies after a year and everyone agrees that mentorship is hard to do well.
The firms that get this right don’t make mentorship a virtue. They make it a normal expectation of senior work, like quality reviews or client communication. Senior engineers who refuse to participate find themselves out of step with their peers, not lauded for being too busy to teach.
The bottom line
Your senior engineers are right that they don’t have time for the version of mentorship most programs ask of them. They’re also right that there’s a real gap between what they know and what their juniors can absorb. Both can be true.
The way through isn’t to add mentorship to their plate. It’s to design what mentorship looks like so it fits inside the work they’re already doing, and to structure the firm so it counts as real work when they do it.
The firms that figure this out preserve their institutional knowledge as a side effect of operating well. The ones that don’t are the ones where the senior engineers feel irreplaceable, and one day discover they were right.
