The Coach is the Key, not the Answer

I’ve been working in the IT business over four years, long enough to have met many people telling me what to do… all kinds of different Project Managers, Team Leaders, Vice Presidents, you name it. They were telling me not only what to do, but also how to do it. So I naturally gravitated to that approach as I advanced into lead positions myself. Participating in Agile Coaching Master Class training opened my eyes and helped me to realize that a correct approach in talking to people can actually solve situations more easily than just yelling out orders, which is what I was doing. I was thinking that if we use my solution, it would be the best in the world. Well, now I know I was wrong.

The very first point that I would like make (and I bet that many people will not continue reading this article after this point!) is that you should finally admit that you, as a coach, are not the smartest person in the room. It is totally fine to have just a brief knowledge about a topic under discussion. Your task as a coach is to help find solutions or help to pick the best one if the person (team) is unsure. Notice the very important word “HELP”. It is not your task to create those solutions yourself. Rather, you should encourage people to find solutions themselves. Trusting your team is the key to success.

A coach should help each team member express how he or she feels about the problem. (We all know that is sometimes very hard, especially with people from IT.) This can be achieved by asking the correct question at correct time, and helping developers realize the meaning of the problem. (What is the problem? In what way is this problem to you? What do you think is the reason it is happening?) By asking well-directed questions you can help the developer to actually start thinking about the problem and how he or she can solve it.

A coach should also help developers split a problem in to smaller pieces. I have experienced many times that a developer has approached me with a problem that he or she could not find solution for. Usually it was because they were trying to “eat the whole elephant at once, instead of one bite at a time”. We took that problem and broke it into 4-5 smaller problems and started solving each smaller problem separately. Magically the “big problem” was not so hard as it seemed to be at the beginning, and the developer learned exactly how to solve each problem (the small ones), and combining them, he solved the problem he had when he approached me.

But bee careful here: the coach should never do the work for developer. You should not be the manager here. Saying “first do this, second do this”, etc. is not helping. You should let the developer find the solution him/herself, by asking the right questions. For example, what is the first step you should take? If that works, what would you do after that? The developer then starts breaking the big problem into smaller ones that he can easily solved.

Another very good approach is to let the developer realize how it will look when the problem is solved. This is something that is called “miracle questions”. Asking questions like, “Close your eyes and imagine that you come to work and your problem is solved… what would that look like?” Asking this kind of question helps the developer to realize what the solution looks like and what he or she has to do to realize the vision.

Another important role of the coach is to lead a conversation. Each coaching session (or I think even regular discussion) should have its purpose. The coach’s duty is to keep this purpose in mind and, if the coach thinks that the topic is slipping away, put it back on track. If need be, the coach might go so far as to change the purpose of the session, of course letting people know about that. Developers in general can spend hours and hours talking in circles. You as a coach should keep the discussion on track and hold people to the purpose of the coaching session as you agreed in the first part of your conversation.

Above all, a good coach should be a good listener. You don’t have to be the smartest person in the room. In fact you don’t really have to understand all the technical details at all. Your only job is to ask the right questions to find the best answer in your developer’s head. Because, most of the time, it is there. He or she just doesn’t realize it.

About author: Martin Popelak is Scrum Master and coach at Polarion Software.

More about Agile Coaching Master Class here.

.