Deciphering organizational structures: Formal vs. informal hierarchies

Your first week in a new company often feels like walking into a building where you know the address but not the floor plan. You have a job title, a manager, and a team. But the question that quietly shapes your early decisions is simpler: who actually decides things here? Yet here's the exciting part: you're not just a newcomer lost in the maze — you're a detective with a unique advantage. Every conversation, every meeting, every hallway chat is a clue waiting to be decoded. The organizations that thrive are the ones where people learn to read both the visible map and the invisible one. And you, starting fresh, have the rare opportunity to build that understanding from day one — not as a burden, but as your superpower. The floor plan may be unfamiliar, but the ability to navigate it is exactly what will set you apart.

The formal answer is usually an org chart. It shows boxes and lines: who reports to whom, which department sits under which division, and where the chain of command begins and ends. Most companies use one of three models to draw those lines.

Functional structures group people by what they do. Marketing sits together, finance sits together, engineering sits together. Authority flows up through a single functional leader. This model is efficient for specialization: you become excellent at your craft because everyone around you does the same craft. The trade-off is that cross-functional work requires climbing up the ladder and back down again.

Divisional structures organize around products, geographies, or customer segments. Each division runs its own mini-company with its own marketing, finance, and engineering teams. Authority is decentralized: a product division leader can make decisions without waiting for a central functional head. This speeds up execution but can duplicate resources and create inconsistent practices across divisions. Matrix structures try to get the best of both. You report to a functional manager and to a project or product manager. Two bosses, two sets of priorities. This model maximizes flexibility and resource sharing, but it also creates the most ambiguity. When both managers want your time, the formal chart doesn't tell you who wins — the informal dynamics do. Here's the part that matters for your first 30 days: the org chart tells you who can decide, not who does. Every company has a second map, drawn in conversations, calendars, and hallway chats. It shows who gets consulted before a decision is announced, whose opinion carries weight even without formal authority, and which managers actually control the budget versus merely approving it.

The practical skill here is reading both maps at once. Formal structure tells you where to route a request. Informal structure tells you who to talk to before you route it. A new hire who only follows the chart gets technically correct answers and slow progress. A new hire who reads both gets decisions made faster, because they've already addressed the concerns that would have stalled the request.

Mapping the decision-making flow across departments

Imagine you need a small budget increase for a client-facing tool your team is building. You know your manager approves it. But the money comes from a shared pool, and the tool touches data that another team owns. Suddenly your simple request has three stakeholders, two approval gates, and a timeline you can't control. This is the reality of cross-functional work: decisions rarely live inside one department. They move through a chain of dependencies, and understanding that chain is what separates a smooth request from a stalled one.

Most companies follow a similar pattern. A proposal starts with an initiator — usually the person closest to the problem. They draft the idea, gather initial data, and socialize it with their immediate team. This is the informal phase: testing whether the idea has legs before anyone commits resources. Next comes the functional review. The initiator's manager evaluates the proposal against team priorities. Does this align with what we're already doing? Do we have capacity? This gate filters out ideas that are good but not aligned. It's often the fastest gate, because the manager already knows the team's context. Then the proposal enters cross-functional consultation. This is where the map gets interesting. The proposal now touches other departments: finance checks the numbers, legal checks the risks, operations checks the feasibility. Each of these stakeholders has their own priorities and constraints. A proposal that looks perfect from marketing's perspective might be impossible from operations' perspective. The consultation phase is where those tensions surface and get resolved — or not.

Finally, the approval gate. Depending on the size of the decision, this could be a department head, a steering committee, or an executive. The approval is often a formality if the consultation phase went well. But if stakeholders raised concerns that were ignored, the approval gate becomes the place where the proposal dies.

The skill to build here is dependency mapping. Before you submit anything, ask: who else does this touch? Who has data I need? Who will feel the impact of this decision? Who has veto power, even if they're not on the approval chain? Write those names down. Talk to them before you formalize the request. The decision-making flow isn't a straight line from idea to approval — it's a network of conversations, and the conversations are where the real work happens.