Balance: Teaching vs. Coaching

Posted by on Aug 11, 2011 in Balance | One Comment

This is the first in a series of posts about finding and keeping your balance as an agile coach or change agent. I introduced the topic as a main theme on this blog a few weeks ago in Spotting the Balance. At the AgileCoachCamp, I committed to writing a post on this every two weeks, and due to holidays in the meantime I’m starting now. My thanks to Gitte Klitgaard Hansen who has been constantly reminding me of that commitment…

I’ll start by roughly defining the “opponents”.

A Teacher

A Teacher - by Tim Ellis

What is Teaching?

This is easy. Enabling people to learn. That usually involves some elements of

  • giving them some sort of information (model, tool, technique…)
  • creating a safe environment for experiments
  • guiding them when they make mistakes
  • evaluating their progress
That’s enough for the moment, I don’t intend to give full definitions here or create a “teaching model”—I’m quite sure you can find that elsewhere. So…
A Coach

A Coach - by TheImageGroup

What is Coaching?

Coaching is assisting and guiding people to identify the goals they want or need to achieve, to spot obstacles that make it difficult to achieve them, to make out a path to overcome those obstacles and to verify that they stay on that path, so that they actually reach their goal. That implies a set of Don’ts:

  • Don’t tell them where to go
  • Don’t show them the obstacles
  • Don’t do their work
And as the primary goal is to enable the client to solve hir problems hirself, your primary goal is to make yourself dispensable as soon as possible. Which is probably true for a teacher, too… So where’s the conflict?

Agile Coaching

As agile coaches, we’re usually in a situation where we know more about Agile then our clients—that means we have experiences and a toolbox of practices that might help the clients to identify or reach their goal. The goal usually comes down to some variation of “building the right system right”—meaning they want to better identify what system to built, and to achieve better ways to build it.

Which leads to the challenge that while you let the clients define their goal and find their own path to reach it, they’ll constantly ask for your advice, your ideas… But you want to stay out of the way.

Notice there’s a main similarity and a main difference to a teacher:

  • Similar: the topic is set. If you attend a maths class, you don’t expect to gain knowledge about biology. When you hire an Agile Coach, you don’t expect hir to improve your resource management (nor your biology knowledge).
  • Different: as a teacher you generally have a predefined curriculum. As an Agile Coach, you have to help your clients identify their learning needs first. At least that’s how I understand our job.
So when you’re balancing teaching and coaching, you don’t want to spoil the one with the other. You need to meet the expectations of your clients to transfer knowledge, as well as your own responsibility to help them find their own way. Notice that failing in one way hurts much less than the other: if you coach while you teach, it probably intensifies the learning. But if you teach when you should be coaching… You might accidentally lead the client to go your way instead of theirs. This is what you want to avoid.


I think to manage this risk it pays to create a clear frame in which to evaluate your options. Your objective is to enable the client (be it the organisation, a manager, a team) to find their own solution. Solution to what? That’s your first thing to find out… So we’ll take this as an example to establish the concept of your Coaching Mode and your Teaching Mode.

Zoom in on the right problem

Let’s assume your client asks you to teach pair programming. Grabbing the right tool from your agile suitcase, you ask, Why? And depending on the answer, you might ask that question again. They tell you they need knowledge transfer in the teams, as there is a legacy system which only two out of many developers dare to touch, because it’s built on an architecture that is very different to the one everybody uses now, and barely recognisable anymore anyway… During this entire conversation you stay in Coaching Mode—you ask open questions, listen actively, thereby pulling the tacit knowledge of individuals out into the shared knowledge of the group.

At times, the conversation might get stuck, you get the impression that you’re rather talking around the real problem than about it. This is probably your experience, pattern-matching what you see and here with situation you’ve been in before. Sometimes, just asking another question might not be enough. Rephrasing what you’ve heard in your own words, trying to break their mental model with an example, can be a good strategy here. When you start giving examples, you enter your Teaching Mode.

“I think I’ve been in a similar situation, when I had to change something in a part of a system where the person who developed it wasn’t around anymore, and nobody really knew how it worked… What I felt I needed at the time was…” This lets the group leave their introspection for a while and gives them new information which they can use to reframe their own situation.

You then enter your Coaching Mode again and ask, “How is your situation different from my example?” This pattern you then repeat.

Switching Modes


Switch - by marceloilers

I think we can generalise for all the balance topics that you need to identify two Modes of Operation for yourself. In this case of Teaching vs. Coaching, the Teaching Mode and Coaching Mode. This is where your own learning takes place:

  • You need to define for yourself how you behave in each mode.
  • You need to sense which mode is required in any situation.
  • You need to decide how (and if) you want to make the group know that you’re switching modes. Remember that what they perceive and what you intend them to perceive might not be the same.
  • You need to hone your switching skills, so that over time it becomes natural to you to adjust your behaviour appropriately to the situation.


In later analyses of other areas of tension where you need to find and keep your balance, I’ll expand on these skills. To be successful as a change agent or agile coach, I think you need to master balancing in some of these dimensions, in the sense that you do not need to think about the modes and the switching anymore.
I expect to find other areas of tension which are risky in both directions: Challenging vs. Pleasing for instance is an area where peril lies in both directions (if you apply the mode that’s not appropriate for the situation). Whereas there will be areas which, similar to this one, can only “fail” in one direction. At first sight, work vs. free time seems to be an area where you do not loose from having too much free time… I’ll analyse this further in one of the next posts of the series. Stay tuned.

Knowledge Injection?

I realised two things while writing this post:

  • The usage of the teaching and coaching modes and the honing of your ability to switch between them is not specific to agile coaching, it’s certainly applicable to many teaching situations.
  • The resulting technique reminded me of BDD and deliberate discovery…

To pay respect to Chris MattsFeature Injection technique we could call this Knowledge Injection. Instead of pushing knowledge into the students, you pull the most important knowledge needs from the class, and inject knowledge using examples. This expands the mental model your students have of the problem domain and this model can then again be broken/expanded with more examples (or questions by the students that indicate more knowledge need). This leads to an Experiential Learning Cycle. I like that.


1 Comment

  1. Chris Matts
    August 11, 2011

    A couple of times people have said I should be a teacher (I think mainly so that I would leave the company we both worked at). I’ve allways objected to that name. For me a teacher sets the agenda and the time frame. I call it “someone who helps another person to learn”. First you create the demand and then they pull the learning they need.

    For example:

    How would you like to do releases every month?

    How do you do that?

    Well you need to automate all the repetative tasks.

    Like what?

    Testing, Deployment…..

    How do I do automated testing?

    With teaching you tend to start at the very beginning of the process…

    Lets do stories..


    Lets do TDD


    Notice that with “Knowledge Injection” ( Love the name. Feature Injection was a homage to Dependency Injection ), the learner is asking focusing questions ( How… ) whereas with the teaching approach the learner asks purpose questions ( Why? ). If you do not satisfy the learner’s “Why…” question, you may lose them or you are asking them to “believe” that what you are saying has value ( i.e. religion ).

    I prefer coaching as the learning is situational. “How do we address this issue”. How often have you been on a training course only to get back to the office and discover the problem you have is the tricky stuff that was mentioned at the end of the course rather than that basic stuff you learned using a game.

    So perhaps a coach should adopt coaching mode when asked “Why” questions and teaching mode when asked “How” questions.


Leave a Reply