Developer Evangelism: Mentoring and Coaching

1. You are here:
2. Handbook
3. Marketing
4. Developer Relations
5. Developer Evangelism
6. Developer Evangelism: Mentoring and Coaching

Maintained by:

On this page

• Introduction
• Mentoring
  • Finding a mentor
  • Resources
  • Topics
  • Tips as a mentee
    • Resources and plans
    • Learning a new technology
  • Tips as a mentor
  • Collaboration
    • Schedule regular chats
    • Learn together in public GitLab groups and projects
    • Talks and Call for Papers
• Coaching
  • Coaching Areas
• Feedback
  • Getting Started with Cloud-Native Help

Introduction

This handbook page documents best practices how Developer Evangelists can help wider community members with mentoring and coaching.

Mentoring

Finding a mentor

GitLab Developer Evangelists actively engage with mentoring wider community members. The team's time is limited with our many activities, please understand when we decline a request. Polywork and other platforms can help finding mentors.

Resources

• Review the process and tips in Mentoring at GitLab
• How to be a mentor: 4 ways to change someone’s life

Topics

If the career path is to becoming a Developer Evangelist, the Developer Evangelism handbook provides many resources.

Engineering and coding sessions depend on the knowledge and focus area of the mentor.

Other examples are:

• Open Source contributions, code reviews, building communities, etc.
• Personal brand, thought leadership, speaking, content creation, developer evangelism

Tips as a mentee

1. Share career ambitions and thoughts where you want to be.
2. Think of your personal challenges, and ask for familiatities and advice
3. Create a tag cloud of topics you'd like to ask your mentor in the future (Observability, Cloud-Native, etc.)
4. Take notes (pen and paper, whiteboard with post-its, GitLab issues, Notion, etc.)
5. Ask questions, share notes and code

Resources and plans

1. Define time commitment, and how much you can invest into the mentorship.
2. Document your learnings, and become a future mentor yourself.

Learning a new technology

1. Define goals ambitiously but do not overload yourself
2. Recap what you have learned, write a monthly blog post and use other methods to document your success and learnings
3. Adjust the goals if they feel reached too early.

Tips as a mentor

1. Define your knowledge and set expectations.
2. Define goals and success.
3. Listen with empathy, cheer and encourage.
4. Discuss career and learning goals and progress.
5. Take action
   1. Burnout: Feeling tired, not sharing good vibes, only work topics, etc.
   2. Blockers: Ask for the problem and google together in a screen share.
6. Provide access to resources and people.
7. Turn learning sessions into fun pair programming and optionally record for later.

Document feedback and learnings in the handbook.

Collaboration

Schedule regular chats

Make it a coffee chat with an agenda, following GitLab communication best practices.

1. Offer a monthly chat, for example on the first Tuesday of the month, time XY.
2. Create a 1:1 Google doc with an agenda
   1. Document all URLs shared in the chat, share async "as you see them"
   2. Write down thoughts and ideas

1. Good vibes 
1. Asks
1. Discussion
1. FYI

Learn together in public GitLab groups and projects

• Create a public group and projects for code snippets, learning projects, etc. in the EveryoneCanContribute DevRel group on GitLab.com
  • Organize learning activities in a group epic for one year (example for FY24 (Feb 2023 - Jan 2024)).
• Re-use best practices from Developer Evangelism workflows
• Use GitLab for learning technologies, practice CI/CD and DevSecOps, and create talk demos

Example in FY23: Julia Furst Morgado changes careers to learn DevRel, related technologies (cloud native, Kubernetes, etc.) and CFP talk submissions.

Example in FY24: Aakansha Priya learns DevRel, works on Linux, container, Kubernetes, cloud-native topics, and learns the DevSecOps journey. Created epics and issues to organize tasks and goals:

• Events and CFPs epic
• DevSecOps journey epic
• Cloud-native journey epic

Organisation:

• Maintain a templates project for the DevRel group, which provides issue/MR templates in a single source of truth.
  • Edit new projects in Settings > Default description template for issues with the following text: <!-- Please choose a description template from the dropdown above to continue. Accept to override this text. -->

Talks and Call for Papers

Start drafting talk ideas in a dedicated Google doc for each topic, and discuss the story and technologies in 1:1s. Add thoughts async, and share suggestions directly.

Organisation and workflow tips:

1. Create a calendar with events in the coming year, and keep track of Call for Paper due dates. Use cfps.dev by Brendan.
2. Copy the Developer Evangelism CFP workflow with issues and scoped labels into a new group/project for CFPs. Example for KubeCon EU 2023.
3. Add issue references to Developer Evangelism CFP issue tracking to coordinate efforts.
4. Review the talk title and abstract in the Gdoc async or sync. As a mentor, change to suggesting mode in the Gdoc and provide suggestions with all thoughts. Encourage the mentee to review the suggestions, and accept if reasonable. This workflow will enable mentees to take feedback from everyone in the future.
5. Encourage social shares when the CFP has been submitted. Start without the talk title, later encourage to add the topic that has been submitted. Example from Julia Furst Morgado in this tweet for KubeCon EU 2023.

Tip: Talks are stories that evolve each time they are told. Think of a rock band giving a concert, each song is a little different when played live. The same applies to a talk story - iterate on talk questions and feedback, and also add new learnings and technologies over time. Events that accept a talk do not have the same audience and new folks can learn from talks.

Events and CFP forms collect different information, and also have different character limits for abstracts, etc. Iterate on collecting all details in a Google doc for the abstract as a single source of truth.

• Context (inspiration sources, other talks, community feedback)
• Submissions (list of events with URLs into CFP issues, acceptance state with emoji)
• Title
• Abstract
  • 1000 chars (fits KubeCon)
  • Less than 900 chars
  • Less than 700 chars
• Ecosystem benefits (KubeCon)
• Knowledge required
• Learning goal
• Open Source Projects
• Track
• Bio/CV (add URL to speaker's SSoT website/Gdoc)

Use these templates:

• CFP template Google doc.
• Biography template Google doc

Coaching

Mentoring usually happens in 1:1 conversations, building trust and relationships, with optional public sharing. Coaching can happen in private and public, and can involve different types of short or long term help.

Engage with public replies in Twitter threads, LinkedIn posts, etc. and offer coffee chats or private conversations to wider community members who seek for advice. Listening to the story and plans helps with making suggestions efficiently, and builds trust and relationships too.

Coaching Areas

Developer Evangelists are encouraged to help with

• Review talk abstracts and slide decks
• Social media best practices
• Help with advice on detecting and preventing burnout
  • Twitter Thread as a response to the question How do I know when I'm showing signs of burnout?

Feedback

Getting Started with Cloud-Native Help

Getting started in the cloud-native community with a huge landscape of tools to understand can be overwhelming. Learning technologies and frameworks, from Kubernetes to beyond, requires guidance and a plan for individual growth.

Michael had a coffee chat with Edidiong Asikpo who started her cloud-native journey as Developer Advocate at AmbassadorLabs in 2021. They discussed a learning plan as a DevRel in cloud-native, and shared ideas on demo deployments, learning with Observability, and also looked into the Developer Evangelism social media handbook.

In 2022, Edidiong shared her promotion to Senior Developer Advocate, responding to Michael's wishes:

The conversation we had when I started my journey in the Cloud Native space gave me the context I needed to learn and improve my skills. Thank you.