Sum up: The Coaching Habit

Flavio Wuensche — Sat, 27 Feb 2021 12:40:41 +0000

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:

The Coaching Habit kindle book on Amazon
Related article: Unlocking Your Coaching Habit

Highlights

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!”

Conclusion

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 https://pragma.team/blog-list/2017/2/16/unlocking-your-coaching-habit-agile-tour-16-recap

Au revoir vim: work in the cloud using VS Code

Flavio Wuensche — Sat, 27 Apr 2019 15:50:02 +0000

TL;DR. Install sshcode with go get -u go.coder.com/sshcode and connect to your remote virtual machine using sshcode kyle@dev.kwc.io ^^ voilà.

Motivation

There are several reasons to setup a development environment in the cloud:

access your development environment from any device
insanely fast internet connection
try new technologies while keeping your local machine safe
easily onboard new teammates by sharing snapshot to your VM
make your laptop battery last insanely longer
buy a $200 Chromebook and start coding with nearly zero setup

Context

So far, in order to work 100% in the cloud, you had to create a virtual machine and ssh into it from a terminal. Then you had to use vim as your main text editor, maybe tmux for managing your terminal sessions and windows. It worked, but you got no choice but to use vim.

Nowadays, with the advent of modern text editors built on top of NodeJS, you can have a full native-like application running inside your browser. And that's exactly what I want to introduce to you today.

With the help of code-server and sshcode, two solutions brought to you by the coder.com amazing team, you can now EASILY code in the cloud using VS Code.

Getting started

What you'll need

Google Chrome (locally installed)
Visual Studio Code (locally installed)
a remote virtual machine: I highly recommend Digital Ocean

Step-by-step installation (Mac)

The instructions at the main project repo are quite minimalist, so I'm detailing them here.

# install sshcode using go
brew install go
go get -u go.coder.com/sshcode

# add the binary to your path
# in case you're using zsh, for instance:
echo "export PATH=\$PATH:~/go/bin" >> ~/.zshrc

# open a new terminal and launch vscode
sshcode kyle@dev.kwc.io

If you have Chrome installed, it opens the browser in app mode. That means there's no keybind conflicts, address bar, or indication that you're coding within a browser. It feels just like native VS Code.

Extra tricks

Open an specific project

You can specify a remote directory as the second argument:
sshcode kyle@dev.kwc.io /root/www/doctolib

Skip extensions sync

By default, sshcode will rsync your local VS Code settings and extensions to the remote server every time you connect. This operation may take a while on a slow connections, but will be fast on follow-up connections to the same server. To disable this feature entirely, pass the --skipsync flag.

Sync back

By default, VS Code changes on the remote server won't be synced back when the connection closes. To synchronize back to local when the connection ends, pass the -b flag.

Drawbacks

you'll notice some delay at times, depending on internet connection
since you're in the cloud, you should be more conscious about security

Any questions or ideas to share? Leave a comment below.

Are you into productivity hot tips for web development? I'm a Brazilian full-stack developer, living and working in Paris, and I regularly share articles like the one you've just read. Follow me on twitter to stay tuned.

DEV Community: Flavio Wuensche