Enabling Change: A Type of Engagement for Every Situation

In consulting and coaching, adapting to the client’s expectations and needs is the key to a successful engagement. So I can honestly say that no two engagements are alike. That said, it’s still possible to identify types of engagement.

The “firefighter” engagement

“Fire! Help!”: development that takes longer and longer, and a worrying rise in bugs. The obvious suspect is technical debt, and there is always some technical debt. But since development sits at the end of the production chain, it’s all too easy to believe it is the source of every problem. Yet more often than not, you also have to look at functional design, and even go further upstream to work on organizational issues, particularly those tied to the product’s modularity. Software quality is therefore more than a technical matter, which is why I’m brought in directly by the CEO. From there, you have to take the issues one at a time, accept that change takes time, and steer the engagement hand in hand with the company.

The modularization engagement

Some companies reach out to me specifically about this issue, because the modularity of IT systems is critical. Addressed early, it will cost you next to nothing, apart from a few days of thinking on paper. Ignored, it will come back to bite you if your startup ever enters a phase of exponential growth. The question is: will it survive? A situation like this calls for method and a cool head: 1. Define a target (map out the business modules, starting from the domain); 2. Define a refactoring path that lets the old and the new coexist; 3. Set time aside for it and refactor, as you go.

The audit engagement

I list it as a category of its own for the sake of rigor, but pure audit engagements are actually quite rare, as an audit is usually the first step toward longer-term support. Just as a doctor prescribes treatment based on a diagnosis (sometimes a hypothetical one: if the treatment doesn’t work, the diagnosis was wrong), an audit establishes findings that everyone shares and identifies the first areas to work on.

Preventive work

As proof that raising awareness of technical debt is paying off, companies have recently started contacting me as soon as they’re founded, to advise their teams as they lay the product’s technical foundations (a.k.a. the Walking Skeleton). This stage is crucial to building an MVP while keeping technical debt to a minimum, bearing in mind that an MVP can take a lot of work. Consider a mature market such as online banking. If you want to win market share from Qonto, your MVP had better be very, very solid. This is the kind of engagement I would like to see grow over the long term, as I’m convinced that an ounce of prevention is worth a pound of cure.

Academic teaching

I was lucky enough to teach for 3 years at Hetic, under Stéphane Dalbera, then Director of Programs. A real pleasure, and someone I’m glad to have met. We shared the view that most schools wrongly focus on teaching technologies. Technologies are useful, but they are also highly perishable: if React is top dog today, what about 10 years from now? Will these architectures still be around? Emphasizing the fundamentals (language paradigms, algorithms, architectures, methodologies) is how you train professionals who are better able to adapt to changes no one can foresee.

Individualized training

Now for an unusual type of engagement: a client I worked with for 3 years had brought me in to help their teams build their skills, with no specific issue in mind (in particular, no major technical debt problem). At heart, the sole aim was to take each person a little further in their mastery of software development, which in itself reflects a very healthy company culture. The engagement took the form of weekly conversations with the developers, one-on-one, around exercises of my own or problems they had run into during their workweek. The value of this format is that it can be tailored very precisely to each person’s needs, abilities, and wishes, in other words to their own pace.

Individual coaching

Knowledge is one thing. Organization is another. But sometimes neither is enough, because it’s the human side that needs work: getting people to put their questions into words and make their beliefs explicit, and helping them find their way back to action, through experimentation. This kind of support, in which conversations stay confidential, can get things unstuck and proves particularly useful for first-time managers, Lead Developers for instance, who face all sorts of situations that are new to them.

Every engagement is in fact a linear combination of these types. In the pre-sales phase, our conversations aim to determine the arrangements that best suit the organization reaching out to me, even though some of it always emerges along the way, all the more so since needs change over time.