Part of this starts at the top. Among other things, the team's performance should be judged in terms of quality. You need to choose your quality metrics carefully so that the team's goal is to improve quality rather than just improving the metrics. For example, if you measure the team by bug count, people will stop logging bugs.
Organizations go through phases where the tradeoffs change between quality, pace, and resources. Larger, more risk-averse customers expect higher quality than early adopters. If your product requires more quality than it used to, your management needs to make that clear.
Another part of this is allowing time/money to be spent on improving quality. It might mean new tools/training/staff, but it might also mean slowing down the pace of development so that developers have more time to find/fix bugs before they declare they're finished.
You may also need to change some of your staff. This can be painful, and it should be done thoughtfully, but if a developer is prone to low-quality code, the right answer may be for them to switch to a different role or a different organization. This holds true for testers, too.
I suggest approaching quality improvements incrementally. If you want to insert automated unit testing into a team that doesn't use it, start with some modest goals. Pay attention to what works and what doesn't, and be prepared to change tactics where necessary.