Mentoring does not scale, and that is the point
The advice for growing engineers is usually to systematise it. Most of what has actually worked for me does not survive being turned into a programme.
Every leadership framework wants mentoring to scale. Office hours, brown bags, a mentoring programme with matched pairs and a tracker. The instinct is understandable — it is the only way to reach everyone — and the results are usually thin.
What has worked for me is narrower and less efficient. Sitting with one engineer, on their actual problem, working through the decision instead of the answer. Not because I have a theory about it, but because people are different enough that the useful thing is almost never general. One engineer needs the confidence to push back on a design. Another needs to be told, kindly, that the design is fine and the anxiety is the problem. Broadcast advice reaches both and helps neither.
The cost is real. It does not scale, it competes directly with delivery time, and there is no artefact at the end to point at in a performance cycle.
What I have settled on is a split: enforce the things that genuinely generalise at a boundary — a shared component library, policy at a gateway, a review standard — so they hold without anyone remembering them, and spend the human time on the part that does not generalise. Systematise the mechanism, not the relationship.