From Associate to VP: What Mentorship Actually Looks Like

Mentorship gets talked about like it’s a warm feeling. In practice it’s engineering work with a different output: people who can make better decisions than you do. Here’s what actually moved the needle.

The practices that worked

Write down the reasoning, not just the answer. When someone asks why a system is built this way, the durable gift is the decision log, not the pointer. Good mentors leave the why behind in a form others can find.

Assign ownership, not tasks. Tasks grow a todo list. Ownership grows engineers. Let a junior own a feature end to end, with you as the safety net rather than the doer.

Review for growth, one theme at a time. A review that lists eight nitpicks teaches nothing. Pick the one thing that would move quality the most for that person and make it the theme until it sticks.

What didn’t work

The “catch-up” meeting with no agenda. A standing hour with nothing to talk about is a box you tick, not mentorship. If there’s no real material, cancel it and save the attention.

Doing it for them. Every time you quietly fix the code instead of handing back the problem with guardrails, you teach a dependency. The slow path is the fast path.

The model that sticks

Code quality is downstream of people. Delivery velocity too. Invest in the decisions people make when you’re not watching, and the systems they can run, and the velocity follows. Mentorship isn’t a favor you do — it’s a multiplier you build.