KIND Mentoring Scheme

Authors
Affiliation

KIND Network members

Brendan Clarke

NHS Education for Scotland

Published

August 22, 2024

Draft guidance

This is currently draft guidance, may therefore contain errors and omissions, and is liable to change

We run an informal mentoring scheme. It’s designed to support professional development, by putting together mentors and mentees to work on a well-defined project over about 8 weeks. The scheme operates entirely by mutual consent, so participants are free to leave at any time. We think the benefits are reciprocal, with both parties gaining from the work.

Why mentoring?

For mentees

  • an opportunity to get support and guidance that might not be available in your workplace
  • an efficient way of putting skills into practice
  • build your professional network

For mentors

  • pass on your skills and knowledge to the wider community
  • to strengthen your understanding of a topic - think of mentoring as a variant of the Feynman method
  • to develop new professional skills, particularly skills relevant to more senior roles such as management, personal development, and community building

Mentoring projects

  • help me turn some R code into a package - specific and achievable
  • support me through a first literature review - sharing expertise
  • I’ve just done a course on x, but need some support putting x to work in y - supporting areas not well-covered by other means
  • teach me how to code - open-ended projects aren’t a good fit for an 8-week mentoring arrangement
  • advise our organisation on x - mentoring isn’t consultancy
  • I need someone to encourage me to work harder - mentoring isn’t cheerleading
  • my spreadsheet is broken - focal requests for assistance would be better asked on the KIND network

How it works

graph TD;

request["Mentee sends a project outline"] --> mentorfinds["Mentor finds a suitable project outline"]

mentorfinds --> email["Both discuss by email"]

email --> meeting["Informal meeting to set goals and expectations"]

meeting -->  contract["Sign contract"]

contract --> complete["Complete the mentoring project"]

complete --> present["Present the project at the mmmmm"]

  1. a mentee puts a request on the KIND Teams channel by filling in the new project form

  2. a mentor sees the request on the Teams channel, and expressed interest in mentoring)

  3. we put the mentee and mentor in touch by email to discuss the project

  4. mentor and mentee meet to agree a broad outline for their mentoring arrangement

  5. both mentor and mentee sign a mutual-consent contract

  6. we help and support them through the duration of the scheme. Either party can withdraw at any time without fault

  7. we invite mentors and mentees to come and present their experiences at the monthly mentoring meetup

Key documents

What makes a good mentoring project?

  • successful projects are generally short and simple
    • short meaning they can generally be finished off during the 8 week mentoring scheme
    • simple meaning they don’t depend on a lot of new infrastructure, require organisational change, or need an mentor to gain an unrealistic range of new skills
  • successful project proposals should therefore be short and precise
    • what are you trying to do?
    • how are you trying to do it?
    • which barrier(s) do you have in place?
    • what do you need a mentor to do?
  • successful projects aren’t about cheerleading
    • we’d expect mentors to provide largely technical advice: “have you considered using x”
    • we do not expect mentors to provide detailed technical training
    • we specifically preclude mentors giving detailed technical advice regarding systems. Mentors are not consultants.

What might I do instead?

If your project doesn’t fit this scheme, consider: