Don’t most most big tech companies have these? At Microsoft it is pretty common for most people to be in a few “tents” (project specific NDAs).
What is more rare are agreements _outside_ the in place system…
I think the best skill I learned at Google was figuring out how other people's code works. You read the documentation, and then you make some RPC. It doesn't work as documented. You go read the other service's logs and see an error message, but it doesn't make any sense. You search the codebase for that error message. You find that the super deprecated do not include field is mandatory; it's sent to some other service that thinks it's important. 10 minutes later, you fix your code, the RPC works, and you're on to the next thing. No meetings, no calls, no emails, no time zone coordination, no bugs languishing in some queue that you're not even sure it's the right one... just a solution!
I was really surprised how uncommon this is outside of Google. People will hit an issue with a library, file a bug, and just sit there blocked without ever opening up the malfunctioning code and reading through it. Why turn a one player game into a multiplayer game unless you really have to? Reading code is what you do for a living!
Like anything, it's a skill that you need to develop, but it's one that will make you really productive.
I find this difference also between people who grew up on open source vs proprietary software.
I'm nervous about running in production software I can't open up and look at how it works under the hood. I often use that ability to understand my systems better.
Some people just don't care about that. They're used to paying a support agreement and opening a ticket or calling a support rep instead. I will never get it but clearly that's how some people like to, or are at least used to, operate.
People do do this. The problem is the docs never get fixed and everyone needs to do what you just did. Great if you have essentially infinite money; otherwise bad.
To me documentation is largely a lost cause, it starts out behind the code and stays that way forever, because the machine can't execute the documentation. Yes, the human maintaining the code is more important than the computer running the code, but when you have an infinite number of tasks to get done, what the computer accepts is a pretty good stopping point for most people.
Personally I see a lot of value in documentation (that's how I learned the basics of programming and the systems I use), but since it's always out of date and wrong, I tend to undervalue it. Maybe that's a mistake.
So I guess the other side of the coin is that some people are very good at managing their vendors, internally or externally. This is another useful skill to learn. I'm not that good at it, but it's good to have both options in your toolbox.
FB is eons ahead of Microsoft in this regard. Their homogenous development experience eliminates tonnes of learning curve and busywork that you get with thousands of unique repos, build pipelines and and environments.
At Amazon, at least AWS, I as a consultant can ask any service team about features coming down the pike and the expected timeline. We can even share with customers with permission if they sign the appropriate NDA. As far as I know, MS is the same way. Enterprise customers want to be kept in the loop and we need to validate an offering and get customer feedback. AWS often makes changes to products before they are released publicly. That’s why you already have customer testimonials before a product is released.