"Face the problems" might have been clearer, but this point is inspired by a time where, in hindsight, I should have got up from my desk and physically gone to another building to talk to the people who could fix the problem. I also should have spent more time reading and and changing legacy systems instead of avoiding them. It means, to me, to get close to the people and systems involved with the problems (or who are causing the problems). Sometimes the problems aren't that hard to fix, but to fix them you'd have to learn a legacy system written in another language, or contribute to another team's project, etc, and so I think of it as going to the problem, you just need to be where the problem is.
Source: Much experience with surgical refactoring/ re-engineering/ rearchitecture.
Plus observation of the after-the-fact results of many less experienced teams "writing" or "rewriting" software.