Org Boundaries and Political Gravity

Here is something nobody tells you when you become a principal engineer: the technical part of your job was the easy part. Not easy as in simple — you worked hard to get here. Easy as in it had right answers. A query either runs in 40ms or it doesn't. A service either handles 10,000 requests per second or it falls over. You can measure, test, profile, and prove.

The human part of your job doesn't work that way. And as your projects get bigger and more important, the human part gets proportionally larger. A project that crosses three team boundaries doesn't have three times the coordination overhead of a single-team project. It has ten times the overhead. Because it's not just the work that scales — it's the number of competing interests, the number of people who feel threatened, the number of invisible rules you don't yet know you're breaking.

This is what org politics is. It's not backstabbing. It's not manipulation. It's not a dirty game played by bad people. It's the natural result of putting a lot of smart people in an organization with limited resources, overlapping responsibilities, unclear boundaries, and different ideas about what matters. Politics emerges the same way traffic jams emerge — not because anyone wanted it, but because the system produced it.

The engineers who ship large, cross-org projects understand this. They've stopped being surprised by political friction the way a physicist stops being surprised by friction in a mechanical system. They've started treating it as a force to understand and work with, not a malfunction to complain about.

This chapter gives you that understanding.

What Political Gravity Actually Is

Think about gravity for a moment. It doesn't care about your intentions. You can be carrying something wonderful — a gift for someone, a piece of equipment that will save lives — and gravity will still pull it toward the floor if you drop it. It's not personal. It's physics.

Political gravity works the same way. It's the tendency of organizations to resist changes that threaten the existing distribution of power, resources, headcount, and recognition. It doesn't care that your project is technically excellent. It doesn't care that your intentions are good. It will pull your project off course unless you account for it.

Here's the most important thing to understand: most political resistance is not malicious. The people pushing back on your project are usually not trying to sabotage you. They're doing what every organism does when it perceives a threat: they're protecting themselves. Their team. Their budget. Their reputation. Their sense of ownership over something they've spent years building.

When you understand this, everything changes. You stop taking resistance personally. You stop seeing the people blocking you as enemies. You start asking a different question — not "why are they being difficult?" but "what do they feel threatened by?" — and that question has an answer you can actually work with.

This is political gravity at work. The solution isn't to overrule them — that creates an enemy who will find ways to cause problems for years. The solution is to figure out what they actually need (recognition, a role in the new system, reassurance that their team won't be dissolved) and address that. We'll come back to how.

The Org Chart Under the Org Chart

Every company has two org charts. The official one — the one in the HR system — shows reporting relationships and team structure. The unofficial one shows how things actually get done. These two charts overlap but they are never identical.

The unofficial org chart is made of influence, not authority. It answers different questions: Who do people actually go to when they need a decision? Whose opinion changes other people's opinions? Who knows where the bodies are buried? Who has the trust of the people who matter? Who has been here long enough to remember why things are the way they are?

On the official org chart, a person might be a Senior Engineer. On the unofficial one, that same person might be the technical conscience of the entire division — everyone knows not to ship something without running it by them, even though their title carries no authority to block anything. Ignore them on your project at your peril.

Conversely, someone else might have an impressive title — VP of Engineering, Director of Platform — and carry very little informal influence. Maybe they're new. Maybe they've made bad calls. Maybe they're not engaged. Their approval matters for process, but their endorsement won't actually move people.

Working on large projects without a map of the informal org chart is like navigating a city with a subway map when you're driving. The subway map isn't wrong — it describes something real — but it's the wrong map for your situation.

Four Types of Power in an Organization

To build your informal map, you need to understand where power actually comes from. There are four main sources.

Most large-project failures involve underestimating one of the last three types. Teams secure positional approval — they get the VP to sign off — then get surprised when someone with expertise power, relational power, or informational power quietly kills the project anyway. A VP can authorize a migration. They cannot make five skeptical tech leads change their minds. Those tech leads are their own kind of powerful.

How to Map the Informal Org Chart

You can't read this map. You have to build it, over time, through observation and conversation. Here's how.

Watch who's in the room when decisions actually get made. Not the official decision meetings — the ones after the meeting, in the hallway, in a side Slack thread, in a one-on-one. Who gets included in those? That's your real decision-making cluster.

Listen for who gets cited. When people are debating an approach and someone says "well, [name] thinks..." and the room shifts slightly — that name is carrying informal authority. Track those names. They're your informal influencers.

Ask who to talk to. Before you go into any new team territory, ask someone you trust: "If I want this initiative to succeed with that team, who are the two or three people I need to genuinely align with?" The answer is almost never the manager. It's usually a senior IC, a veteran who's been there forever, or the person everyone respects even though nobody can quite explain why.

Follow the skepticism. When a proposal circulates and comes back with concerns, trace those concerns to their source. Where do they originate? Who amplifies them? The center of gravity of the skepticism tells you whose concern you actually need to address.

The Five Forces Acting on Your Project

Once you understand where power comes from, you need to understand what specific forces that power gets used to protect. Large cross-org projects collide with five invisible forces. Each one is predictable. Each one can be worked with once you can name it.

Force 1: Turf Protection

Organizations divide work into territories. Teams own services, products, or domains. Those territories are not just technical — they're also social. Owning a critical system is a source of status, leverage, and job security. It means your team matters. It means other teams need you.

When your project crosses into another team's territory — even if you have good reasons, even if the current owner will admit in private that the boundary doesn't make sense — you're triggering an ancient instinct. Animals mark and defend their territory not because they're evil but because territory equals survival. The same thing happens in companies.

Turf protection manifests as process objections ("we need a full design review before you touch anything in our domain"), technical objections ("our system has complexity you don't understand"), and timeline objections ("we don't have bandwidth to support this right now"). None of these are lies exactly — they often contain real concerns — but they're being raised now, with unusual vigor, because of what's underneath: this team is worried about what happens to them if you succeed.

Force 2: Budget Gravity

Every large initiative comes with resource implications — headcount, infrastructure costs, opportunity cost of things you're not doing. Budget is how orgs translate priorities into action, and it is always scarce. When your project would require another team to spend some of their budget — or absorb some of their team's time — you're asking them to de-prioritize something they've already chosen to prioritize.

This force is subtle because it often doesn't show up as a direct "we don't want to spend the money." It shows up as questions about scope. "Is this truly necessary? Could we do something lighter?" What that question is really asking is: "Can you reduce the tax you're putting on my team?"

Budget gravity is strongest at the end of fiscal years, during planning cycles, and whenever the broader business is tightening up. Understanding the budget calendar of the teams you depend on is not just useful project management — it's essential org navigation.

Force 3: Narrative Control

In any large organization, there are competing stories about where the company should go, what the priorities should be, and who should be leading what. Your project is not just a technical initiative — it's part of a narrative. And narratives have authors who guard them.

When your project lands in a space where the narrative is already owned, you will face friction that looks technical but is actually about story. The team that has been telling leadership "our platform is modern and capable" will resist a project that implicitly tells a different story — that the platform has gaps. Not because they're dishonest, but because the narrative they've been building is load-bearing for their team's reputation and roadmap.

This force is why the framing of your project matters as much as its content. "We are replacing the old authentication system because it's bad" is a narrative that threatens the team who built it. "We are extending the authentication platform to support new use cases it was never designed for" tells a different story — one that includes the original builders as heroes rather than failures.

Force 4: Legacy Loyalty

Some systems, processes, or approaches have been around long enough that they've become part of the identity of the people who built or maintained them. These things attract a particular kind of devotion that is hard to reason with — not because the people are unreasonable, but because you're asking them to evaluate something with both hands tied behind their back. They cannot be objective about a thing they helped create.

Legacy loyalty is most powerful when the original builders are still in the building. The engineer who designed the old data pipeline in 2014, who is now a Staff Engineer and has a lot of credibility, will defend that pipeline in ways that seem irrational from the outside. The pipeline is their work. Criticizing it feels like criticizing them.

The right move is not to argue about the pipeline. It is to honor what the pipeline accomplished — because it did accomplish something, or the company wouldn't have survived long enough for you to be here — and then make the case for what comes next in terms of what new problems need to be solved. You're not replacing the pipeline because it was bad. You're building the next thing because the world changed.

Force 5: Credit Anxiety

In most companies, career advancement is tied to visible impact. This creates a force that operates below the surface of almost every large project: who gets credit for the success?

People who would otherwise want to help your project will be less enthusiastic if they can't see how their contribution will be recognized. This isn't greed — it's rational behavior inside a system that measures contribution and trades it for opportunity. When someone is weighing whether to invest their team's time in your project versus something that more clearly benefits their own roadmap, credit visibility matters.

This force is why you should be proactive about acknowledgment. Be specific and public about what other teams contributed. Don't just list them in a footnote — go out of your way to make their contribution legible to the people who influence their careers. When you write your project retrospective, when you present at an all-hands, when you send the launch email: name names. Specifically. With context for why it mattered.

Building Alliances Without Looking Political

Here's the irony of org politics: the engineers who navigate it best rarely look like they're doing anything political at all. They look like they're just being good colleagues. Because at the deepest level, that's what effective org navigation actually is — being the kind of person that people want to succeed.

Alliance building is not the same as schmoozing. It's not about lunches and flattery. It's about building a track record of behavior that makes people trust you with their interests, not just your own. That track record is built through specific, consistent actions over time.

Give Before You Ask

The most common mistake engineers make when they need something from another team is that they lead with the ask. They show up in someone's Slack DM with a request. They schedule a meeting to explain what they need. They're surprised when the response is lukewarm.

The people who get help reliably are the people who have already given help. They reviewed that team's RFC six months ago and gave genuinely useful feedback. They flagged a bug in that team's service when they saw it in the logs, even though it wasn't their responsibility. They shared data from their system that another team needed, without waiting to be asked twice.

This is not strategic — or rather, it's only strategic if you do it cynically, which defeats the purpose. It works because it's genuine. You're actually being a helpful colleague, and that changes how people feel about you. When you eventually need something, you're not a stranger making a cold request. You're someone who has demonstrated that they care about collective success, not just their own project.

The best political move you can make is to spend six months before your project starts being the most genuinely helpful person in your org. Then when you need help, it doesn't feel political at all — it feels like friends helping a friend.

The Shared Enemy

Nothing unites people faster than a problem that hurts everyone. If you're working on an initiative that addresses something multiple teams are all quietly suffering through — a fragile shared service, a painful manual process, a gap in observability — you can use that shared pain as the foundation of an alliance.

The move is to surface the shared enemy before you pitch your solution. Start by listening. Ask different teams to describe their biggest pain points. When you hear the same pain described three different ways by three different teams, you've found your shared enemy. Then you can build a coalition around solving it — and your project becomes the vehicle for something everyone already wants, rather than something they're being asked to support.

This changes the political dynamics completely. Instead of one team trying to get resources from other teams, you have multiple teams with aligned interests pooling resources to solve a common problem. That's much easier to sustain through the inevitable friction of a large project.

Finding and Keeping Sponsors

A sponsor is different from a stakeholder and different from a champion. A stakeholder cares about the outcome. A champion advocates for the project. A sponsor uses their own political capital on your behalf. They go into meetings you're not in and make the case for your project. They unblock things quietly, before they even become visible problems to you. They tell you what they're hearing in the room so you can course-correct before it's too late.

Every large cross-org project needs at least one genuine sponsor. Without one, you're pushing uphill against the natural resistance of the org with no one at a higher level clearing the path.

Finding a sponsor is not about finding the most senior person willing to put their name on your project. It's about finding someone who genuinely believes in what you're building and who has the political standing to act on that belief. Two questions help you identify the right person:

• Do they have standing with the people you need to influence? A VP who is respected by other VPs is worth more than a VP who is tolerated by them. An informal influencer who is trusted by the tech leads you need to align is worth more than a formal authority who those same tech leads dismiss.
• Are they willing to spend capital, not just lend their name? Some people will agree to be listed as a sponsor but won't actually do anything. Others will proactively reach out, raise issues in forums you can't access, and put their reputation on the line for you. The second kind is rare and worth enormous effort to find and keep engaged.

Keeping a sponsor engaged is its own discipline. Give them just enough information to stay informed without overwhelming them. Brief them before they go into any meeting where your project will come up. Tell them specifically how to help when there's something you need them to do. Thank them publicly and specifically. And be honest with them about problems — sponsors who are surprised by bad news become unreliable sponsors very quickly.

Working the System vs. Challenging It

At some point in every large project, you will face a moment of decision: do you work within the existing system to make progress, or do you push back against the system itself?

The existing system — the process requirements, the approval chains, the decision-making structures — exists for reasons. Some of those reasons are good: they prevent bad decisions, ensure accountability, catch things that fall through the cracks. Some of those reasons are obsolete: they solved a problem that no longer exists, or they made sense at a smaller scale and never got updated. And some of them are just inertia: nobody particularly likes them, but nobody has pushed hard enough to change them.

Your job is to figure out which is which. This requires intellectual honesty that is harder than it sounds, because there's a strong temptation to classify anything that slows you down as "bureaucracy" and anything that helps you as "valuable process."

There is a third option that feels appealing but is almost always the wrong choice: going around the system secretly. You skip the review because it'll take too long. You get informal approval from someone but don't go through the formal channel. You make the change and ask forgiveness later.

This feels efficient. It is not. Organizations have long memories. The people whose process you bypassed remember. Even if your project succeeds, you've created a reputation as someone who can't be trusted to follow the rules — which means that on your next project, you'll face more scrutiny, less trust, and more friction than you would have if you'd just done it right the first time.

The Three Political Landmines

In fifteen years of watching large projects succeed and fail, there are three specific patterns that blow up technically sound projects through political failure. Each is predictable. Each is avoidable. But you have to know to watch for them.

Landmine 1: Surprising the Wrong Person

There is a special category of bad discovery: the powerful person who finds out about your project from someone other than you, when the project is already too far along for their input to change anything. Maybe it's the VP whose team is directly affected. Maybe it's the principal engineer whose domain you're walking into. Maybe it's the person who owns the roadmap you're now competing with.

When this person finds out about your project — not from you, not early, but through the grapevine after you've already made commitments — they experience two things at once: the concern they would have raised anyway, now mixed with the sting of being excluded. That combination is far harder to recover from than the concern alone.

The rule is: identify every person who could be surprised and unhappy, and loop them in early. Not to get permission — you don't need permission from everyone. But to give them the dignity of being consulted rather than the indignity of being surprised. There's a huge difference between someone raising concerns in a productive conversation two months before launch and someone raising concerns as blockers two weeks before launch.

Landmine 2: Winning the Argument and Losing the War

Engineers are good at arguments. We accumulate data, we build logical cases, we identify flaws in opposing positions. In a purely technical domain, this is a superpower. In a cross-org political context, it can be destructive.

When you win an argument against someone in a public setting — in a meeting with their peers, in a design review, in an all-hands Q&A — you may get what you wanted in that moment. But the person you defeated will remember it. The people who watched it will have registered it. And the next time you need something from that person's team, you'll face a headwind that you can't fully explain because nobody will say "we're being difficult because you embarrassed our team lead in front of her director six months ago."

The discipline here is to give people room to be right. When someone is raising an objection that you think is wrong, your first move should not be to dismantle it. Your first move should be to steelman it — to find the most legitimate version of their concern and address that version. Most of the time, there is a legitimate version. Addressing that first shows that you took them seriously. It often reveals a real issue you hadn't fully considered. And it makes the person far more likely to update their position, because they don't feel like they're losing — they feel like they've been heard.

Landmine 3: Org Change Without Org Buy-In

Some projects don't just change technology. They change how teams work, which teams own what, and what skills are valued. These projects carry a special kind of political weight because they're not just technical changes — they're organizational changes. And organizations resist changes to their structure the way bodies resist foreign objects.

The failure mode is treating org impact as a side effect rather than a primary concern. Engineers focus on the technical design, do thorough eng review, get leadership approval — then discover that the affected teams never really bought in, because nobody asked them to. The technology lands, the org doesn't change with it, and the project fails in practice even though it "succeeded" on paper.

If your project will change who owns what, how teams interact, or which skills matter, you need explicit, sustained org change management. That means: telling the affected people clearly and early what will change, giving them a voice in how it changes, being honest about what's hard about the transition, and following through on commitments about resourcing and support through the change period.

Staying Clean

Everything in this chapter is about how to navigate org politics effectively. None of it requires you to become the thing you're trying to navigate.

There's a version of being good at politics that involves information manipulation, selectively sharing information to create impressions, building alliances to marginalize competitors, saying different things to different people. This version works in the short run and destroys careers in the medium run. Companies eventually figure out who operates this way. Once they do, that person's influence collapses — because everything they say gets interpreted through the lens of "what are they trying to get from me?"

The version of political effectiveness that lasts — the version that actually gets large important projects built — is built on a foundation of radical honesty about the work. You can be strategic about timing, about framing, about who you talk to first. But you cannot be strategic about the facts. What your project can and cannot do. What you know and don't know. What the risks are. What other teams would need to contribute.

This honest foundation is not just morally correct — it's strategically correct. It means that when things get hard (and they will get hard), the people around you know they're getting the real picture. That's rare and valuable. It makes you the person that leaders want involved in their hard problems. It means that when you say a project will succeed, people believe you — because you've been the person who told them the truth when the answer was "I'm not sure" or "we're at risk" or "we need to change the plan."

The long-game strategy in any large organization is to be the person who builds things that matter, treats people with integrity, and gets increasingly hard problems thrown at them because they've shown they can handle the hard ones. Org politics is the context in which that work happens. It is not the work itself.

Navigate it. Don't become it.