The second one exists nowhere in writing. It lives in people’s heads — in the instincts of engineers who have been around long enough to know who you really need to talk to before a proposal goes anywhere. This is the shadow org chart, and understanding it is one of the more underrated career skills an engineer can develop.

What the Official Chart Actually Represents

Org charts are documentation of authority, not influence. They tell you who has formal power — who can hire, fire, promote, and approve budgets. That information is real and it matters. But it captures a snapshot of a single dimension of organizational life.

What it misses is everything informal: who the technical expert is that three teams quietly consult before making architecture decisions, which program manager is the actual connector between two organizations that are theoretically aligned but practically siloed, and which senior engineer has been at the company long enough that even VPs will run a contentious idea past them before taking it to a staff meeting.

The org chart is the skeleton. The shadow org is the nervous system.

Why Informal Power Structures Develop

Organizations are made of people, and people form relationships that predate and outlast any reporting structure. A manager who was promoted two years ago still defers to a peer who mentored them. An engineer who moved teams carries institutional knowledge and trust that their new org chart position does not reflect.

Tanya Reilly’s The Staff Engineer’s Path makes this point clearly: staff-level engineers need to understand not just the technical landscape but the organizational one. The ability to influence without authority — a phrase that appears often in conversations about senior technical leadership — is fundamentally a shadow-org skill. It only works if you know where the informal authority actually sits.

Expertise creates its own gravity. When someone becomes the go-to person for a particular system, a domain, or a type of problem, people route around the org chart to reach them. Trust networks form through repeated collaboration, especially in ambiguous situations where the org chart offered no guidance. Historical relationships — people who worked together through a reorg, a crisis, or a product launch — carry weight that no reporting line can fully convey.

The Types of Power That Never Appear on Any Chart

There are a few archetypes worth learning to recognize.

Decision gatekeepers are people whose approval or buy-in is required before something moves forward, even though they have no formal authority over it. This might be a security architect who hasn’t shipped code in three years but whose concerns can halt a launch.

Informal advisors are the people leadership quietly consults before making anything official. Their titles are often misleading. They might be an individual contributor with a decade of context, or a director who is technically peers with five others but whose read on a situation carries disproportionate weight.

Connectors hold the shadow org together. They know everyone, they understand each team’s actual priorities (not the stated ones), and they are often the fastest path between two groups that technically have a shared manager but practically never talk.

Blockers are their own category. These are individuals whose opposition — stated or unstated — can stall an initiative indefinitely. Ignoring them is almost always a mistake.

What It Costs to Not Know

The consequences of shadow-org blindness tend to be concrete and painful. An initiative that needed sign-off from a particular team lead stalls because the engineer driving it escalated to the wrong person. A proposal gets shot down in a staff meeting because the informal advisor whose concerns were never addressed chose that moment to voice them publicly.

Missed alignment is probably the most common failure mode. Two teams are nominally working toward the same goal but the engineers who actually have influence over each team’s direction have never been in the same room. The official structure suggests this should be fine. The shadow org makes clear it isn’t.

How to Start Mapping It

Observation is the first tool. Watch who speaks in large meetings — not who is called upon because of their title, but who volunteers information and whose contributions visibly shift the conversation. Watch who gets thanked in all-hands updates. Both patterns point toward informal influence.

One-on-ones are the best research instrument available. When meeting someone new, asking “who else do you think I should talk to about this?” generates a map of consultation networks faster than any org chart crawl. The people who keep appearing in these referrals are usually load-bearing nodes in the shadow structure.

Pay attention to who gets consulted before decisions go public. There is almost always a pre-meeting before the meeting — a round of informal calls or Slack conversations where the real debate happens. Noticing who is in that circuit, and eventually being in it yourself, is how influence compounds over time.

Watch where escalations actually land. When something is stuck, where do people take it? The answer is often a person, not a process — and that person’s real organizational weight becomes visible in how quickly the problem moves afterward.

The Map Is Never Finished

Shadow org charts are not static. They shift when people leave, when teams merge, when someone builds trust through a high-stakes project or loses it through a public misstep. The engineer who was a key node two years ago may be largely invisible today.

The work of mapping it is therefore ongoing, not a one-time exercise. It requires staying curious about people — their history, their relationships, their areas of real expertise versus nominal responsibility.

The engineers who navigate organizations well are rarely the ones who read the official chart and followed it literally. They are the ones who understood that the chart describes one kind of organizational reality, and built the patience to understand the other kind too.