The Coaching Architect
6 min read
6 min read
In this talk, Roy Osherove speaks about how to become a better coach. A nice talk highlighting some of my personal principles I try to follow every day. Coaching others is a nice thing if you like it, but it also needs to be learned.
Ok…, so jump here then.
Here are my notes I took during the talk.
By growing others to not need you, you will always be wanted, appreciated and highly valuable.
Observations have shown that there are periods of slow learning followed by periods of very quick learning. The reason for such ravines before the fast growth are because we first need to “unlearn” what we knew before in order to be able to acquire new knowledge and try something new. For example:
To grow the team, we must first realize we can do this ourselves.
Mentoring others needs to be learned…in fact, it might be uncomfortable initially. But in the end, the process of mentoring is a learning process for both, the mentor and the coached person.
Common symptoms: Others will do the task much slower than myself
The key is to make time.
There are different kind of modes
Goal is to not only have two of them, but all three: features, time and quality.
Again, same rule, try to avoid being the bottleneck. You’ll never be able to review all the code of your peers and as such, you have to teach them how to do it by themselves (shared code ownership).
How do we lose quality? Dilemma:
But, “the project is going to take 3 weeks without unit tests and 4 weeks with unit tests…”
There is no choice, this is the way things are done. It’s the same as saying “the car costs $20,000 without wheels and $30,000 with them”.
Stand up for the values you believe you’re right.
For each behavior, The world is perfectly designed for that behavior to happen (Influencer - the power to change anything)
There are different reasons why people may not follow certain behaviors.
Social motivation are the people that draw you into a certain action. This is strongly related to group membership. As such, creating a support group might be helpful in convincing people to acquire certain behaviors (like doing TDD).
Environmental ability define the infrastructure around you, i.e. having an automated build server that executes the test you write in the process of performing TDD.
Environmental motivation on the other hand is strongly related to rewards. For instance, people might get rewarded for being able to quickly ship a task. As such, others, writing unit tests and thus shipping a bit more slowly, might get the feeling that their work isn’t As such, doing a good job by writing automated tests for your code seem not to be appreciated.
The words we use when we promise something. Saying what you want to do, meaning it and to actually make it true.
All of them give you a way out, a “permission” to not do it.
This creates a commitment of something real. Moreover if people have a problem saying it, you’ll immediately know there might be problems (due to time constraints or whatever). So you can react on that. It helps to raise problems that might exist inside a team.
But attention, you can make people to only commit to things that are under their own control.
Don’t be a bottleneck, coach the people around you. When people come to you about a problem, challenge them in order to help them learn and grow: “What are you going to do about it?”
Know how learning works and how you can allocate time in order to create spaces for learning and for moving people out of “survival mode” into “learning mode”.
Consider also potential problems that hinder the adopton of new practivces and their potential personal, social or environmental barriers.
Also employ common language which leads to more clear commitments.