Training — Coaching When You’re the Expert
Coaching by the manager is a short-term, time-boxed facilitation of the efforts of the direct report in order to gain a specific skill.
Examples of coaching topics: giving feedback to direct reports, pivoting a table in Excel, reviewing code, TDD in javascript and stopping passive-aggressive messages.
As a manager, coaching is your duty and one of the basic tools, in fact, leverages, in order to increase results and retention.
It’s important to note that coaching is the facilitation of the process. The direct is doing 95% of the work. As I wrote before, your role comes down to:
- Collaborate on goals with the direct report
- Brainstorm on resources
- Collaborate on the plan
- Direct acts and reports on the plan
Training is the actual transfer of skills. It means you’re the teacher.
From TeachGoals — Kareem Abdul-Jabbar and coach John Wooden
Coaching — benefits to the team
- Performance improvement, whether due to better “soft skills” or functional skills
- Higher bus factor and business continuity — more people on the team can do more tasks, no bottlenecks or dependency on specific individuals
- Sharing workload
- Higher loyalty
Coaching — benefits to the individual being coached
- Grow a skill, become better, a new capability to bring more value
- Higher market value
- Feeling appreciated that the company invests in them
Note: coaching is different from mentoring. Mentoring is
- General, like “how to be a team lead”, “how to become a public speaker”
- An infrequent and long-term effort and relationship (over one year)
- Strategic
- Usually not done by the direct manager due to potential conflict (as a manager you can maybe help to find mentors)
What to coach on?
The most common reason for coaching is a gap in expected results.
Before starting any coaching, check with yourself and with the direct report, whether you have set expectations — you can ask the direct report to repeat them in their own words.
Then, check whether you have given positive and negative feedback.
Don’t assume others know exactly what and how to execute. Things need to be said.
Some specific reasons and opportunities for coaching:
- Failures on the job, e.g. how to handle an incident
- Gaps already identified in the interview for a new joiner, e.g. programming in Golang
- Hearing others complain about a specific topic, e.g. that their code review comments are aggressive
- A new skill is needed due to changes at work, e.g. a new technology or moving teams
- An upcoming promotion, that requires a certain skill, e.g. producing architecture diagrams
- An upcoming project that requires new skills, e.g. writing status updates to stakeholders
- Role/responsibility change, e.g. learn a tool when transitioning from manual QA to QA automation
- Direct requests, e.g. “I want to pioneer writing end-to-end tests here”
- Topics from 1:1s, e.g. “I wish I was better at handling pressure from stakeholders”
To extract information during 1:1, you can use the open-ended questions from the “ Coaching Habit “ book by Michael Bungay Stanier:
- What’s on your mind? — kickstart the conversation
- And what else? — get more potential insights and issues, address the biggest one
- What’s the real challenge for you here? — pinpoint the actual difficulty
- What do you want? — make sure the outcome is clear
- How can I help? — prevent falling into the “rescuer”, “victim” or “persecutor” role (Karpman drama triangle)
- What are you saying “no” to, if you’re saying “yes” to this? — make sure commitment is possible
- What was most useful for you in our conversation? — ensure learning and reflecting
How to execute the training
I mentioned that the role of the manager is to facilitate the process. This allows the manager to coach many direct reports on many topics without being a bottleneck.
But what about the case when the manager is the expert who can do the training?
Then one of the brainstorming ideas is the manager performing the training with the direct report. If it’s valuable and likely to succeed, it would be decided upon, and the manager will take an active part in the coaching, in this case, by doing the training.
If the direct has come up with the topic or request for coaching on their own, they understand the benefits and would already be motivated. If not, you first need to get their buy-in:
- Understand any issue or difficulty — when? with whom? how much? in order to address these concerns
- Show empathy (maybe you forgot how hard it is to learn something new)
- Smile — it’s the global invitation to cooperate
- Explain the benefit of changing behavior (to the team, to them) — paint the picture of the bright future after the change
- Use effective communication in accordance with their DiSC profile
- D — decisively and directly tell it’s what we’re going to do
- I — energetically put emphasis on the new skill that would help everyone
- S — explain how the new skill would support everyone and reduce the load
- C — show data about the necessity and usefulness of the new skill
Depending on the situation, use the following tools:
- Set a target date, otherwise, people tend to be forever “working on it”, as it has a lower priority than the “real work”
- Set measurable goals to remove ambiguity and subjectivity, that demonstrate the new skills
- Decide on the frequency of the coaching sessions and check-ins from the beginning, to prevent perception of micro-management and surprise
- Teach, the theory and practice of how to do and what is important
- Show, do the actual work yourself, so they can see
- Pair up, work together
- Let them do it and give positive and negative feedback. Acknowledge that the quality of their work will not always increase, there will be ups and downs
- Give assignments that exercise the required skill
More tips
Identity: when trying to change behavior, adopt the aspired identity rather than apologetic behaviors.
Examples:
“I am trying to quit smoking” → “I am not a smoker”
“I run here and there” → “I am a runner”
“I will try to get to it” → “I meet my commitments”
“I will try to test my own work” → “I am responsible for the quality of my work”
“I will try to not bully my teammates in code reviews” → “I am successful in getting my teammates to adopt high coding standards for readable code”
Anchoring: attach a desired action to an existing one.
Examples:
Forgetting to update the colleagues → Check follow-up items before each daily standup meeting
Forgetting to check emails → review emails immediately after lunch
Want to have impactful 1:1 for the direct → ask one open-ended question in the beginning of a 1:1 meeting
Indication: set indicators or signals, that once you spot them, it means you’re in the right direction.
Examples:
Meetings running over time → 3 meetings ended at or before the allocated time
Being late to meetings → 5 meetings in which you were the first to show up
Passive aggressive messages → 2 positive unsolicited feedbacks about the change
Training Case Study
Alex is a senior software engineer. Her manager, Julia, heard from other direct reports in 1:1s that Alex was bullying them during code reviews, in written form.
Julia went through some of the code review comments and agreed that they were not effective because they were aggressive and lacked explanations.
An example was “I expect a senior engineer to name variables better”.
The effect was low psychological safety, where team members asked other members privately to review their code in order to avoid Alex’s reviews. This created delays and the team didn’t learn from Alex’s experience and knowledge. Bypassing a team member is a clear smell that something is not right.
Julia used the feedback model. She asked Alex if she could give her some feedback and after Alex said yes, she told her: “When you attack members on code reviews and don’t provide explanations for the requested changes, the members avoid your code reviews, which causes delays, and they don’t benefit from your experience. Can you do better next time?” Alex was familiar with the feedback model and agreed.
Julia continued to go over the code reviews comments in the upcoming days and didn’t see much improvement. She used the feedback model again:
“When you attack members on code reviews and don’t provide explanations for the requested changes, the members avoid your code reviews, which causes delays, and they don’t benefit from your experience. What can you do better next time?”
Alex responded that she’d forgotten and promised to work on it, adding more explanations.
In the days that followed, her code review comments did include more explanations, for example about the readability of variable names, but were still very harsh and insulting at times.
Julia decided that it was time for coaching.
As Alex was a high D, Julia explained what they were about to do and discussed it with Alex who agreed that it was hurting her professionally.
In the first stage, they collaborated on the goals. They came up with 2, to be achieved within 8 weeks:
- Zero complaints and avoidances from other team members — a dramatic goal to ensure the new skill has been acquired
- Conducting at least one code review per day — to ensure that the lack of complaints is not due to lack of code reviews, and keeps sharing her knowledge
As for the identity phrase, Alex picked “I am a role model for code reviews.”
The key moment in the discussion was after Julia asked Alex what was her purpose with the comments, to which Alex replied “To get everyone to be better”. Julia asked if this had been effective so far, and then Alex realized that it wasn’t. She explained that she grew up in a strict environment, where you needed to insult someone in order for them to do better, but it didn’t work in the current environment, and maybe she even enjoyed showing how smart she was.
In the second stage, they brainstormed ideas and came up with several, here are the ones who were picked from the collaboration on the plan:
- No code review comment could be added without giving the reason
- Alex will do some reading about productive code comments
- Julia will pair with Alex on code reviews several times
Check-ins were to be had during weekly 1:1, where Julia would review some comments and get feedback from the other members.
The training part was the pairing, where Julia showed how she conducted code reviews, which had constructive feedback as well as positive feedback where deserved. This helped Alex think about encouraging better work in the future, rather than personal insults and vague feedback that made people feel more insecure.
Outcome: as Alex had the buy-in of what it took to be effective, the target was achieved already after 4 weeks and no further coaching or training was needed on this topic. Alex has become a role model for how to do code reviews.
