Working in a Big Corp: Alignment, Process, and Getting Things Done at Scale

The first thing that surprises people who join a big company from a smaller one isn't the perks or the org chart. It's how little of the system any one person controls — and how well it still works anyway. You arrive expecting inefficiency, and you find a machine that ships reliable software to millions of people, runs by rules you didn't write, and would barely notice if any single engineer disappeared for a month.

That's not an insult; it's the design. A big corp is optimised for scale and reliability, not for any individual's speed. Once you understand that, the things that feel frustrating at first — the meetings, the approvals, the documents — stop looking like bureaucracy-for-its-own-sake and start looking like the price of operating at scale. This is a practical guide to working well inside that machine: where your work fits, why alignment is the real job, how to actually ship, and how to grow.

It's the first deep-dive after the overview comparing big corp, startup, and outsourcing — so here we go all the way in on the enterprise.

What "big" actually changes

Scale doesn't just add more people; it changes the physics of the work. Three things flip:

• Blast radius. A bug you ship can affect millions of users, other teams' systems, revenue, or compliance. The cost of "move fast and break things" is no longer a shrug — it's an incident review.
• Coordination cost. With dozens of teams touching shared systems, the expensive part isn't writing code — it's making sure your change fits everyone else's. Communication, not typing, becomes the bottleneck.
• Permanence. People rotate, but systems live for a decade. Decisions have to be legible to engineers who aren't born yet, which is why so much gets written down.

Almost everything that's distinctive about big-corp life follows from those three. Hold them in mind and the rest stops being mysterious.

Where your work fits: the planning hierarchy

In a startup you often see the whole board. In a big corp you see your square of it, and the board is large. Work descends through layers:

By the time a ticket reaches you, the "why" sits several layers up. This is the famous double edge of corporate life: clarity at the cost of distance. You rarely have to wonder whether your work matters — someone decided it does — but you can lose sight of how it matters. The engineers who thrive deliberately climb that ladder in their heads: they read the OKRs, ask which objective their epic serves, and reconnect their daily tickets to a customer outcome. That single habit separates people who feel like cogs from people who feel like owners of a small but real piece.

Alignment is the real job

Here is the thing nobody tells you before your first enterprise role: a large share of senior engineering work is not coding. It's alignment — getting many people to agree on an approach before anyone builds it. That's not a failure of efficiency; with high coordination cost, alignment is the efficiency. The alternative — everyone building their version and reconciling later — is far more expensive.

Alignment runs on written artifacts, because writing scales and meetings don't:

The same instinct shows up in code review, where a clear pull request is itself an act of alignment — see How to Write a Great Pull Request. At scale, your writing is your reach.

Process isn't (only) bureaucracy

The gates that feel like friction usually exist because something expensive went wrong once. A security review exists because a breach cost millions. A change-management step exists because an unreviewed deploy took down payments on a holiday. A formal QA stage exists because a regression reached customers who can't tolerate it.

That doesn't mean all process is justified. Plenty of it is cargo cult — ritual copied from a context where it made sense into one where it doesn't, defended by "that's how we do it here". The skill is telling the two apart:

• Earned process protects against a real, costly, plausible failure. Respect it, and learn the reasoning so you can navigate it fast.
• Theatre protects against nothing measurable and mostly produces status updates. Question it — politely, with data, through the right person — and you'll be one of the people who makes the org better instead of just complaining about it.

Deep, narrow, and dependent on others

In a big corp you usually own a slice — a service, a subsystem, a domain — and you own it deeply. The flip side is that you depend on specialist teams for everything outside that slice: SREs for production, DBAs for data, a platform team for infrastructure, a design-system team for UI, security for sign-off, a release team for the path to production.

This is efficient, but it means a surprising amount of your effectiveness comes from working across boundaries: knowing who owns what, building relationships before you need favours, writing tickets other teams can act on, and respecting their queues and constraints. Engineers who treat other teams as obstacles get stuck; engineers who treat them as partners get unblocked. If you came from a startup where you just did the database change yourself, this is the biggest adjustment — and learning to hand off well is a real skill, not a downgrade.

How to actually ship inside the machine

Shipping in a big corp is less about raw coding speed and more about navigation. A few tactics that consistently work:

• Find the real decision-makers. The org chart tells you titles; the work tells you who actually unblocks things. Identify them early and bring them in before you've built the thing, not after.
• Write the doc first. A one-page proposal surfaces objections while they're cheap to address and creates a record that protects you later.
• Make changes small and reversible. Feature flags, incremental rollouts, and backward-compatible steps move faster through review chains than big-bang changes, because they're lower risk to approve.
• Pre-socialise, don't ambush. Walk the key reviewers through your plan in advance. A review meeting should confirm an agreement, not be where people hear your idea for the first time.
• Respect other teams' queues. Give dependencies lead time. "I need this today" to a team that plans in sprints will fail; the same ask two weeks out succeeds.

Stakeholders and politics — the healthy kind

"Politics" has a bad name, but in a large org it's unavoidable and not inherently dirty. Healthy political skill is simply this: understanding what different people care about and helping align it. Your work affects a product manager's roadmap, another team's reliability, a director's OKR. Making those interests visible, and showing how your plan serves them, is how things get approved and funded.

The toxic version — taking credit, hoarding information, undermining peers — exists too, and it's worth naming so you can avoid practising it and recognise it when it's aimed at you. But don't confuse stakeholder management with manipulation. Done with integrity, it's just the senior version of teamwork at scale.

The failure modes to watch for

Big companies have characteristic ways of grinding people down. Knowing them is half the defence:

How to grow here

Big companies usually have the clearest career ladders of the three worlds — defined levels, written expectations, and calibrated promotions where a committee, not just your manager, reviews your case. That's a gift: the rules are legible. To climb them:

• Increase your scope of impact, not your hours. Promotions track the size and breadth of problems you own — from your task, to your team, to across teams.
• Make your impact visible. In a large org, work that isn't communicated may as well not exist. Write the doc, give the demo, share the win (and the credit).
• Build a track record of landed cross-team work. The behaviour that gets rewarded — driving alignment and reducing risk — is exactly the senior skill set.
• Find sponsors, not just mentors. A mentor advises you; a sponsor argues for you in the room where promotions are decided.

If after all this you find the pace too slow or the distance from the customer too great, that's useful self-knowledge — it might mean a startup or the variety of outsourcing fits you better right now. None of these is a one-way door.