DEV Community

Cover image for Sum up: The Coaching Habit
Flavio Wuensche
Flavio Wuensche

Posted on • Updated on


Sum up: The Coaching Habit

This is a summary of The Coaching Habit written through the eyes of an Engineering manager in 30-min.

The main sources were my highlights from the book itself and an interesting article I've read in which the author adapted some questions of the book:


My favorite one:

The single biggest problem with communication is the illusion that it has taken place.

First things first. Be comfortable saying no:

It doesn’t matter if you’ve mastered all the productivity hacks in the world; the faster you dig, the faster the world keeps flooding in.

Block defined an adult-to-adult relationship as one in which you are “able to ask for what you want, knowing that the answer may be no.”

About asking open questions:

be comfortable with the silence, stop planning the next question, follow-up with "and what else?"

Optimize for usefulness (get off firefighter mode):

Coaching for development is about turning the focus from the issue to the person dealing with the issue, the person who’s managing the fire. This conversation is more rare and significantly more powerful.

Call them forward to learn, improve and grow, rather than to just get something sorted out.

About starting 1:1s with a direct open question:

Cut the preliminary flim-flam. You don’t need a runway to pick up speed—you can just take off.

About running your 1:1s:

Tell less and ask more. Your advice is not as good As you think it is.

When you start your weekly check-in meeting by asking, “What’s important right now?” keep the pressure on by asking, “And what else?”

Silence is often a measure of success.

Don't mask your advice behind a question:

Stop offering up advice with a question mark attached. That doesn’t count as asking a question. If you’ve got an idea, wait. Ask, “And what else?” and you’ll often find that the person comes up with that very idea that’s burning a hole in your brain. And if she doesn’t, then offer your idea—as an idea, not disguised as a fake question.

Still on 1:1s, don't jump into solutions too early:

what they’re laying out for you is rarely the actual problem. And when you start jumping in to fix things, things go off the rails in three ways: you work on the wrong problem; you do the work your team should be doing; and the work doesn’t get done.

About providing timely feedback:

Have you ever made popcorn? One “pop.” Then another. Then another. And then the popping goes crazy. Problems proliferate in the same way.

Back to saying no:

“No, I can’t do that” is another option. Having the courage to say No is one of the ways you stop being so “helpful.”

From my experience, tho, you don't always need to say no. Most of the time, when you say no, what you actually mean is "yes but". Say YES, but set your boundaries. "Yes, but I'll need two extra weeks." "Yes, but the team needs a more seasoned developer." You get the point.

And finally, you can just buy yourself some time. “Let me think about that.”

As humans, we tend to overreact to things. We enter urgency mode too fast. That's how we got where we are today, but that's another story. The point I want to make here is that it is often a good idea to let people sleep on their problems. More often than not it was not a real problem after all. Other times they'll just get sucked into a new urgency. A good way to leverage that is to show yourself available, but just enough so that they have time to think. For instance: "Sure, glad to help, can you schedule us a call next week?"

About avoiding being dragged into something you don't want to:

Why are you asking me? Whom else have you asked? When you say this is urgent, what do you mean? According to what standard does this need to be completed? By when? If I couldn’t do all of this, but could do just a part, what part would you have me do? What do you want me to take off my plate so I can do this?

Yet another say no strategy:

if you write down someone’s request on a bit of paper or a flip chart, you can then point to it and say, “I’m afraid I have to say No to this,” which is a little better than “I’m afraid I have to say No to you.”

About planning things. It's all about the process:

“Plans are useless, but planning is indispensable,”

The 7 (+3) questions

1. Kickoff: what's on your mind?

The Kickstart Question is the way to start any conversation in a way that’s both focused and open.

2. AWE: and what else?

The AWE Question—the best coaching question in the world—works as a self-management tool for you, and as a boost for the other six questions here.

3. Focus: what's the real challenge here for you? Why?

What makes the Focus Question work so well are those two final words, “for you.” Don't forget them. Adding “for you” to a question helps people figure out the answers faster and more accurately.

The why is optional, and be careful with that. You ask why because you want more detail. You want more detail because you want to fix the problem. And suddenly you’re back in the vicious circles of overdependence and overwhelm. If you’re not trying to fix things, you don’t need the backstory.

4. Foundation: what does success look like for you?

The Focus Question and the Foundation Question are about getting to the heart of the challenge, so you’ve got your attention on what really matters.

5. Action: what could you do to get there?

There’s being helpful, and then there’s being “helpful,” as in stepping in and taking over. And way too often, you get suckered into doing the latter.

When you offer to help someone, you “one up” yourself: you raise your status, and you lower hers, whether you mean to or not.

Hold yourself! Let them think.

6. Support: how can I help you?

Michael calls it the Lazy Question and claims it'll save you hours. Put this way, it sounds more like a passive-aggressive way to delegate the responsibility than actually offering your help. I'm not comfortable with the mindset, so I'm recategorizing it as the Support Question. Oh, and it won't save you hours. If you want to preserve your time, opt for the Action Question just below.

7. Commitment: what are you committing to?

There's no action without commitment. Assign a responsible, decide a delivery date, and be clear on the specs. If you hear their silence, politely ask them to rephrase what we're committing to.

8. Prioritization: if you're doing this, what are you saying no to?

While the Action Question could save your time, the Prioritization Question will save the time of those you’re working with.

9. Close: how do you want to follow up on this?

We're good to go. We have an action. The problem is, other people not always have a well-oiled system to process their work. When that's the case, ask this question. The outcome might be another meeting, and it should be scheduled now. Or it could be a follow-up task, in which case you might as well want to add it into your waiting task list.

10. Learning: what was most useful for you?

And the Learning Question, after all, will ensure that everyone finds their interactions with you more useful.

They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened.

“What’s essential is to interrupt the process of forgetting.” That forgetting starts happening immediately, so even by asking the question at the end of a conversation, you’ve created the first interruption in that slide towards “I’ve never heard that before!”


It was a simple and quick read, for a very low price ($3,99 on Amazon) and the value I'm taking from it, while applying on my everyday job, is way above my previous expectations. Highly recommended.

I've actually printed the modified version of the 7 questions I've found in the forementioned article, added one of my own to make it 10, and pasted it into my wall. Here's what the article version looks like.

Image from

Latest comments (0)

An Animated Guide to Node.js Event Loop

Node.js doesn’t stop from running other operations because of Libuv, a C++ library responsible for the event loop and asynchronously handling tasks such as network requests, DNS resolution, file system operations, data encryption, etc.

What happens under the hood when Node.js works on tasks such as database queries? We will explore it by following this piece of code step by step.