Technical debt
Making it visible, acceptable and a priority
1 to 2-day training for senior devs, tech leads and fractional CTOs.
The symptom
"Let's talk about it again after launch"
You said it in the leadership meeting. Calmly, with examples. The backend has become hard to evolve, three people out of five no longer dare touch it, and every new feature takes twice as long as it did a year ago.
The CEO listened. Then said: "OK, let's talk about it again after launch."
You never talked about it again. The launch was followed by another launch.
Six months later, this quarter's feature ran five weeks late. In the meeting, someone asks why things are so slow now. You explain again. And you can see a thought cross people's faces that nobody says out loud: that one always wants to rewrite everything.
You were right on the substance. You lost the argument, and you lost a bit of credibility on every topic that followed.
The cost of inaction
What it's actually costing you
You lose the argument before you even open it.
You're defending quality, they're defending revenue. As long as the conversation stays on that ground, you'll lose every time, and that's logical.
You get filed into a category.
The purist, the craftsman, the one who wants pretty code. That label devalues your opinion far beyond the debt itself: it taints everything you say afterward about deadlines, priorities and risks.
You end up staying quiet.
This is the most common outcome. You stop raising a topic you keep losing, and you become a silent accomplice to the accumulation.
Or you get the rewrite, and it's worse.
A poorly scoped full rewrite that slips by six months is what has cost our profession the most credibility with leadership. Many of the refusals you face today come from a project like that experienced elsewhere.
You absorb the consequences you had warned about.
With nobody connecting the two, and often while being asked to account for the delay.
What changes
What you gain
Winning the argument instead of losing it.
Debt translated into cost, delay and risk becomes a management decision like any other, one a leader knows how to make.
Getting out of the character judgment.
When you talk trajectory, delivery capacity and business risk, nobody can file you under the developer who just wants elegant code.
A shared language with the leader.
You get something more useful than a one-off approval: a reusable discussion framework for every quarter.
A trajectory that gets funded.
A progressive project folded into the product roadmap gets through where a rewrite sprint gets refused, because it doesn't ask anyone to stop shipping.
Credibility.
The tech lead able to lay out a clean business trade-off becomes the person consulted before decisions, not after.
Profile
Who it's for
Also relevant for employed CTOs and technical managers who need to defend a modernization budget.
You need to have worked on a codebase with real history, and to have already lived through at least once the moment when delivery speed degrades without anyone being able to explain it to the business.
This isn't for you if
you're looking for refactoring techniques, design patterns, or a technical repayment method. The work here is about qualifying, translating and negotiating trade-offs. How to actually pay off the debt, you already know.
The method
The main steps
Three kinds of debt, three treatments
Not all debt is a problem: some of it is an excellent decision. We distinguish acceptable debt, dangerous debt, and strategic debt. Knowing how to say "that one, we keep it" is what makes it credible when you say "this one, we need to address it."
Connect the debt to business risk
A fragile area of code interests nobody. A checkout flow you can no longer touch safely before the sales period interests everyone. We connect every technical symptom to a consequence the leader recognizes as their own.
Map it
Make the diffuse visible: by area, by criticality, by frequency of change, by human dependency. A map does more for your case than three meetings.
Translate into cost, delay, risk and loss of autonomy
The four units a decision-maker understands. Golden rule: stay within a defensible order of magnitude, an inflated number destroys the whole argument the moment it's challenged.
Prioritize with the client and fold it into the roadmap
Arbitrate in front of the leader rather than in their place: present options rather than a request, and secure a commitment that will survive the next urgent topic.
Sell a progressive trajectory
Why the full rewrite fails so often, and how to build the alternative: a step-by-step trajectory, with visible gains at each stage.
Deliverables
What you leave with
Reusable materials for your very next engagement.
Pricing
Format and pricing
1 day
€900 excl. VAT
The essentials: qualify, connect to business risk, translate, lay out the trade-off.
2 days
€1,800 excl. VAT
An extra day devoted to in-depth mapping, building the progressive trajectory, folding it into a product roadmap, and a leadership-meeting simulation based on participants' real cases.
Deliberately practical teaching: short inputs, work on your own situations, role-play with a leader across the table, and group feedback.
Frequently asked questions
Questions we get asked
"We need to refactor the backend."
"Every change to the backend costs twice as much time as it did a year ago. Without action, we lose a month on Q4. Here are three options, with their cost, and my recommendation."
The same technical problem. Two meetings that end in completely different ways.