Yeah I guess the difference is that at my workplace there's a lot of tribal knowledge. Even when there is a design document it often hasn't been updated or requires nuance to interpret that's only really in one or two peoples' heads. Often the question/discussions is about engineering priorities, some discovery was made during coding that would alter the design, and half the time simply bringing up the topic with them for 5 minutes brings new information to bear that produces a superior result.
I try not to waste their time and develop my questions as much as possible on my own, but I'm not going to risk several hours of wasted work going down the wrong path when a 5 minute discussion with a SME would confirm something.
And it is an RTO discussion, because in the office they're available to some degree. WFH that availability drops off a cliff, and these are questions about the inner-workings of proprietary software, if the answers were on Google there would be legal action.
That again sounds like a problem with your company's knowledge sharing culture, not with the industry at large. Silos exist even when every butt is in an office seat, that's a well-known issue that far pre-dates pandemic remote work moves. The answer isn't "make everyone defenseless to random interrupts from other people" but "learn how to actually document things so you're not a company full of points of failure".
It seems like what you really want is for others to treat your emergencies as theirs. They're not, they're yours. If you can't wait 15 minutes for a ping back without being completely stuck, you aren't planning your work correctly. That's nobody else's fault.
So this is such a good example of why the office is actually a major liability. Being in person allows you to get away with creating a culture where documentation doesn't really exist and that tapping people on the shoulder is more efficient. Everyone will be better off if instead knowledge is shared efficiently.
A good analogue is the culture of "the smoke break"(see the Friend's episode The One Where Rachel Smokes for a funny example). It's easy to say "the best decisions are made during smoke breaks therefore smoking is necessary for efficient businesses." Clearly that's absurd. It's not the smoking that makes good decisions, nor does the ability to tap people on the shoulder make for good documentation. Depending upon an accidental formation of office culture is never going to go well in the long run.
> Being in person allows you to get away with creating a culture where documentation doesn't really exist
Viewed a different way, it allows a team to spend less time documenting and more time on other things. Increased documentation could be seen as one of the costs of working remotely.
Increased documentation is a cost you pay no matter what, you just pay it later in other formats when in-office - when the SME you treat as a guru finds a better-paying gig you have to scramble to rebuild their expertise from nothing or hope they are nice enough to do a thorough knowledge transfer. That kills productivity far worse and for longer than taking 30m at the end of your day updating some shared wiki.
All this to say, the trade-off you're proposing doesn't exist. You're arguing for paying twice instead of paying once - twice in the sense that you lose productivity now via random interrupts, and in the future when your siloed knowledge leaves you high and dry. Hope the "other things" you got done instead of documenting were worth it in that scenario.
I try not to waste their time and develop my questions as much as possible on my own, but I'm not going to risk several hours of wasted work going down the wrong path when a 5 minute discussion with a SME would confirm something.
And it is an RTO discussion, because in the office they're available to some degree. WFH that availability drops off a cliff, and these are questions about the inner-workings of proprietary software, if the answers were on Google there would be legal action.