Being a Developer Coach - What I Learned.

When this role was entrusted to me, I wasn’t expecting it at all. Previously, I mostly did development work and some mentoring for junior and new employees who were starting at our company.

In essence, it was new territory for me, and I had to find my own way into it and improve my people skills so that I could help the people in my own coaching team.

How It Happened

Initially, we had a restructuring in the company, and new roles were introduced where we had two paths on which we could develop: as engineers and as managers.

In between, we had a new special role that was called a “Coach”. We didn’t get much context at first about what this new role meant, but anyway, I was awarded the Coach role at our all-hands meeting (to my surprise).

It was overwhelming at first to somehow fit in the new obligations to my new coachees, as I was now responsible for their professional and personal development, and also responsible for their performance. Some questions popped up in my mind, imposter syndrome shining through most of them. How do I qualify to help another person with their career when I often don’t know where I am going?

I have no idea

But as with any new skill, I had to dive deep and figure it out, find resources to learn from, and talk to other Coaches to get some insight into how they approached their coaching teams.

The Why

The reason for introducing this kind of managerial role for a company, from my understanding, is to have better visibility into a growing organization, where each employee in the company has a dedicated “Coach” they basically report to, while the Coaches report to the company top management. It’s essentially an Engineering Manager type role, with more focus on helping developers be and achieve their best.

✷ Here Are Some Processes and Methods I Used

✧ 1-on-1 meetings with each team member

One of the first decisions I made to start in this new role was to organize 1-on-1 meetings and get acquainted with each of my team members. Even though some coaches did the first meeting with all their coachees present, that style didn’t really work for my personality. I like to be able to focus on the person to get to know them. I also didn’t yet have a proven way to get things going, so 1-on-1 style better suited my situation as I could be flexible and change my approach based on a team member’s specific needs.

✧ Schedule regular checkups/syncs

After getting to know each person in my team, my second decision was to schedule a monthly meeting/checkup with them. The goal of this was to be able to get a sense of how they are doing on a particular project they are working on and if they have any problems we can discuss.

✧ Have notes

The next important point I realized is that it’s hard to keep track of the discussions and remember the things we talked about and decided on as action items. So ideally, it’s best to have a shared document with each coachee where you outline meeting goals and decisions or action items, so it’s much easier to stay accountable.

✧ Listen first

The whole point of coaching developers is to be able to understand where they are right now so that you can push them forward, and you can only find that out by listening and asking the proper questions.

  • What lifted you up in the past month, and what weighed you down?
  • What do you feel is an area where you’re lacking at the moment and would like to improve?
  • If we had a scale from 1 to 7, where would you put yourself in relation to a skill you would like to develop?
  • How can I support you?
  • Do you have any problems in your team? (more specific)
  • Do you feel like you can raise any concerns to your team or manager? (more specific)

✧ Set goals

It’s hard to move forward and know that you’ve made progress unless you have set goals and ways to measure them. So after a year in my coaching team, I tried to help my coachees set their goals for the next period. Initially, we tried setting the goals for the whole year, but it proved to be hard to fulfill most of the goals because of time constraints. So we trimmed down the goals to be achievable from the coachee’s perspective for the next 6 months.

✧ Be available

In order for coaches to trust me and share their concerns and problems, I think it’s key to just be available. My approach was always to get on a call, and often pair program and have the person describe the problem, where I act as an observer and ask questions. It’s an indispensable tool when doing any kind of mentoring in software development.

✧ Find motivation, switch things up

One of the things that I struggled with, even though my coachees were doing fine on all fronts, is just to find motivation and the why, because you don’t really know how much you’re actually making a difference in the person’s career. We can often get stuck in the regular schedule/agenda, and finding new areas to explore in our sessions is not easy. So my approach there was to ask and get a feel for how we’re doing, and if they feel like they have gotten some real benefit from the discussions. Also, another idea is to just ask the coachee what they would like to talk about.

In the above article, I tried to draw mostly from my own experiences as a manager for a number of developers. You can draw any conclusions from it, but I do hope it’s helpful to anyone starting a similar journey.

👋 If you have any comments or suggestions, feel free to reach out to me!

 Date: October 23, 2023
 Tags:  management coach en

Previous
⏪ Making network requests in React with useEffect, the correct way.

Next
My Side Project Journey - Building a Developer-Friendly Logging Tool ⏩