Aside from what Flankk suggested about being one with the tribe: while you're waiting for your tribal acceptance card, measure the problem in silence.
The change defect rate (how many percent of your commits are made to fix a problem introduced in an earlier commit) is very easy to sample manually, and gives you an idea of the scale of the problem.
Then you can go to the team and say, "Look, 40 % of the things we do are fixing up problems we created in the first place. With better processes in place, we could free up a lot of bandwidth for things that matter."
Or maybe you find out that you have a change defect rate of only 12 %, and the things you think are important, for some reason, don't matter in this team.
----
Measurements that complement the change defect rate for a fuller picture, according to Forsgren et al.
- Deployment frequency (literally, what's the average time between deployments to production)
- Time to fix (when a problem is first reported, how long does it take on average until the working fix is deployed to production?)
- Lead time (once a developer considers themselves "done" with the code, how long passes until that code is in deployed to production?)
The time to fix and change defect rate measure quality, so these are the ones you probably would focus on. The other two measure speed.