Coach or consultant?
In the software development industry, these terms are rarely, if ever, clearly defined. Many people use them interchangeably, whereas to me they seem to refer to distinct approaches.
Like many others, I came to coaching “by default,” because my technical expertise was recognized. But possessing expertise and knowing how to convey it are two very different things—especially since the goal isn’t always to convey that expertise (we’ll come back to this).
As a coach, I help my clients find their own answers
My coaching practice involves helping my clients make informed decisions, both big and small. So there’s a “training” aspect, but above all, it’s about “post-training support”—to help these organizations move from theory to daily practice. Practice involves making choices—something that becomes quite clear as soon as we start talking concretely about agility (should we run sprints? make estimates?), testing strategies (which tests?), or even refactoring (which strategy?). I therefore help my clients ask the right questions and understand all aspects of the problem.
However, I avoid providing answers. There are two reasons for this:
-
If the client isn’t actively involved in their own decision—if they do things “because Mathieu said it was better that way”—that decision will fall flat. They won’t muster the energy needed to implement it and make the most of it, despite the obstacles that arise along the way. At the first sign of difficulty, they’ll second-guess the decision because, deep down, it wasn’t really their own. I’d rather the client make their own decision—even if it’s different from the one I would have made in their place—so they can conduct their own experiment, draw their own conclusions, and iterate. Put simply, I trust my client.
-
The whole problem is that, precisely, I’m not in my client’s shoes. Even though I take the forces at play into account, I’m not part of the company; I don’t experience its day-to-day reality and am therefore only partially informed. Furthermore, I evaluate the pros and cons of decisions in my own way (which, a priori, is not my client’s) and do not bear the consequences of those decisions. But above all, my knowledge of their history is incomplete. This point is crucial because while certain areas for improvement may seem obvious to an outside observer, implementing them often feels like a revolution. Sometimes a revolution is necessary; other times, a velvet revolution is called for.
As a consultant, I provide answers
My approach as a consultant is entirely different: as a consultant, I provide answers, while making sure to explain my reasoning. I reserve this approach for complex issues that are particularly critical for the company, such as the modularization of information systems—a subject where mistakes can be costly. However, I strive to involve my clients in the process, because it’s important that they be convinced the goal we’re setting is the right one, given the future cost of refactoring. This generally involves an initial one-day training session on the strategic aspects of Domain-Driven Design, followed by the formation of a small working group comprising the two or three people who will lead the initiative internally once my engagement is complete.
The Importance of Reflecting on One’s Practice
These different approaches are complementary. It’s up to each individual to experiment, adapt, and organize themselves to take a reflective look at their work (peer exchanges, supervision, etc.). This reflective aspect is essential in my view, given how great the risk is in these people-oriented professions of causing harm while trying to do good.