One team was delivering for 12 months.

... but definition of done not met. Code crap everywhere. Tests barely there and are total mess.

I inherited mess after previous lead engineer.

I exposed all the issues to the management in a straight way, no sugar coating.

... and now guess who's the bad guy for "complaining" instead of shut up and "making it work"?

P.s.
"Giving accurate report about situation" is seen as "complaining".

Did you present how you're gonna fix it?

This ^^^^

Chances are, management knew and gave it to you exactly because of that.
Their preferred statement would have been "Uhh, that code base is a mess!!!1 But don't worry, i will make it work. Let's meet next monday for presentation of the first production-ready feature."

@electrineer I did. The team who created the mess don't agree with that anyway.

@bzq84 So they didn't agree and no alternative was provided? What a bunch of scums.

Let them suffer... Push it to production and call it a beta version

I can shrug off missing tests if the product has been changing fast enough that tests would add a ton of inflexibility and time when flexibility and speed was the priority. Agile projects have this often.

If you aren’t in that ‘build more faster’ phase now then you can group areas of complexity in the system and identify how they couple. Make a diagram of them and get the team to work on the major decouplings. When the decouplings are done you can start rewriting each area of complexity as modules. Usually the UI and the business logic both have a separate map for that. Use TDD to build a clean version of the modules.