We recently hosted a
live session with Benoit Gantaume from
artisandevelopeur.fr to discuss the different attitudes a technical coach must adopt to bring new concepts to a team. Benoit has 10 years of experience as a technical coach, he studied similar patterns within teams and gave us 4 misconceptions about how to coach a team to adopt
software craftsmanship values and its common practices. This webinar was in French, the replay is available
on YouTube.
1. Explaining rationally is enough to define best coding practices
The technical coach arrives in a team to explain to developers what they’ve done wrong, it can be quite cold and easily seen as judgmental. All the nuance is in the way it is said. When you arrive with a strong expertise, you can think that explaining it rationaly will be enough. However, people will agree but don’t change anything. Rationality is not a decisive factor in change, people make decisions based on their emotions.
2. Being an expert is enough to transmit
Acquire an expertise isn’t enough to share with other. Managing change can’t be improvised, other skills are needed, especially empathy and listening. These are relational softskills, but they can easily be worked on, by practicing
active listening for exemple.
3. Being an expert is needed to share best coding practices
On the other hand, there is no need to be an expert to transmit. This can even be an advantage; the expert’s bias is avoided. “When I train beginners, there is a real effort to make to put me back in their posture, while when you are a beginner yourself it is easier” explained Benoit. Nothing better than a beginner progressing to transmit to other beginners because he knows the difficulties that will be encountered. Also, it makes you get out of the dogma of the expert when the expert says something, everyone agree without thinking. It opens up the conversation and the thinking. However, it needs a lot of humility, it’s really easy to fall into a certain form of arrogance otherwise.
Julien Topçu, a technical coach, gave a nice example in a recent talk: “Do you really think Usain Bolt’s coach runs faster than Usain Bolt ?”
4. Imposing best coding practices is effective
The management/ the internal coach/ the product manager/ the tech lead decides one day to do some crafting so it must be done is a situation Benoit often see. For agility, it worked a bit because the processes remained the same, the fundamental’s didn’t change. Software craftsmanship is changing the way people work. “Change is a door that opens from the inside”; if a developer don’t want to, it will not happen. Then, all the coach can do is help the other person to realize that this is a good thing for him, provide the context that is suitable, provide the tools and resources, but when it comes to doing it is up to the other person to do it. A solution to this would be to go step by step, victory by victory. Changing a whole system at once requires too much energy and it doesn’t work.
Here are the learning’s of Benoit about how to be a good technical coach. What do you think about these 4 misconceptions? Do you have any others?
If you don’t want to miss the upcoming webinars, register here! 
