Recognise Your (Present) Limitations
... but don't dispair.
It is possible that people have different levels of talent regarding their abstract thinking ability, and you may (or may not) have to accept that you'll never reach the levels of your colleagues. However, that really doesn't matter.
The important thing in the long run to make the best of the talent that we do have. For example, I'm no Van Gough, but I can paint a lot better now than when I was 3 years old. Moreover, my scribbled diagrams have been valuable to others as an aid to communication. In other words, my skills don't have to be exemplary to be useful.
At the same time, value the fact that you bring skills to your work that your workmates may not have. Personally, I find that my memory is poor compared to some of my team, which means that I have to slow down and look things up more frequently. On the other hand, I'm an excellent abstract thinker, analyst and problem solver. The benefit of teamwork is that we each bring something to the party.
BTW: One thing I note about your question - you give two examples of a problem, and then try to generalise it. Perhaps you're not as bad at this as you think...
Record Your Thinking
The colleague of mine introduces me the scheme of the project... he draws it on a board... some time later I find myself to stop being able to comprehend this scheme, literally, stop being able to see it.
In this case, it might have been helpful if you had a copy of what was on the board, or of what your co-worker said.
So, why not capture things like this in the future?
- Take photographs
- Draw sketches
- Make notes
- Record conversations as mp3s (with the participants permission, of course).
Sometimes it is easier to see a problem if you have a concrete example rather than an abstract understanding of it. For example, it is easier to answer "What is 2 + 2" than to answer "What are the rules for adding integers".
So, when someone is explaining an abstract problem, try to come up with examples.
It can be a lot easier to visualise more abstract problems from drawings than from words. This is a skill that takes time to learn: practice with things you do understand, or with parts of systems that are clearer to you.
Make Switching Levels a Habit
I often loose sight of the "bigger picture" when I'm working on specific details of a project. To compensate, I try to ensure that I pull back at the end of a piece of work and see how that fits into the grand scheme of things. The more I do this, the better I get at it.
Build (Visual) Mental Models
Physicist Richard Feynman tells a story in about this in his book, “Surely You’re Joking, Mr. Feynman!” (the story is called “A Different Box of Tools”). He recalls how he “gave a lot of trouble” to mathematics students during his time at Princeton be telling them that their subject was “trivial”. He would get the mathematicians to explain a complex and strange scenario to him, and then make a statement about that scenario. Feynman would immediately tell the mathematicians whether their statement was true or false. He achieved this apparently impossible feat of mental gymnastics by building a mental picture of the problem in his head… involving hairy green billiard balls or whatever… and then base his answer on whether or not the statement was true of his model.
In the programming world, a problem can often be explained from different perspectives. For example, from a business perspective, at the module level, at a statement level, at the level of 0s and 1s. Testers, programmers, analysts, managers etc. will all see the problem from a different perspective. Practice explaining things (to yourself, if needs be) from these different perspectives. In doing so, your abstraction level will increase, too.
Don't worry if you need to ask more questions than other people - ask them anyway. If your job requires that you understand things at an abstract level, make efforts to do so even if it highlights your apparent lack of skill in this area. By doing so, you'll improve your skill and will probably help others along the way.
A powerful technique is to reflect back what you do understand, and ask people to correct any misunderstandings that you have.
Of course, you need to be sensitive about this - don't badger people if you don't need to, but do keep digging when you do. Nobody should mind if you're working to improve yourself because that'll be good for the team, too.