No More "Someone Else’s Problem", Tackling Tech Debt at Scale

When 50+ Android engineers contribute to a rapidly growing codebase, technical debt and executing migrations becomes an organizational challenge.
At Qonto, we transformed our tech debt management by moving from vague group responsibility to empowering teams with a way to visualize and prioritize their debt, turning "someone should fix this" into "we’re on it."
In this talk, you'll learn how we:
- Built a first prototype in just one month with a single engineer without any new new tools, just clever use of existing
- Integrated it into our day-to-day processes, making tech health a routine
- Designed a Health Score that teams actually want to improve
- Orchestrated large-scale migrations with real-time tracking, no more guessing “are we there yet?”
- Made debt reduction engaging with intuitive tooling and team-specific dashboards
- Expanded the playbook to tackle dependency updates, flaky tests, and beyond

We’ll also share hard-earned lessons and take a sneak peek at what's next.
Join us to see how teams like yours can cut tech debt while boosting ownership, starting with what’s already in your toolkit.

Transcript

1. No More ‘Someone Else’s Problem’ Tackling Tech Debt at Scale Florian Mierzejewski
2. Qonto Making day-to-day banking easier for SMEs and freelancers • Online business account • Invoicing, bookkeeping and spend management tools • Clear pricing & 24/7 customer support
3. Context Our team as of last week 58 Android 56 iOS 13 Teams + 9 Leads + 9 Leads Split in 4 domains
4. Context Our codebase as of last week 950 Modules 1.2M LoC 300 PRs/week
5. Context Scaling Up • Not a start-up anymore • But also far from Big Tech • Slowly hitting scaling issues →
6. The Problem
7. The Problem You’re a new engineer starting • Familiarizing yourself with the codebase • Getting used to how your team operates • Shipping features with the right amount of speed and quality • Cleaning up code as you go →
8. The Problem But… How do you know 👍👎 If the code your team owns is doing good? 💣 🚫 What are the most pressing issues to solve? Is your team’s code blocking an important migration?
9. The Problem Every issues are on SonarQube
10. The Problem Consequences • Discouraging, how can I fix something I can’t visualize? • Debt doesn’t decrease, worse, it increases slowly but surely • Endless discussions at weeklies on the state of the debt • Debt is everyone’s problem, so it’s no ones →
12. DEBT Finding & Building a Solution
13. Finding & Building a Solution What do we want? 👑 Improve Ownership of the Debt 👀 Enable Visualization & Prioritization 📉 Reduce Debt
14. Finding & Building a Solution With the following constraints • Start with a cheap PoC • Get a first version out fast • Bring some value straight away →
15. Ownership Who owns what? • 20% of our modules do not have an Owner • Our Monolith has no owner but contains 23% of our codebase ➡ Not the goal of this initiative to fix every ownership issue ➡ Start with what we have and make the lack of ownership visible
16. Metrics Where do we get our debt data from? • Start with the output of our Static Analysis tooling: → Detekt, Android Lint, Custom Rules • Solution should be flexible enough to allow other types of debt
17. Metrics Where do we get our debt data from? • 🔴 Option 1: Custom tooling ➡ See for instance Code Health Score: How Slack Tracks and Manages Code Tech Debt at Scale - Valera Zakharov ➡ Too much upfront e ort & cost, we want to start small and bring value fast • 🟢 Option 2: Use the SonarQube API ➡ We already pay for it and has all the data we need ff ➡ Issues from our custom Lint and Detekt rules are already reported
18. Visualization Where do we display that data? • 🔴 Option 1: Notion ➡ Our go-to tool, at the time was not handling graphs ➡ Would need some extra synchronisation between our DB and Notion • 🟢 Option 2: Metabase ➡ Already connected to our DB ➡ Really good at data visualization in general
19. “We want to empower each team to be able to visualize and act on the debt they own. To do so we will leverage the data from SonarQube, format and store it thanks to our mobile metrics service, and display it using dashboards on Metabase.” Building the first prototype
20. “90% of the teams reduce their tech debt by 50% in the next 6 months” 1. Definition of success
21. “No manual cost for tracking codebase wide migrations” 2. Definition of success
29. Finding & Building a Solution Beta Testing & Early Feedback • Test it on a smaller subset of teams • Gather some feedback from all our stakeholders (ICs & Leads) • Implement low hanging fruits from feedback, log the rest • Find a name that sticks, CFT Health Board (CFT HB for short) →
30. Adoption
31. Adoption Communication • Created a dedicated channel, cockpit and documentation • Communicate in our weeklies • Share wins • Listen to feedback, log improvements and ideas • Gamification →
32. Adoption Iteration on the score • Introduce an easy to read score • Make it more fair • Introduce coefficients • Keep only relevant rules →
33. Adoption Involving the Team • Encourage ICs to write their own rules • Support engineers that want to build around the Health Board • Make it easier to report issues by introducing @QontoIssue
34. Results
35. “90% of the teams reduce their tech debt by 50% in the next 6 months” 🟢 Less than 3 months in
36. “No cost for tracking codebase wide migrations” 🟢 Real time updates on Metabase
37. Demo Time
38. Learnings
39. Learnings What Worked • Iteration is key → Start small, see if the value is there, build on top • Don’t underestimate small features that reduce friction → “See in AS” button is engineer’s favorite feature of the Health Board • Keep it positive & avoid blame → Use the score as an indicator that a team needs support
40. Learnings What Worked • Leverage AI when you are unfamiliar with technologies or documentation → Also really good at SQL queries
41. Learnings What We Adjusted • Make changes to the score clear and visible ahead of time → Teams need predictability • You can’t add or implement every request → Log requests, encourage people to do it while offering support
42. Learnings What we’re still figuring out • How to write a good Lint rule for the Health Board? • How do we not overwhelm engineers with thousands of issues to fix? • Some teams are not as focused on the Health Board as others →
43. The Future & Conclusion
44. The Future • Integrate other dimensions of the debt (app size, module dependencies…) • Support other stacks to integrate the Health Board • Reduce friction by integrating it into our IDE Plugin →
45. The Future Automate debt reduction 1⃣ ✅ Visualize Everything 2⃣ ✅ 3⃣ 🏗 Automate easy ones and visualize the rest Automate everything, trickier ones using AI
46. The Future Automate issues resolution with AI on the CI 🔍 📃 📝 MCP to query old and new issues Prompt to describe how to solve an issue Review and correct if needed
47. Conclusion • Use tooling you already have and are comfortable with • Smart small, bring value, validate & iterate • Communicate, listen and support rather than just do →
49. Thank You! Florian Mierzejewski