BLOG
As a software developper, it's perfectly normal to place a great deal of importance on technology. But making a good software product means first and foremost being able to understand the customer's needs, and then communicating those needs well in all spheres of the software product, including the code. Through my various experiences in software development, I've observed that we developers tend to take too big a bite, be cryptic and fail to emphasize the language and concepts of the field.
But beyond the code, software development is also about communication, good manners, know-how and exchanges with people.
And that's where the technical coach comes in! In this blog post, I share with you my background, as well as the skills, day-to-day life and responsibilities of a technical coach.
How did I get into technical coaching?
I started my career in a geomatics research center as the only developer on the team. I mostly worked with students for whom software development was not their main strength. It was in this context that I learned to cope with code written by different people, at different levels of quality, to try to integrate and standardize it, and to make it last over time. I've discovered that the most important thing in all this is communication. I've tried to find strategies to summarize and popularize the work of others, to refine the code to bring out the important concepts so that new graduates can continue to work on the concepts of others. It's quite a challenge to work alone in a context where everything is being explored and maintained at the same time!
Building a new software is like writing on a blank page. It's easier and faster! But that's only a small part of software development. Once you've built it, you have to maintain it.
Until a developer has worked on software maintenance, it's hard to see the added value of good practices that seem to slow down the work. What you need to understand is that it's only a temporary slowdown, with the aim of going faster afterwards and making the product last over time. It was this realization that drew me to technical coaching in the first place: a need to give back to the community through my experience, so as to raise software development to a higher level of quality.
In recent years, with the added perspective that comes with aging, I've discerned similar behaviors in others that mirror those I exhibited at the beginning of my career. Behaviors that are repeated ad vitam aeternam when developers don't have someone to guide them and get them to take a step back. Even if I'm far from knowing everything, there are some basic fundamentals that are repeated everywhere!
What's a technical coach?
A technical coach wears many hats, and his or her scope of work can vary greatly depending on the context. In all cases, his ultimate goal is to implement best practices through teaching and talent development. The technical coach supports people and gives them the tools to do their job better.
In most cases, the technical coach is an external consultant. He or she immerses himself or herself completely in the team, working closely with them on a day-to-day basis.
However, we're seeing more and more in-house talent taking on the role of technical coach, whether senior developers, Tech Leads, Team Leads or Engineering Managers. In my case, I'm Senior Engineering Manager at Nexapp, as well as taking on technical coaching in my day-to-day work. Technical coaching is fairly new to me, as it's an emerging profession, but it's very complementary to my role as Senior Engineering Manager.
Unlike an Agile coach, who focuses more on processes, work organization and facilitation, a technical coach is more micro-focused on code and quality.
For example :
- How do you cut out better stories?
- How do you code incrementally, in small steps?
- How do you determine the desired result before coding, to check that you're coding the right thing?
- How to recognize what's wrong with the code (e.g. code smells)?
- How can I refactor safely without regression?
- How can we eliminate silos and waiting times by promoting teamwork (e.g. mob programming)?
We make it easier to answer all these questions by sharing a toolbox full of micro-techniques, exercises, rehearsals, methodologies and work techniques that develop good reflexes. As the coach is not a mentor, he doesn't give all the answers. The aim is to give developers plenty of tools so that, as a team, they can find what works for them and what will enable them to achieve their objectives.
What does it take to be a technical coach?
Experience
A technical coach needs to have been through the worst himself to be able to explain to another developer the problems that could arise if he continues to code as he does.
Softs skills
There are things that you can't learn, but they will help you to better support teams in technical coaching:
- Leadership | Getting people to trust that we'll get where we need to go.
- Convincing ability | Finding the right arguments to get developers to try out new ways of doing things (which can sometimes seem counter-productive at first).
- Humility | In the end, change is in the hands of the developers.
- Passion | Be interested not only in new developments, trends and best practices, but also in the history of the industry, to learn from the mistakes of those who have gone before.
- Pedagogy | Being able to recognize when it's time to give advice and when it's time to let them learn by making mistakes.
- Empathy | Immerse ourselves in the team's reality to equip them according to their stage of maturity and context.
What's it like to work as a technical coach?
For an external technical coach, the day generally begins with a training session or Learning Hour, i.e. an hour of more theoretical presentation followed by a short exercise. The coach will then work with a different team in the morning and afternoon to build on what has been taught and put it into practice in the developers' day-to-day work.
For me, technical coaching is an integral part of my daily work. I really enjoy working in groups (mob), on the one hand to break down silos, and on the other to build on what I've learned during Learning Hours and identify new ways of improving team dynamics.
For example, we could practice identifying the smallest slice of added value, implementing the simplest possible solution in order to work in very short iterative cycles and detect problems more quickly, or start from an existing piece of code and discuss as a team what we like and don't like in the code with a view to defining our quality thresholds.
Apart from practical exercises, I strongly encourage teams to work on mob-programming or ensemble-programming to find solutions together and put the week's learning into practice. My role is to let them experiment and make mistakes! But I'm never far away if they run into problems, to guide them or reframe them with a concrete example we've just experienced. And strangely enough, it's very effective!
When is a technical coach's job done?
When a team has understood what I call the fundamentals, like spotting code smells or good refactoring techniques, and they've reached a nice maturity, and one team member is ready to take over the lead, I can let them go. My aim is to train other technical coaches! When I feel that someone is ready to take over and become the team's day-to-day technical leader, I can simply maintain the work begun at regular intervals.