Technical debt: making it visible, acceptable and a priority
Make technical debt understandable to non-technical people, without jargon.
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.
The cost of inaction
What it's actually costing you
You lose the debate before you've even started it.
You're defending quality, they're defending revenue. As long as the conversation stays on that ground, you'll lose every time.
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 6 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 nice code.
A shared language with the leader.
You get something more useful than a one-off approval: a healthy framework for the discussion.
A trajectory that gets funded.
Broken into stages and folded into the product roadmap, the work gets a budget where a big-bang rewrite gets refused: the team keeps shipping throughout.
Credibility.
The tech lead able to lay out a clear business trade-off becomes the person consulted before decisions get made.
Profile
Who it's for
Developers, tech leads, technical consultants or CTOs.
You will recognize yourself if:
- You have been raising the debt for months and nothing moves.
- You are told it is not a priority, and you lack the arguments to push back.
- You cannot put a number on what the debt actually costs.
- Your only credible proposal is a rebuild, and it frightens people.
- The same incidents keep coming back without anyone tracing the cause.
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 or design patterns. The work here is about qualifying, translating and arbitrating.
The method
The main steps
Qualify the debt and connect it to business risk
The whole work is about connecting every technical issue to a business consequence the leader cares about.
The outcome: debt that is sorted, with each weakness tied to what it costs.
Map it
Make the issues visible: by area, by criticality, by frequency of change and by human dependency; so you can convince more easily.
The outcome: a map of the debt with an order of magnitude for each area.
Translate into cost, delay, risk and loss of autonomy
These are the 4 units a decision-maker understands, and they're what let them properly weigh up remediation work.
The outcome: an explanation the leader can take up as their own.
Prioritize with the client and fold it into the roadmap
Arbitrate in front of the leader: present options with a recommendation and secure a genuine commitment.
The outcome: debt work written into the roadmap, with its rank.
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.
The outcome: a plan the client can start on next month.
Deliverables
What you leave with
Reusable materials for your very next engagement.
Pricing
Format and pricing
2 days
€1,800 excl. VAT
The essentials: qualify, connect to business risk, translate, lay out the trade-off, in-depth mapping, building the progressive trajectory, folding it into a product roadmap, and a leadership-meeting simulation based on your real cases.
The price shown is per person. For any group or in-house training, please contact us.
Frequently asked questions
Questions we get asked
Make debt something leadership actually decides on
Leave with a costing, a shared vocabulary and a path the client can commit to.