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.

If you don’t want to miss our next webinars, you can register to our next sessions.

 

1. To explain rationally is enough to convince

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 transmit

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

Start connecting developers' knowledge with Promyze

Best coding practices shared from IDEs & Code reviews.

Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.

Crafted from Bordeaux, France.

©2023 Promyze – Legal notice