Here be dragons
I'm Brian Duff, a Scot 🏴 living and working in the California Bay Area. I've worked, written, and presented about technology since the 90s.
My journey with computers started in the 80s while playing Manic Miner and hacking BASIC on the Sinclair ZX Spectrum.
I'm currently a Distinguished Engineer at LinkedIn. Previously, I was a Principal Engineer at Google. Before Google, I worked on Engineering Effectiveness at Twitter, and then before that, led Mobile Developer Experience at Facebook. Prior to that, I worked at Google leading projects and teams on a large number of things for many years, including Nearby, Cloud SQL, Bazel, and Google+. My first job out of university was at Oracle, where I built IDE frameworks for a living.
When you first join a new org or company, draw a map.
Months into some roles, I've made faulty assumptions due to my understanding of organizational relationships. I'd wonder why a function was inefficiently split across two orgs, only to find that it gained a different kind of efficiency with that split. I'd ponder why there was no team to solve some problem, when in fact there was, but they weren't solving it, just "licking the cookie".
I'm working on getting better at drawing organizational maps. It's just a bunch of diagrams, notes, and annotations about who does what at an individual and team level, and how things are related.
Figure out where the unexplored territories are. Identify who to talk to in those teams. Mark up parts of it with "here be dragons" based on the conversations you have. Form questions to ask, or ideas about taming the dragons. Your first versions of the map will look like a crude cave picture six months from now. The orgs and people will change. It's ok - keep revising the map as you learn more.
There's usually more than one way to visualize the teams and individuals that make up an organization. Don't be satisfied with org charts alone as a primary structure. The real value is in the "shadow graph" through which influence and support flow.