Agree and follow this principle to certain degree, however there are caveats here - something being a blocker shouldn't prevent you from trying to resolve the blockers by yourself or work with your boss to resolve them ie - "hey boss, I'm blocked with task A with refactor of this code; are you happy for me to do XYZ?". Then I have options to say: "yes! excellent! go ahead!" or "no, we need to do ASD here" or "no, we cannot do XYZ right now". If every time people encountering blockers would come to me to resolve them, or wait until they're resolved I'd not get anything done. On the flipside, if every time a blocker is encountered people were to handle it themselves, then a) it might not align with my vision on what actually needs to be done here b) I'm blindsighted with what was actually done.

Clear boundaries and strategies eliminate these caveats = team members are aligned on what they can make decision for and general direction the team is heading towards.

Yeah like I said if we are straying in to over-reliance/not really doing our job, he clearly lays out what to do and says "there go take care of it" a few times. He does a good job of not fostering a culture of constantly playing CYA