Here is something nobody tells you when you join a new company. The org chart is a lie. Not a malicious lie. Just a polite fiction everyone agrees to maintain because it makes things easier to explain to new hires.
The org chart shows you boxes and lines. It shows you who your manager is, who your manager's manager is, and so on up to some VP whose calendar you will never get on. It describes the formal hierarchy — who has the authority to hire, fire, and set compensation.
What it does not show you is who actually decides things.
Those are two very different lists.
Authority is formal. Influence is real. The engineers who understand this early don't just survive in top orgs — they shape them.
The engineer who figures this out in year two instead of year eight has a completely different career trajectory. Not because they play politics. Because they understand how the system actually works and stop wasting energy fighting the wrong battles.
This chapter is about understanding that system.
01 / The Invisible Network The Org Chart Is a Map of the Wrong Territory
Every organization has two structures running in parallel. The first is the formal structure — titles, reporting lines, the hierarchy. The second is the influence network — who people actually listen to, defer to, and seek out when they need clarity.
The formal structure determines who can sign off on your offer letter. The influence network determines whose opinion shapes the roadmap, whose objection kills a project in a design review, whose approval you actually need before you walk into a meeting with your proposal.
These two structures overlap but are not the same. And here is the important part: in almost every organization, the influence network is more powerful than the formal structure for day-to-day decisions.
Imagine you want to get a new infrastructure initiative approved. You schedule time with your manager. Your manager says it sounds good, let's bring it to the team. You present it in the team meeting. Some people nod. One person — call him Ravi — asks a sharp question. You answer it. Ravi says "I'm not sure about this." And somehow, mysteriously, the initiative dies. Not in that meeting. But in the two weeks after, you notice the energy around it draining. Nobody kills it explicitly. It just stops happening.
Ravi is a Staff Engineer with no management responsibilities. He has no formal authority over your initiative. But he has influence. And you didn't understand that until it was too late.
Ravi's influence exists for real reasons. He has been at the company for six years. He has shipped things that worked and predicted things that failed. People have calibrated their judgment against his judgment and found him reliable. That track record is real. The influence it produces is real. The fact that it doesn't show up on an org chart doesn't make it less real.
The lesson is not to resent Ravi. The lesson is to find Ravi before the meeting.
02 / Finding the Real Network Who Are the Actual Decision Makers
The good news is that influence networks are not hidden. They are hiding in plain sight. You just need to know what to look for.
Here are the signals that reveal the actual power map in any organization. None of them require asking anyone directly. Just observe.
Spend your first 90 days in any new team or org doing this kind of observation deliberately. You are building a mental model — not to manipulate people, but to understand the actual terrain. A soldier who knows the map wins more than a soldier who doesn't. This is the same.
Notice something in that map. The formal authority holder — the Engineering Manager — is not at the top of the influence ranking. That's not unusual. Influence is earned through track record and relationships, not granted through job titles. The sooner you internalize this, the better your decisions will be about where to invest your energy.
03 / The Pre-Meeting Where Decisions Are Actually Made
Here is the thing most engineers get completely wrong about meetings.
They think a meeting is where a decision gets made.
It is not. A meeting is where a decision gets announced.
By the time a proposal hits the big room, its fate is almost always already decided. The meeting is a ratification ceremony, not a deliberation.
This sounds cynical. It isn't. It's just how humans work. Nobody wants to be surprised in a room full of people. Nobody wants to look uncertain in front of their peers. Nobody wants to make a commitment they haven't thought through just because a calendar event appeared. So people do their actual thinking — and their actual deciding — before the meeting. In 1-on-1s. In Slack threads. Over lunch. In the five minutes before standup.
The engineers who understand this do something very specific. They treat every formal meeting as the final step in a process, not the first. They do what we can call the pre-meeting.
Priya is a Senior Engineer who wants to propose migrating a critical service off a legacy data store. She knows this will be controversial. Some people are attached to the old system. Some people are worried about migration risk. The VP is nervous about downtime.
Two weeks before the proposal meeting, Priya has coffee with Ravi. She walks him through the plan, asks for his sharp questions, adjusts her risk section based on his concerns, and ends by saying "I'm going to propose this in the architecture review — would love your support if you think it's solid." Ravi says yes.
She then meets with her EM for 20 minutes, not to ask permission but to make sure there are no surprises — no context she's missing about why this was tried and abandoned before. She finds one. She adds a paragraph to the doc addressing it.
She pings the PM to understand if this creates any roadmap conflicts. It does. She adjusts the timeline in the proposal to avoid the conflict.
On the day of the meeting, Priya presents the proposal. Ravi says "I've looked at this and I think the risk section is solid." The PM says "the timeline works with our roadmap." The EM has no surprises. The VP sees a cohesive front. Decision made in 15 minutes.
Compare this to what most engineers do. They prepare a beautiful proposal. They put it in a doc or a deck. They walk into the meeting and present it fresh. Then they're surprised when people raise objections they hadn't anticipated, when someone says "wait, what about the X migration from 2022?", when the VP says "I'm not sure I'm comfortable with this timeline."
Those objections were not surprises. They were predictable. They were findable. The engineer just didn't go find them.
Before any proposal meeting, ask yourself: Have I talked to the highest-influence person on this topic? Have I talked to the person most likely to object? Have I talked to whoever owns the roadmap to check for conflicts? Have I talked to my manager to surface any context I'm missing?
If any answer is no, you're not ready for the meeting. You're ready to write a better pre-meeting agenda.
04 / Your Skip-Level's Reality What Senior Leadership Actually Cares About
At some point, your work becomes visible to people two or three levels above you. A VP. A Director. A Principal Engineer from a different org. And the engineers who make a strong impression on those people share one common trait: they speak the right language.
Here's the problem. Most engineers spend their careers optimizing their communication for their own level. They talk about technical elegance. They talk about latency improvements. They explain the implementation approach in detail. This works great with peers who share your technical context.
It doesn't work with your skip-level.
Your skip-level lives in a different reality. They own outcomes across maybe ten to twenty teams. They are measured on metrics you can barely see from where you sit. Their day is a constant triage of competing priorities, escalations, and decisions that must be made with incomplete information. They are not trying to be dismissive of your technical work. They are operating at a completely different altitude, and the view from up there looks nothing like the view from your desk.
So what is on that list? In almost every senior engineering leader's mental model, the concerns cluster into four buckets:
-
Are we shipping with predictable velocity?
Not "are we working hard" — are we shipping reliably. Surprises are expensive. Missed timelines erode trust with product and business partners. Engineers who help their skip-level predict the future accurately are very valuable.
-
Are there landmines I don't know about?
Every leader has been burned by a technical issue that blindsided them in a bad meeting. The engineer who surfaces these early — even when the news is bad — is a trusted operator. The engineer who hides them becomes a liability.
-
Is the team scaling or is it becoming a bottleneck?
As organizations grow, some teams become force multipliers and some become friction points. Leaders watch for this constantly. Show that your work unblocks others, not the reverse.
-
Are my best people engaged and growing?
Attrition is expensive and visible. Leaders remember the engineers who made the team better — not just technically, but in terms of morale, mentorship, and forward momentum.
When you walk into a meeting with your skip-level, or when you write a status update they'll read, or when you give a tech talk they'll hear about — your job is to answer one or more of those four questions. Implicitly or explicitly. That is what connects your work to what they care about.
An engineer presents a beautifully detailed plan for refactoring the authentication layer, complete with before/after latency benchmarks and a twelve-step migration plan. The VP says "looks good" and checks their phone. The engineer walks away thinking the VP wasn't engaged.
The VP wasn't engaged because nobody connected the work to the thing that's actually on their radar: three compliance requirements that are due before year-end and a hiring freeze that means doing this with existing headcount. The technical work was probably excellent. It was presented in the wrong language to the wrong person.
The fix is simple. Before any communication going upward, ask: why does this matter at their altitude? Not your altitude. Theirs. Translate the work. "This reduces incident rate by 40%, which means fewer pages for on-call engineers, which means less churn risk on the team you've been trying to retain." That's a sentence a VP can hear.
05 / Putting It Together The Power Map in Practice
Let's make this concrete. Here is a simple practice you can run in your first 60 days on any new team, or any time you feel like your influence is not matching your effort.
-
Draw the org chart — then draw the real one
Start with the formal structure. Then, using the signals from earlier in this chapter, annotate it. Who are the high-influence nodes? Who do people seek out? Whose objections stick? You're building a map. It doesn't need to be on paper. It needs to be in your head.
-
Invest in your first relationship with each high-influence node
Not networking in the awkward sense. Just genuine curiosity. Ask them about the problems they're trying to solve. Ask them where they think the team is underinvesting. Listen more than you talk. You'll learn things you can't learn from any doc or meeting. And they'll remember the engineer who actually wanted to understand their perspective.
-
Never walk into a high-stakes meeting cold
Every proposal, every design review, every planning session that you actually care about — do your pre-meeting. Talk to the skeptics first. Get their concerns in private, where they're less invested in their position. It's almost always possible to address concerns before they become objections.
-
Learn your skip-level's vocabulary
What are the three things they talk about most in all-hands? What is the one metric they keep referencing? What was the last major incident that affected their credibility? Connect your work to their world, not the other way around.
Engineers who do this work consistently don't just get better outcomes on individual proposals. They build a reputation. People start saying "talk to her before you finalize the plan." That reputation is a compound asset. It brings opportunity to you instead of requiring you to chase it.
The game is not about being Machiavellian. It is about being the engineer who understands the system clearly enough to work within it effectively — and eventually, to help shape it.
Chapter Summary What You Should Take From This
Organizations have two structures. The formal one is what you see on paper. The real one is built from relationships, track records, and repeated demonstrations of judgment. The real one is what actually drives decisions.
Decisions are not made in meetings. They are made before meetings, in 1-on-1s and side conversations, and then ratified in the formal room. The engineers who know this show up to every important meeting having already done the real work — not the slide work, the human work.
Your skip-level is not your audience for technical prose. They are your audience for a different story: one about reliability, risk, scale, and people. Learn to tell that story and your work becomes visible at the altitude where it can change your career.
You cannot change how decisions are made. But once you understand how they are made, you will never be surprised by an outcome again. And you will rarely lose a proposal you cared about.
The Real Org ChartThe engineers who reach Staff and Principal level didn't just do better work than their peers. They understood the terrain better. They knew where the influence actually lived. They built relationships before they needed them. They spoke the right language to the right people at the right altitude.
That's not politics. That's engineering — applied to the most complex system in your company: the organization itself.