Some of the things I think about when asked how to influence change in teams/orgs as a Principal/Staff engineer:
Invest time in building relationships before (big) course-correcting. In the start: a productive relationship is more important than being right. Spend time working together with people and sharing the constraints they are facing day-to-day, it will help you understand their context which makes your future interventions more likely to be useful.
Automated tests as a safety net are most valuable in codebases with high risk when making a change. Those are conflated, coupled codebases where:
1) the average rate of change per element (method/class) is high and
2) the risk of introducing problems with a change is high (too much coupling).
The latter is a consequence of the former, and codebases with long methods and classes inherently exhibit these characteristics.