Mentoring Engineers

Mentoring helps an engineer learn how to handle work they cannot yet handle alone. You provide context, questions, demonstrations, practice, and feedback. The engineer does the thinking and the work.

That last distinction matters. Mentoring is not a task handoff to the mentor. GitLab's support-engineering guidance tells mentees to prepare and state the problem, while mentors support learning instead of taking over. A mentor who always supplies the answer may finish today's task but delay the engineer's independence.

The working agreement

Start by agreeing on four things:

• Outcome: What should the engineer be able to do with less help?
• Evidence: What observable work will show progress?
• Cadence: When will you meet, practice, and review?
• Boundaries: What is confidential, what can be shared, and when should either person escalate?

The agreement is collaborative. Google's mentor guide recommends setting project goals, communication frequency, availability, feedback methods, and performance measures together. Clear expectations make feedback easier to interpret and give both people a basis for changing the plan.

A goal such as "get better at backend work" is too broad. Prefer an outcome connected to work: "design a small service change, explain its tradeoffs, implement it, and respond to review comments." Break that outcome into smaller pieces so you can inspect progress before the final result.

A repeatable mentoring loop