Knowledge workers aren't usually hired to be process-following automatons confined strictly to requirements known in advance by their superiors, but rather to creatively design, optimize, and troubleshoot the processes around them. Which requires visibility into how they are actually operating in production, and not just in the imagination of some other designer.
That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.
Salesforce's worst design principle is hiding things people don't have access to.
And it cuts to the heart of the agility you're describing -- if I can't know what I'm NOT seeing, then how can I discover I need to request it?
From this perspective, Salesforce is absolutely engineered for top down "Identify the process, create a set of permissions that allows it, then apply those permissions to the appropriate set of people" design.
As opposed to bottom-up discoverability (e.g. I can see that I don't have access to this thing, somewhere) + RBAC requests for a permission set I learn I need.
>if I can't know what I'm NOT seeing, then how can I discover I need to request it?
This is so true. I feel that most of our closed source scripts are duplicates because you can't search for existing internal projects in our system. If you know it's there you can ask for it, but you usually don't, so you build your own.
Most places I’ve worked default to letting everyone read any source. Is that not the norm? Agree that it’s a game changer for those willing to use it, but I find that last qualifier to be surprisingly rare.
That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.