There is a Boy Scout rule, “Leave the campground cleaner”. Engineers need to follow that principle. Whenever someone changes legacy code, clean up the portion code that was worked on, make it testable and introduce more unit tests especially covering the cases that prompted touching the legacy code and add more unit tests is possible.

The key is to start small and be consistent. It should be a team goal and plan discussed and agreed upon by the team. - First step is to have automation and test coverage. App should have enough unit and integration tests. This ensures that the behavior remains consistent even after refactoring. - Integrate linters and code formatters (like rubocop) with strict review cycles for every change. - Plan Incremental refactoring. Identify and update key areas/features. Look for design patterns and modularize reusable key features. - Improve Documentation for existing and new changes - Lastly keeping track of progress and assessment in sprint with the dev team. While adding new code, it's crucial to update existing code to prevent legacy issues.

I belief that the quality of the legacy code is best kept by having owner/responsible programmer for each part of it. Someone that knows the design and implementation decisions that were taken and where the dragons live. Then, if this product has a long(ish) future, start a separate track of moving away from this code.

Make sure all legacy code items and tech debts are in the back log with associated risk and cost impacts. Agree with engineering that every so many development cycles one is purely focussed on tech debt and tech debt only. This will cause resistance in the business but a good product manager understands the commercial and reputational impact of tech debt and should fully support this Break down items into small deliverable and testable pieces of work that can be added to the schedule. These do not have to deliver full functionality in a single sprint but creates foundational blocks.