About three months ago, I was assigned as a mentor for our new intern on the team. He will join us for about six months as a software engineer intern with a specialization in the backend. Basically, a backend engineer intern. To add more context, he is basically a highly motivated (senior) college student who wants to give a quite impactful contribution. In the last three months of working together, I learned lots of things. I finally understand that managing another (soon to be) engineer is quite challenging. Why? Well, because I don't want to let him down! We are trying to accommodate his goals while keeping him on track. I mean, as a mentor, I want to keep him motivated by giving him what he wants while also making sure that he contributed to our backlog which sometimes (or maybe often) is not to his liking. I also need to make sure that he gets something to learn from. Meaning that giving him repetitive tasks is a no-no.

Anyway, this is a journey of mine who want to be a good mentor.

Prelude

First of all, before trying to manage someone else, I need to be able to manage myself. In my free time, I often look for a way to improve my way of managing myself. Then, I remember something like "self-governance" and look for anything that may help me. Finally, I get to know about the Self-Governance Developer framework (SGD). This framework separates activities into several steps. The steps are:

• Pre-Work Activities
• Work Activities
• Post-Work Activities

Each step contains several subactivities. The complete steps are:

• Pre-Work Activities
  • Preliminary Activities
  • Planning Activities
• Work Activities
  • Preparatory Activities
  • Coding Activities
  • Testing Activities
  • Evaluative Activities
  • Debugging Activities
• Post-Work Activities
  • Self-Assessment Activities
  • Delivery and Sign-Off Activities

Although I said that those are the steps, they are actually pretty flexible. I mean, you can include/exclude some steps or even change the order. Only use anything that is necessary. We also need to create an SLA for ourselves. Something like, let's say, "I will finish at least 80% of the work today." What about the rest? We can carry it to tomorrow. The point is that it helps me to be more focused and more efficient.

Since I have on-call rotation, I add a new activity namely "Inquiry Activities" and put it under the "Work Activities". This is so I can help anyone that mentioned the "on-call" group later if it is not urgent. Anyway, if you are interested to learn more about SGD, just search it on the internet and then read the paper.

Now, I can finish my job just fine. I'm ready to get more challenges!

What We Want as an Intern?

Before he on board, I had a throwback of when I'm an intern. I'm trying to remember what I want as an intern back then and what I actually get. I also think of what good and bad things I experienced. Assuming that he is just like me, I already know what he wants. I'm then able to list what I can offer to him later when we have our first one-on-one.

Since people are different, in our first one-on-one, I asked what he actually want to do. I want to know his wishful thinking. Fortunately, he is just like me. To summarize, he hopes to achieve these:

• Able to learn lots of things. Specifically, something that can't be found on an online course.
• Able to give a significant contribution.

Those two summarize everything. Now, I need a way to give him more diverse tasks. I also need a way to give him more tasks of high importance and show him something interesting. Toy projects, fixing documentation, working on technical debts, and easy bug fixes are out of the question. We may still give it to the intern. However, we need to control the frequency of those tasks.

Long story short, I kinda know what I need to do for the following months.

Documenting His Journey

I want his internship with the team to be meaningful. I want him to feel appreciated. I want to give him my utmost guidance. That's why I created a special Confluence page just to document his journey. I named it "Internship Journey" with his name on it. I want everyone to know his amazing work. I also put his onboarding journey with many checklists. Making sure that everything he needs should be completed as soon as possible.

To make it more interesting, I also add a template that is shown in the picture above. I want to list every amazing work that he has done. By doing this, everyone on the team will aware of his achievements. He might as well join as a full-time software engineer after he graduates! I believe this will makes it easier for him to join us later since everyone already knows his work.

Keep in Touch

Basically, I try to regularly ask how is he doing. I always tell him to reach out whenever he needs something. I want him to feel free to do so! By doing this, he won't feel reluctant to "nag" on me which is good. I usually chat with him through Slack. If I deemed necessary, I will ask him to join a meeting and have a conversation.

Show Him How

In his first month, I showed him anything that is necessary. Starting from how we setup our project to how we use our internal tools. I also explained how is our workflow, pipeline, backend service release, JAR release, SQL release, incident mitigation, and many more. This should fulfill his second wish, to learn lots of things that are not available on the online course. After all, you get to experience the real thing. Something like "incident mitigation", where should I get that from? I legit invited him to our incident mitigation meeting to let him know how we handle and mitigate the incident.

Actively Reviewing His Work

As an intern (more like as a mentee), you want to know which work of yours should be improved. Or is it just me? Anyway, whatever the tasks are, as a mentor I need to review his work. Make sure that his work is high quality that can be accepted by the other team members. If it is code, for example, it should follow the agreed code standard, have acceptable performance, and be secure enough.

Keep Him Motivated

In my opinion, the hardest part is to keep the intern motivated. I already know what he wants. I just need a way to accommodate most of it. Even better if we can accommodate all of it. But well, in this case, it was quite hard. I decided to just mix his tasks. Here is the list of easy tasks that may not be to his liking:

• Implement unit tests.
• Trivial (easy) bug fixes.
• Update our documentation.

As for what he would like to do, here is the list:

• Do an experiment or exploration.
• Own a project (becomes the project PIC).
  • Writing a technical design document from scratch.
  • Designing his own idea.
• Code (including SQL query) optimization.

By looking at this list, I decided to mix his tasks for each sprint. Or maybe give him trivial tasks after he finished the hard tasks he has the time to cool down. Because we also need to maintain his sanity. Make sure that he won't be burned out.

For the experiment/exploration task, I asked him to do some research regarding the PostgreSQL index for full-text search. He kinda loves this task. The result is really great. As for owning a project, so far I give him two projects. The first project is ready to be released. As the second project, he just started it. I can see his excitement when I say that I have another project that I can give him. A quite impactful project in fact. This second project will be used widely by the engineers in our product. Sorry, I can't tell you the detail since it would be a confidential matter. Anyway, the point is if we give the intern a boring task too often, it will make him demotivated. So, be careful!

Own His Mistakes (and Protect Him)

Like it or not, as mentors, we partially own the intern work. Meaning that his mistakes are partially my mistakes as well. That's how people see it. What should I do as the mentor? Blame him? Gaslight him? Of course not!

Let's say that he made a mistake. His work somehow resulted in an incident. When people ask about it, first let the intern answer it. If he was able to communicate just fine, let it be. Otherwise, take over and help him answer the question. Then, offer a solution and then mitigate the incident. Finally, tell him that it is okay since he is in the middle of learning.

Closing Statement

Managing people sure is hard. We need to manage ourselves and also manage others. To make it happen, I need to use a certain platform to note everything. In the context of an internship, I think one mentor should be assigned to one mentee only. This is so the mentor may fully focus on tracking his mentee's growth.

That's my journey so far. I know this writing is kinda unstructured. Apologize for that. I need to post this soon since my finger is itching to write and publish something. I hope next time I can post better writing than this. Thank you for reading. See you later.