There's a clear difference between someone with grit and someone without.
A person without grit will message me on slack with a half baked question that is practically, "I tried almost nothing and I'm stuck, can you solve this for me?"
The question is how many times these hours are spent.
If the project is due tomorrow, it's worth asking ten people for a few hours of their time. If it's not urgent, blocking those ten people for a few hours might lead to more work time being spent on the problem than you figuring it out.
I think there's a sweet spot in between asking too little and too much, and it's contextual.
That's why bigger orgs are inefficient and need to acquire smaller companies to get stuff done.
Middle managers give the impression of doing something useful without actually being able to do much.
It's up to senior engineers/tech lead/manager to detect that and then give feedback, helping that engineer grow.
It's also an important quality for an engineer to be able to take feedback and correct. Grit isn't the only important quality.
It also happens with more intermediate or senior engineers who have been able to get away without rigorous methods to solve problems. Maybe they are used to an overly helpful tech lead, or they have changed domains to something more challenging/where stack overflow doesn't have the answer.
Many a time I've been faced with obscure build/environment issues that no one on my team has seen, and googling doesn't provide any easy out. At that point, I feel the necessity for grit. It's a good word too, as it can feel like sandpaper on my soul to start cracking open codebases I wished just worked to get past a complete impasse that my deadline didn't account for me to face.