I actually have to do this a lot at work. It would be very hard at first, but with practice it gets easier.
The "top-down read and get it all in your head" won't work. Unless you're a genius, you don't need to do it like this. Hell, I couldn't even do that to my own code if it's a mid/large project.
The hardest part is the start. You have to drop "the wall" between you and the code. That incontrolable "what the fuck" sentiment when you're reading the code. Try to put yourself in the writer's shoes and ask yourself "why would I do it like this?". When you begin to understand why things are the way they are, it gets easier to pick up the whole picture.
The codebase probably follows some patterns. Try to identify them. This is because, when people are adding code to something that is already there, there's some resistence to breaking the patterns that are already there. So people will end up writing code that is close to what's already there (or at least what they think is close).
Start small with small modifications, as demanded. Let your manager/boss know you will take some time there. You mustn't rush, or might endup messing something up.
That said, this is very hard and generally unpleasant work. So I wish you good luck (: