“The effect you have on others is the most valuable currency there is.” — Jim Carrey
At some point in your programming career so far, you might have been asked to “coach.” Most programmers get into the field to write code, and often before we know it, we end up in a leadership role, almost as if by accident.
Only a few months into my first job I remember telling my boss that I felt like I was teaching a lot. I’d like to say it was a natural inclination towards teaching, but I don’t think that’s it. Because of the nature of the field of technology, teaching and coaching others is an inherent part of what we do. Even if we’re really new to the field.
Coaching might not be perceived by most developers as a “required skill.” But programmers who do have the aptitude, patience, and willingness to coach have an untapped superpower. If you are willing to use that superpower to help others on your team or at your company grow and develop, you will stand out from the crowd. In addition to working with a more cohesive and happy team and increasing your own job satisfaction, being a coaching hero means you are more likely to get recognized for your work and maybe get a raise (or two!).
Even superheroes need a plan. If you’re going to be a coaching hero, there are a few simple things you need to know to do it well. I’m going to give you a plan — a cheat sheet, if you will — with everything you need to know to coach your fellow programmers.
But I Can’t Coach. (Right?)
Maybe you’re a little skeptical, thinking that you don’t know enough to coach. Coaches have to have years in the field, or multiple degrees, or something like that. If you think this way, you’re not alone. A surprising misconception about coaching is that you need to know everything about a subject first. In reality, you don’t.
And yes — you did read that correctly. I’ll say it again because it warrants the emphasis: You don’t need to know everything about the subject area in order to coach. I hope I haven’t confused you, but in case I did, let’s look at what a coach actually does.
A coach is someone who is armed with one weapon only: Questions.
Coaching Programmers Using the Socratic Method
I first discovered the Socratic method when I worked for the technology mentoring company Thinkful. In their mentor welcome pack, they talked about something called The Socratic Method. I’d heard of it mentioned before in programming talks but hadn’t really understood what it was about or why it was relevant to programming.
The Socratic method of teaching means to teach via questioning. Rather than answering questions directly, you guide the individual by asking questions that force them to think through the problem themselves. It takes an element of self-restraint to hold back on trying to give advice but to instead guide the other person. To understand the Socratic Method better, let’s take a look at an example:
Coachee: “I have been trying to solve this bug; do you mind giving me a hand?”
Coach: “Sure, why don’t we start by telling me what you’ve tried so far?”
Coachee: “Okay, I’ve been writing this function that multiplies two numbers together.”
Coach: “Right, and what else?”
Coachee: “Well, I expect it to return the number, but instead it returns a weird string error: NaN.”
Coach: “Okay, and do you know what NaN is?”
Coachee: “Er, I’m not sure.”
Coach: “Okay, well if I told you it was an acronym and that one of the words is ‘number,’ would that help?”
Coachee: “Not-A-Number!”
Coach: “Right! And do you know why it might be throwing that error?”
Coachee: “Ah, the second variable is a string, not a number, so when they’re added together it returns NaN — that’s why it’s erroring!”
In the example, you can see that the coach didn’t jump in and solve the problem for the individual. Somewhat counterintuitively, when we jump in to solve problems it can create a sense of reliance in the long run.
The goal of a coach should be to liberate our co-workers so that they can do their job, not make them rely on us to be there all the time to solve all their problems. It might feel nice to be the go-to guy for a little while, but when you’ve got an army of 20 junior developers bombarding you with prods and Slack messages, you might come to regret what was a well-intentioned effort at helping.
This method isn’t just a better way of teaching; I’ve seen entire businesses grind to a halt because individual programmers “solved” problems for other programmers rather than liberating them to solve their own problems. In programming, this human-bottleneck is called Brent, after the character in the famous novel The Phoenix Project who is called in to firefight every problem. Brent gets burnt out, disgruntled, and becomes not such a great guy to be around.
Be smart — don’t be like Brent.
Two Types of Coaching
I like to think about coaching as two different types: coaching for development and coaching for performance.
Coaching for development is the slower type of coaching. Coaching for development is focused on developing long-term skills and relationships, and it usually happens in a one-to-one setting.
But it doesn’t always have to be that formal. The more intuitive you get with your coaching, the more you’ll see opportunities in your everyday routine. It’s the little moments, like walking to lunch, during a code-review, or following a meeting that you might get a chance to flex your coaching muscles. The informality of these situations can even play into your favor as the person you’re talking to might be so at ease they don’t even realize you’re practicing your coaching Jedi-mind tricks.
The second type of coaching, performance coaching, is more spur-of-the-moment. You’re giving one-off bits of feedback. These are less strategic in approach and more tactical, like a real-time correction of the rudder of a ship when it might have drifted slightly off course.
A real example of this type could be giving a colleague feedback on their sprint demo straight after it’s happened. Or it could be giving feedback on how they dealt with an area of confrontation.
And now for the promised cheat sheet, which will help us with both of these types of coaching.
Your Five-Question Coaching Cheat Sheet
Okay, I’ve brought you with me this far, but now we’re going to have to do some strategic borrowing for our cheat sheet. To borrow Isaac Newton’s words, we’re going to have to “stand on the shoulders of giants.”
Standing on the shoulders of giants is precisely what we’re about to do. Whose shoulders? That of coaching extraordinaire, author, and owner of coaching company Box of Crayons, Michael Bungay Stanier. In his book, The Coaching Habit, Stanier lays out seven strategic coaching questions we can use to become better coaches. Today we’ll look at just the first five.
I’ve used these questions in everyday interactions and also in one-to-one sessions with the developers that I coach.
And remember, you don’t need to be a lead developer, manager or even a subject matter expert to use these questions. The best part of coaching is that anyone can use these questions. And once you know them all you can experiment and get creative in how you apply them.
Without further ado, let’s get to it!
Question 1: What’s on Your Mind?
This question can be a great opener to a one-to-one session. Asking what’s on your mind gives an element of freedom to the individual you are coaching to express what they feel is important. It’s not a loaded question that’s going to steer them toward a certain answer or confine them to one topic area.
If you’re not in one-to-one coaching, the question is still good for understanding the frustrations of your co-workers. When you know problems that are frustrating those around you, you can be proactive in helping out.
The question might evoke the response: “Oh boy! I’ve had the worst week so far; I’ve been given this feature, and I have no idea where to start. I’ve only been here a week and they’re expecting this to get done by Friday. It’s really starting to worry me!”
When you get insights like this example, you can use them to nudge your other colleague toward solving the problem with you. For example, you could let one of the other programmers know that the new person is struggling and see if they have time to offer to pair program.
If you’re not the lead developer, you might be thinking: “But this isn’t really my job, is it?” and maybe it does seem like a fair bit of effort. And if I’m honest, this thinking is technically correct; it is a little extra work, absolutely. But, we’re not in the business of doing just our job — we’re in the business of doing the best for our teams and our colleagues.
Working above and beyond is what gets us noticed and rewarded, with the added bonus of doing it through work that’s fulfilling.
Question 2: And What Else?
Sometimes what’s on your mind isn’t enough. The first thing that comes to mind might not be your colleague’s root problem. That’s where you can use what Stanier calls the AWE-some question which is and what else? This method prevents our knee-jerk reaction to jump in and try and solve any immediate responses.
We have to keep in mind that coaching is all about being Socratic and taming our advice monster, instead choosing to guide through inquisition.
You can ask this question a few times to get deeper into someone’s thoughts and concerns. When you ask someone what’s on their mind, they might say: “I’m just wondering about whether I want to implement this module with the Factory pattern or the Singleton pattern.” You might be tempted at this point to jump in and download all your design pattern knowledge into the brain of this unsuspecting colleague.
But holding off and asking and what else can lead to more insight and hopefully to them reaching a conclusion on their own. They might respond: “Well, actually I’m confused mainly because I’ve noticed Sarah really likes the Singleton pattern whereas I know Sam doesn’t; maybe it would be worth discussing the pros and cons to decide on a pattern that makes our code more aligned.”
You can see here that by giving someone the breathing space, they can then solve their own problems.
Coach 1 – Problem 0.
Question 3: What’s the Real Challenge Here, for You?
By this point, you might have dug a little too deep, and now you’re drowning in problems that your colleague has now confessed to you. Whilst therapy can be calming, our role as a coach is to help guide the person towards solutions, not encourage mindless gossip about potentially grumpy colleagues. Consider the following scenario:
“Well, I’ve been having difficulties speaking to Craig, our product owner, the tickets he writes are so vague — I’m a details person, I just need more details.”
…And what else?
“And I’m not really sure if I’m even in the right role in this team anyway; maybe I should think about moving to a team where there’s more detail.”
…And what else?
“Well, the commute is such a pain. It takes me nearly two hours to get into work each day!”
Okay — by this point we might be veering into the woods, possibly an existential crisis, and something ultimately out of our remit as a programmer. To get back on track, we can subtly drive the conversation by asking what’s the problem here for you?
By asking this question, we encourage the person to pinpoint a specific area. This area might be that they’re struggling to get the appropriate level of instruction from someone in their team. With this knowledge, we can then try and encourage them to think of different ways they can solve this problem.
Adding “for you” to the “and what else” question prevents the focus from moving on to things that we can’t control, like external events and people. And as a coach, we can only coach the person in front of us, and unfortunately not everyone in the company.
Question 4: What Do You Want?
A deceptively straightforward question: What do you want? As a coach, we want to empower our colleagues to make changes — to be in the game playing, not on the sideline judging. That’s why it can help to ask the question: What do you want? Or a similar alternative: What are you trying to achieve?
If we’re coaching with a programming problem, sometimes it can help to take a step back and ensure that we’ve got the goal in mind. Especially for those new to programming, when we’ve got quite a few code functions working together, it can be easy to lose track of the bigger picture and what we’re doing. By asking what are you trying to achieve, we can help guide the programmer to think more about the end result and take a step away from the detail for a moment.
Question 5: How Can I Help?
Lastly, it can be important to extend an invitation to help. After all, so far we have just been digging for details. It’s good to remind them that we are available to help, if necessary. It might be that simply by asking this question the person we’re talking to replies, “No, that’s fine — I’d like to have a few more attempts at fixing the bug first. But if I’m still stuck, I’ll send you a message?”
Just offering the support is all that is needed sometimes to remind our colleagues that we’re there should they need us. It’s a small gesture, but it often goes a long way.
Choose To Be A Coach
With these questions as a guide, it should give you the confidence to see yourself as a coach — which you are, if you simply choose to be. Coaching is an ongoing skill. And it’s one that we can practice every day until it becomes a habit. We just need to tame our desire to give advice and simply ask a little more instead.
And lastly, don’t forget that the most liberating thing about coaching is that you don’t need to know everything. Sometimes all it takes it to get someone to think out loud, and they’ll find their own way to a solution. So get going; you already have what it takes.
See you on the field, coach.
| Published on Java Code Geeks with permission by Lou Bichard, partner at our JCG program. See the original article here: How to Coach: A Programmers Cheat Sheet Opinions expressed by Java Code Geeks contributors are their own. |
