Flipping the script a bit: As a senior developer, avoid cultivating learned helplessness. You can push back on this in a couple ways: 1) Instead of answering

Flipping the script a bit: As a senior developer, avoid cultivating learned helplessness. You can push back on this in a couple ways: 1) Instead of answering questions, give a nudge to where the solution is documented ("Hey I'm swamped, but I'd recommend checking X for more info. If you haven't read through X yet, that's a good resource to skim"). Keep tabs on how much your junior team members are expected to know, nudge them harder if they aren't taking the time to ingest the gestalt of what's there (it feels like a waste of time to do so sometimes... Reading isn't getting code written. But knowing what's already there saves work in the long run). 2) When something isn't documented... review the docs a junior team member writes, don't write them yourself. This both encourages them to have ownership over the system and will probably generate better docs in the long run (everyone has a notion of what docs should look like, but communication is two-way: seeing what someone writes down clues you into what you missed is necessary to record. Can't tell you how many docs I've seen for cloud systems, for example, that assume the user is logged in with proper credentials when that step alone usually requires handshaking across three services and maybe an IT team). 3) Prefer mistakes to silence. Don't bash a team member for making a correctible mistake, even in production; use it as a learning opportunity both for them and for you (if that mistake was possible, you're missing a guardrail). Actively communicate to junior members that wrong code that exists is preferable to no code; wrong code can be talked about, no code is work yet to be done. And be aware that for a lot of junior devs, the reaction to making a visible error is like touching a hot stove; cultivate a soup-to-nuts environment that minimizes that hot-stove reflex.